SPEERMINT minutes IETF67 ======================== meeting begins [11:20] Milestones issue: will be reordered, and sent out to the list after the meeting About the agenda: Terminology draft is not on the agenda, Dave will have an update after the IETF is over, and hopefully we can last call this then. Agenda bashing: --------------- http://www3.ietf.org/proceedings/06nov/agenda/speermint.txt Use cases were requested at the interim - they would drive requirements. bunch of use cases received, they'll receive ~15min each. after use cases, we will have a bunch of other drafts - architecture, message flows, etc. more an update to what has happened with the docs. however, focus is on use cases today. last presentation will be a VoIP security threats presentation after that some open discussion Agenda was accepted by the WG. SPEERMINT ITSP problem statement [15:20] ---------------------------------------- draft: draft-newton-speermint-itsp-problem-statement-00.txt slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-4.ppt Andy Newton speaking reason for draft was because wanted to help focus WG discussions on what we should do. it is not intended to become an RFC (hopefully will die after that purpose) two new terms: "routed peering" - what currently happens out there "limited indirect peering" - people can only terminate certain types of calls. many types of diff. relationships. bilateral multilateral (hot thing right now) many peering shops approaching VSPs and then there is the "internet mail model" - "free for all". tools don't exist to do this(yet). E.164 namespace problems, because: provisioning: everyone has a different protocol - why not RFC4114? We do Number lookups - esp. ENUM lookups. public trees not considered useful atm. (whole countries going offline) many private trees which are useful (parallel queries, not optimal).. troubleshooting is problematic more elements make it harder. esp. true with media, but also an issue with signaling. sometimes hard to get hold of the right people. any help on those issues appreciated. security is not a big problem right now. security is contractual issue. IETF docs not gonna change that. perception of general public is that signaling is easy to intercept, and media is not. codecs: reside in the CPEs, so they run at customers side. so, hard to change when switching to a federation. RFC compliance: Number of RFCs is pretty high, vendors complain. they start interpreting those. vendors have hard time to keep up - RFCs that are not helpful are therefore harmful! otmar lendl: you mentioned 4114 - do you propose to use that between peers, or between client and central registry? andy: would even be useful bilateral, but focus is on "peering houses" right now. they all have different protocols keith: have hitchhikers guide in SIP - does it fulfill what is missing? andy: not too many peaople know about it - is still true that there are _lots_ of RFCs... keith: telling the SIP WG that this will not solve problems? andy: was a message to speermint more than sip - vendors have hard time understanding... penn: any authoritative way to "terminate" number? Any registry systems using? What happens when both want to provision the smae number? andy: contracts contain "you can only terminate numbers that you host". never has been a problem. James: media: different codecs are there - we will need to live with it, and trascode if we don't like it. andy: transcoding is very unpopular... all wanna do something bettern than G711, but G711 is still the "least common denominator". mule: codec thing: discussion has shown that codec list seems not to be possible. mule: consensus seems to be that we will not have a list. best you can get is a "federation policy" about that. You want to reopen discussion? andy: yes, still up for debate... Peering BCP [30:30] ------------------- draft: draft-rosen-speermint-peeringbcp-v1-00.txt slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-9.ppt Brian Rosen speaking purpose: start what i think the result of speermint could be a BCP that describes how we use the tools we have... what is what we end up with? name of the draft has "v1" - thats not the draft version, but the version of stuff that we do right now (after that, start with more complicated issues) model is simple: in the first version, only consider one single federation. (a decision that we _could_ make) currently, draft only talks about inter-federation. ToC slide. - probably the most important part Brian wants feedback on that. What are the things that we talk about? What does a federation do? What is our policy? What about protocols, NAT traversal, etc...? other section: What does a peer need to do to get into that federation... feedback on "what is not in or wrong here" requested... wait with the doc - we can't agree right now on that probably. but: What is the shape of the doc that we want to achive Adam: why would a federation dictate capacity control between peers? Brian: Federation has to say what the _policy_ is, however, the policy might be bilateral about such things... Adam: so, is that a blank sheet to be filled out by federations? Brian: may vary. Some feds may define what the actual policy is, but some may leave it to peers to define. wants to define a mechanism for federations how to find out how that happens. Brian: intention to show what needs to be taken care of... Mule: term federation is overloaded. "closed user group"? "carrier club"? Brian: i'll use what is in the terminology. Dave: suggesting to change terminology? Mule: tried to avoid federations - is too much tied to "carrier club" imho. otmar: had a lot of comments on the list, not received feedback yet. Brian: yes, will respond to them... thanks for those. SIP Peering Use Case for VSPs [39:20] ------------------------------------- draft: draft-ietf-speermint-use-cases-00.txt slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-0/sld1.htm Adam Uzelac speaking work at global crossing, have a "carrier club" federation there this is "current practice". this does only apply to Voip, not beyond. peering in various contexts some IPVPN, some blue cable, some open internet pre-estab. contracts. signaling & media collapsed. and symmetrical. transcoding accomplished at the first point where recognized that needed. IP reachability is assumed. Proxy-to-SBC-to-Proxy (b2bua involved in interconnect) is operated by the originating VSP. terminating VSP might have packet filter etc. next hop lookup to the SBC, then next hop lookup to the terminating point. next case: back to back b2bua (if they don't trust us or we don't trust them) next scenarios: transit VSP, with two SBC - typical for enterprise to enterprise when they don't have SBC itself. one step further: 4 b2bua's ... David: Q to previous slide: why 2 bsbua's Adam: one only possible if common ip denominator... requirement: Any originating on IP and terminating on IP should stay on IP. Daryl: q to prev. slide. thinks that is it not in scope to do IP-PBX and inter-enterprise peering? mule: whole draft could be summarized with one word: "trust". developing "trust boundaries" to left and right then q: what attirbutes would you associate with a trust domain? what reqs could we derive than from that? Adam: it is more than just trust. more value than just introducing trust boundaries. Mule: do you envision certain security mechanisms? Penn: notices hop-by-hop scenario... what is going on here? get different data each time a lookup happens? Adam: all those use cases are non-ENUM currently. problem: would loose originating information with translations Penn: so you tranlate once number->uri, but then next hop via uri? Adam: correct. Otmar: taking on on NNI vs. UNI - afaik we don't differentiate between those... Dave and Andy agree on that . Andy: reason for B2bus anonymization? what about troubleshooting? Adam: yes, is for anom partly. debugging is not very easy hence. stastny: 1) legal problem - what are you allowed to provide (NNI vs. UNI) 2) ECMA has many pres. to ETSI, and they alone have about 8 scenarios. so, approach could be after "v1" we have "v2" and then add enterprises q: the next hop lookup could also return a "private URI" which just points to the exit point, and then there you have another lookup. anonymization looses info, but the loss of information is then architectural... otmar: how is provisioning being done (the local routing databases) adam: will defer that to the list proposal: we have a bunch of use cases now - consolidate them into a single draft? then investigate why they exist in the way they do. Session Peering Use Cases for Federations [57:45] ------------------------------------------------- draft: draft-schwartz-speermint-use-cases-federations-00.txt slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-7/sld1.htm David Schwartz speaking This draft is not intended to become an RFC. this is sharing what we see in XConnect. calling those functions "peering stack". most talk is about location function - comment on provisioning is valueable... need more work on that. other peering functions "security" , "trust" - eg. the whole privacy stuff, spit, spam. how do you pass privacy on etc. "routing" function - business relations stuff - yes, we can terminate, etc. yes, we have IPsec, etc... "cost" function - could also be zero, but ignoring is silly. can per dip, per minute, capacity, per federation etc. each peering function has content then. then there is also a framework (policy negotiation, enforcement) - NOT in scope of this document. six functions identified - they're in the draft. example of a location function... what is the content of such a function - that needs to be defined.. lookup? cache? srv afterwards? whose location returned? anonymizing? etc. queries per second limits? etc. some answers could be "no, we don't do that" - but this is a policy decision. another example for security function. again, it's a policy decision. so within the security funciton, there is a policy function. new terminology "peering service provider" proposed. he provides one of the peering functions just mentioned. the "direct" model - just the lookup in the PSP, signaling directly between VSPs Adam: can i be a PSP and VSP at the same time? David: absolutely. Sohel: maybe use "function" or "entity" instead of provider then? shockey: function may reside in the originating VSP. a "trusted registry" may be a subset of a peering function, which distributes the authoritative info to the VSPs. David: is location function? Shockey: "vessel" that distributes data to VSPs David: that gray in that pic there box is the registry. problem: complexity associated with direct model. not scalable. two options: 1) keep it really simple 2) outsource more functions to PSP. alternative: seperate the "lookup" from the "intermediate"/"transit" function. "intermediate" works as "firewall" to eg. do transcoding, and "cleans" traffic. Adam: need an L function probably in the originating as well... "putting it all togehter" - this is reality. open internet - "come through him". "premium" - you speak directly to me conclusion: different relationships req. diff. peering modesl. direct peering does not scale. shockey: don't take on that direct peering does not scale - GSM has direct peering, and works pretty well. David: interopability issues between the ~1500 VSPs aorund... andy: agree that direct pering is a hassle, but we wanna do that as well. (and we do currently a lot of) Presence Use case [72:00] ------------------------- draft: draft-houri-speermint-usecase-presence-00 slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-6/sld1.htm Avshalom Houri speaking wrote this draft because SPEERMINT is very voice centric presence is key enabler for many services, including voice. peering domains will need presence to be a better enabler. domain to domain presence peering already exists. other aspect: real time collaboration. instant messaging, chat, file transf. etc. use cases: presence subscription resource list subscription (list of users on other domain) a lot of real time collaboration use cases. specific reqs: mapping different presence docs. statuses may differ between domains. also, consolidation of subscriptions. scalability is an issue here. propose: presence and RT collaboration to become "first class citizen" in SPEERMINT. Adam: very much enjoyed the draft - enocourage people to read it Henry: important - maybe recharter SPEERMINT? Dave: will address this comment in open discussion section. Requirements draft [80:00] -------------------------- draft: draft-ietf-speermint-requirements-01 slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-3.pdf Jean-Francois Mule speaking changes since first draft: - clarified scope and intent of draft - feedback from interim incorporated. - generalized some reqs to be not VoIP-specific. - aligned Terminology with new term. draft. - various editorial comments received and incorporated. - split between requirements and motivation for them. - added stuff on viability for call routing data. some "chat" style threads examined, and tried to captured issues from there (session peering policy, eg. codecs) new stuff: incorporated discussion about network layer security vs. application layer security (IPsec vs. TLS discussion from interim meeting) goals: describe type of policy information that needs to be exchanged between peers... some discussion on the list - federation abstracted, etc. tried to add info about that to annex A of the draft. moving from "how" to exchange to "what" do we need to exachange. q: is this a good direction for the draft? Move that annex into core? David: figuring out what we need to know is a good thing. Brian: Solution doc subsumes what wasin the reqs. Solutions should not show up in the reqs. last slide: TLS considerations tried to start discussion points on what peers need to discuss when going to TLS. architecture draft / message flows draft [89:30] ------------------------------------------------ draft: draft-ietf-speermint-architecture-02 slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-2/sld1.htm Reinaldo Penno speaking changes since interim: received many comments during interim meeting itself, eg. should move some content. move some from flows draft to architecture (and reduced a bit). unclear whether we should have a policy document- maybe discuss that later? david: daryl, you volunteered? :-) reinaldo: probably chairs should consider policy doc as milestone? mule: recalls that policy function could also be distributed over all the other functions according to interim meeting. to be done: move some ASCII art from flows to architecture, align with new Terminology, comments - getting the draft stable... (unless we discuss inter-federations stuff :-) message flows draft [94:20] --------------------------- draft: draft-ietf-speermint-message-flows-01 slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-1/sld1.htm lots of good stuff there that "didn't have a home" incorporated on-demand/static and collapsed/decomposed. removed QoS stuff. private addresses stuff moved to architecture draft. policy (re)moved to architecture same for media considerations. To be done: decomposed/collapsed to arch draft? remove mentions of "speermint"? (post-WG?) get more call flows. Jason: some call flows may come out of the use cases. Security presentation [96:50] ----------------------------- draft: draft-niccolini-speermint-voipthreats-00 slides: http://www3.ietf.org/proceedings/06nov/slides/speermint-8/sld1.htm Martin Stiemerling speaking proxying Saverio Niccolini state of current draft give taxonomy of Voip sec threats. start discussions on how to avoid those. second versions will be out before IETF68 identify then threats specific to SPEERMINT, and related requirements. Examples (input from Reinaldo) discussion expected on the list as well. David: isn't eg. proxy impersonation a SIP issue rather than SPEERMINT issue? Jon Peterson: knowing how SPEERMINT systems look like would enable us to look at threats. should look at use cases drafts, which could reveal issues. Open discussion starting [101:00] --------------------------------- first issue: presence an IM - should that be in scope? then: Enterprises being a VSP or not? then: Federation term? should be renamed? then: Codecs again? then: Q about another interim before Praha? Brian: would like to know whether we add inter-federation to "v1"? Brian: if we going to handle that, it might impact charter... Brian: So, first version: Intra-federation only, or"inter" also? Jason: Q: seems as if you wanted to do intra only? Brian: would be hard to agree, so that was reason to step back. if we have consensus about inter - fine. David: IM issue is about protocol interopability, not soo much about functions. clearly is not in scope of SPEERMINT, but could be identifed as interop problem. we could hence put that into the "interopability" charter point. Jon: clearly IM has interopability issues... Jon: regarding federation term: is that a "multilateral peering agreement"? Jon: other than that, codec stuff is scary :-) Andy: scoping issue: Do we take on _open_ peering models? jean-francois: comment about the intra/inter-issue: do we become overly complicated in describing the problem? What about Rohans direct peering draft? we also have the use case of naptr records. so, start point to define the very simple, easy, direct peering, and then add the more complicated issues? Avshalom: issue with presence is not about interopability between protocols. thinking only about Voice and Video is not enough. ??: Issue about Enterprises: involved in ECMA work - has relevance to work in SPEERMINT here. jason: volunteering for a use-case draft here? Otmar: mentioned update to milestones? can elaborate on that? Jason: some milestones didn't make sense, esp. the order of them. Going to look into reordering? Otmar: regarding federation definition: comes from the Domain Policy draft ("within a federation, i can talk to anybody") Otmar: room has so far avoided "number vs. uri" - location function based on numbers or uris? Jason: so, both in scope? Otmar: think that we MUST not describe a solution which just works with one of them. Henry: think that Enterprise is out of scope. Penn: wanna not see a "lowest common denominator" approach where enterprises are not different from carriers at all, but has not problem including Enterprises. same for IM. adn presence. seen a lot of nice use cases, would like to see a common terminology for them. shockey: no problem with IM/presence in scope. but WG attempts to boil the ocean. look at deliverables. regarding Enterprises: should bring SIPCONNECT into the IETF? Jason: can't hurt to look at this. Stastny: v1 is fine, but we should keep in mind that support for use cases is first priority. (limiting of v1, that is) Geoff ??: have strange Deja Vu feeling of trying to find out what all that means. eg. federation: if the group can agree itself on a meaning, that's fine already. recommend: deal with voice issue first, and develop common terminoligy. Adam: think that IM and presence needs to be in scope. we could learn something from use cases. codecs - bad - don'T go there. Andy: think presence should be in scope. Enterprse: yes, they are VSPs. some enterprises are larger than certain VSPs. Jason: do we have people about IM and presence here? Avshalom: could bring people from Microsoft, they wrote the draft. David: address "other": Would like to see the "uploading" / "provisioning" of numbers standardized. Jason: ok, summarize as "provisioning of location function". Steve Morgan: responsible for call centers etc. many requirements are "higher" than those of carriers... so the "least common denominator" would mean that carriers would need to move up :-) interconnects trading floors etc... uses chat etc. because chatting with 20 people is easier than talking to 20 people. Otmar: regarding domain policy: we didn't come to a conclusion regarding those docs during the interim - what does the group want me to do with that? Daryl: regarding enterprise: "intra"-enterprise or "inter"-enterprise? Brian: would like see IM/presence in scope - but limit issues that may rise by prioritizing. think that IM/presence would fall out then... regarding codecs: should _not_ presume that audio is not the only service. shockey: provisioning location: produced 4114 in ENUM - EPP was defined for the domain name industry. service provider have strong desire to _not_ use EPP... so, if provisioning is in scope, what would the group do? proprietory work (such as Neustars) needs to be standardized, however. Andy: response to "why not 4114" is always "because we did not read it". Henry: we should at least define the difference between enterprise and carrier, if we don't do it. ??: lot of devices that people built assumes VoIP only... Jason: good point - remembers SPEERMINT vs. VOIPEER naming ... ??: conferencing in scope? [first ?? = Ben Campbell] Reinaldo: should not loose the broader scope of the group - although we talk only about voice. Jason: but - "let's get voice done first"? Reinaldo: yes, if thats consensus - but don't loose the other ones. Dave: Voice-centric because that was the first applications... ??: people generate revenue with voice _today_ - SBC can do lot of things already, but VSPs need to set the SBCs to _do_ so. ??: didn't want to start an SBC war... Brian: return to the provisioning thing - allow the chairs to charter a design team on this? requirements only in the first place... (about 15 people raise hands they want to be on a provisioning design team) Otmar: what about my drafts? Dave: will take to list - cannot decide that here. meeting concludes.