speermint wg ============ milestone review ---------------- stay very focused on near time milestones agenda bashing -------------- agenda accepted staying tightly on agenda, discussions moving to end of agenda. terminology draft draft-ietf-speermint-terminology-00 ----------------------------------------------------- changes: remove reqs, added federations text very few comments, ready for WGLC? haberler: "peering" was in a BoF this morning defined as between originating and terminating only, policy announcement. will send text to list. jason: please look at this draft, send feedback. we will make a -01, and then move on. draft-ietf-speermint-requirements-00 ------------------------------------ jean francois mule there were a bunch of threads on list - clarify scope - review / discuss - discuss feedback WG deliverably March 07 ( BCP) ("submit minimum reqs for SIP VoIP interconnect") - document bcps in current networks, or do we state reqs? or bit of both? schwartz: "current practices" without "best"? dave: "BCP" is term from publication process jon: take bcp liberally - bcps have been implemented david oren: rohan: document "bad things" as well, and why? intended scope: who's the target: nodes, users? or for design goals of the WG? proposal: write for ip nodes involved in VoIP interconnects, 2119 style application is VoIP jason: post to list? scope (3) no other req id in milestones options: - one req docu - or two or more (generic and voip) jon: single doc suggested, but subsequent doc could refer to sections of that. categories of reqs DNS, call routing data, enum long thread on min sip/sdp media related security call routing data: sip vs. tel? 3824 (tel numbers with SIP) dns names (resolveable) 3263 (locating sip servers) enum: how client work? min service types? resolver reqs? (dns client) important for implementors, looking for feedback. 3263 poll - state of implementations: 40% use NAPTR 50% use SRV (does not say whether NAPTR is just for ENUM?) believe minimal support for NAPTR transport selection. operators: 3 responses, one says its way to go, 2 others say no (statically configured protocol). other source: sip forum ip pbx few responses from list. conclusion: not widely used. suggestion: SRV should, NAPTR optional ? francois ??: dont have input for that. ok to warn people that not everybody supports this. mule: 3263 not clear, 2 instances of "must" lowercase.. francois ??: things start breaking of trying to work around this adam ??: very concerned about weakining normative stuff in standards track docs. hoeneisen: openser now supports NAPTR mule: operators using internally, kuthan: nice thing that has been released, but nobody cares. sip/sdp: email discussions on list first should agree to set of RFC 3261 + "hitchhiker" others: PRACK, UPDATE, reason header field insist on some reqs buried in these RFCs? or do we lower the bar on some specs? rohan: shouldn't include PRACK, etc. 3261/3/4 should be it. would be useful to go thorugh and clarify certain things. stastny: should be something about conveying identity media-related in /out scope? codecs (wireless not g711) security long thread on TLS - we lack reqs for SPEERMINT security top / bottom draft (bottom: start with deployed stuff, and work up from there). charter assumes l3 is there? q: top /bottom up? jason: post each one of those question as seperate thread to list. peering architecture draft -------------------------- new authors & contributors significant revision since last time peering network context reference peering architecture location function: discovery of next hop peering, eg. ENUM, DNS. out of scope: NP operation function: discovery of SF sf: discovery of endpoints, exchange of params for mf mf: media function (eg. transcoding) qf: reserves resources / policing sf and mf together or seperate Q: sense of the room - tough mule: define functionality of squres, some have been declared out of scope. khan: last time only private, so added public these this time call flows draft (penno) ---------------- more comprehensive than SIP call flows (now including media relay) peering phases: - discovery - security establishment - sip signal exchange - media flow optional: SIP policy, domain / federation exchange? taxanomy of Peering Scenarios on-demand vs. static. moving forward: refine/incorporate new message flows, introduce with federations etc. align terminology wg adoption? shockey: like this. sense of room: would be useful - no hands for "no". cable use cases ---------------- darft not yet in repository, but still discussing it here. jason: use cases show up later in milestones, useful. can show reqs gaps, and "test" terminology. 2 layers: user location layer, session routing layer user layer: resp. for locating peering session routing layer: routes SIP messages schwartz: SIP routing may not be point to point ok, multiple proxies actual invite call flow nat issues. future wokrs: - peering policy exchange? - user location 3263 enough? - peering security? TLS? - QoS important. quality for media a must. - accounting and billing - what is the right model? khan: need OF for accounting and billing? need QF for QoS? adam, global: source based routing? haberler: peering policy distribution - need instance identification, but distributing not neccessary. schwartz: peering qos: should be universal regardless access. 3263 problematic? yes, not using it atm. eric burger: is ist _documenting_ or _proposing_? maybe more useful than just "Cable". jason: ask other people using thst eric burger: collect more cases.. more a individual? jon: useful as informational shockey: have "experiences" as well in ENUM. jason: ok, if consensus then add adam, globalcrossing: dave: trying to get use cases jon: yes, getting collections of cases. we could concat them before, or make individual docs. mule: no opinion, but other WGs where deployments have been documented. vendors should/must comment on those use cases... peering - minimalist approach ----------------------------- what's the output of the wg? imo peering convention as simple as possible consequence 1: describing USE of other protocols. conseq 2: multple possible, but we should use ONE. the approach: - discovery user enum / infra enum (sip / pstn services) im / pres uri -> go RFC3861 - peering: - do 3263 - contact via TLS for mutual authentication - exchange traffic, use identity header schwartz: TLS for minimalistic solution? TLS or not? no signaling protection: (not allowed at IETF, 3385) schwartz: can use if i want without TLS mahy: ietf will not document in BCP solution without security eric burger: RFC3365 must be done. does not mean that nobody does this. needs to be in security considerations. ??: ipsec _or_ tls as options? option to use TLS _or_ IPsec bad idea. requires everyone to implement both - bad. sips bad idea as well (is end to end, no clients support this) hadrial capland: accept practicality to not do TLS? rohan: no, between carriers is fine! hadrial: can't compete against the market force. shockey: check private ENUM as well - should be in scope schwartz: The decision to use TLS itself is already a policy decision. newton: what about the root ca who will do that for the TLS stuff? And: peering applications should not check user enum, because infra is specifically for this. trust issues ------------ tls only method to authenticate, ipsec needs to use source address filtering, which requires manual configuration. build list of trusted roots? RTC provisioning requirements ----------------------------- communities need a way to connect between them in easy / secure manner current experience cumbersome, error prone. definition "community" / "provisioning" core reqs: secure push /pull of provisioning data clearing house (interconnects multiple communities) jason: put some of the reqs in the docu of jean francois? schwartz: premature to push/pull policy if we don't have background stuff. federations ----------- full mesh is unrealistic transit federations. rules according to hop policy complex situations would require a full routing protocol till this morning 3 steps: federation internal / call flows / transit scenarios summary of 11/7/ discussion: transit too complex, fabric anonymization, not distinguish between "transit" and "hosting" federation (existing mechanism can be used) further work: spell out restrictive / side effects aggregator role to be explored "discovery call flows" into pennos draft? daryll: make federation discovery via dns a requirement? could use sip messages as well haberler: need to agree on one solutions. jason: need interim meeting? dave: we have now 2.5 architecture drafts, which one to choose? rohan: suggest to use his draft, of course ;) jon: premature to choose an architecture - use cases are influencing them. collect more use cases. (least common denominator). hadrial caplin: are indentity mechanism being discussed? rohan: reason why identity included is because it identifies sender. domain of sender might different from domain of last hop. shockey: identity needed for billing (eg when going to the PSTN) hadrial: work in progress to make that work ??: glad to work on that. put in touch with security people as well. jon: identity: endpoint wants to know who is on the other side. scores of drafts depend on being identity in place jennings: sip has lots of approaches. jason: requirements should be matches with mechanisms. schwartz: policy decisions on border, mechanisms for acting on rules needed which rohan: contradiction schwartz: tls is just another policy decision. tls good solution. khan: requests comments on his draft. daryll: identify problems that we want to solve. stastny: what is the sep 2006 deadline? jason: initial architecture draft - need decision on rsn. dave: will hit min reqs earlier than mar 2007 schwartz: "cleansing proxy" needed by service providers - SPs want to "have hand holded". shockey: no need, functional part of edge proxy, not part of federation.