Reported by Tom Taylor. Due for revision soon.
draft-sijben This was left over from the first session.
Problem: how to pass RTCP through NATs. Solution: SDP already supplies source routing capability (c=line per media stream). Handle RTCP by imposing convention that its source port will be one greater than RTP receive port.
Jonathan objected that this was incompatible with his view of cone NAT operation. Paul received support from Dean.
draft-undery-sip-digest
Motivation: why more integrity? -- limitations of existing methods
Draft reviews two choices -- extending the Digest scheme using qop parameter is backwardly compatible, but vulnerable to step-down attack -- proposed answer is clean start incorporating latest HTTP work
Authentication-Info -- HTTP form doesn't quite work -- add a couple
Michael T asked why this particular set of headers to cover. James replied that protected headers are selectable. Michael suggested this still a patch on Digest -- still doesn't cover a number of threats. (Hop-to-hop vs. end-to-end protection. This is just hop-to-hop.) Henning had a response.
Brian Rosen noted security BOF coming up. Need agreement on threat model. Hop-by-hop will be solved, real challenge is end-to-end. Allison noted threat model doesn't have to cover every possible threat.
Jonathan: predictive nonces. ----------------------------
Intent: improve Digest resistance to replay attacks. One-time nonces cost a lot in terms of state. Proposal: compute nonces as hash of predicted headers.
List discussion: needs to include private key of proxy. Doesn't solve man-in-the-middle attacks. Some tweaks to mechanism.
Basic question: is it necessary to standardize anything? Main reqt is that main spec advise against changing of headers between request and resubmit. Concerns expressed by Martin Euchner. Jonathan emphasized: incremental improvement, better than no security. James Undery made point. Henning made point on use of absolute vs relative timestamp.
Hoeneisen: Proxy-Supported --------------------------
Intent: allow UA to query in an initial request the capabilities of all record-routing proxies. Assumes Route header specifies strict source routing.
Has a number of advantages over Proxy-Requires -- more calls can be completed
List concerns: most features require support in initial request, hence need Proxy-Requires
Is there general interest? Jonathan: very complicated to make this work. Likely to get more infeasible as Record-Route discussion proceeds. Rohan? Dave O: would like to work through some practical examples of what this would be used for (ie clarify reqts)
Dean summation: might be interesting, but not of interest to group until a real application is demonstrated. General agreement.
draft-kiss-sip-s100rel Markus Isomaaki presented --------------------------
SPRACK instead of PRACK: reduce number of messages to establish a session Needs special transaction model: SPRACK-specific proxy behaviour. Makes resource reservation flow simpler.
List discussion: effect on SIP transaction model need for proxy support -- motivation for Proxy-Support Jonathan: yes, helps wireless a bit, but does a lot of damage to SIP. His counterproposal the transport shim layer for compression.
Basic assessment (Brian): interesting, but not a WG interest
Changes To Session Timer (Jonathan) more leftovers from first session ---------------------------------
Made consistent w/ bis recoverability -- use From tags -- 481 on onknown leg fol by BYE 30 min rec minimum Reject low session timers -- new code 422 ... Biggest change: refresher parm to Session-Expires -- makes clear which side sends re-INVITEs Procedures for initial INVITE, re-INVITE. Solves problem with role-switching on re-INVITEs. Open: use Min-SE in 422 instead Session-Expires? Jonathan rec. "yes". No disagreement. : use relative times only? Proposes to remove absolute time. No objections. Looking for feedback on list.
Open Issues in bis -------------------- Jonathan
Comments associated with issue numbers.
Issue 113: overlapping fwd transactions Current limits: no INVITE within INVITE, only one non-INV at a time. Limits throughput, doesn't allow INV update Reasons: INV: confusion about most recent session desc. Non-INV cannot guarantee seq of delivery. Ques: would this confuse state-aware w/ RRoute Jonathan: works w/properly implem proxy Rohan: offer w/ SDP fol by reINV w/ no SDP. How to interpret? Dave O. provided safe interp Proposal: allow overlap INV w/ conditions: each req has full state (Contact). Most recent response has precedence. : allow overlap non-INV: need method of strict sequencing carried within content (body). Jonathan welcomes comments, not entirely sure it will work.
Issue 7: CANCEL for non-INV Allowed by spec. Seems strange -- non-INV has to be answered imm, hence CANCEL always a race. Makes sense only because may be human interation. May also wish to give up on timeouts when no response comes. Comment: This last is a reasonable motivation. Dave O: suggests leaving in spec., but note it is rarely useful. Robert Sparks, Rohan. Henning: remove it, may regret for some future case. Adam: concerned w/dead code. Rohan would remove.
General sense that there is slightly more sentiment in favour of removal. Jonathan open to private discussion. Will report back to list on conclusion. Allison suggests hum. Hums on both sides. Management really wants closure. A small number of people indicated by hum that they would object if provision would be removed. Brian asked for objectors to discuss with proponents -- looks close to rough consensus in favour of removal.
Issue 10: stripping maddr
If a client sends a req to URI w/maddr, using the maddr, should it strip it first? Yes (as stated in bis-03). No objection.
Issue 11: RR non-INV mid-call. Proposal: proxies can record anything. UA ignores RR for mid-call. For non-INV "session": proxies can RR anything. UA behaviour method dependent. ie SUBS can say NOTIF RR establishes a route set if there was none.
Question for clarification. Dependency on Issuye 138 (next)
Issue 138: fork or not to fork?
Forking for INV: deprecate in favour of B2BUA? No!
Forking for non-INV: need some way of knowing who you are talking to. Must have three-way handshake. Can it be done in non-method-dependent way?
Proposal: allow. Method specific resolution. eg SUB/NOT defines its way.
Deprecate forking of INV? Hum very weak: will not deprecate. Deprecate forking of non-INV: Jonathan notes list has identified two cases: forking can reach a number of interchangeable entities, or forking reaches different entities, would like results back from all of them. Jonathan proposal: allow non-INV fork because of this latter case -- has a real case.
Argument: should disallow. Not widely deployable. Can be done at UA. Jonathan notes now allowed, hence not a deployment issue. Adam argues for forking. Henning: B2BUA not scalable, hence not a substitute for B2BUA.
Dean notes we haven't solved QOS issue for forked calls. Jonathan counters we ha\ven't solved w/B2BUA. Noted that CANCEL for forked SUBS per normal behaviour is an issue Hum: rough consensus for forking of non-INV.
iSSUE 11 reprise: Hum: allow RR non-INV: accepted (no opposed)
Issue 20: mixing unicast & multicast in offer/answer If offer SDP contains uni, can response contain multi? What does it mean? Proposal: general rule: answer should be something offeror can do. Hence don't send in answer. Dave O: thinking of conference bridge, consider incoming and outgoing as two different streams. Jonathan interp: bridge sends re-INV adding multicast stream.
Hum: accepted Jonathan's proposal. Add scenario to conf models draft: how to set up unicast to bridge, multicast from.
Issue 23: dynamic PT reuse
Spec says you can't reuse a dynamic PT number used previously for a different codec type Implication: limits no. of codecs in a call to 127 In principal, can reuse it once you've completed the transition. Restriction is there to not req SIP signalling to be synch w/ media synch
Prposal: keep restriction. Accepted -- no oppos.
Issue 146: reuse disabled streams
Spec says once you have disabled a stream by setting port = 0, can't reuse it.
Implication: SDP size increases as you disable/add streams Reason: to maintain implict ordering of codecs. Proposal: cannot remove disabled stream But if new one added, can take disabled stream's slot within SDP. No restriction on media type. Keeps ordering w/o increasing size of SDP.
Comments suggested not worth the pain (backward compatibility.) Motivation apparently 3GPP manipulations. Henning noted FID draft in MMUSIC provides better solution. Jonathan withdraws proposal for change. Gonzalo: FID has limitation, doesn't solve issue. Conclusion: need more discussion.
Issue 58: rejected mid-call SDP in 2xx
Consider offer/answer where SDP is in 2xx/ACK. Consider a reINV in this model. Q. how does UAS reject entire SDP? In init INV, we use a BYE. Don't want one for reINV. Possibilities: --ACK, disabling all streams. Re-INV w/old SDP. Problem: what if response to re-INV is non-2xx -- define NACK -- not bkwds compat Dave O: turn 2-way handshake into three-way. Jonathan: not exactly the problem. Dave: summarizes -- existing rule: response subset of offer. Assumes starting point was null. Re-INV different. Suggests answer might be to send back no SDP, with meaning "keep previous session description". Basic problem is to keep transitions graceful -- should never move from working to non-working state.
Jonathan summation: will use general approach of using some signalling means to say that previous session description should be rtetained. Will sort out what this should be.
Issue 133: on-hold indication
All-zeroes indication of hold was a hack. Problem now is that it removes IP for receiver reports, and these are need in some cases. Also IPv4 specific.
Proposal: use a=sendonly for bidirectional media, a=inactive for recvonly. Must still be prepared to receive c=0.0.0.0 for bkwd compat, but don't send it. No other explicit hold indicator need.
Dave O: may need means to synch resource reservation state -- provide for in spec. Jonathan argues each end can manage its own state. Dave will think about it. Rohan suggested method of signalling, Jonathan questions need.
Michael Thomas: SIP Security Status
Currently:
2543bis currently leaves HTTP stuff, drops rest. Many BOFs, pts of view, but starting to identify common themes. Several drafts since last IETF. One framework/reqts draft, several concrete scheme proposals.
Many drafts showing awareness that we don't have enough now.
Low probability that any one draft will get everything right.
Proposal: separate out easier from harder part, move that part forward: "outside" vs "inside" attacks.
2543bis provides a base mech for outside attacks: IPSec, TLS, return routability Retain HTTPisms for compat Allow 2543bis to adv w/o requiring answers to hard-to-counter "inside" attacks
==> moratorium on crypto
Work Program: Create Reqts/Threats draft Come to consensus on bis base reqts Create framework which can accomodate current popular authen mech: X.509/PKI, Kerberos, Pre-shared, RADIUS/AAA Focus on a simple initial authen schene -- maybe pre-shared &/or null? Focus on two scenarios: UA-Proxy authen Proxy-Proxy identity assertion Try to align w/ SRTP/SDP work.
Bar BOFs Security Wed 1730-1930 Firewall traversal Thur 1745-1900 Hilton Rm Privacy, outbound services from remote proxy Thur 2130-2300 Rohan asked for time to work on call control issues. Suggestion: Wed after the plenary. Accepted.
Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)
Updated 13 Dec 2001 13:23:08 -0600