Session PEERing for Multimedia INTerconnect (Speermint) Stockholm, Sweden Friday, July 31, 2009 @ 1300 - 1400 (and -- if needed -- 1415 - 1515*) Room Name: Large Stage ============================================================================================== CHAIRS: Jason Livingood Daryl Malas SECRETARY: Alexander Mayrhofer RAI AREA DIRECTORS: Cullen Jennings Robert Sparks RAI AREA ADVISOR: Cullen Jennings Document Progress ================= Jason provided a progress update of the WG: CURRENT DOCUMENT STATUS: - done - 1 - Terminology: RFC 5486 2 - Requirements: RFC Publication Requested (In Last Call) 3 - IM & Presence Use Cases: RFC 5344 4 - VoIP Use Cases: RFC Publication Requested (In Last Call) - still in process - 5 - Architecture: -09 6 - Flows: -06 7 - DNS SRV and NAPTR: -06 8 - VoIP Threats: -01 - There was a design team meeting between IETF 74 and 75 held on June 3. Almost all of the time was used to edit documents etc. The participants went through section by section of documents, discussed and applied changes on the spot. All results from that design meeting are or will be updated soon in documents. The next interim design team meeting is scheduled for Oct 19, since the previous interim meeting was very productive. Peering Architecture Draft ========================== draft: http://tools.ietf.org/wg/speermint/draft-ietf-speermint-architecture-09 Presenter: Sohel Khan (on behalf of Adam Uzelac, who could not be at the meeting) current version is -08 - version -09 will reflect updates from the design team meeting, plus input received during IETF 75. Section 1 - No comments Section 2 - Conclusion it does not serve a useful purpose - removed Section 3 - (now section 2 because of the removal of section 2) - changed the reference architecture figure. Removed all text after the figure. Added a new sub-section that describes various relations between functions and communication paths. Section 4 - Editorial modifications to the interdomain SSP Session Establishment steps. Section 5 - Many changes in details. General: New co-author list The new version will be published as soon as possible. There were no comments from the audience. Security Threats Draft ====================== draft: http://tools.ietf.org/html/draft-ietf-speermint-voipthreats-01 Presenter: Jan Seedorf Goal of the document: list security threats that are specific to SPEERMINT. This is an informational document. Changes: Security Requirements have been moved from this document to the Speermint Requirements draft. Comments received since IETF 73: - minimization of SED should be in - text regarding password cracking was misleading - digest auth on all requests was considered unrealistic - the countermeasures section was restructured. New threats were added: "network discovery" and "unwanted requests", plus respective proposed countermeasures. Proceeds to List of suggested countermeasures - only the last two are needed to meet the requirements (eg. TLS), while others are not necessary to fulfill reqs. Hadriel Kaplan: PKI is assumed for TLS? Jan: people asked about it, there's no text saying that PKI is assumed. Cullen Jennings: mignt not necessarily need root, local certs may be ok too. Jon Peterson: make clear how this can benefit from PKI. shared secrets might even be a use case sometimes, so ... There's some discussion about how the deployment model affects PKI, shared password, etc. Jan explains: Regarding passwords: there was text that peers should do digest, and that was removed, because it was deemed unrealistic. There is more discussuon about: IPsec vs TLS? Jan poses a question to the group - What shall the draft say? "both is fine" or "you should do at higher level" Hadriel: From tech perspective, TLS is better because the application knows. (sighs) Hard question, might not be the "real" thing, though. Jon: Hadriel has a good point - difference between *demonstrating* security and not knowing - TLS couples it into the application, while IPsec is a opaque "bump in the wire" that might be misconfigures without the app knowing. Cullen: MS voice.net stuff used IPsec, and exactly that happened - if sometimes goes wrong, you don't know, and you don't notice. Jon: Suggestions: Document what we just said. "apps out there, but TLS seems to be the better choice". Section on deployment issues - any other countermeasures that are not yet deployed besides DNSSEC? Peter Koch: DNSSEC will be more important for the LUF rather than LRF. Jan: Intention of the section is just to list protocols where deployment is ongoing. Peter Koch: Deployment of LRF/LUF itself is ongoing. Hadriel: LRF might also be DNS - eg. private ENUM lookups. No further comments, Jan requests to post comments on the List! Message Flows Draft =================== draft: http://tools.ietf.org/html/draft-ietf-speermint-flows-05 Presenter: Hadriel Kaplan Unfortunately the update was not submitted, but there were changes. The structure was moved around a bit - basic (static/dynamic), inconsistencies in terminology were cleaned up, and the diagrams were made clearer. There were not really many changes, but diffs look massive because lots of things have been moved around in the draft. Interconnect Guidelines ======================= draft: http://tools.ietf.org/id/draft-hancock-sip-interconnect-guidelines-01 Presenter: Jean-Fran¨ois Mulˇ Goal: Reduce the costs related to interconnect establishment Major changes to the document: Section 4.1 - Previous version indicated what SBEs should do in the "Supported" header. comment was that an SBE cannot add a SIP extension that the source UA might not understand. "Supported" can only contain what sending UA understands Section 4.2 - Changed "sip" and "rn" from uppercase to lowercase, missing country code (assuming = +1) seemed too NANP centric - removed Section 5.1.2.1 - Had inconsistency with 5.4.2, and was too restrictive (must not use PRACK) Resolution updated that is not 3pcc Section 5.4.1 - Call transfer - assume a lot of problems here. comment that text refers to 3603, too cable labs specific - reference was removed. There are some comments that still need more discussion the -00 release. - Comments to increase scope - extend to enterprise, security, non-voice - Other comments that scope should be reduced to exclude SIP procedures at endpoints. This needs to be discussed - enterprises probably fine? Removing SIP procedures would be against the initial goal of the draft... Jon Peterson: "Supported" header - concerned that intermediate elements judge about. Hadriel: 100rel as example that people don't like. Jason suggests to discuss that on the list. - Comments about text was inconsistent on the requirements - sometimes on networks, sometimes on network *elements*. Section 5.1.2.3 - Early media from multiple endpoints - comments receive that correct way is sequential forking. Section 5.3 - Call forwarding - comment about History-Info (H-I) header: not widely implemented, not likely to survive, but it is the only standardized way that we have. Cullen: Are there other ways for loop detection? Hadriel: Says loop detection with that is impossible - just keeps URI - no document about it? Max-Forwards MUST be decremented - he will send text to list. Martin Dolly: Max Forwards can be reset (B2BUAs, SBEs) - which leads to problems. H-I can be used within and potentially between, but local policy might strip it out. probably needs to sent both H-I and Diversion. Jason: Take this to the mailing list Open Discussion =============== No other comments - there will be an interim design team meeting before Hiroshima. Conf bridge will be provided as well. Documents will come out soon - at least one will be ready for Last call before the next meeting. >end.