============================================================ Session PEERing for Multimedia INTerconnect (Speermint) IETF#73 Speermint Meeting Minutes Thursday, November 20, 2008, 1520-1720 (Afternoon Session II - Salon C) ============================================================ The Speermint WG met once at IETF#73. The meeting was chaired by Jason Livingood and Daryl Malas. Minutes reported by Alexander Mayrhofer. 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: - RFCs Published RFC 5344 - Presence and Instant Messaging Peering Use Cases http://tools.ietf.org/html/rfc5344 - Publication Requested http://tools.ietf.org/html/draft-ietf-speermint-requirements-07 http://tools.ietf.org/html/draft-ietf-speermint-voip-consolidated-usecases-11 - AD Evaluation http://tools.ietf.org/html/draft-ietf-speermint-terminology-17 - Needs Reviews http://tools.ietf.org/html/draft-ietf-speermint-flows-04 http://tools.ietf.org/html/draft-ietf-speermint-voipthreats-00 - Needs Update http://tools.ietf.org/html/draft-ietf-speermint-flows-04 http://tools.ietf.org/html/draft-ietf-speermint-voipthreats-00 http://tools.ietf.org/html/draft-ietf-speermint-architecture-07 http://tools.ietf.org/html/draft-ietf-speermint-srv-naptr-use-04 - Other Drafts http://tools.ietf.org/html/draft-lendl-speermint-background SPEERMINT Peering Architecture (Presented by: Adam Uzelac) ======================================================= Draft: http://tools.ietf.org/html/draft-ietf-speermint-architecture Slides: http://www.ietf.org/proceedings/08nov/slides/speermint-3.ppt Overview: Purpose slightly different from what was shown at IETF 72 meeting, but spirit the same. Want to provide a context for Speermint LUF / LRF discussion made traffic on list explode in last 2 hours. Issue #1: Figure 1: SPEERMINT Network Context has caused confusion. Recommend removing the figure. Issue #2: LUF vs LRF (larger issue) Daryl: Functional properties of the LUF/LRF should be in the architecture not in the terminology draft. Adam: Would like to gain consensus on LUF/LRF concerns before addressing in architecture. Alex: Suggest to add the word "ultimate" somewhere, but some think this is dangerous. Daryl: Although LUF and LRF are different functions, they can of course be in one application. Adam: Might be one additional revision before WGLC (trying to define the functional context). David Schwartz, Jean-Francois Mule, and Jim McEachern volunteered to provide an detailed review of the document. Use of DNS SRV and NAPTR Records for SPEERMINT (Presented by: Jason Livingood) ======================================================= Draft: http://tools.ietf.org/html/draft-ietf-speermint-srv-naptr-use Slides: http://www.ietf.org/proceedings/08nov/slides/speermint-1.ppt This is one of the "implementor level" drafts in SPEERMINT. Jason will provide details regarding some decisions about "SHOULD/MUST" to the mailing list. Jason mentioned the ENUM IPR claim by Comcast, and offered to talk offline about that. SPEERMINT Security Threats and Suggested Countermeasures (Presented by: Jan Seedorf) ======================================================= Draft: http://tools.ietf.org/html/draft-ietf-speermint-voipthreats Slides: http://www.ietf.org/proceedings/08nov/slides/speermint-2.ppt Become a working group item since IETF 72 -00 WG item is identical to the original -05 individual. Changes: From version -03 on the draft identifies security threats specific to SPEERMINT, not just specific to VoIP, and added a section on deployment. Added a section on SRTP. Provided more text on how each threat can be addressed, provided a table matching countermeasures and threats, and there is a new addition covering the Location Routing Function (LRF). Dan: LUF/LRF does not jump out for the security people, they do not understand what the functions do. Suggest a brief summary of what these are. David: Would like to see a section on protection against resource mining. Adam: Response to David: If communication is secure and authorized, mining would be an non-issue. Jean-Francois: Suggest more traffic on the list about this document. Concerned this was presented a couple of times, but has not had good discussions on the list. Peter Koch: Size and Target: It is 20 pages without a boilerplate, some sections seem to be a bit raw after reviewing the DNS section. Would like to understand the envisioned size, and do you need help? Daryl: We should not repeat security considerations from other drafts and protocols, only add new and specific issues to SPEERMINT. David: Would like to see a recommendation for DNSSEC. Peter: Response to David: Very brave to request DNSSEC deployment in a RFC. Request to the authors to identify specific threats to Speermint and provide guidance, not just pointers to RFCs. Shockey: Believes situations are different for LUF vendors versus SSPs with private agreements that include built in security measures. Question: Is it tied to the message flows draft? Daryl does not think so. Jason: Please point out things from operational experience to the authors, so that they can include it or shift their recommendations. Discussion: Should authentication between proxies be considered? David: SPEERMINT is a good place to look at security models across boundaries. Schafer: One countermeasure missing seems to be the minimization of SED by not exposing more than necessary. Suggest something should be added to address this. Hadriel Kaplan volunteered to provide a detailed review of the document before year end. SPEERMINT background (Presented by: Alex Mayrhofer on behalf of Otmar Lendl) ======================================================= Draft: http://tools.ietf.org/html/draft-lendl-speermint-background Slides: http://www.ietf.org/proceedings/08nov/slides/speermint-0.ppt Hadriel Kaplan: Thinks this is a great draft for folks to read. However, he disagrees with a few items regarding the LRF and LUF. Hadriel Kaplan: Believe that LUF and LRF need more work. Rich Shockey: LUF and LRF function in DRINKS is very straight forward. Makes no recommendation on the protocols used, more about how data is provisioned into certain elements. Hadriel Kaplan: Thinks "provisioning" is a bad description, prefers advertising numbers or routes. David Schwartz: Should not be considered like BGP, while possibly interesting, has pitfalls that we should avoid. We also need cost numbers associated with different routes. Peter Koch: Strongly agrees with Otmar regarding comments on LUF and LRF. Set aside BGP references to specific protocol BGP, feels we still need something similar. This has been discussed and in DRINKS they recommended bringing it to SPEERMINT. Wants us to discuss LUF and LRF (Jason noted the upcoming discussion). Jean-Francois Mule: He likes page 17 and onwards to discuss what is Speermint achieving. Jean-Francois takes some of that blame, he says. He would like to have some mechanisms and solutions for implementers. Ultimately, what are we going to gain from Speermint? SPEERMINT Routing Architecture Message Flows (Presented by: Hadriel Kaplan) ======================================================= Draft: http://tools.ietf.org/html/draft-ietf-speermint-flows Slides: http://www.ietf.org/proceedings/08nov/slides/speermint-6.ppt Question (hum): Are the message flow use cases comprehensive enough? There was no clear concensus, so Hadriel will take this question to the list. John Elwell: Asked if the diagram is supposed to look like RFC 3263? Hadriel: Yes, that was intended. David: Has concerns that SED is being associated with the LUF. He does not believe this should be the case. LUF vs. LRF (Presented by: Hadriel Kaplan) ======================================================= Draft: http://tools.ietf.org/html/draft-schumacher-drinks-luf-lrf-diff Slides: http://www.ietf.org/proceedings/08nov/slides/speermint-4.ppt There was discussion about the terminology of the "LUF": Should the definition be updated to indicate a terminating domain, target, ultimate target, or what? There was also discussion on whether it should target a Domain or an Identity. There was additional discussion whether or not to remove the word "routing" from the LUF definition. Jon Peterson: Suggest we KEEP "target" in LUF and LRF since the confidence in being assured of the ultimate destination is a weak one. Target is a better word. John Elwell: Agree with Jon Peterson. Alex Mayrhofer: Suggest we change it to say, "the ultimate target domain in the context of session peering." Jim McEachern: Alex's description is dreadful. Agrees with Jon Peterson; however, would like to remove "...to which the request should be routed." Someone on the Jabber session has suggested doing above as well: Would like to remove "...to which the request should be routed." Peter Koch: Challenged the word "domain" in this sentence. He thinks "domain" is not well defined. If we mean DNS domain, say so. If we mean SIP domain, say so. He would like to qualify the term "domain". David Schwartz: LRF may need to be further broken down into (1) how do I get there, and (2) what do I need to do to send to that place (security, etc.) A TLS decision is probably not a routing function in the LRF. Hadriel: Response to David: These are link attributes and are hop-by-hop decisions. David: If LRF returns path, what about "other" data? He is concerned these are not included in the definition. ***The meeting was adjourned.