Notes on SIP at IETF 62
Reported by Spencer Dawkins
Session Initiation Protocol WG (sip)
Monday, March 7 at 1930-2200
Tuesday, March 8 at 1300-1500
==================================
CHAIRS: Dean Willis <dean.willis@softarmor.com>
Rohan Mahy < rohan@ekabal.com>
AGENDA:
Monday, 1930-2200
1930 Agenda Bash and Status
1945 GRUU Remaining Issues (Knowing AOR, Rewriting by SBC, etc.)
Jonathan Rosenberg
draft-ietf-sip-gruu-03.txt
• Need to be aware that proxies
will be doing more location service lookups with GRUUs, in cases like
mid-dialog requests when it would not have done so previously
• Concerns about a chain of
proxies when a proxy removes Record-Route header from 200 OK when
Supported: gruu - are there side effects on downstream proxies? Spec
already allows rewriting, but this was unexpected. Jonathan thinks he
has a workaround (based on Path header with a hint: "this guy has a
GRUU" - and this can be a local proxy decision, since it's only used by
the proxy itself in the other direction), but doesn't want to design
this in real time during the meeting
• Is extracting AOR from GRUU
required? SIMPLE thought so, but wasn't in original requirements so out
of scope. Jonathan proposed naming convention with current mechanism,
Orit proposed something else, back to square one... Presence document
should have AOR, anyway? If a GRUU from a presence document gives you
AOR, isn't this useless anyway? Does a GRUU become AOR with an extra
parameter? Jon Peterson thinks opaque GRUUs are required. Refer-to
lacks a displayable name in To, and this points to part of the
confusion with GRUU - it doesn't have one-to-one relationship with AOR,
so not sure how including AOR as part of the GRUU is going to help. If
we don't have a strong need for this, don't make our naming problem
worse! Where does the requirement to hide the AOR come from? Just
anonymity? GRUU doesn't solve this anyway. Provider needs to be the one
who hands out the GRUU. What problem are we solving by tying GRUU to
AOR? This opens a big can of worms - don't do that without a good
reason. GRUU is not a user-friendly identifier in the first place. We
can allow domains to hand out reversable GRUUs, but don't need to
require reversability? A GRUU is peer to an AOR at this time - is this
right? There's no distinction between any of these URI types, and
that's a big source of problems for us. Is this how we will do RFC
3323bis in the future? An AOR needs to be an identity, and GRUUs
aren't. But GRUUs are just as return-routable as AORs. GRUUs are
supposed to be serving as replacements for non-routable IP addresses in
Contacts - not as a replacement for AORs. We'll continue this
discussion on the list
2015 Non-Invite Transactions
Robert Sparks
draft-sparks-sip-nit-future-01.txt
• NIT problems and NIT actions
drafts at the IESG now
• Want to formally decline
changing NIT state machine to "pend" - Alternative B. Too big a change
for too little benefit, with too much state in proxies - mild room
concurrence - please send text on why we're not going to do this
• Want to accept and define
Timeleft - including a way of estimating Timeleft if you don't have
this information. This is kludgy and a tarpit. It's better than what we
have now but not better than Alternative B. If we just put out a magic
number now, is that good enough? It will still work. Sense of the room
is that this is silly, and we shouldn't worrry about this at all
• Want to avoid general "try
again later" with new protocol work - we need this with existing
applications using existing methods - some clarifications for mass
registrations (example) would be helpful. Message transfer proposals
are getting shot down for lack of this mechanism - consensus of the
room is that we DO want general "try again later" in next version of
the draft
• Want to pursue address success
and failure caching - people are deploying blacklist with
implementation-defined timeout. We should provide guidance. RFC 3263 is
very vague on this topic. Would it help if a blacklist only works when
you have other alternatives? Blacklisting becomes "move to back" - this
is what resiprocate implemented and it works well. What if you never
use this resource again? In this problem space, we're talking about
second requests. "Move to back" isn't enough - we do need to blacklist,
even if there's only one possible resource, to avoid hordes of
transactions that chew up state for 32 seconds and then all fail.
2030 REFER Extensions
Orit Levin
draft-ietf-sip-refer-with-norefersub-01.txt
draft-ietf-sip-refer-with-feature-param-01.txt
• New option tag norefersub
defined and registered with IANA to allow REFER that does not create a
subscription dialog
• Use Supported, Required,
Require headers to make this work.
• Proposal assumes Options before
REFER - do phones still do this? Pingtel does.
• Who decides not to do an
implicit subscription? REFER-issuer or REFER-recipient? Supported is
usally "everything you support", and we're trying to use it as
"everything you want" - that's what's breaking.
• We've gone from Required header
in REFER request to Supported header, trying to get norefersub in one
round trip
• We can turn subscriptions off
with 481 response to NOTIFY (but this does put more packets on the wire)
• This discussion ajourned into
the hallway - resolution
2115 SIP Resource Priority
James Polk
draft-ietf-sip-resource-priority-06.txt
• two weeks shy of five-year
anniversay for this effort
• Removed all modes from 05,
added element-specific behaviors for premption/priority-queue namespaces
• Provided semantics for
priority-queue based elements
• IANA namespace registry table
is prettier
• 07 will be submitted Monday
• Cleaned up text, removed
prioritized responses, added introductory text, reworked security
considerations
• Does anyone who had an
issue still have one? Not in this room
2045 Identity -- Request
Jon Peterson
draft-ietf-sip-identity-04.txt
• Added new response codes
• Softened direct TLS connection
requirement
• Added support for CID URI in
Identity-Info
• Added non-normative text about
requests in the backwards direction within a dialog
• 4xx responses go back to the
UAC that didn't create the header? That's valid. Proxy could consume
4xx response (as in forking now) - no problem with this. This is for
proxies that are acting as an authentication service - how does a proxy
know what to propagate upstream? Correctable errors should be forwarded
- how does a proxy resubmit after a correctable response? If there's a
forking proxy in the path, the normal rules apply on response selection
for forwarding
• Need to fix section 6.1 -
prejudicial toward response identity
• Cover display name with
signature? SIP doesn't assume display name matters, but UAs may
continue to display unauthenticated display names instead of
authenticated identities - if a provider figures out what display name
to provide, they can provide the exact bits to display and cover those
bits with a signature - don't mix authenticated and unauthenticated
information - are we defeating replay or MITM attacks? - are we
internationalized enough with quoted strings? Not protecting display
names in the age of phishing is insane... but minting identities is
really easy - we aren't solving all the problems, we're letting service
providers try to solve this
• Applicable to REGISTER method?
uses same credentials for REGISTER and authentication, this is circular
- depending on deployment strategy of provider
2100 Identity -- Response
Jon Peterson
draft-peterson-message-identity-00.txt
• Jon has lost his way on this
draft. sip-identity doesn't work for responses because of retargeting.
Who do responses actually come from? What are intermediaries allowed to
do when routing SIP requests? How would a UAC make authentication
decisions based on response identity?
• Anyone can impersonate a
requester, but impersonating a responder is a lot harder - need dialog
identifiers, etc.
• Improve channel security to
make it even harder to impersonate a responder? Provide causal trace
after-the-fact? Let UAC explore new targets for a request? Assume bar
is high enough for impersonators now? - what if the real responder
tries to impersonate someone else?
• We're headed the right
direction - Rohan will send text
Content-Disposition
Gonzalo
• How do we say we don't
understand content-disposition?
• Add Accept-Disposition
(equivalent to Accept header)?
• We have several ways to require
support for something - method, option tag, body with
handling=required. Want to pick one and clarify content disposition
handling
• Combining two problems - Accept
is used as hint about how you goofed. Isn't Warning closer to what
we're getting at? Accept headers became useless because everyone
Accept: * (everything). Don't we really want an explicit code that
tells us what we want to know?
• How to tell refusal from lack
of comprehension?
• What is scope of
Accept-Disposition?
2200 Close
Tuesday, 1300-1500
1300 Agenda Bash
1310 SIP Interaction Framework
Jonathan Rosenberg
draft-ietf-sipping-app-interaction-framework-04.txt
• Minor comments from WGLC
• One new issue posted to list -
unifying dialog identification mechanism between app-interaction and
other specs
• Want to use a Target Dialog
Header
• Do this as standalone ID?
• Remove existing Refer-To
extensions from app interactions
• Normative reference from
cc-transfer
• Informative reference from
dialog-usage
• Hummed to accept Jonathan's
proposal, chairs to coordinate with ADs and make sure this is part of
our chartered milestones
1350 Management of Outbound Connections
Cullen Jennings
draft-jennings-sipping-outbound-01.txt
• Issues from topology
complications - firewalls, centralized proxy farms, decomposed proxy
farms
• Previous ID said new
registrations removed old registrations - what we need to do is try
newest registration first
• Still getting lots of questions
about UDP keepalives - we decided STUN at IETF 61, is this still what
we've decided now?
• Problem with 3rd party
registrations - this is broken
• Need tighter specification
language
• URI tag for STUN support, like
sigcomp support
• Option tag to know if registrar
and UA support flow-id - do we need this? Will registrar behave
differently? what if proxy forks you two calls on every INVITE?
Register with Require? Supported header? Content header? Supported
headers carried all the time, with no additional value. We don't really
care how we can do this as long as we can figure out if it's supported.
Jonathan - this is the most broken thing in SIP today.
• Discuss configuration for
redundancy and geographic redundancy
• Contact header will have a GRUU
1405 Using Certificates with SIP
Cullen Jennings
draft-ietf-sipping-certs-01.txt
• Minimal changes, but lots of
editing (now it's a specification instead of a proposal)
• Defined SUB/NOT as transports
• Subscription time no longer
tied to certificate validlity time
• Now you can publish just a
certificate without private keying material
• Added subsection on generating
PUBLISH
• Corrected typo in crypto type
• Concern - this doesn't work
well with forking/retargeting when you get different credentials back
from each fork. Is this just out of scope?
• This assumes that we're
expecting subscriptions for certificates and not getting certificates
some other way
• What happens when I subscribe
to a GRUU? (What's a GRUU? what's the connection between an AOR and a
GRUU?)
1420 End-to-middle security
Kumiko Ono
draft-ono-sipping-end2middle-security-04.txt
• Moving beyond requirements to
how-to phase of this work - expect this may become a working group
effort
• Adding Proxy-Required-Body
header
• Adding 495 Signature Required
response code
• Changed how to protect label
and its constraint (by using TLS)
• Allowed to remove a label at a
proxy depending on policy of service providers
• We need signature for a whole
body, not a body part - inside, in the middle, or outside when body
part is encrypted? RFC 3261 discussions are that this doesn't matter,
but if there is a right answer, it's probably signature inside the
encrypted part - crypto community recommends this as well
• How does a proxy tell a UA to
disclose a body while protecting integrity? Suggest an existing
response with Warning header - 493, undecipherable
• We're adding semantics to
Warning headers that weren't there before - use another header?
• Do we need a CID? This is about
operating on a part of a body or on an entire body - we're talking
about content types, not about contact ids
• When you get an encrypted lump,
you can't point into a part of it. Proxies may just ask "show me
everything" anyway - or by content type, or by content disposition
• Do we want to take this draft
as baseline working group text? Consensus of the room is in favor of
adopting (with a few opposed)
1440 Media Type Extension Negotiation Negotiation in the SIP Accept
Header
Volker Hilt
draft-hilt-sip-ext-neg-00.txt
• Accept allows negotiations of
major MIME types, but does not cover extensions. XML uses extensions
heavily (for instance, name spaces)
• Announcing extensions increases
overhead significantly - don't announce an extension unless it's
beneficial for sender receiver
• How do we handle multiple
versions of the content?
• This makes an existing problem
worse - we don't know when to send Accept headers now...
• This may be OK for OPTIONS
request, but what about other options?
• How long do we cache this
information? For the life of a subscription? Accept is "everything I
accept".
• Interoperability is maximized
when you tell people everything you support up front.
• Does RFC 3261 limit Accept
scope to a dialog? That would help, if it does - apparently it does
• Anytime you tell implementors
"only send this if the other side will want to know it", that's no help
at all
• SUBSCRIBE/NOTIFY dialogs also
seem to have the same Accept scope
• Is this actually useful? The
presence server might send an entirely different document because it
knows its peer can't use the first document
• Saying what you don't support
is even worse. What's wrong with filters?
• Server can't know that you
DON'T support a content type - you can leave stuff you do support out
of the list - this is just about semantics-free
• Conclusion - we should
seriously consider use cases
"Are Proxies Trusted?"
Jon Peterson
• What are proxies trusted to do?
Fundamental authorization concepts are NOT explicit in RFC 3261.
• "Everything that is not
preventing by mechanism tends to be permitted in practice"
• SIP proxy servers behave as if
UACs have no authority to exert policy controls over the handling of
requests
• Applying integrity mechanisms
to all SIP messages as a requirement would change this.
• Can't tell the difference
between intermediaries and attackers
• Retargeting is inherently
insecure - service hijacking, response identity, establishing security
parameters, blacklist circumvention, and transitive trust (or lack
thereof)
• Unanticipated respondent keeps
us from just reusing request identity as response identity
• Naive implementations of
connected-party are going to have security problems
• "Unanticipated" isn't
requester-only view - called parties may have very clear plans for
retargetting that callers don't know about
• Security is about preventing
sessions, not about reacting to undesired sessions quickly
• People are tolerant - I'd like
to establish a secure session, but will accept an insecure session if I
can't have a secure one. This is subject to bid-down attacks, but maybe
that's still OK
• Are we going to use SRTP or
not? If we can't, we shouldn't bother worrying about security at all.
• CallerPrefs doesn't solve any
security problems, but does help with preferences in the absence of
malicious attackers
• Do we want to UACs what
intermediaries DID, or do you want to have the UACs explore new targets
instead of intermediaries
• We have lots of excellent
requirements in this draft - don't we just open new holes when we close
old holes?
• Jonathan - take this work and
produce informational document, define narrowly scoped problems, and
focus on secure channels so we don't have to probems we have with SIPS
today