Minutes of SIP WG: IETF 61
Edited by Rohan Mahy
Monday, November 8 Session
--------------------------
Agenda bash and Status - Chairs
Seven RFCs since last IETF, including PUBLISH
WGLC - GRUU, non-Invite-Transaction
Some things are late
Proposing new milestones
- two REFER drafts - two
different milestones?
Rohan has new sponsor and new e-mail address
Connection Reuse
Rohan Mahy, Cullen Jennings - draft-ietf-sip-connect-reuse-03.txt
Non-trivial security problems with
existing digest-based reuse mechanisms
Now support reuse of
mutual-authenticated TLS connections
Cullen has an open issue (the only
one on the table)
Based on Via: header with ;alias
Certificate could contain
multiple domain names URIs
Cullen suggests basing the alias on the TLS peer
value
Vulnerable to DNS cache poisoning, but easier to do
Rohan suggests going with existing proposal
- Lots of discussion about many other ways to
authorize connections
- Long discussion ensued about the
scope. Is there any time you don't want to reuse a
connection? Yes, for load balancing. How does this
mechanisms interact with existing DNS SRV weighting algorithm from
RFC3263.
- Jonathan taking action to provide scenarios
Cullen - lots of problems between UA and proxy
- firewalls, etc.
Proxy keeps track of
"connection" (whether TCP or UDP four-tuple).
1. TCP keepalive every periodic number of
seconds? CRLF? REGISTER? New message (PING)?
Comments:
- REGISTER is horrifically expensive - not a general solution
- CRLF doesn't generate an application ACK - have to wait for TCP
keepalives. question about if standard TCP interface allows
check. We think we can check unacked bytes in most(?) socket
interfaces and use CRLF.
2. UDP keepalive - same problem plus small residential NAT
rebooting can't be detected (still respond to PINGs)
Use STUN for UDP "connections"? No objections in the
meeting
3. Redundant connections? Need a unique device id in the
registration
Allow this? yes
May need Quick Reconnect to reduce proxy
load on avalanche restarts, etc. - the limiting factor on scaling most
deployments. Don't add load when the proxy is most loaded!
Identity - Jon Peterson - draft-ietf-sip-identity-03.txt
New version of the draft, removes response identity
text, added examples
Added text on privacy and
providing identities for telephone numbers ("punting until later")
Identity-Info schemes: allow CID? DNS URLs? but
don't be TOO generous (interoperability problems)
Commment: What's the
mandatory-to-implement scheme? RFC 3840 already has "schemes I
support".
Q: Does everyone implement CID URI? apparently not, at least not
the people in the room :-)
What's the relationship to the -certs draft? We're concerned
about required modifications to installed base
Rohan - normative dependence on -certs not a
good thing. the draft does not require UAs to implement certs
draft.
Shopping for response codes?
can't dereference Identity-Info, don't like your certificate, bad
Identity in From field...
Do we need three new
response codes? We only have 100 4XX response codes, so ...
Room concensus is three new
response codes
Q: we're assuming use of global PKI.
It's harder than it looks
A: but it does work for the WWW today, and no root or trust
model is mandated by the draft
Q: but on the WWW, users are making
choices. In this case, proxies are making choices. That's harder.
Q: Is "don't like your certificate" a provisional
response? No, it's final.
Jon believes it is possible for servers to
make these decisions in some scenarios.
Look at message-identity draft - it's 44
pages of analysis about how we got where we are today!
GRUU - Jonathan Rosenberg - draft-ietf-sip-gruu-02.txt
General problem - what should gruu
specification say about sips and gruu?
Want to avoid two two
registrations to get a sip and sips URI for the same resource.
Existing spec allows upgrade from sip to sips
(resource must be the same for both schemes)
Assume both don't have to exist, but if
they do, they must point to the same resource.
If contact is sip, GRUU is sip URI, but server creates sips URI,
too.
If contact is sips, GRUU is sips URI, but server does not
create sip URI.
Does this work for everyone?
Q: if sips URI is created and then used, we may/may
not be able to tell a connection is secure. This is bad.
Q: creating sips GRUU is implicit behavior (client
didn't request this)
A: creating a sips GRUU doesn't mean much - don't have to create
a TLS connection, etc.
Q: problem is that if we're not doing TLS, we may be doing
something else (present or future protocols)
Q: The recipient can do the same upgrade to sips anyway.
Q: Does this require
unnecessary resources on the server?
A: We have the same problem with
people trying to connect to people who don't support SIPS now
Q: When we register, do we see sip and sips URIs?
A: Depends on what you send as the
contact URIs. Should work the same as AOR registrations
Jonathan to add text reflecting his
proposal
Connection reuse/GRUU reuse has been problematic -
when we have multiple connections, we get wrapped around the axle
Allow multiple contacts in a GRUU for redundancy
(all to the same instance)?
Q: If my TCP connection dies and comes back, is my
connection-id the same? If so, it's not a connection-id...
Q: If I'm hosting these things, how many do I know to
create?
A: Maybe just two, but this is provider policy - does the
client know how many interfaces it has? Maybe...
Who understands the issue here? a
critical mass - please send e-mail to list/Jonathan and chairs
Conflict Resolution -
current spec requires since contact per instance, which helps avalanche
restarts
Does AOR map to a GRUU? how does edge proxy know it should
record-route? Should not record-route if client uses GRUU
- this happens in IMS architecture, for instance
200 OK contains Supported:
GRUU EP? Remove record-route on response
Q: Shouldn't edge router be authoritative
anyway and route without GRUU?
A: IMS proxy may be in a
different domain (HSP and VSP domains) - spiral is expensive - don't
use GRUU in these cases
* (resumed here)
Does GRUU map to AOR? AORs map to contacts, so do you
redirect to a GRUU or to a contact?
You get different proxy behaviors
for AOR->GRUU and GRUU->contacts
Q: If GRUU was just a higher-priority
contact, would that solve this problem?
A: Would depend on the logic of routing
Proposal: AOR -> GRUU -> contacts? Register and refresh up
the chain, AOR -> GRUU mapping disppears when GRUU contacts
disappear
Q: This is the wrong
direction, we're going to explode. Enumerate new behavior reflecting
GRUU extension
We have a real terminology
problem with contacts and connections - sometimes they are headers,
sometimess not
Cullen - we're confused, we need a room with a white board
Q: Should reg-extension be merged with
this draft?
Content Indirection - Eric Burger -
draft-ietf-sip-content-indirect-mech-05.txt
05 draft provides optional content, content-disposition
entity header now a MUST (from SHOULD)
Using hash, not base64
Open Issues - e-tags and
content-ID? work this week
URI scheme negotiation - full negotiation needed? ("yes" =
hack SDP, out of scope)
History Info - Mary Barnes - draft-ietf-sip-history-info-04.txt
Added protocol structure text as descriptiove
Added text on scenario when TLS not available
Some editorial changes
Should -> MUST for applications lacking History-Info and
privacy impacts
Updated response processing
to reflect privacy
Added text for reason header in response
Added appropriate characters
for escaped example URI
Have identified indexing error, 480 timeouts should
be 408s, missing quote on "Busy Here"
WGLC ends on November 29
Feedback, especially with
text, is always appropriate, especially now.
SIP Working Group Meeting: Session 2, 11-11-04
Resource Lists : Adam Roach
- Updated Schema
- Added text on S/MIME Handling
- Open Issue: Credential Transfer – How can you be sure user has
authorized being on resource list? Using Identity covers 95% of
cases: for now, resource list server needs to be either in the domain
of the subscriber of the list or in the domain of the notifier.
Will put off solving the three domain model (list server is in an
orthogonal domain), but make sure text doesn’t prevent doing this in
the future.
Resource Priority: James Polk
- Updates from 04 to 05 were extremely controversial. Intended to
address expected IESG concerns on interoperability, normative
inspecificity, and IANA registration.
- Proposal to remove confusion about Modes. Agreed to Remove
Semi-strict Mode.
- Editor proposed New Table describing Resource Priority namespaces for
IANA.
- Big fight occurred here: 04 vs 05
agreement on specifically defining terms
people adjourned, and issues will be brought to the
list
Refer Extensions – Orit Levin
- Split refer extensions into two separate drafts: REFER with no
implicit Subscription, and Feature tags with REFER
- Refer with no implicit subscription should be included
Cert Usage: Cullen Jennings
- Draft describes both HTTP and SIP method for Fetching Certs and
Credentials. One open issue: Which mechanism is mandatory to
SUBSCRIBE over SIPS or HTTPS GET:
- Using HTTPS expected to scale easier (no subscriptions) and is lower
bar for server implementation, while SIP mechanism allows for automatic
certificate revocation and reuse of a protocol known to be implemented
in the client.
- There was very rough consensus to go forward with SUBSCRIBE/NOTIFY as
the mandatory mechanism
SAML for SIP
- Latest draft Covered Identified Problems in previous version
- Need to Document Assertion Constraints and scope solution approaches
- Comments were solicited
Other:
Rough Consensus on making multipart-mime mandatory in all SIP
implementations to be taken to list