Notes on SIP Session 2, IETF 68
reported by John Elwell 


sip-sips-guidelines-02(Francois Audet)

Intended status, bearing in mind it uses RFC 2119 wording. Francois proposes
to make a standards track document, normative extension to RFC 3261 and
conforming to RFC 4485, include justification for bug fixes, but bug fixes
will need to be done in another document that updates RFC 3261. Jonathan:
really need a single document that says this is sips and it works, so a
single document that updates RFC 3261. Jon: prefers to see a short standards
track document and keep informational stuff separate. EKR: Anybody opposed
to having a document that changes behaviour? Cullen as individual: Can't
answer the question because we don't know what the changes are - changes in
current document are very small or non-existent.

Dean: If you disagree with the proposal you are disagreeing with the agreed
essential corrections process. Jonathan: This isn't delivering the document
that people really need. The essential corrections document when then just
refer to this document.

Keith clarified the 3 elements that the proposal would do. One element
definitely has to go into the essential corrections doc - what to do with
the other two elements?

Deprecation of last hop exception. Francois says we have not heard
opposition to fixing this for a long time. Initial idea was not to do it in
this document but do as a bug fix later on. Since then there have been
proposals to make the change right now and in present document, which would
certainly make the document standards track.

Proposal to deprecate last hop exception or do not deprecate. Clear
consensus to deprecate last hop exception. This will be an update to RFC
3261 and a bug fix.

Jonathan: but SIP has another "bug" in that there is another exception when
you retarget, which prevents you using SIPS for things like media security
when you trust your proxies. Without deprecating this too, SIPS has no
useful security properties. Some dispute over whether this exception really
exists. Francois says present document recommends not to do this but RFC
3261 allows it.

Jon: security is not made worse by allowing change from sip to sips.
Francois: it is made worse, because UAS believes it is secured.
Cullen: Whatever 3261 says, can we get agreement that change from sips to
sip on retarget should not be allowed.
Dean: will not reach consensus now, so out of time.

Francois mentioned the appendix that talks about what we could do in future
about true end-to-end security, and if others have ideas on this they could
be included. The gurbani-sip-sipsec draft is one idea, but could be others.
Question whether we charter the group to work on this. Hadriel: charter
should specify what security properties need to be achieved. EKR: Danger
that you will end up replacing SIP with some other rendez-vous protocol.
Otherwise you basic have Identity for integrity and SIPS for
confidentiality. Although we need integrity protection, confidentiality is
only a nice-to-have. Hadriel: even Identity does not give end-to-end
integrity protection. Jonathan: agrees with Hadriel - have to trust proxies
to some extent, otherwise it is not SIP anymore. Rohan: if you have an AoR
that resolves to a given proxy, you trust that proxy to do forwarding for
you. Let's get more operational experience with TLS and Identity at SIPIT
etc and then come back and look again at end-to-end security. Jon:
end-to-end is kind of hopeless, will at least need to trust the proxy with
which you have a relationship, but not necessarily other proxies.

Francois: to summarise there are some security properties we should address,
but no support for full end-to-end security. Keith: any enhancements need to
be proposed to working group along with problem it is trying to solve. Dean:
and threat model.

sip-outbound-08 (Cullen Jennings)

Cullen explained some corner cases relating to use of CRLF as keep-alive for
TCP versus STUN for UDP, in particular interaction with RFC 3263 SRV. One
solution already discussed and rejected by group.
Rohan: The fact that application and stack need to cooperate in a particular
way is not unique to outbound, e.g., Identity. Problems only relate to
misconfiguration.
Christer: don't really need to indicate keep-alive mechanism in DNS.

Cullen wants to call the question:
Option 1: don't do CRLF keep-alive - revert to 07 text
Option 2: keep 08 text.

Cullen recommends option 1.
In response to question from Francois, Keith clarified that consensus from
both room and mailing list will be taken into account.

Dean: there is a bunch of people, not necessarily here in the room, who
don't want to implement UDP with outbound and therefore don't want to do
STUN as keep-alive.

Rohan: stitching together two different stacks for SIP and STUN for TCP is a
lot more complicated than for UDP, based on information he received from
several sources.

Francois: The multiplexing is a lot more complicated on the server side than
the client side. One reason is that proxies would not normally need to
include a STUN server (whereas clients need a STUN client for other
reasons). Supports final hum on this and move along.

David Thulim: A proxy could do both TCP and UDP, but requires outbound
clients to do TCP.

Jonathan: would chairs like to hear a compromise approach. Dean does not see
that there is consensus yet, so a compromise would be welcome.

Ted Hardie: Please let's have a hum first.

Dean: Has heard from people that would not accept either decision:

Cullen: Let's have a hum.

Aki: Consensus on mailing list is clear. I am not hearing what is the real
problem with having different keep-alives for TCP and UDP.

Cullen: Some vendors are willing to do TCP keep-alive but not CRLF, and also
there are some situations that are difficult to configure.

Francois: We should vote.

Chair: Those who would be prepared to accept either solution in order to
come to a conclusion today, please hum. Very clear consensus for this.

Christer: Proposed a solution for resolving configuration problem, using
tags in Path header.

Cullen: That was an editorial drop off and will be fixed, but only solves
case where Path header is used.

Hum on option 1 and option 2 from slide:

Greater loudness (2/3?) for option 2, which is to retain CRLF as in present
draft.

Dean stated that AD believes we have consensus for option 2.

Issue of when does the client have to do keep-alives. Server might be using
them to see when client has disappeared, even though primary purpose is for
client to see when server has disappeared. Proposal to do keep alives at
rate governed by parameter on URI, or if not present based on client's own
preference (but no more frequently than in draft). No longer a need for
keep-tcp parameter - just rely on keepalive-timer parameter. No opposition
to this proposal.

Issue of whether we want to simplify draft in a number of areas as shown on
slide.

One type of instance ID (just MAC and not UUID).

Andrew: why can't we use other URNs, which might be shorter than UUID.
Possibilities include IMSI and IMII.

Henning: Which of these items can't be added again later if we drop them
now? Which are a pain to do on client side or server side.
Cullen: answered for each of these (missed his answers).
Cullen: enough feedback to know that discussion on UUID will be long, so
skip.
One algorithm for flow tokens. Rohan asked if anyone is using the other
algorithm at present - nobody spoke up. Cullen: security issue with second
one if SIPS not used.

EKR: Get rid of the one that requires SIPS.
No opposition to getting rid of that algorithm.
Proposal to drop OPTION probing for STUN. Adds complexity but only deals
with configuration errors.

Hadriel: I thought that wasn't what we were going to do, but we were going
to do SIP first to see if option supported, rather than first waiting for
keep-alive failure.

Cullen: Doing OPTIONS first significantly increases load on server when
everyone is trying to register.

Hadriel: We have a precedent for not using OPTIONS. Also not helpful to do
it if don't do it at start. Just go with relying on configuration and get it
done.

Christer: Leave document as it is.

Aki: Doesn't see a deployment when this will be a problem that OPTIONS will
help you with.

Rohan: Fine with deleting it.

Hadriel: If not a MUST, should not be there at all. Don't want an option.
Problem that server might blacklist the phone, and hard to trouble shoot
because phone will re-register successfully and it won't fail again until
later.

Hum on whether to change to MUST or delete. Unanimous to delete.

Rohan: There is a SHOULD statement and a MAY statement - can both be removed
- no objection.

Issue: Failure procedures for failure within 120s of registration different
from those thereafter. Do we need this. Not so difficult to implement, but
only really useful if proxy keeps failing shortly after register. Hum on
those in favour of keeping versus deleting: consensus in favour of deleting.

Sparks: Expecting to test outbound at SIPIT.

Chair: Outbound is due for WGLC very shortly, so if any more issues, get
them on the list quickly.


DNS-SD/mDNS overview (Henning)

Comparison with SIP multicast

Rohan: there is an error on slide 2, which possibly invalidates any
discussion.

Henning: take a look at mDNS

Jonathan: procedural question - we should be looking at enhancements to SIP
based on requirements from SIPPING.

Chairs: Yes, that would be the correct proposal.
Henning: requirement comes from P2PSIP charter discussion, but not in scope
of P2PSIP charter.

Dean: exploratory - not worth beating to death in this room.

Ted: Suggests should discuss with an mDNS expert - doesn't fit present mDNS.

Henning: iCHAT works in similar way.

Aki: This is a no-brainer and we shouldn't let process get in the way. Silly
to go write requirements drafts.

Chair: Would still be helpful to clarify problem we are trying to solve,
even if it is in same document.

Henning: Would welcome information on status of DNS-SD work in IETF.


Privacy-clarified (Mayumi)

Options: obsolete or update RFC 3323 and define new priv-values.

Separate into two drafts

Jon: Don't get stuck on documentation question, but on question of UA-based
versus network-based privacy. UA can do using GRUU and TURN, so do we need
an additional story for network-based? Not sure it is sensible to have
Privacy header field to request something from the network that it could do
itself.

Jonathan: Even if the UA does everything, it is important that the network
does not mess it up, so at least need Privacy: id. As separate issue, there
are two reasons for asking a B2BUA to do it: UA-based can only provide a
limited degree of privacy, so would still reveal the domain. So would need
to contact a B2BUA in anonymizing domain to initiate the call for me in just
the way that a UA would.

Jon: Confused by Jonathan's statement - why can't UA just get GRUU and TURN
stuff from anonymizing domain.

Chair: Seems to be agreement there is a problem to be fixed with RFC 3323.
There are two parts: fixing RFC 3323 and then what else can we do.

Jon: It doesn't make sense just to fix RFC3323 as it stands.

Rohan: We could separate them, and a UA using GRUU and TURN would simply not
use Privacy: id.

Jon: Clarified that we need to ask not do undo my anonymization.

Consensus there is interest in carrying this forward - to be pursued on list
and chairs to investigate updating charter.

Record-route-fix (Froment)

Robert: Believes most of this is informational / BCP text and should become
a BCP RFC. The proposal merely explains that you CAN do double record
routing and explaining why overwriting is bad.
Consensus that there is an interest in doing this work.