Notes from SIP WG. IETF 55 Recorded by Andrew Bender, taqua.com *** *sip *** sip meeting minutes from the 55th IETF Tuesday, November 19, 2002 1930-2200 Salon I Chairs: Dean Willis R. Mahy J. Peterson Opening Comments: dean-brian rosen and joerg ott have moved on... say thank you open to ideas on how to show appreciation new co-chairs are rohan mahy and jon peterson sip working group will include ... ? -status and charter 11 of 19 charter items are complete everything not done is late, so update to timeline is required 31 drafts on supplemental page 14 drafts in draft tracker working with rfc editors on 9 4 rfcs released / published since last time: RFC3310 - HTTP Digest Auth using AKA RFC3311 - UPDATE Method RFC3312 - Integration of Resource Management in SIP RFC3361 - DHCP Option for SIP Servers Agenda status and charter caller prefs content indirection identity and auth id s/mime 3261 open issues sip guidelines issues -caller prefs presentation- rosenberg- previous doc was a model for using 2533 wasn't sure how to fix some of the issues this took time changes- have been posted to list in detail priority has been changed from a token to an integer added support for quoted strings added the require-contact header issue 1- didn't have a lot of use cases came up with about 20, thanks to "paul" didn't get the document in before deadline for this ietf a bunch of applications need the "forced parameter" i.e. if call-ed ua doesn't say explicitly that it is a vm server, then don't connect current behavior is such that if a ua doesn't say anything about a parameter, it still matches rule this puts the burden on ua to declare what it ISN'T... this is impractical / undue proposal: add a parameter to require contact rule indicating "must match" issue 2- use of 'AND' within a single feature tag i.e. if you want to reach a UA that supports invite AND subscribe at the same time right now you can do this with two discrete require-contact headers previously, we were able to use 'AND', but doesn't match the 2533 model if there is a long string of ANDs, having to enumerate all of the contact headers becomes tedious / inefficient e.g. if you have both methods and languages to require, the number of contact rule permutations grows quickly, etc. *paul-last time you said this wasn't good enough. rules were written so you cant repeat the same values jonathan-these are separate values issue 3- weight q value algorithm based on amount of overlap in requested profile think I can devise / propose an algorithm for computing q automatically / intelligently *oran-what is the metric for amount of overlap? jonathan-don't know yet, have to propose algorithm *oran-will this lead to a spiral where each parameter has a different q? jonathan-don't state q explicitly; we will effectively compute q automatically, based on what was matched *keith-why is not exact match a limiting case of this problem jonathan-it is. this says give it a different q value if you don't match, vs. just kill it 2533 says this is impractical for the general case, but we have enough constraints here to do it. issue4- merge require- and accept-contact proposal is to use a single accept contact header field there will be a parameter for accept-contact that indicates the require behavior issue5- no one cares? / interest level surprising / confusing in light of the fact that this draft is one of the most cited normative references has lots of customers but very little comments / interest *somebody-lack of comments does not equate to lack of interest. may be that this is just not contentious anymore. issue 6- priority semantics may be out of scope, since this is really a calee rather than caller issue... proposed that this should handled through CPL issue 7- forget it / not discussed (scribe was looking at display when slide was flashed) issue 8-escaping 2533 syntax for feature tags allows characters not supported in a token :( there are already feature tags that use the colon and slash for urls disallowed by the token however, allowed codespace for a token is actually larger than that of the 2533 feature tag proposal is to use the '!' or single quote allowed by token for escaping of special chars *fluffy c jennings-cant we just escape using the established means for url/uri? (i.e. '%') rohan-this is just remapping fluffy-convince me strongly this is better than uri escaping, please. somebody-there is nothing worse than "almost compatible", as folks will assert that this is "almost 2533", etc. jonathan-btw, percent is not allowed in a token, so we still have a problem rohan-also note that this stuff does not go on right hand side of equal sign, so we can't quote it somebody-use something other than single quote please, for the sake of making this readable *keith-there should be only one escaping mechanism rohan-you are missing something. there will be not translation that occurs. we are just renaming feature tags in the token codespace, etc. jonathan-yes, there is never a decode next steps- one more rev with these issues addressed may be ready for wglc after that? rohan-chairs think 2 wk wglc would be appropriate for this draft jonathan-this is on the higher end of my priority list... resolution should be snappy what to do about use cases? should it find a home? should we discard, or should it stand alone as its own sipping things. *somebody-don't discard... can it be an appendix paul-we should get rid of it (use cases). doesn't have requirements. you can't answer all of the issues. is that important that you cant answer all of the use cases? paul-the move to use 2533 seemed like a nice thing because it provides a lot of semantics. we keep playing with it so that it doesn't feel like 2533 anymore jonathan-graham (klyne, 2533 author -scribe) is not adverse to anything proposed along these lines so far, including my q factor stuff. paul-the scariest part is the priority munging thing *sinnreich-need a provision for inserting a relay for hearing of speech disabled oran-in favor of maintaining this somehow. violates the principle of "least astonishment"... -content indirection mechanism presentation- sean olson- open issues- use of size parameter in content-type - this can be used instead of content length header richer negotiation of indirection per mime type security issues- sips/smime, access control, revocation / invalidation proposal(s)- * use standard size parameter* * recommend s/mime and or tls * acl and negotiation are out of scope for this document... should be solved for sip in general * suggest wglc jon-why do we need size? sean-it is optional. idea is to know how big something is before you get it... recommend it be mandatory unless objection fluffy-offer option to leave it out jonathan-if you know what it is then you can put it in, etc. Draft Tracker: demo by rohan allison mankin-anything you want to put in the draft tracker can go there 9 in editors queue at 48 hours stage compression has been approved... page will be updated after meeting as per allison caller prefs and session timer. some events will require WG attention. guidelines draft points is at odds with 3261 re: cancels and provisional responses for new methods 3261 says provisional responses or cancels SHOULD not be sent for non-invite methods guidelines draft says behavior of method upon cancel or provisional must be defined *rohan(personally)-think non invites should be banned from using cancel and provisional responses rohan(as chair)-just because you can do something doesn't mean that you should. *vijay?-did we originally have this for non invites? rohan-spec says you should not send cancel until you've recd a provisional. as far as I can tell there isnt a reason to do otherwise sparks-there is a reason why you need this; if a non-invite times out without provisional, then dns srv says you should failover for that endpoint. this is REALLY bad if it makes proxies unreachable. immediate provisionals are clearly bad. draft will say any behavior you engage in that consists of delaying finals is bad. rohan-robert will start list discussion as soon as draft update is available. *jonathan-tcp throws a wrench in this, because there is no other way to prevent retransmit rohan-tcp vs udp did not go over well somebody2-??? *keith-can we make sure to distinguish between 100 trying from other provisionals? yes. *somebody-what about bye? rohan-in the bye case failure is actually not a problem, because the desired behavior occurs anyway -authenticated identity- jon peterson- -will not use all 45 minutes -changes peterson-00 has been split into two documents that are both ietf drafts now: sip auth id body: spec of a mime body that could be used as an authentication token sip identity: status codes and practices for providing a token -auth id body no open issues i am aware of if you have a sip frag, how much needs to be included to provide reference integrity and reply protection must contain: call id, form and date should contain:contact, cseq, to *sparks-might actually want less wrt call id. this comes up with referred by. jonathan-could downgrade call id *rohan-in review of 3pcc, it was agreeed / determined that we should be able to secure page mode exchanges, etc. *jon-what are requirements? rohan-message integ over the body with replay. *fluffy-cases where multiple signatures are required, with more than one party to vouching jon-draft does not prohibit this, but does not suggest more than one. goal is not necessarily to make this tamper proof sparks-there is a lot of useful work here that could be applied for other contexts we have already seen applications that have differing replay requirements referred-by actually uses this for authentication *sparks-this will take a lot more work... *jon-you don't know a-priori when you send a sip request if a b2bua is out there. b2buas do a lot of evil things. you could tunnel I guess... somebody-this won't work without callid integrity *rohan-if you cannot rely on using a call id that will be the same at each end, then you need a different mechanism; that is fine *jon-there may be reasons why you might want to see if there is some intermediary that may be tampering with the bodies, etc. *somebody-consider for including parameter specifying where userid is valid? jon-no jonathan-whether or not you can do this through a b2bua, depends on what you define a b2bua to be. so, unless you define granularities of what headers are supported for each case, you can't be serious about that. jon-it might be worth inserting some text that says that hostile b2bua treatment might not preserve authentication. concerned about the vulnerability in contact header field. (or its absence) contact header is one of the stronger things we have to facilitate reference integrity *robert-if you are using it for auth inside a dialog, then contact should be a must *jon-ok scales down some of the behavior suggested in 3261 deals with sip frags specifically for authentication i think it is pretty straightforward -authentication service defined: there is a server in the network that a ua will send request may be the same entity as the local outbound proxy will add a token to sip message (for responses as well) the place you send dns requests is probably the right place to do this describes the way that body can be added to / modified in requests for the following cases: 1.redirection 2.try again with this token (use auth token) not useful for responses. proxy can not add bodies, so that makes it a b2bua 3.content indirection ua picks indirect uri that is populated by the auth service works very well for responses this is attractive but, difficult to predict uri that will be populated by auth service *somebody-why couldn't we use a header? jon-put a mime body in header? given the s/mime direction, it more or less has to be a body. very difficult to apply security properties to headers. *keith-we do definitely need this for responses as well a requests. when we were discussing long term vs short term this could vary... rohan-you can say "trust based" vs "cryptographic" :) *keith-is there a way to assert "this is my identity for free calls", etc. jon-as long as the same auth service for these. don't think we need to define free phone call header. could do that in body, p-headers, etc. keith-this is my identity for the purposes of charging, etc. jon-says you can add any other auth information you want *fuzzy-requirements question. do we need to discriminate identity on a per-service basis? jon-from header has a strict definition for isup *keith-we have multiple identity headers already, but not clearly defined semantics. it is unclear whether auth service must implement at least this token type *jonathan-you have to for interop. if were supporting a number of different types, how do we need what is supported jon-agree that you must indicate aib is the format used *jonathan-as soon as you say there are other formats, you have a negotiation nightmare allison-sip is not so simple... we don't have to limit its future, but we can use straightforward approach using codepoints, etc. jon-getting aib alone would be an achievement to provide reasonable federated identity. maybe we should just declare victory on that. aes and smime- everybody has already implemented s/mime, right? :) there are opportunities for optimizations, perhaps to make it easier to implement 3261 specifies current minimum profile, requiring 3des it is believed that aes has advantages, is more lightweight, etc. should this be 3261 errata vs. separate draft? suggest we do a draft now, so we don't have to wait *rohan-this also has the advantage of requiring the same algorithms for both s/mime and tls. technically if you do s/mime and tls today you have to do both types *vijay-will this be mentioned in the discussion / draft of 3261 issues? jon-yes *jonathan-most stuff in bugzilla is silly, this is much more serious also cleaned up misc stuff transport area advisor? has already provided comments on wording would like this to be a wg document *oran-this is possibly a nit-is the use of "all other encryption" wording advisable? rohan-ok, any other supported *somebody-think it is important this happens soon *keith-we should not create rfcs that say don't implement this rfc rohan-obsolete vs updated allows us to address this allison-it is an accepted practice to update only sections of an rfc with another rfc. may want to consolidate sip updates at some point. -3261 open issues presentation- jonathan rosenberg- don't think there are enough real 3261 open issues to talk about -session timer submitted -10 draft rewrote overview semantic changes: added 422 timer too small, specified that standard retry behavior should be used answered often asked question: a mid-dialog re-invite without session timer cancels the timer. this is consistent with the behavior that the initial invite uses -issue several comments stated that session time was just too complicated there were no documented requirements, but motivational text is provided in the introduction useful for one thing only: cleanup of stale state, so the timer does not have to be really large supports asymmetry, proxies adding headers, negotiation of values -options 1.redefine scope by throwing out requirements, then design a simpler protocol 2.reword to clarify 3.keep scope same, but approach new design dialog event package could be a stand-alone solution for this problem *somebody-only sometimes is this true. *jonathan-this evokes the globally routable ua problem all over again. agreed.my preference was to pursue option 2. think this was list consensus as well. *fluffy-perfectly happy with this. important property is to make sure that timer runs on the ua, not the proxy. jonathan-don't understand fluffy-if proxy in the middle doesn't have to run the timer itself, can re-create state through a reset of the proxy also. *keith-this is dialog specific, not generally applicable. *somebody-subscribe an register will naturally time out, but invite lacks that property. no requirements exist, etc jonathan-dont think redoing requirements process is necessary dean-should be a reasonable discussion of requirements in the draft *eric burger-this has more valuable uses elsewhere, especially media servers / non humans. -which method to use? up to version -08 only invite method was used in -08 allowed update offer/answer without sdp *dean-can still use invite for this * rohan-offer/answer is necessary for a device that is controlling a middlebox... sees offer/answers, pinholes them. not stateful, but may need the "refresh" maintenance. rohan-how many implement this now: hummmm rohan-how many would implement something else instead: hum rohan-how many people violently object to moving this forward as is: -0- -sips uri attempting to do two things: 1.e2e security on an address of record 2.can also have just hops that are sips uris, for protecting only portion most of the text describes #1, confusion stems from the passing mention of #2 items have to agree what it means to protect a hop to fix this *jonathan-sips implied that since you requested sips: all hops to that point would be sips: jon-here if the to header indicates sips (vs contact), then this would require every hop to do it. jonathan-there are complications with record route. jon-we have the same problems for transport=tcp... how do we handle that? *sparks-are you winging another aspect of dean's interface problem? jonathan-this is the same issue that gonzalo's compressed sip handles. should we have a consistent scheme for compression, record route and sips? gonazalo-double route trip works now, but may be ruled out here sparks-if we capture this abstraction with double record route, it may introduce other constraints, i.e. for sips. specify a general mechanism, but indicate when special cases occur. create an exploratory draft that lives in one place *sparks-we started to talk about loose route issue with sips. there are two aspects to loose route: 1. just can't do sips with loose route (proposed) 2. fixing the conflation of route set and remote target jon-i read this too hastily. don't think that this is where you should require strict route. jon-regardless of the approach, 'section a' text still needs to be remedied go to www.sipwg.org to see bugzilla logged against 3261-3265 some bugs there were carried over from bis-09 may not make sense anymore. -s/mime report- rohan-meeting ended 45 mins before i got there, so they must be making all kinds of progress, etc. Closing Comments: mib is not on draft tracker... a thorough update expected we will do a 2 week wglc for session timer will do the same for caller prefs after revision sean's draft will go to immediate wglc