IETF 65 Session Initiation Working Group Session 1 notes

IETF 65 Session Initiation Working Group Session 1

From Notes by Spencer Dawkins, Steve Donovan, and

Edited by Keith Drage and Dean Willis

Topic: Agenda Bash and Announcements

Second day is busier, if time permits items may moved to first day.

Certs and End to Middle mechanism stalled in WGLC.

Announced that the chairs are changed. Rohan Mahy is out, Keith Drage is in.

----------

Topic: Connection Reuse

Vijay Gurbani presenting

HYPERLINK "http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-05.txt" draft-ietf-sip-connect-reuse-05

Currently still in WGLC.

Document has been revised to -05. Changes included:

an added statement that this is for peers with direct connection.

removed stuff that was overlapping with outbound.

removed section which caused problems with DNS SRV. Reuse done using IP:port as the index.

Issue 1: Virtual Hosting 1 – Problem with identifying domain of proxy requesting a TLS connection for white list or black list access control logic when a proxy supports multiple domains. Doesn’t feel that there have been sufficient comments to address this cleanly.

Action: Take to list.

Issue: Virtual Hosting 2 – Problem with the alias being shared. Client 1 connects to a.com, Client 2 connects to b.com. Is this important enough to deal with?

It was questioned as to whether virtual hosting was a requirement, and is it important enough to deal with.

Resolution: Need to take a look at virtual hosting before finishing WGLC.

----------

Topic: Outbound

Cullen Jennings presenting

HYPERLINK "http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-02.txt" draft-ietf-sip-outbound-02

Much improvement since the last IETF because before it had too much content – this is more about simplifying and talking about a small portion. What do the UA and simple proxies need to do? Still allows the other uses to be done, just not described in this document. SUBSCRIBE is now available and supported as a normal usage. Instance ID definition is moved from GRUU to outbound, this flips the dependency. Flow-id replaced with reg-id.

Issue: Concern with configuration of outbound-proxy-set. This was too hard. Suggestions were SRV based and config framework based solutions. Author wants to leave as is and leave this to other drafts.

Resolution: Consider it out of scope for this document.

Issue: Two algorithms for generating a flow token.

Resolution: Leave it like it is.

Issue: NAT keepalives for TCP-based transports

Alternatives:

SIP PING method – special SIP method, modified SIP processing for performance reasons

Operating System TCP KeepAlive

Double CLRF request and CRLF response

STUN – requires protocol demuxing on the same port

Discussion: It had been decided in previous meetings to use STUN for UDP as at least one of the options. Stated that if PING is choosen, that can be used for UDP as well.

Use TCP keepalives. Statement about which OS can do this is not true in the draft anymore; it can be done on some OS.

Proposal:

Do STUN for TCP and UDP

Do CRLF for TCP and STUN for UDP

TCP KeepAlive if supported, 1 or 2 otherwise

Resolutions:

OS TCP KeepAlive should be used if the client supports it.

Need something more because OS TCP KeepAlive is not supported in every client OS.

Consensus to use STUN for UDP

Consensus to use STUN for TCP, with use of OS TCP keep alive above.

----------

Topic: GRUU

Jonathan Rosenberg presenting

HYPERLINK "http://www.jdrosen.net/papers/draft-ietf-sip-gruu-07.txt" draft-ietf-sip-gruu-07

-07 was submitted by Jonathan but had not shown up on the server. Principle changes between –06 and –07 were to deal with agreed interactions with outbound.

Changes:

removed instance ID,

added dependence on outbound, but this doesn’t mean you need to have outbound to use it – only if you want multiple contacts for one instance, which is really only needed there

GRUU is now a URI param like lr

removed require for GRUU in 200 (OK) response and associated mess for edge proxies

removed stuff about e2e mid dialog

big change is removing the edge proxy record route stripping. Record route works normally now. Home proxy rewrites and discards path.

Issue: How do we handle this for multiple contacts? Proxy remembers using record route stuff. Question from floor: why does it matter? Can a client not handle it if it has multiple registrations? Speaker from floor identified a case that breaks this. When the mid dialog requests gets there and we discard the path. If we have two edge procxies and one home proxy, we lose that. JDR: No change as result of discussion.

Resolution: Ready for working group last call after

author resubmits –07 version.

Chair action: Poll list to see if WG believes that –07 is done and then send to IESG.

----------

Topic: TLS with SIP

Presenter Vijay Gurbani

HYPERLINK "http://www.ietf.org/internet-drafts/draft-gurbani-sip-tls-use-00.txt" draft-gurbani-sip-tls-use

Goal: explore, look at test cases, compile list of open questions. Presented assumptions.

Issue: Cert doesn’t say that the sender of the request is authorized to be a SIP proxy for that domain. Discussion of whether it is even an issue, some say yes and some say no.

Resolution: If a cert is received for a domain, then that is what is used to determine if the sender is authorized to send the request.

Issue: Mutual authentication – can RFC3261 do more on mutual auth? Using DNS to verify received IP address points to the sending host. Question of whether using DNS to verify the ip address adds any security.

From floor: This draft is the first one that covers some of these issues that have come up and we should not be dismissive of this draft. From floor, TLS with SIP is unspecified and we need a better specification of SIPS. Not volunteering to write but we need it. Francois Audet indicated that he planned to submit a draft on this subject soon talking about how SIPS should work.

Resolution: Take it to the list.

No time to discuss other issues.

----------

Topic: Location Conveyance

James Polk presenting

HYPERLINK "http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-02.txt" draft-ietf-sip-location-conveyance-02

draft hadn’t changed since before Paris. Changes in latest version (42 pages lost):

deprecate the stuff that wasn’t pushing location.

changed the organization of the requirements.

removed full SIP message examples.

completed the ABNF.

reduced option tags from 7 to 2

deleted call for 425 response.

A long list of open issues were identified.

Issue: Meaning of 424 (Bad Location) response.

Resolution: more text on 424 needed

Issue: There was discussion on the meaning of multiple locations, and whether they were allowed. Attention was drawn to the scope of the work of GEOPRIV versus SIP.

Resolution: It is legal to have more then one location indications. The text will say the what that means is outside the scope of the spec. Meaning (if any) of multiple locations are in scope of GEOPRIV. Lack of correlation between location headers and location bodies is in the scope of this document.

Session 2: Tuesday, March 21, 1300-1500

Topic: Response Identity

Feng Cao presenting
draft-cao-sip-response-identity-00
Redefines scope for response identity
Cannot rely on existing fields, need response identity as early as possible (non-dialog, response code confirmation, response identity spoofing)
Provide response identity inside response message with the security mechanism for verifying the integrity of response identity
Must be backward compatible, in the header by responder (or its proxy), covers identity of both UAs and proxies, with integrity checking, enforced through originator's request.
Not sure what to do about anonymous responses.
Responder-id is response ID - can any intermediate proxy ask for it?
New response code 380 ("Warning: 380 response identity cannot be revealed"). Not sure what exact behavior is, not sure what response is.
Can't do anything with a response you don't like, right? it's a response. Can't reject a response, can only terminate the request that caused it? Either say UA can do anything, or say UA should drop the response.
Jonathan - don't like that we say we support this mechanism, but don't have a way to tell someone to use it. Don't agree with scope that we like proxy identity. SIPS is sufficient to overcome the attacks listed in this draft. History can help here.
Jon - banged head against a wall here for a while, not sure there are any interesting security properties being addressed here.
Jonathan - can't make authorization decisions further along the path based on this mechanism.
Jon - no way to influence or evaluate proxies in routing calls - there's no way to get benefits from this mechanism without removing retargeting, etc.
Robert - people are already looking at this mechanism as a source, not a sink, of security attack possibilities.
Introduces "Domain-based Authentication Service" (DAS) on slides.
Open issues - is AIB needed? 403 response code? Warning issue.
Work item in this working group? Please discuss on mailing list, unless someone is passionate about this.
Connected Identity John Elwell draft-elwell-sip-connected-identity-01 15
Can change From field in mid-dialog, with no new headers. dialogUriChange tag advertizes support for this.
Robert - for subsequent requests in dialog, we MUST allow the to to be changed
Rohan - do I change both From and To header when I do this?
Jonathan - maybe, depends on semantics. To has well-defined semantics in initial dialog, we're doing the same thing for mid-dialog, and 3261 is actually broken.
Jon - I think there are perils here, have already talked about them
Adopt as working group item? Hands raised - many "yes", but some "no"
Revise charter? Jon thinks this is identify-connected-party - chairs will work with ADs to come up with charter text adopting this.
----------
Topic: SAML
Jon Peterson presenting
draft-tschofenig-sip-saml-05 15
Do have an update for this IETF.
Best way to carry SAML in SIP (SAML assertion within SIP request) is scope of this draft
Make this look as much like SIP identity as we can
Jeff Hodges adding a lot of SAML clue, SAML profiles and bindings
Changes to identity-06 implementations - UAC - nothing, Authentication Service - mint assertions, Verifier - download and parse assetions and attributes
Rohan - assertions still in bodies, or in headers? Only by reference. Concern that you aren't using certificates, you're using assertions that change on a per-call basis - verifier is easy to overwhelm
Jon - ruled out a CID URI in last-minute change to Identity. Think there are more reasonable cases for SAML than for Identity, actually. Need a decent by-value story for SAML. Don't see doing SAML in a SIP header...
Rohan - would like to get assertions, don't have a mechanism in mind.
??? - did not update SPIT draft, like the SAML work and want it to continue, people would like a SIP header so proxies can insert/aggregate information.
Jon - we're actually chartered for SAML, are people thinking "something else", or "anything but SAML"?
Bob Moscowitz - doing SAML that isn't single-sign-on. Using SAML to get other SAMLs along a supply change (in automotive). There are problems, but if you're careful, it's useful. Will try to send references on this to SIP WG.
??? - draft is going the right direction, I was trying to use SAML for something else
Jeff Hodges - this is one profile, there could be others if needed
Hannes - this is one of the simplest solutions that covered most scenarios - but not all scenarios, as Rohan mentioned. Flesh this one out and then move past this starting point. Could put assertion in body, but don't know how yet
Dean - are we on track for July?
Cullen - who understands this draft? about 8 - not bad. Is this the total SAML thing? Not yet. We don't have a framework for SAML yet (and this draft isn't a framework). Not ready for WGLC yet, July deadline seems optimistic.
Hannes - ??? missed comment
Rohan - fall seems reasonable timeframe, don't object to this work. Worry about DOS attacks on verifier
Bob - will volunteer to help with this - SAML is too big to explain, we need frameworks here. Will be doing SAML in msec as well
??? - is SAML identity-info? What if it's not there?
Jon - assume there's a federation that understands these attributes
Jonathan - member of multiple federations? don't know where this request is going, multiple versions might apply to this request
Jon - this has been applicable in SAML from the start. It's not universal, we know this
Chairs to poll WG mailing list for adoption
----------
Topic: Loop Fix
Robert Sparks presenting
draft-ietf-sip-fork-loop-fix-00 15
This is a followon from Vancouver discussion
3261 downgraded to SHOULD loop-detection, but MUST use some algorithm
Short term is better, long term still has problems
Rohan - Is this required for serial forking?
Need help to discuss this
Need to talk about max-breadth, additional restrictions on 3rd-party registrations (outbound, consent).Is this needed now, or is later OK?
Cullen - I care.
Sean Olson - not sure this needs to be done in the IETF (fully defining 3rd-party registrations)
Robert - can identify 3rd-party registrations, don't think you can detect all of them - we'll talk
Rohan - don't have consistent definitions of 3rd-party - outbound isn't 3261, others are floating around as well.
Robert - "send the response over there" - as opposed to "to me". "on same connection".
Rohan - serial outbound needs this?
Robert - don't think so.
Sean - don't bite down too hard or too arbitrary on 3rd party
Cullen - anyone with credentials can take the network down
Robert - this is the first step
Jonathan - publish immediately, without normative block on outbound?
Robert - wordsmith this week, onlist, finish next week
Topic: SIP Standards Advancement Requirements Tracking
Robert Sparks presenting
Tools for Advancing - SIPit interoperability testing, with hundreds of implementations (next one is mid-April). SIPit 16 found two major spec bugs, a dozen clarifications, hundreds of implementation errors
Opportunity to observe, opportunity to listen - finding things that multiple people do without a spec -- "why should we ever implement a SHOULD"? Some organizations refuse all bug reports on SHOULDs. Everybody does DNS, half do SRV or NAPTR, some do IPv6, half do TLS, 100rel/PRACK and message waiting indicator are at 30 percent level. Nobody was doing GRUU, nobody was doing Outbound. Will be looking at a number of items at SIPit 18.
Currently tracking about 120 spec bugs
Interop reports will be huge - 2607 MUSTs. Cannot meaningfully report interop at this level
Jonathan - need to get down to 200 or 300 behaviors to do this
Cullen - we actually do more tests than MUSTs in product testing
Rohan - identify things that we know we don't want to include - timestamp seems less important than it did then
Jonathan - divide up like we did 3261 editorship and produce subsets. Please send e-mail if you are willing to spend non-trivial amount of time on this.
Ideas:
Use different systems for spec issues versus bugs in drafts under development
Use wiki for tracking state of implementation and interop statements (integrated with SIPits)
Vijay - how current is current bug system? IPv6 with brackets?
Jason - if we could make something superclear, and capture what we said?
----------
Topic: SIP Standards Advancement Roadmap
Jonathan Rosenberg presenting
draft-rosenberg-sip-hitchhikers-guide-00 15
Read the Douglas Adams book - it will help a lot. A step toward advancing, plus help for newbies. Defines "Core SIP" - goes to draft standard together. Mostly an enumeration of specifications. SIP Family supports SIP and has extensions of its own.
Rohan - SIP Family is also good to have, but should be in RAI
Jonathan - omitted common policy, probably a mistake. RFC 3264 isn't on the Core SIP list - not an extension. PAID *IS* on the list (controversial P-header, but widely used).
James - what about Refer? Not "Core", to Jonathan - would put "Core" in one spec if it would fit
Robert - have more Refer than Subscribe in implementations
Paul - RFC 3264 is sort of missing - Jonathan will put this in
Mary - RFC 2564 had 3264 functionality inline
Why not PUBLISH? No deep reason
Jonathan - "if you're implementing SIP and don't implement Core SIP, something is wrong"
Francois - very arbitrary divisions
Jon - "If you're not doing PAID, you're doing something wrong?"
Jonathan - if you don't implement PAID, your caller ID won't interwork with anyone else's.
Do O/A get included in "Core SIP"
P-header is core SIP?
Please send Hitchiker's Guide references so book will be fun
Adopt as WG work item? Lots of hums "yes", no "no" hums
----------
Topic: SUBSCRIBE Etags
Aki Niemi presenting
draft-niemi-sip-subnot-etags-00
Want to supress NOTIFYs when you refresh a SUBSCRIBE (reduce traffic that is unnecessary)
Subscription refresh, resume, terminate, fetch as use case scenarios
Optimize Fetch - Suppress-Body-If-Match/If-No-Match e-tag
Jonathan - think there are problems in theory but not in practice
Tim - allow subscription state to pass in subscribe responses in a fetch?
Adam - there are intractable forking problems if you do that - don't go there, you'll have problems with deployed solutions
"I wish to suppress NOTIFY if 412"? (not sure I got this correctly) - then just don't send etags?
Sean- No, what you're saving is very minimal
Suggests going with proposal 1 - simple, works
WG item? Inconclusive result, need to poll list.
Jonathan - Sean suggested a 3-A approach, right?
Sean - would be much more useful
Dean - please talk to Sean, revise draft, post to list
----------

SIP Route Security

David Schwartz
draft-schwartz-sip-routing-managment-00 10
Trying to get discussion on the list, not much going on.
Issues - removing critical flow elements, detection of confidential information, launch pad for attacks on other systems, O(n**2) spiral generation issue
"Solution" - "proxy should not let that happen", but is ambiguous, TLS required between proxies but is not used in practice
Please discuss on list
Vijay - cryptographically protect record-route, etc?
Loop detection is actually hard. People had done some initial work, but it was dropped five years ago and David doesn't know why.
Jonathan - are real issues here, and don't like solutions, but this is ultimately a question of policy. This stuff came up in ECRIT today. Hard issues, don't want to hard-code this into the next spec.
David - does anyone really need to know more than the next hop?
Rohan - this is like something Jonathan brought us 18 months ago - it was cool, it was an implementation detail, and we have our hands full with stuff that's required for interoperability
Jonathan - agree, but this is also something implementors need to do to avoid attacks
Keith - need to have more discussion, involving the chairs
Robert - please tell us about the real problems with your real networks - that would help us set priorities a lot
----------
Topic: SIGCOMP
Gonzalo Camarillo
draft-ietf-rohc-sigcomp-sip-02 10
This is a ROHC draft, Gonzalo focused on SIP part
Application currently identified by host part of URI
Open issue is outbound proxy that's really a proxy farm with shared SIGCOMP state farm-wide
Record-route takes different path than expected from service-route
Need an explicit application identifier?
Dean - what else does this affect?
Jonathan - a whole lot - the whole SIP outbound proxy issue applies here
Gonzalo sent Jonathan e-mail on this but didn't get a response (yet :-)
Adam - you get an explicit outbound identifier - use an instance identifier in the opposite direction?
Jonathan - agree that this would be the right thing to do
Jonathan - example shows two host names - would be one host name with multiple IP addresses, right?
Do we need to be symmetric, or use FQDN in other direction? That would be fine.
We really need a way to do this in an standardized way.