[Sip] Draft minutes of SIP meeting at IETF 62

The following are the draft minutes. Please send any required 
corrections by COB August 7, 2005.

Revisions will be posted as processed at:

http://www.softarmor.com/sipwg/meets/ietf62/notes/minutes-sip-ietf62.html

-----

Minutes edited by Dean Willis based on notes by Paul Kyzivat, Spencer
Dawkins, Vijay Gurbani, Amy Pendleton, and Migual Angel Garcia-Martin.

Monday, 1930-2200

Topic: Agenda Bash and Status
by Chairs
Slides presented and to be included in proceedings.

Agenda accepted as presented.

Chairs reviewed status of current work. It was noted that the current
charter and milestones are completely obsolete, despite having had
changes submitted several times by the chairs and the ADs. Apparently
there is some sort of process problem with the IETF web site.

Topic: GRUU Remaining Issues (Knowing AOR, Rewriting by SBC, etc.)
by Jonathan Rosenberg
see draft-ietf-sip-gruu-03.txt
Slides presented and to be included in proceedings.

Changes to previous doc reviewed. The redundancy issue has been
declared out of scope, and discussion suggested that this should
perhaps be placed into the Jennings "outbound" draft. The current
model assumes that both "sip" and "sips" versions of a GRUU are
created when a GRUU is, and that they route to the same resource. The
URI scheme of the "To:" header is used to select the appropriate
GRUU. It was suggested that this should be clarified in RFC 3261,
perhaps as an errata.

Several record-routing cases were discussed based on slides. There was
inconclusive discussion of a scenario where the use of GRUU creates an
undesirable "tromboning" effect back to the upstream entity after
resolution

1) Open Issue: Discovering AoR from A GRUU

Discussed issue about getting AOR from gruu - why this is/isn’t a
need.  Objections were raised to the proposed compromise in the
draft. Various other alternatives discussed. Cullen Jennings didn't
see a compelling reason for it. Paul Kyzivat (who had raised the issue
initially) said he no longer found this a need- solutions other than
GRUU were sufficient. Aki Niemi and Orit Levin still expressed a
desire for this feature. Dean, as chair, said we have no requirement
for this, and a domain can do it anyway if it wants. Inconclusive
discussion followed.

2 )Open Issue: relationship of Identity to GRUU

The relationship between these two elements was discussed without
conclusion, although Jon Peterson (author of the Identity work)
asserted an pinion that a GRUU and an identity are not the same thing.

Topic: Non-Invite Transactions
by  Robert Sparks
see draft-sparks-sip-nit-future-01.txt
Slides were presented and should be included in the proceedings.

1) Proposed that we accept and refine Time left concept, and not define
general "Try again later" behavior. This approach uses a new header
indicating how much time the downstream element has left.  Adam roach
argued that it was not a good idea - if we don't get any hints from
proxies who are not aware of this extension, we will go round in
circles.  Robert called for a hum on if this work should continue or
not. The consensus was for neither the timeline nor the "try again
later" work to continue.

2) Proposed that we pursue address success and failure caching.  The
goal is to allow next NIT to avoid non-responding address.  Question
is how often to probe the non-responding address?  No concrete way.
Jonathan Rosenberg proposed that we use Jenning's outbound I-D.  Cullen
Jennings stated that this may work for UA - Proxy, but Proxy-Proxy may
not quite work. Robert Sparks proposed that for now we carry a
blacklist; put these addresses in a cache with a timeout (let the
developer determine the timeout).  And we continue to pursue Cullen's
outbound I-D as a possible better answer. Discussion followed. The
conclusion was that for now we will use some weighted back to list
algorithm that will be fleshed out on the mailing list.

Topic: REFER Extensions
by Orit Levin
see draft-ietf-sip-refer-with-norefersub-01.txt
Slides were presented that should be included in proceedings.

Only one open issue remained for the draft since its WGLC. This was
"How does a REFER-Issuer enable the feature?". Alternatives include:
a) Commonly preceded by OPTIONS, b) supported header in the request,
c) required header in the response, d) require header in the request.

Discussion agreed that the Supported header is the wrong approach, as
it indicates which features are supported by the sender, not required
for the respondent.

Discussion became prolonged, and the participants were moved to the
hallway for a focused discussion. This discussion reached the
following conclusion:

   1) Add a new Refer-To header field
   2) Keep option tag
   3) Including this option tag in Require header is NOT RECOMMENDED.

This conclusion was shared with the WG, and no objections were noted.

The "hallway" conversation necessitated a slight juggling of the
agenda, with resource Priority being discussed during the hallway
discussion.

Topic SIP Resource Priority
by James Polk
See: draft-ietf-sip-resource-priority-06.txt
Slides were presented and should be included in proceedings

It was noted that this draft is just 2 weeks shy of its 5th
anniversary, making it one of our longer-lived discussions. Changes
since previous version were discussed. The plan of record is to submit
and WGLC a revision of this draft with minor cleanup as proposed
here. The authors requested: "For those who care, please approach us
and let us know of any concerns.  If someone can read this as an
innocent bystander and provide comments, please do".

The chairs polled the room: "Does everyone who cares about this draft
think their issue have essentially been met?" The consensus of the
room was favorable and no issues were raised. It should be noted that
Mike Pierce, a long time participant in this discussion, was not
present as of this poll.

Topic: Request Identity
by Jon Peterson
See: draft-ietf-sip-identity-04.txt
Slides were presented and should be included in the proceedings.

New open issues:

1) Display name handling - should identity signature
cover the display name?  All clients (MS Outlook,
for instance) use the display name, and not the name-addr.

Jonathan noted that this is usually a good thing; the service provider
bears the burden of coming up with the display name and the client is
provided a bit-by-bit rendering of the display name. Following
discussion indicated a strong consensus to protect the display name if
feasible.

The consensus was to protect display name, and in the display name,
just put quoted strings and prohibit LWS. In the security section of
the draft there should be a discussion of the disadvantages of
including display names (account minting a la Yahoo!)...)

2) Applicability to REGISTER - why provide authentication info to a
authentication server as well as to the registrar? Jonathan Rosenberg
presented an acceptable use case, and the authors concluded that they
would amend the draft to indicate the usability of Identity in
REGISTER transactions.

Topic: Response Identity
by Jon Peterson

No slides presented.

Jon lead a discussion about the meaning and critical aspects of
response identity.

Jon says he has lost his way on this draft. The sip-identity work
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?

Jonathan Rosenberg said major threat is if someone fakes a connected
party id, assuming we had that, and that such is a requirement. Rohan
Mahy thought History-Info is the right solution and said he plans to
write up something about it.

Consensus: We're generally headed in the right direction but have a
long way to go.

Topic: Accept-Disposition
by Gonzalo Camarillo
See: draft-camarillo-sip-accept-disposition-00.txt
Slides presented and should be included in proceedings

open question: 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?

Conclusion: Rather than pursue this approach, for the application
(exploder) that stimulated this draft there was a decision to use an
option tag to negotiate support for the needed combination of
features.

Separately, there was interest by some (at least Gonzalo and Paul) in
starting to investigate the underspecification of Content-Disposition.

Tuesday, 1300-1500

Agenda by Chairs Agenda accepted as proposed in slides. The proposed
topic of "Connection Reuse" was withdrawn by author Rohan Mahy. If
time allows, a discussion of retargeting led by Jon Peterson will be
undertaken.

Topic: SIP Interaction Framework
by  Jonathan Rosenberg
See: draft-ietf-sipping-app-interaction-framework-04.txt
Slides presented and should be included in proceedings

The current state of the draft has raised a requirement for other work
that Jonathan calls the "target dialog" approach and has fleshed
out. Discussion of this approach ensued. Alan Johnston noted that an
option tag is needed. Robert Sparks spoke in favor of the
approach. Following discussion, the chairs polled the room and a
consensus to proceed with this approach was reported. The chairs are
instructed to work with the Area Director to add the target dialog
draft to the working group charter.

Topic; Management of Outbound Connections
by Cullen Jennings
See: draft-jennings-sipping-outbound-01.txt
Slides were presented and should be included in proceedings

Open issue: Do we need an option tag to know if registrar supports
flow-id and if UA supports this.  Rohan argued against the option
tag. Jonathan proposed that it would be needed it in the Require in
the REGISTER.  Rohan countered that one could check in the response
what it came back, and perhaps add a Contact header field parameter to
discover if the functionality is supported by the registrar.  Alan H.
noted that if the registrar does not support the functionality, you
end up with a wrong binding that you have to fix later.

After discussion, there were no sustained objections to adding an
option tag, and a quick poll indicated consensus for this
approach. Cullen agreed to make this change in the next revision.

Topic: Using Certificates with SIP
by Cullen Jennings
see draft-ietf-sipping-certs-01.txt
Slides were presented and should be included in proceedings

1) Robert Sparks commented that the draft needs further text about
caching certs, and checking certificate revocation.

2) Jon Peterson suggested that we make sure to clarify subscription
duration, which Cullen noted should not cache beyond validity time

3) Rohan observed that we need to refresh the subscription even if the
cert is still is valid, when there hasn't been a NOTIFY for some long
period of time.

4) Francois Audet noted issues with retargeting and forking. For
example,the sales group example does not work properly. An other case
is retargeting. Use case: the help desk. You don't care who is going
to answer, but the requirement is the conversation to be
encrypted. Cullen observed that the assumption of this draft is indeed
that all devices for the ID have the same credentials. Jon Peterson
suggested that RFC 3261 with SIPS resolves theses cases. Cullen
observed that there are separate problems: a) to determine who the
certificate belongs to, and b) acquiring the certs. This draft
addresses only b.  It was resolved that the scope of the draft should
be clarified, and that we should change the name to "credential
management" instead of "certificate management".

5) Jonathan asked:"What happens if I send a SUBSCRIBE for a GRUU? Do I
get the cert for the AOR?" Cullen responded that the draft discusses
users, not devices. Jon Peterson stated that this problem should be
resolved in the identity draft, not here.

Topic: End-to-middle security
by Kumiko Ono
see draft-ono-sipping-end2middle-security-04.txt
Slides were presented and should be included in proceedings

Chairs noted that they expect this work to migrate from SIPPING to SIP
fairly soon, as has gone beyond the requirements consensus and into
implementation.

1) Open issue: Signatures inside, encryption outside or the other way
around?

Jon reported that we did some analysis about this when drafting RFC
3261, and think the signature should go inside, the encryption
outside.  Cullen believes that signature inside the encrypting part
will give better security properties (from the security group).
Catherine also stated that the crypto community thinks signature
inside is generally better, although there are sometimes exceptions.

Conclusion: consensus to have signature inside.

2 )Open issue: How a proxy can tell a UA to disclose a body while
protecting data integrity?

Options include new error response, existing resp with warning header,
or existing resp instruct UA one task at a time.

James Polk asked if we could use CID and Reason header? Jon Peterson
noted that CID is valid is the scope is a partial body of the
multipart, but if you talk about the whole body, you don't need a CID.

Dean asked: can the proxy request a body? Jon responded: if it is
undecipherable, how can it point to one body? The proxy only knows the
whole multipart body, not the individual parts. It is better to do it
at the high level -- the proxy says I need to read this body, without
indicating which one.

Dean and Jonathan noted that Content-Disposition may also be applicable.

No conclusion noted for this issue.

Chairs Poll: This is a proposal for an implementation of the
end-to-middle requirements established by SIPPING. Do we wish to adopt
this as a working group item? A consensus in favor of adoption was
reported, and the chairs are instructed to work with the D to get this
item added to the SIP WG milestone list.

Topic: Extension Negotiation
by Volker Hilt
See: draft-hilt-sip-ext-neg-00.txt

Slides were presented and should be included in the proceedings.

Discussion followed.

Paul K noted that this aggregates on not being clear of what is the
scope of what an Accept header is. Does it apply to OPTIONS?  Severe
discussion about when to include or not the Accept header, in which
methods.  Jonathan replied: There is not a not clear answer, but
interoperability is maximized when you put everything you support in
the header. OPTIONS carries a permanent scope: this is what I support.
Gonzalo observed that, at the end of the day what we want to disclose
is the desired Content-Disposition.  Dean also observed that RFC 3261
scopes the Accept header to the duration of a dialog and that RFC 3264
scopes the Accept header for the duration of a SUBSCRIBE dialog.

Dean suggested that this would be a good time time to have guidelines
for Accept headers. Cullen and Jonathan maintain that it is simpler to
populate the Accept header with everything that is supported, even if
this set becomes very large.

Jonathan clarifies that the use case is when the server can provide an
alternative extension in case the client does not support a given
extension. The example: if the presence server knows that the client
does not support RPID, then the server might put the contents of
activity elements in note elements.

Adam noted that there is currently no way for the server to determine
that something is not supported at the client.

There does not seem to be a clear path forward, and we should perhaps
look more closely at use cases.

Topic: Retargeting
by Jon Peterson
Slides presented and should be included in proceedings.

Discussion followed.

Rohan Mahy observed that sometimes an unanticipated respondent is a
desirable outcome. And sometimes it isn't.

Keith Drage proposed that response identity should be connected party
ID.

Jon observed that the response identity problem is defined as the
ability from the UAC to determine that the response came from an
impersonator. Implementation of connected party is likely to occur
security problems, and a UAC doing wrong authorizations.

Jonathan suggested that we reduce the scope of the requirements to
something that we can solve today. There are other harder problems
that we can't solve today.

Jon proposed that we need to solve the problem that ends up in SRTP,
starting from SIP identity, SIP certs, Mikey, SRTP.

Discussion of endpoint vs proxy trust followed, with the general
consensus being that, at least to some extent, proxies must be
trusted, because "the SIP proxy allocates you with a SIP URI and can
take it out of you at any time".

Jon proposed that we takes this work as an informational document in
SIPPING discussing the kind of attacks.

Jonathan noted that we need to update the SIPS behavior in SIP, there
are a few open holes.

Jon restated that the scope of this work is to detect that there has
been a retargeting, not to prevent that retargeting to happen.

No further conclusions were noted.

The meeting of the SIP working group concluded on schedule.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip