motivation for interim: quicker progress with documents than is possible in IETF sessions. discussions could be quicker resolved than on mailing list meeting start ============= first: general things, starting with terminology. trying to close that draft down. then: requirements draft, trying to close that after lunch. agenda change: reinaldo delayed, so draft will be moved to tomorrow andrew mc donald will give a voip-security presentation. possible vulnerabilities, then requirements, would then be used to influence other docs. there is a new draft about SRV NAPTR usage. second day: more docs, then closing out issues on terminology and requirements, try to finish 3pm. discussion: should "IMS-style roaming interconnect" be in scope for this group - probably there needs to be a discussion about this. try to capture minimum things which _needs_ to be done. more complexity could be introduced later. we should be efficient in getting documents out, because there is a lot of competition in this space. introduction round, "blue" sheets going round. terminology draft ================= dave explains changes from last version, would like to incorporate more changes, and then last call that again. comment: there seem to be a few definitions missing, esp. considering that some definitions are differently used in diff. documents (eg. "sending", "receiving"). comment: do we want to keep the word "policy" defined here? what is "policy"? what is the least common denominator on technical layer - what is the "political" policy to be able to connect to me - policy doesn't need to be technical only. technical and "political" should not be mixed up. jason: please refocus, there's lot of policy on the agenda. dave: do we want something in the "terminology" draft? would rather like to see "policy" in a different doc. "policy" is an overloaded term. can only be defined in a very broad sense in terminology. there seem to be several different policies. brian will write text on policy definition. jon: "policy lookup" etc. should be used carefully, overloaded terms, like "location". what does "service location" mean here? is that an "application service location"? could be used for "dynamic peering", to eg. discover auth mechanisms, number of calls. discussion: for simplification, declare that "dynamic" stuff out of scope. q: what is "dynamic peering" - peering without formal relationship. is not yet defined. generally, the internet is _full_ of dynamic peering - we really want to rule that out? no, but not define _any_ possible way to find out how to peer. define "dynamic" vs. "static" - eg. Diameter contains elements to discover upstreams, but nobody has implemented it. look at that? request for text about "dynamic" vs. "static" - will be posted to jabber room. more and more peerings will be dynamic in sense that only for a certain session a peering is et up. not real today, but probably moving towards that more and more. i might even want to announce eg. codec, call time, first contact eg. for my personal domain - my "personal peering policy". discussion on "individual peering" rather than "network peering"? federation could be a website with "waht you need to do", and done. if not define in terminology, but make another draft: go ahead. 2 different topics for terminology: "dynamic / static" and "policy" difference to email: timeout on firewall is not acceptable for SIP. jason: so, we have a few new terms that people are working on. accoring to picture, speermint seems to be a "resolution layer" transforming identifiers - q: do we need this picture anymore (was intended as division of labour to ENUM) naming the output of the "speermint resolution process" would provide something meaningful (ENUM does X, SPEERMINT does Y would be possible by naming the output) discussion about "acronym plunder" - "CAD" "call addressing data"? "session establishment parameters" - "SEP"`? "CRD" was input, "CAD" was output of otmars algorithm. is it (?) something based on eg. network conditions, or just on eg. agreements? "SED" - session establishment data? see "policy" and "addressing" seperate. agree that SED makes it more broad. discussion about "resource control paramters" - move them, or remove them? Clarify that those are examples. change to "optional resource control parameters". what's the functional difference between "VSP" and "ITSP"? defining both will confuse people, they will choose one of them randomly. proposal: use VSP in the working group, and say that this is "inclusive an ITSP". discussing transport: no relation between those layers? influences "service provider" term. wanna change "VSP" to "SSP" (signaling service provider)? "RTSP"? "peering service provider"? joking... moving to section 4. q: what's "assisted" peering? maybe a box in the middle which is just relaying, like BGPs route servers. like a SIP redirect server? porposal: other entity where security relations etc. are required, but not "peering" with it. make a subsection, or delete it? is there a difference between "indierect" and "transit"? is "assisted" something different than "transit"? "transit" might not be distingusihable - you send traffic somewhere, and it is begin terminated correctly. what about anonymizer providers? why does it matter _whom_ are you sending to? because if several clouds, there are several policies (federation, endpoint), and there is a difference, because each node adds its own stuff. anybody not fine with "indirect" for those cases? when we started with the documents, there was no such "layer5 transit". jason: move that to a hallway/coffee discussion. last point: federations? -> coffee break, end of first recording. second recording: requirements draft ================== still -00. what are we writing in the requirements doc? will be a BCP, include both general requirements and specific VoIP requirements. a lot of threads bring up the issue whether requirements should be for products or operational requirements. split the motivation from the actual requirements: short sentences with capital words for actual reqs, and then motivations in later sections. remove all normative references, and keep just 2119? other question: are we writing guidelines for SPs who use certain parts of the technology? those would not be normative. discussion about whether a reqirements can be a BCP. is the requirements doc a repository for things that need to be done? different req levels - eg. ECRIT has high-level reqs, and then protocol-level reqs. "requirements" is what we are supposed to achieve? Thats more the charter, not the reqs. 1st section could contain general reqs beyond voice, remaining sections specific reqs (00 put togehter quickly that way) - however, reopen for suggestions. hard time to find out what should be required on protocol level (TLS, ENUM - see list discussions) what is the matching bullet in the charter? are we tablking about operational stuff now? if we say MUST use SRV MUST use NAPTR, there will always be somebody who turns it off... are we talking about the "minimum reqs for network-network-interfaces"? "all federations MUST do the following things:" sounds good to brian. use cases? problem with use cases is that you run into use cases that are out of scope. make a "shopping list" of what to do to connect to somebody else? what is required to connect is a policy element of a federation. NAPTRs, how to handle TLS, etc. capabilities supported don't need to be supported all the time for all links. coming back to the question: should we specify any min. requirements on ENUM resolvers, on how to provisioning, etc. opinion: yes, there are rquirements for this, so we should specify something. stastny: ENUM wg does the URI resolution, SPEERMINT starts with a URI... private SIP URIs (eg. GSMA internal) may not be resolveable to anybody. ENUM "gives something back" - agreed ... SIP Endpoints may be in private networks, and not reachable for everyone. codecs: minimum codecs? we reached some agreement that some codecs should be specified, and transcoding should be avoided. new text last week, some comments (brian, andrew) minimum reqs on transcoding capabilities? 1) req: RTP and RTCP support on terminal. 2) should support compatible codecs 3) transcoding should be avoided 4) where transcoding neccessary, go to G711. proposal: not to specify requirements on the endpoints! we want to see interop at the peering point, and requirements on the SP interfaces. what about enterprises? media reqs would introduce a media peering point in addition (and differen from) signaling peering point no - policy on media in federation itself is different than policy at peering point there are federations out there who specify the codecs. really nice would be a list of codecs to give out to vendors, because they should implement it. discussion about AMR, G.729, etc... wanna require these? if you don't want to trancode, you have to specify endpoint reqs. one or the other. nowadays: no codec match - no call. but adding transcoding reqs would mean calls when no codec match. is it up to speermint to specify endpoint requirements? could define transcoding architecture. we should say that codec list can be part of the federation policy (join that fed - must support those codecs) "federation bylaws". note: signalling might not be aware of the codecs at all... question: good to have a list of media related requirements? federation must have a codec policy which must be supported by members? "federation policy includes codec policy". problem: codec negotiation first needs to find the final endpoint, and hence routing decisions based on codec negotiation... proposal "at the signalling peering point, media must be compliant to policy" [lunch - continues with third recording] working on req. text - sdp related requirements. PRACK? is that to be supported? - is implemented on the endpoint, again. we would need to be very explicit - someone is worried about that. haven't we agreed that we do not support it? those issues draw the bottom line - PRACK is not just peering point, but more stuff as well.. does the requirement doc evolve into a BCP? could have a "cutting edge bcp" with all the latest features, and another "low profile" BCP... comment: requirements is a reqs doc, not the answer to the reqs. look at what is common to many peers, and look at this? should focus on implementation rather than on reqfining reqs again. what about IMS roaming scenarios? what about GRUU? regarding the document: if starting a peering company tomorrow, i should be able to look at the reqs doc to see what i must implement. we could use text about what peering points require today - there is a volunteer for this.. [fourth recording] agreements for traffic between the two boxes: TLS transport,etc... - minimum set of reqs. comment: won't implement TLS. secure peering today is not going over TLS. it's manually (out of band) configured and static. ipsec tends be easier to scale. tls with lots of connection is difficult, because tied to applications. ipsec runs on hardware - if you need something to be resilient, you choose ipsec rather than tls. tls provides authentication, too. certificates. ipsec is less dynamic. with TLS you have to have an application layer, but you also know the identity. it is important to know when an INVITE comes in from where it comes. have a section about current practices (nailed tunnels, afe routes) have another sections about rationales (develop args for TLS) provisioning reqs and domain names moved to tomorrow. federations =========== otmar speaks about federations. introduction, why is this done that way. looking at status quo. islands which are concerned about the fully open internet. peerings manually configured, etc. market shows that there is demand for peering services. calls originating and terminating on ip should not touch pstn. what blocks people from peering? tries to provide something between completely closed and completely open. if we can make peering secure and anybody will peer with anybody like email - fine as well. but that's not gonna happen soon. voip does not point to point interconnect. this is about routing - finding the next hop. key to routing is the domain of the destination URI. q: why is this needed? a: number of domains prevents static policy distribution. q: how dynamic is routing data? does it change once a week, once a month? a: if it's AOL with it's customer domains behind it, it will change every minute. could announce via NAPTR/SRV plain RFC3263, but a try there could fail with timeout if the destination does not allow contact. need list of conditions sufficient to access. number based: is the number on IP? who is hosting it? do i have access? what do i need to access the next hop? in all cases, you get the proxy or b2bua back (next hop). number: ENUM lookup -> URI -> next hop q: its already hard to make them do one lookup - how would we argue the second query for every single call... otmar: will elaboreate later number->URI: infrastructure ENUM, etc. URI->peer discovery (where to route to) ENUM: number to URI URI: routing based on requirements [break - next recording] otmar continues about federations. feds are a "group of service providers" - "group" in mathematical sense any SP can be member of any number of federations. federations could be walled garden, open, whatever. policy discovery via NAPTRs based on domain. no extra lookup costs, because 3262 already requires NAPTR query for destination domain. input: domain. output: list of policy identifiers map policy identifiers to policy that i'm capable of - use one of the matches to route. (federation matching with own memberships) policy identifier can be any URI/URN. openser module available already. example policy: usage of TLS, federation central sip proxy, network type, etc. replacement for customer domains possible - customer domain can point to service provider's policy. supports several ingress points for domains, based on federation membership of originating side ("special" federation: go there, everybody else: go elsewhere) q: possible to extend that scheme to support eg. groups of instant messaging users? eg. looking for people who watch the same football game... security tutorial ================= we're going to see voip-based phishing, break ins into eg. mobile phone boxes (via call id replay) basis for fraud: maximum return on minimum time. [next recording - speermint_66.66_155029.mp3] people tend to think phone numbers are good, uris are bad. but phone numbers are even worse - there's no whois and way to trace it. 4 or so cases of voip based phishing seen so, how to identify a callee, eg. from a bank? not as easy as on the web. a lot of systems use phone numbers for authentication (calling card, credit card, etc.) - so phone number faking is attractive. would end-to-end session authentication stop those attacks? not neccessarily if its easy to get a number without proper authentication... q: is this a topic for the WG? (phishing..). Do we want a doc which says that SIP identity is required to stop scam? Do we recommend eg. TLS? jon: people want pstn, so service providers emulate it. hence it's as good as that. [ break - next recording - speermint_66.66_165031.mp3 ] SRV and NAPTR use draft ======================= scope: address eg. discussion from this morning - what is required regarding SRV and NAPTR. introduces a "peering proxy", which has a ENUM client - this must support UDP/TCP. if deployed in multiple instances, must be chosen via SRV. how to locate ingress border elements: 1) determine the domain part 2) use 3262 to look up services. 3) use SRV records 4) esatablish session recommended caching 1h for SRV, 2h for NAPTR. (srv to change more frequent) feedback regarding EDNS0 and DNSSEC received. comment about redirection - the MUST regarding use of a specific sbc is not neccessarily the case when a redirect from sbc1 to sbc2 occurs. do we want a document _before_ this about how to use ENUM etc.? be careful about requiring parts. that may prevent people from actually using the whole thing. should this become a BCP? conclusion post to the list: make this a WG item? [ end of day 1 - next recording - speermint_66.67_090700.mp3 ] security tutorial ================= intention: overview of the topic - stimulate questions voip is an application on the internet - subject to application attacks as well as internet attacks (attacks on all layers possible). idea of securing every layer independently. most common: eavesdropping (monitoring ip packets) - just where packets are sent to is revealing. signaling and even DNS packets can be interesting as well. traffic capture: eavesdropping & recording. (number harvesting, also possible via the DNS packets when using ENUM - even when signalling is encrypted). Media packets can be recorded and played back again. packets may be decrypted offline depending on encryption level/method. voicemail interception (very low security model in PSTN today) interception ------------ call blackholing / redirection. authentication can play a big role in preventing such attacks. if asymetric routing, it can be difficult to authenticate responses. call retargeting. the more intermediaries, the higher the chance that it's possible -> use as few hops as possible media rewriting. (or injecting false packets into the line, DTMF) have to think about RTCP as well. bad rtcp packets could force bad call statistics up & terminate call. identification chains: if one link is misconfigured, the whole chain trust becomes useless. mechnisms like rfc4454 needed to protect against caller id issues. the more substantial the architecture is, the bigger target you are. eavesdropping: difference between sniffing on the open internet and a malicious peering partner? how to handle that? peering session could be encrypted, but peering partners still could sniff.. speermint primarily needs to address peering that goes over internet, peerongs over "private lines" are probably secondary.. perimeter security alone does not work - gateways, endpoints etc. need to be secured as well. continuing: bad protocol messages, DoS via QoS, registration hijacking, contact hijacking. even with proper authentication if an attacker can change the contact, he can hijack. server masquerading (impersonating many servers behind a nat). DDoS via "send me a five MBit/s video stream" - also possible to play with ICE here (media will only be sent when clients agree) non technical threats: social engineering, physical intrusion. CANCEL cannot be authenticated - some workarounds possible. some of the possible attacks have been seen in the wild, not all (yet). comments: client privacy hasn't been mentioned (end to end media streams...) early media. (being abused in the PSTN as well) message flows draft =================== put a number of different message flows to see which make sense, changes from last version are listed on presentation. talked about policy function, expanded QoS message flows, and added federation related message flows. added a "phased approach" to peering - how does it fit together. received some comments to the draft (some off-list). comments were about that some sections should be moved to other drafts. - decomposed/collapsed discussion to architecture draft (p3, p4 ff) (some text should remain here, but pictures etc. dynamic/static could be put into arch draft, because more an arch. discussion. comment: do we care about internals of networks? We care about _between_ networks, not how a network looks from the inside? might be ok in the security consideration because of transitive trust, but why more? could be a simplification, would reduce number of options. interesting is only "what happens in the middle". when we cross admin domains, we cross security etc. borders. so, that _is_ between networks. do we want to have eg. QoS interaction in here? Had that discussion L3/l5 before... looking at the charter, we have some fuzzy wording for this issue... we should not drop the text on QoS on the floor - we should keep it somewhere. consensus on the first bullet? (collapsed/decomposed): not much difference between the two, merge them into one, but where does that one go? does it fit better in the arch draft? proposal: the definition should move over to architecture. consensus on second bullet (static vs. dynamic)?: put that into the terminology draft (adam will provide text) in addition, look at "assisted peering" in this context? consensus on third bullet? remove QoS discussion from draft (but keep it somewhere) discussion on private network: is private RFC1918, or "just not accessible from the internet" - comment: again, the insides of the networks should not be in scope - interesting is addressing at the peering perimeter. consensus: submit discussion about addressing to the mailing list, and ask for feedback. reinaldo: section actually came out from discussions on the list. somewhere, an endpoint media and signalling must get a public address, because only that way it comes into the scope of speermint. comment: there will be private networks, like GSMA... [lots of discussions in parallel] next: policy function introduction. in some point, it might be necessary to exchange policy in a dynamic matter. is this document then pointing out "holes" in the requirements document? comment: 99% of IETF-work is "policy-less" (but eg. Diameter contains some policy work) we could remove policy stuff here, but then we need to introduce it in architecture & terminology docs. try to get rid of the references to SPEERMINT - documents will hopefully survive the WG. discussion/proposal: is static policy in scope, but dynamic policy out of scope? domain policy / peering policy: we need first to go to terminology about this, and then go to architecture... [ break - continues with speermint_66.67_105926.mp3 ] architecture draft discussion ============================= current version of draft is -01. significant changes from the original draft, so read this. update on terminology based on feedback from the mailing list. reinaldo gives background about policy functions: mixture of congestion control / dynamic control. there was consensus that some "feedback" functions were necessary. Named "policy" because sipping calls that "policy" as well. eg. work on media policy where policy server pushes policy (use that STUN server, use those codecs). - reason for choosing the "P-word". policy is optional in the document. placeholder for future discussion. can we rename "policy" to "routing decision"? eg. "congestion control" = how many calls do i want to get = "routing"... comment: two policy - "location" policy (finding next hop) eg. domain policy. this doc goes directly from enum to SIP resolving - domain policy missing? reinaldo: incorporated some wording about the policy function. tied to "develop call routing data". comment: still missing in -01 (before section 5.1.5 have a section about domain policy...) domain == where i go? routing == how i go? different things? so one gives SRV records, and the other one gives some "overriding rules".. so the routing function gives how to get there. location can be ENUM, static mapping, etc. next question after resolving WHERE to go is HOW to get there. So do we have a terminology problem here? And after that, we have to decide what we're dealing with here. how do we name that "where i go to" namespace? And how do we name that "the ip address i talk to" namespace, which is different from the first one? i have then probably multiple ways (including the PSTN), but which way is the best one... and, those parameters can change very dynamically (where to terminate a call to). from earlier ("ready, shoot, aim") discussion: a policy server would help adding the dynamic stuff to the routing (based on who's asking, more dynamic than DNS). somebody agrees that we need a domain policy function in there. what you get first is an SIP aor, which can be reached direct or indirect. After that, you use the domain and it's policy to find a destination domain. And then you use SRV etc. to address the actual packet. somebody is worried about grouping too much functionality. are we missing a layer in the call routing? some may use plain 3263, other federations may use a dedicated peering fabric only accessible to members, etc. rephasing question: there are several dicrete functions proposed (media, signaling, location, policy, and there was an "qos" function in earlier versions) - do people agree on high level that this is the set we need on a high level? comment: no practical signs that a set of federations will agree on a common translation service from phone numbers to uris - may be true in future, but is not realistic now - means we don't have a single location funtion now. jon is uncertain what we mean by "function". has a rough idea what "signaling" and "media" function does, but the other ones? maybe the "policy function" should be renamed? could even be part of the "signaling function". there seems to be consensus that there is a signaling function. we found out in the message flows that there are two different policy functions. but we have a terminology probem: "next hop policy" vs. "what to use policy (which NNI)" and probably a third (congestion, dynamic stuff) - how to name those three? there might be policy functions spread all over, eg. in location function, etc. comment reinaldo: isn't that just the combination of two seperate functions into one (terminology problem then, again)... q: should speermint develop protocols to dynamically exchange policy information? there is a need on congestion control, etc. reinaldo: do we have mechanisms on policy differentiation depending on who's asking? consensus seems to be yes. haven't looked at the "procedures" section of the document yet. some stylistic mismatch with a reference here as well. will e corrected QoS/Media discussion: some description of transcoding would probably be useful. currently transcoding from one to another is a part of the media function. brian thinks we should have several very concise sentences about transcoding etc. parts of the media function. q: consensus about policy should be a subfunction within location, signaling, media? pretty fundamental question - think about over lunch? summary: discrete policy function OR subfunction of other functions... do we have a "canonical" message flow in the architecture draft? was a private request. actually might be dangerous in the arch draft, but should actually belong to message flow... unless it's an excellent example. comment: arch doc is in better shape than message flows - work on message flows underway? authors claim that they received very few comments. [ lunch break - continues with speermint_66.67_133239.mp3 ] terminology draft ================= dave speaks about updates: federation now very short, just explains what it is. otmar: what do we do with my draft? we doing trials on that, "we can't do it" is not correct hence. conclusion to ask on the list for what to do with it. if we would accept it as a WG item, what would we solve from the reqs? a: it's about next hop selection... there will be requirements that this is addressing sent to the list.. dave: we talked about diff policy types: "next hop policy", "nni policy", "dynamic policy". comment: we also have "routing policy", "domain policy", "location policy". so, what do we do with all that? requirements draft ================== reviewing open issues. issue that we just had with requirements for federation stuff... otmar: proposed a framework with the DDDS application, and announcing federation policy is one application. provisioning requirements now on hold? summarize key points: - UA requirements are attached to VSP? Endpoint reqs only "indirect"? again goes into transcoding issue: endpoints _could_ have shared a codec, but because transcoding happened, you are not aware of this.. architecture draft ================== conclusion about the various functions: pose the question to the list to not have a dedicated policy function, but make it a subfunction of the other functions? location function, signaling function could provide a policy function. "next hop" and "nni" policy could be part of the location function, eg. federation policy could also fit in here, and could be referred to. differences between enterprise and VSP? UNI vs. NNI? SIP itself doesn't differentiate. In the charter for this group, we talk about NNI, or? NNI definition could be federation policy. Federation policy could also mean "members are all licensed communications service providers". housekeeping & concluding ========================= - jason & david reordering milestones - preparing agenda for IETF 67 - work in suggestions & comments - like to see more use case submissions - get terminology agreed for use cases - please do revisions of drafts when everything is fresh in mind meeting concludes. Attendees: Chris Celiberti, Neustar Tom Creighton, Comcast Geoff Devine, Cedar Point Martin Dolly, AT&T Labs Michael Haberler, NIC.at Avshalom Houri, IBM Alan Johnston, SIP Station Hadrien Kaplan, Acme Packet Sohel Khan, Sprint Gaurav Khandpur, Comcast Yiu Lee, Comcast Otmar Lendl, NIC.at Alex Leung, Comcast Gene Lew, Neustar Jason Livingood, Comcast Daryl Malas, Level 3 Jim McEachern, Nortel Mark McFadden, British Telecom Patrick Melampy, Acme Packet Dave Meyer, Cisco Jean-Francois Mule, CableLabs Andy Newton, SunRocket Adam O'Donnell, Cloudmark Reinaldo Penno, Juniper Networks Jonathan Peterson, Neustar Penn Pfautz, AT&T Shawn Pouliotte, Nominum Tom Raleigh, Telcordia Brian Rosen, Neustar Jonathan Rosenberg, Cisco David Schwartz, Kayote Networks Richard Stastny, OEFEG / Telecom Austria Hannes Tschofenig, Adam Uzelac, Global Crossing