SPEERMINT WG minutes ==================== IETF 71 - Philadelphia, PA. Wed, March 12, 2008, 1300-1500 CHAIRS: Jason Livingood Daryl Malas SECRETARY: Alexander Mayrhofer RAI AREA DIRECTORS: Cullen Jennings Jon Peterson RAI AREA ADVISOR: Jon Peterson Agenda: http://www.ietf.org/proceedings/08mar/agenda/speermint.txt charter: http://www.ietf.org/html.charters/speermint-charter.html Audio recordings: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf71/ietf71-ch4-wed-noon-speermint.mp3 status report (Jason/Daryl) =========================== nothing new on the chart of document flow terminology beyond WGLC, voip-use-cases close... architecture / requirements are next to be finished - coming up soon. then naptr use / message flows bashing agenda - no objections VoIP Consolidated Use Cases - Adam Uzelac ========================================= draft: http://tools.ietf.org/html/draft-ietf-speermint-voip-consolidated-usecases-05 slides: http://www3.ietf.org/proceedings/08mar/slides/speermint-0.pdf changes: most were syncs with terminology, so waited for that to settle. federations are going to be discussed later direct static peering slide shown. indirect lookup, direct peering slide. David Schwartz: we don't indirectly look up something here - this is assisted peering. Daryl: fixed that in the terminology draft David: agree, terminology is correct - "assisted function". This is an "assisted" example, not "indirect lookup". Jason: Diagram fine without the words on top? David: Yes. Jean Francois: We keep spending time on terminology, instead of focusing on what arrow #2 means.. says that #3 returns the terminating SBE, what if that is simply an ENUM tree? Jason: Suggesting to put additional detail into the doc? Jean Francois: what parameters are you looking for the function to provide - that should be it Daryl: Use-case draft should not outline solutions Jon Elwell: Agree with JF comments. unclear from the digram which function we query there. in #2/#3 Adam: We could go over and over about this and that scenario - there will always be some ambigiuity.. Jason: Suggestion to send "other" use cases to the list - please don't complain you don't see them here, rather send them. Jon Peterson: Problem with use cases is that there are so many of them. Commenting on JF's point: specifying what you send and what you expect (what kind of information) would be appropriate here - at a high level. David: there might just be one arrow - but there might be more queries. Outcome: PLEASE mail use cases to the contributor. WGLC in about 4 weeks planned. Adam: Next slide "indirect lookup", "indirect peering". session "transiting" to the ultimate destination provider. Next steps: cleanup, add message details. Q: Are there any "on-demand and DIRECT" use cases in the wild today? Brian: relays for deaf people. any consumer can talk to any relay. Otmar: RFC3263 is a live example of that... Jon Peterson: The use case of an "independent" SIP client on the notebook is the same... Are we ruling out 3263 cases here? Q: Is that "open" stuff really peering? It works today already... Adam: maybe of no concern here.. Adam: Q: is federation for "intra-domain" traffic? Daryl: Federation is made up of more than one domains, and that has a common policy.. Federation does not mean that once i am member i can always talk to anybody? Federation _is_ defined. David: currently have today peerings of federations that peer with other federations. Adam: Q is whether we need to say with the scenarios whether "this could be a federation". Q regarding federations... Daryl says that federations are made up of all the scenarios described... JF: stuck again with the definition of the federation. in favour of keeping that in the doc. not create a seperate pocket for federations, but for the scenarios say what cahnges. David: Federation can be a "mixture".. eg. name what different kinds of federations you could have. Jon Peterson: _use_ cases should be substantiated in that draft.. Adam: Will issue next version next week - and then about a month until WGLC? Jason: If you think you haven't got enough feedback, please raise any issue. Then new revision, then make detailed review, and then WGLC. Requirements - Jean Francois Mule ================================= Draft: http://tools.ietf.org/html/draft-ietf-speermint-requirements-04 Slides: http://www3.ietf.org/proceedings/08mar/slides/speermint-2.ppt Scop and status changed since 03 - producing an informational defining requirements that enables use cases. Main changes: removed the SIP hitchhiking guide stuff entirely. Intent for today is bringing up open issues that pop up very often - same things come up, and seem to confuse people.. eg. "egress session border elements" - protocols to "communicate" them.. there are some reqs. regarding inbound traffic engineering. Brian Rosen: I understand the Requirement. I think that is provisioning, not protocol. Jason: what about policy? Brian: the only policy i can think of is the destination tells the source which one to use, and that does not seem to happen. David: Regulatory issues? Hadriel: media profiles, etc. quite more than ACLs. they can even change dynamically. conclusion to keep that in. chris ??: communicating the inbound SBE could be useful for antispit. JF: Has some implications on IP acls - not going there. ??: who is the user of that egress information? John Elwell: agree that this might be part of a SPIT prevention requirement - however, i think this is provisioning, not protocol.. opne issue #2: Data path border element. "where might you see media coming out of my network". Call by call that is sdp, of course. Looking at other mechanisms here. might be neccessary to color packets in diffserv differently, depending on the source. Adam: I believe that is needed. Example: barrier plane transcoding.. Daryl: Is that dynamic or static data? don't disagree that this is sdp, but might there be a different requirement too? JF: SDP solves that for call-by-call.. Elwell: If not call-by-call, then it is provisioning -> PEPPERMINT issue #3: peer and media variability. different elements for different peers, and different elements for different media. eg. voice borders vs. im borders. David Schwartz: Same as like "SS7 clear channel", not provided or provided. Alex: "trust level" variability Open issue #4: Security cons. sat with severio to integrate some text. lookup protocols must allow for securely exchanging data. David: Has to be mutual authentication. We see that with redirects - many people don't use them. Dan York: implementation MUST ALLOW, but you're not required to do so. Opinion to remove 5.3? Dan York: remove the req. on TLS, or remove it entirely? Looks like an implementation guide? Brian: TLS is not the only option. Carriers are interested in IPsec, for example. JF: Removed all the other things, that was the only "close" stuff left. ??: This is not what the document is for. We could think about giving security advice later Jon Peterson: rather outline the properties than the protocols to use... Dan York: Agree, put in that "there needs to be a mechanism to..." but not name protocols. Jan Seedorf - speermint security bcp ==================================== Draft: http://tools.ietf.org/html/draft-niccolini-speermint-voipthreats-03 Slides: http://www3.ietf.org/proceedings/08mar/slides/speermint-1.ppt up to 02 idea was to investigate and list security issues now requirements from threats are included in the requirements draft itself not adopted the new LRF. identified threats specific to a function, and identified countermeasures. David: important to focus on SPEERMINT-related threats _only_. Severio replies to David: Fuzzing _does_ come into peering. David: That's not _different_ for speermint than for any other SIP UA. Jan: see you point - will look into this. Asking for adoption of the document as WG item. Hadriel: Agree with having a doc, but that lists things that nobody does.... not sure whether that doc is a good foundation. Peter Koch: Thinks this is useful, think is useful for having such a doc in the WG rather than outside. BCP are premature - informational? Which milestone requires that doc? John Elwell: not clear about the relationship to the requirements doc. David: Seconds what peter said. be careful to not steer people in the wrong way (There might be more than TLS). This is not what people are _doing_ (no BCP). Think it's premature to be added as WG item. conclusion (jason): chairs will work with the authors, then will ask the question on the list whether it should be adopted.. think that it's a good doc, and covers something we'll need at some time. Daryl (speaking for Reinaldo) on Architecture ============================================= Draft: http://tools.ietf.org/html/draft-ietf-speermint-architecture-05 Sldies: http://www3.ietf.org/proceedings/08mar/slides/speermint-3.ppt background: based on the reqs draft the idea is to define what an architecture should look like. current revision is 05. changes: aligned with terminology (as much as possible). removed normative wording. number of comments received on normative TLS use. Reinaldo already working on next version of draft. messages-flows-02 died... too much changing in terminology, architecture, requirements. now going back to those old drafts. Hadriel: Seems as if it doesn't cover the indirect case. Daryl: Not intentional Open mike time ============== hadriel: talking earlier might be good if peppermint gets chartered. shockey: lets set up peppermint before we define dependencies. Daryl: How is the feeling that that SPEERMINT is progressing into the right direction? 1) sentiment correct? 2) .. 3) adressing the right tools? John Elwell: Where are the things we need to conform to? Shockey: Don't ever make something that looks like a cash flow document. Meeting concludes.