============================================================ Session PEERing for Multimedia INTerconnect (Speermint) IETF#72 Speermint Meeting Minutes Monday, July 28, 2008, 1300-1500 ============================================================ The Speermint WG met once at IETF#72. The meeting was chaired by Jason Livingood and Daryl Malas. Minutes reported by Alexander Mayrhofer (Daryl Malas) 1. Introduction and Progress Report The chairs provided a review of the high level overview of the Speermint document flow, provided a status update of current drafts, and reviewed the agenda. Status of documents: - Publication Requested http://tools.ietf.org/html/draft-ietf-speermint-terminology-16 - Ready for WGLC http://tools.ietf.org/html/draft-ietf-speermint-voip-consolidated-usecases-10 - RFC Editor Queue http://tools.ietf.org/html/draft-ietf-speermint-consolidated-presence-im-usecases-05 - Needs Update http://tools.ietf.org/html/draft-ietf-speermint-requirements-06 http://tools.ietf.org/html/draft-ietf-speermint-architecture-06 http://tools.ietf.org/html/draft-ietf-speermint-flows-03 http://tools.ietf.org/html/draft-ietf-speermint-srv-naptr-use-02 - Other Drafts http://tools.ietf.org/html/draft-niccolini-speermint-voipthreats-04 VoIP SIP Peering Use Cases (Presented by: Adam Uzelac) ======================================================= http://tools.ietf.org/html/draft-ietf-speermint-voip-consolidated-usecases-10 Status of the document: three new releases since Philly, 06 with some larger changes, 07 with some clarifications, 08 incorporated NITS feedback. Missed the deadline for 09, but that should be out right now. Changes in 09: mostly editorial and "bug fixing" changes. Removed section 7 about Federations entirely. David Schwartz: What if there are more use cases; especially, use cases that might drive new requirements? Daryl: Purpose of requirements draft is based on what we know today. Future use cases may be applicable to new work in Speermint, but should be captured in related future drafts. Jon: We'll never get done if we continually change the requirements. Lets do the work based on current knowledge, and put the new things into new drafts. David: What if I have a new use case? Should I delay the WGLC? Daryl: Remember we did WGLC already twice on this. Unless wer are missing something really urgent, then we must move the draft forward. David: For example, decomposed media, when media and signaling points are entirely different, could be such a use case. Jason: Remember that the use cases draft was to drive requirements, so we might still have corner cases (not covering 100.00%). Adam: Thanks to John Elwell for his efforts in reviewing the draft. SPEERMINT Requirements for SIP-based Session Peering (Presented by: Jean-Francois Mule) =============================================== http://tools.ietf.org/html/draft-ietf-speermint-requirements-06 Latest changes in 05 and 06 presented. New Security Requirements Section. There is no traffic on the mailing list. Jason: If you have not read it, please do so now. 5 major points changed, some requirements were uppercased, comments from IETF 71 and nits addressed, etc. Updates to the security section were added for LUF/LRF mutual authentication and SIP protocol exchanges. David: Many people are using SIP, do we authenticate 302 or do we use layer 2? Alex: Agree - although we can use Layer 2/3 security. ENUM without DNS SEC would probably not qualify. Jean-Francois: Looked at a couple of drafts, for example the naptr-use-case draft. Jean-Francois: Are we considering RFC 4474 for every request? Adam: Are we going down the Elwell-draft and URI change draft "rat nest" here? Jean-Francois: We are just describing what we need in terms of requirements. Keith Drage: This does not look like requirements text. You need to capture what you are trying to achieve, not what the solution is. You need to phrase the requirements around the problems. John Elwell: There might be different levels of requirements for security, and there may be components for a solution, like TLS. Jean-Francois: I need more feedback how the working group envisions that section. Other feedback? Ready for WGLC? David: There are many reasons for different media points for different types. For example video codecs just on one side. For example DID use with Audio and Video... Jean-Francois: Consensus in IETF 71 was to remove it, although I do personally share your points. Mixing two things now - an element to traverse vs. routing a request differently. Question to the working group -- What about a case where SIP is sent to one element, and then finds out where to forward video/audio? David: Yes, that is one use case; however, one use case is seperating traffic already on the originating side. Jean-Francois: We are revisiting that point every meeting... SPEERMINT Peering Architecture (Presented by: Reinaldo Penno) ======================================== http://tools.ietf.org/html/draft-ietf-speermint-architecture-06 Draft defines a reference architecture for SPEERMINT Major changes: - The document is now split into actions on originating and terminating SSP rather then both steps for each part. - Fixed LUF, LRF, pictures and diagrams, and TLS based on SIP-certs. - Pointed out that functions can happen more than once. - Some nits remaining. Next steps: Issues? WGLC? David: Substantive issues: May go to more ENUM trees, and the reason why something is routed to the PSTN needs to be given (assumption as a "default" route?). David will send comments to the list. Jason: Regarding ENUM - Should say that this is "not the end" after public and infrastructure ENUM. Adam: How can that go to WGLC? Jason: It can't, we need to close out other docs before. Need to get comments on the document, and feed it back to authors. SPEERMINT Routing Architecture Message Flows (Presented by: Hadriel Kaplan) ============================================ http://tools.ietf.org/html/draft-ietf-speermint-flows-03 Basic peering connection sketch shown "Integrated" model "Decomposed" model Changes: - Covered is on-demand, static, federation (Enum model to be added in the next version) - Removed lots of messages (If people have an issue with removing the Federation things, let Hadriel know on the list) - Added definitions Issues to be closed before WGLC: - Planning to remove integrated vs decomposed (looks identical from the peering perspective) Hadriel: There's not a difference in the protocol from "outside". Daryl: Write the draft according to the architecture, and mention differences that arise from integrated/decomposed in the text. If there are differences in the individual steps, mention them. David: Agrees, this is waste of time in that context. Jon: Question is when media box is in a different administrative domain.. David: That is what I said before.. Question from Savarrio: Is the message flows what is being done, or what is recommended? Daryl: This draft is written to indicate how peering would be done in the near term (or similar to). John Elwell: Problem with LRF/LUF/SED usage in the draft? Adam: Is this a reference document? Daryl: This is intended to provide a peering message RFC, similar to RFC 3665 for SIP. Jon: Architecture showed different possibilities. Those message flows can just be examples. Adam: Do we catch the ugliness in those messages? Jon: We don't want to flag vendors in here. David: Considers that ENUM in here very "one-sided" as well. (Implication: There should be examples of SIP Redirects.) SPEERMINT Security Threats and Suggested Countermeasures (Presented by: Jan Seedorf) ========================================= http://tools.ietf.org/html/draft-niccolini-speermint-voipthreats-04 Changes since IETF 71: Renamed the draft. History: Content until 02 was investigation regarding attack vectors contirbutions to requirements draft on 06 Updates for 03: Threats for LUF, LF, SF, and MF. New in 03: Mentions 12 security BCPs and their relations to SPEERMINT Observation: "BCP" is misleading because some solutions not deployed yet, so renamoed to "countermeasures". Added a "deployment" sub-section. Some of the countermeasures are not Speermint specific (fuzz testing). Re-wrote to be more Speermint specific. Open issues: Where to put solutions? Suggestion to put them here (comments at IETF 71 indicated that requirements should contain actual protocols) Jon: Good mapping from threats to countermeasures would be good. Difference between requirements and actual threats. David: Thinks that few comments received because it's too premature. Jon: Would like to see more details on how countermeasures relate to draft? Daryl (individual): Would like to see _one_ draft about security, thinks this doc is on the right path. Alex: Would that mean we make all other security sections just pointers to that doc? The working group took a poll to determine if there was consensus to accept the draft as a working group item. After a "hum" and "raise of hands", there was no consensus. The discussion will be raised again on the mailing list. Open Mic Time ============== David: Now that we have DRINKS (the WG), how do we get the information out that is in "there" (SIP header, ENUM - how to we transport them?) One might give a lot more information out, but how? Personal observation, more people are using SIP than ENUM for LUF and LRF. Hadriel: For the 10% of cases where it does not work with ENUM, we point them to SIP for the LUF / LRF. (Discussion about collisions between working groups.) ***The meeting was adjourned.