Minutes, SIP, IETF 60
Edited by Dean Willis
Session 1, Wednesday, August 4, 0900-1130
Agenda modified to substitute discussion of body part modification
instead of resource priority..
Topic: Status of Working Group
Discussion led by chairs. Slides presented.
Discussion of Non-Invite Transaction Drafts: <>Consensus reported
that
two Non-Invite drafts are ready for WGLC:
draft-sparks-sip-nit-problems-01.txt and
draft-sparks-sip-nit-actions-01.txt.
The chairs are to arrange for WGLC.
"SIPPING 16": Proposed that the WG should prepare a document denying
that there is some set number of possible SIP features. Discussion
centered on whether or not this should be an RFC. Resolved: We will
sart with a draft and consider it as usual.
Topic: Content Indirection
Discussion led by Dean Willis acting as Editor. Slides presented.
Issue: Editor. Volunteers were requested to replace Seann Olson, who is
not able to contribute at this time. Eric Burger volunteered.
Issue: Do we need content expiration? Do we have to update RFC 2017 to
add it? Rough consensus seem to be to retain this function, as it
was present for WGLC and IETF LC. The document editor is to discuss the
addition on the ietf-types mailing list and determine whether a change
to RFC 2017 is needed.
Issue: Hash format. Consensus that the hash parameter should be named,
as per "hash-sha1". The hash value shall be wrapped in double quotes.
The editor is tasked with reviewing the hash parameter on the
ietf-types list.
Issue: Partial rejection of content. Noted that some RFC (3359?) allows
rejecting non-critical content. The editor is directed to clarify this
in the text, potentially discarding confusing section 5.10 text .
Topic: Body Part Modification by Proxies
Discussion led by Rohan Mahy as Author. Slides presented.
Background of problem presented along with use cases and a variety of
topologies including triangle, trapezoid, and local as well as foreign
piggybacking.
Discussion was heated and active. This is clearly a controversial topic.
Notable points from the discussion:
- This is related to the policy discussion.
- Modification of bodies has a significant impact on the security
model, and seems to require that S/MIME be applied on a per-part basis
rather than per-message basis.
- Having individual body parts signed by different entities is
problemactic.
- Any solution is going to have to address a large number of uses
cases.
Discussion will continue, with no consensus recorded at this time.
Topic: Connection Reuse
Discussion led by Rohan Mahy as Author. Slides presented.
The main issue seems to be around identifying a specific connection in
a manner suitable for use as a reference. The URI doesn't provide
adequate context, except in the case of a GRUU which is instantiated by
the element using the reference.
Discussion will continue, with no consensus recorded at this time.
Topic: Authenticated Identity
Discussion led by Jon Peterson as Author. Slides presented.
Issue: Retargeting vs. Redirection. The proposed approach effectively
denigrates retargeting in cases where identify functions are performed
by the retargeting element. Noted that this isn't all bad --
redirection offers a majority of the capabilities needed, without the
problems introduced by retargeting including response identity,
multiple forking response resolution, and so on. However, it does NOT
provide some of the benefits, including proxy control,
proxy-facilitated NAT traversal (especially with connection-reuse), and
privacy control.
Does non-local retargeting go away so we can get identity? Don’t want
security property downgrading – more choices allow more downgrading. If
identity is critical, we’ve got to go there – not with a flag day, but
we’ve got to go there.
Specific aspects discussed include:
- Does this contradict caller preferences? Jonathan thinks “no”.
- This doesn’t mess up request-history (after thinking about it a
while).
- Do all the applications work? Extra RTTs are OK, although they'll
chafe the wireless community.
- Need to make requirements so we can make sure we meet them.
- Cost-benefit from a speed perspective is subtle (and probably
small as well). Almost all forwards are local forwards, and almost all
phone calls have local forwards today.
- “The main thing is to make sure this actually works in a
practical sense, and I’m not there yet.”
- RFC 3261 limits recursion – but was this text ever coherent?
Would we clarify this text?
- This probably will slow down call setup in wireless domains, but
it’s not unreasonable for retargeted calls to be slower. SIGCOMP helps
here, too.
- RFC 3261 is pretty clear on who can muck with Request-URI – this
should work.
It was observed that few participants in the room displayed confidence
in their understanding of the problem or the proposal, and that further
study would be a Good Thing.
Topic: GRUU
Discussion led by Jonathan Rosenberg asAuthor. Slides presented.
Issue: URN Equality. Consensus indicated to use lexical equality
where a specific quality function for a URN is not specified and known
to the element.
Issue: Ramp-up problem. The current text requires that registrars
refuse registrations resulting in a conflict, after which restarting
devices that caused the conflict can remove the old registration before
trying to re-register. This reduces the capacity during a restart by a
factor of four over simply overwriting the old registration. Proposals
include overriding the old registration, or keeping both contacts.
Several alternatives and issues were discussed, with key comments
including.
- Question: Does having two registrations for same instance violate
a critical GRUU property?
- Worry: Keeping both might contribute to another avalanche restart
problem, and is more complicated<>
- <>Preference: (Paul K). prefers overriding
oldregistration.Comment
(Rosenberg) - Ok to have multiple routes/connections for an instance,
so #1 above is "no".
<>- Question: (Rohan) Could we use a flag or special response
code to tell the registering mobile than an existing instance has been
overridden and that something odd must have happened?
- Worry: Multiple contacts with the same instance id
complicates the way proxies handle certain errors. Complicates a lot
of things.
<>- Comment: (Sparks) - Sounds familiar with Etag and
XCAP.
No consensus observed on the ramp-up issue.
Session Two, Thursday, August 5 1300-1500
Topic: SIP MIB
Discussion led by Rohan Mahy as Chair.
Proposals to close 3 of the 4 known open issues were made on the list.
One issue remains. Rohan propsoes that the MIB functions related to
configuring SIP UAs be deleted, as we have a seperate UA configuration
framework. Some elemenst would remain, but as read-only. The group
indicated a consensus to proceed with this approach.
New issue raised: We added an application index to all these tables.
The problem is to define application name may end up in the same name
repeated. Is this legal? The problem is that the same application is an
instance of the same application. RFC 2788 seems to say one entry per
application. The MIB spec is restricted in the name. A suffix to the
application name may solve the issue, although this point is not
agreed. Follow up on the list.
Topic: The History of History and Voicemail, A Diatribe by Cullen
Jennings
Discussion led by Cullen Jennings as Amicus Curae, with slides
presented.
Two solutions for users with voice mail.
1. History: proxies retarget include information
about where and why they retargeted.
2. Voicemail uri: proxies figure out what services
they want voicemail to provide and tell the voicemail the voicemail to
do that
Slides: A long list of drafts that request this issue.
Slides: reviewed the history of changes in voicemail-uri.
Proposal: The possibility of using both: Cullen indicates that both
seem to be needed and not mutually exclusive..
Recommendation: chose something now: History, URI, Both. The
recommendation is to use both, since the do different things and they
work together.
Rohan, as chair: We are already doing History. So the question is: we
do History alone or we do History AND URI.
Poll: Anyone implementing voicemail URI? No answers.
Suggestion by Dean as Chair: to take voicemail URI as an individual
submission heading to informational RFC, and proceed with History as
planned in the working group. There seemed to be general consensus to
proceed with thsi approach.
Topic: Request History
Discussion led by Mary Barnes as Author. Slides presented.
Mary goes through the changes from -02 (see slides)
Issue: Section 4.1 has normative statements that appear to overlap with
the normative ABNF. Resolved that the author will make the text
explicative rathen than using requirements language therein.
Broader review is now desirable. The author feels that the document is
ready for WGLC, and there seems to be a consensus in the room to
proceed with last call.
Mary presents an analysis of History-Info vs robust security:
comparison with draft-ietf-sip-identity-02 and
draft-ietf-mahy-sipping-add-body (see slides).
Mary also presents an analysis of History-Info versus Privacy.
Discussion ensued, with key lements being:
- Jon: People are much confortable with the request portion than
with the response portion in the request identity draft. Suggest to
split<>the request-identity in two drafts. Considering to work on
two optionsfor request-history as well, since they are
incompatible.<>Rohan:
transition mechanism that the P-Asserted-Identity to thegeneral
internet.
- Jon: the request identity draft just says that a proxy
cannot add a body.<>Keith: we need to solve the ientity stuff
before
the history, not the other way round.<>
- Rohan: is is sufficient to say in history-info that a proxy
that retargets to a non-local then it should redirect. This will
work. Other mechanisms may be specified later. If a proxy want to
convey history-info securily, then you can redirect to TLS.
Rohan is to send text to Mary as per above.
Topic: Connected Party -- who am I talking to?
Discussion led by Cullen Jennings as Author. Slides presented.
Problem description in the slides. Possible solutions:
1) update of state in the dialog;
2) transfer to a new user.
Noted that 1) has two
subsolutions:
1a) Update To or From, although is not compatible to 2543.
1b) update with a new header, body, AIB, etc. Compatible with 2543, but
a 2543 phone will not update its display.
- Jonathan: With respect to 1A, I hope people are not using To and
From as the primary source of information for the user.
- Rohan: WRT solution 1a and 2543. A 2543 implementation will
return 481. To and From are useless today.
- Andrew: don't depend on To and From headers, the UA will not use
them.
- Jon: email contains From and To headers, and they are useful and
intuitive. They can be forged, and that's why we need identity, and
this is approach taken by identity, making them meaningful. it requires
a lot of motivation to make the to/from header less meaningful.
- Jiri: In forwarding scenarios across different domains, there is
not traces of the original sender.
- Keith: the problem is reusing a header for different usage. This
is the problem why we end up with so many identities.
- Rohan: the semantics of from/to: To is a semantics of to which
you address the dialog. Cullen suggests the semantics of to who you are
communicating. The identity work addresses part of this correlation.
- Rohan: if we go with 1a and do not change the To header, someone
has to change a bunch of stuff in Section 26 of 3261 to indicate how to
do things now with S/MIME.
- Hisham: ok to change To/From, if you authenticate the user you
don't authenticate the To/From. If I want to change my name, I can
re-INVITE to change my From.
- Cullen: sort of agree with Hisham. right now we don't have a
mechanism to change the name. Solution 2 is about INVITE/Replaces, not
about REFER.
- Jonathan: Think about the way many people visualize billing
systems toay -- the billing system charges the user on INVITE and
BYE. This is wrong. The billing system should take information about
"what happens" during the call, and figure out that information when
the call started/ stopped.
- Jonathan: don't understand the serious security issues (see
slide, solution 2).
- Rohan: replaces has requirements for authorization of the
replacement,and the way to do it is to look at the Referred-By header
and correlated.
- Jonathan: a solution: GRUU + cryptographicly random grids
Chair: I think I sense a developing consensus to look at the
cryptographic technics of the GRUU and the dialog usage. Poll of the
room about the possible solutions: Room prefers support for Replaces
with GRUU and cryptographic randoms (solution 2). If that does not
work, then try a new header (solution 1b).
Topic: SIP State Update
Discussion led by John Elwell as Author. Slides presented.
Proposed: Treat the contents as clarifications to existing RFCs as bug
fixes and add similar clarifications to authid-body and future drafts.
Discussion: How does this related to the previous presentation. Do we
need to put this on hold until we resolve the previous proposal?
Chair proposal: Bring the list of bugs, one at a time, to the mailing
list, so we can get attention focused on each and work through it.
Topic: Making S/MIME Work With Certs
Discussion led by Cullen Jennings as Author, with slides presented
Issue: Fetching credentials: options are
- use notification
- use
config framework
- use https
Discussion follows.
Several points were raised.
- The trick to make this deployable is to have one certificate
per domain instead of a certificate per user.
- Tieing the lifetime of the certificate with the lifetime of the
subscription solves a bunch of problems.
- Using HTTS to fetch a certificate could avoid a bunch of SIP
messages.
- Jonathan: we can do this with zero call setup delay. buddylist
provides a context to get certificate from my buddy. You can add a flag
to a presence document "hasCert".
- Rohan: if I received a signed message from someone I don't have a
certificate, for then HTTPS is better. From deployment perspective
it's easier.
- Jonathan: this is easier to deploy with SIP. In which way the is
the HTTP solution superior to the SIP solution?
- Maintaining a large number of subscriptions is server side state.
The
HTTP solution has no server side state. However, we already have the
subscriptions for the buddy list.
The subscription solution offers immediate notification of
certificate revocation. However, the short subscription timer in
certificates cannot be used, since
it is
expensive to generate certificates.
- Note that fetching the cert does not require TLS -- certs can be
sent safely via plain HTTP.
- If HTTP is used, how does
one compute the HTTP URI? SRV may already solve the problem.
Further discussion deferred to list.
Chair: we have a lot of dependencies on making S/MIME to work. There
is strong consensus to make this work. Proposed to make this a WG
item. Poll to the room indicates strong consensus to adopt this as WG
item. Chairs are to work this out with the ADs.
Topic: How offer/answer interacts with multipart/alternative in SIP
Discussion led by Cullen Jennings, with slides presented.
The problem of first trying a secure call and then the insecure, is
that the secure call is prioritized (e.g, if the voicemail implements
secure, S/MIME, SRTP, the voicemail will always answer).
Proposed Solution: Content-ID in each multipart entity in the offer and
a Content-Reference in the answer.
AD: This is probably in the scope of the MIME WG.
Issue: do we need a Require header. Proposal: yes
Points raised:
- Jonathan: If I do SRTP I need to encrypt the SDP. Better to
start with the problem statement. The problem: I cannot use SRTP
because it is a backward compatibility problem.
- Cullen: the solution to the bid down attack is to use auth body
and encrypt everything.
- Jonathan: Second problem statement: Due to the consequences of
sending secured multipart, the nonencrypting UA will reject.
- Dean: problem 1) can be defined as "how to find out if the other
party can do SRTP". Solution: multipart. Alternative: send an offer
encrypted, if rejected, send offer unencrypted, but what happens with
forking in that case? Multipart is probably cleaner.
- Jean Francois: the number of alternatives is big (encrypted
voice, non-encrypted audio type of things). This may increase
complexity and size of the multipart.
- Dave: It should be possible to accept the session but reject the
offer. Get a 200 OK, but sending something that "I want to establish
the session, but there is something in the SDP that I don't understand".
- Hisham: yes, you can reject everyhig in the answer
- Hisham: Can you offer both RTP and SRTP as options?
- Cullen: the problem is that if you do SRTP you need to encrypt.
the SDP.
- Aki: There may be inspiration for the Require: tag in the
the security agreement specification (sip-sec-agree).
- Jonathan: may need to look at preconditions as a solution.
- Rohan: backwards compatibility is an issue, so preconditions does
nothelp.
Further discussion is deferred to the list
Topic: Using SAML for SIP
Discussion led by Hannes Tschofenig
Slides presented
No discussion due to time constraints.
Chair To-Do List
- WGLC draft-sparks-nit-problems
- WGLC draft-sparks-nit-actions
- Work with MIB team to delete UA configuration.
- Rohan to send text to Mary clarifying that proxy retargeting to a
non-local destination will redirect instead. When this is incorporated
into request-history-mech, the draft will be WGLCed.
- Get certs work on-charter and add milestone.