Subject: [Sip] Draft minutes, SIP WG at IETF 63

From: Dean Willis <[email-masked]>
Date: Wed, 31 Aug 2005 21:59:10 -0500

Draft minutes are posted at:

http://kevlar.softarmor.com/sipwg/meets/ietf63/notes/minutes.html

and text follows. Please review for accuracy and reported back by
midday Friday, Sept. 2,  US CDT (GMT-5).

Minutes, SIP WG, IETF 63

Reported by Dean Willis and Adam Roach

Edited by Dean Willis

Session 1

Status, presented by Rohan Mahy

Slides presented.

Note that content-indirection has finally cleared security review and
requires a small RFC editor note that will be drafted by Allison.

Discussion of milestones:

Suggested that it would be a good idea to have a regular report on
status for WGLC, etc.

The WG will consider getting a WG secretary as an assigned role.

Noted that if we can't track the work we have, we shouldn't accept new
work.

Proposed that we delete the response identity work from our work plan.
We plan to reopen this during the discussion of the related draft in
the Tuesday session.

Discussion on priority of resource conveyance. Proposed schedule is for
Spring 06. James Polk thinks we can get it done sooner, and should due
to dependencies. We agreed to reopen the schedule discussion after the
WG discussion of this draft in the Tuesday session.

Discussion of SIP Security Flows

There seems to be some support for this work, and a consensus that this
stuff if important.  Possibility raised that we might also need to
update 3261 and related documents, either to add clarity or to fix
bugs, and that this is more important than getting example flows. We
also have references to outdated security documents, and common
implementations may also not be acceptable for current security review.
It was noted that S/MIME implementation issues have been common at
SIPIts. Poll: Who has an implementation of S/MIME? At least 5 in the
room, and two others at last SIPit who are not represented in this
room. consensus: We do not have all required expertise in this room. A
significant problem is that there is a knowledge gap between the
implementation community and the IETF security area. We'll work on a
plan for reducing that gap. An important goal is to move the knowledge
from this document (once it's there) into the broader community.

Topic: GRUU

Discussion led by Jonathan Rosenberg

Slides presented

Changes since last version reviewed.

Comment: Opaque parameter: Cullen offered a lengthy comment supporting
the idea that nodes other than proxies be able to extract the AOR from
the GRUU. The current text seems to allow this if the opaque parameter
is used. Rohan will send to Jonathan commentary on an apparent error in
the current text.

Comment: We may need to discuss the situation where a client has two
connections to different proxies.

Comment: Would like to see more discussion on the opaque parameter.
Jonathan will plan to clarify the general usage and synchronize the
work with the SIP outbound dual-registration use case.

Comment: When is the GRUU assigned? Is it a function of registering a
contact, or is it a function of someone needing the GRUU? Jonathan
considers this to be a function of domain policy. It would appear that
it cannot be constructed after the registration, but could be
constructed before. Further discussion of this can be added to the GRUU
document.

Comment: There needs to be something about the ability of a user agent
to determine whether an AOR is or is not a GRUU when it receives a
GRUU. This relates somehow to use of the GRUU in transfer cases. One
possibility might be a ";user=gruu" parameter. Discussion seem to
indicate that the receiver just has to try the URI and see if it works
-- it can't really care whether or not the contact is a GRUU. Proposed
to keep as-is, except for clarification.

Comment: We have a September milestone. Will we make it? This seems to
depend on the acceptance of today's proposals.

Issue: The Double Role of GRUU

Proposed three solutions 1) GRUU for new requests only, 2) Amend use of
Contact in mid-dialog request, 3) , keep as is

Comment: The SBCs are going to ruin GRUU in all the usages proposed.
This may more strongly affect #2, and favors #1.

Comment: The contact information is usually wrong anyhow. This favors
#2.

Comment: Currently, route sets in a dialog are immutable. The
ability  to use applications at the end point is dependent
on  this,

Comment: #2 is favorable, because it also encourages endpoints to deal
properly with.  Draft should note that when used with Replaces,
INVITES to a GRUU should only get automatic and not interactive service
treatments.  This will require some changes in the document
relating to edge proxy behavior and moving treatment.

Comment: After the preceding discussion, Cullen no longer favors #2.

Comment: Multiple implementations have proposed to use multiple
contacts in dialog as a failover mechanism, This does not favor idea 2.

Poll: Does anyone strongly object to "keeping the text as is"? for this
issue with clarification as discussed above)? Consensus on this
position is reported.

Topic: Dialog retargeting

Discussion led by Jonathan Rosenberg

Slides included in GRUU deck

No open issues, currently in WGLC

Topic: End to Middle Security

Discussion led by Kumiko Ono

Slides presented

Issue #1 UA reaction to (undecipherable) error? If there is only 1
error code and the UAC doesn't support e2m, they don't really know what
to do.

Comment: What we want here is the client to encrypt the body and add
the proxy to the keying. This differs from the current usage, in which
we want the UAC to change the target of the body rather than adding a
key.

Comment: The confusion on this relates to confusions on the 493
response, and that leads to the question of response identity. It might
be possible to use SIPS to target the alleged proxy.

Comment: We must be careful to not accidentally introduce errors that
lead to "base 400" style behavior. This favors a separate error code.

Proposed that we move forward with a separate response code.

Issue #2: How does a proxy indicate disclosure of a specific content
type or whole body?

Proposed that an error code without body type have semantics of
"disclose whole body". No objections were noted to this proposal.

Issue #3: Do we need a labeling mechanism to instruct a server to
validate a signature

Proposed: No. No objection noted.

Issue #4: How does a UA know if the target proxy server complied
to  the UA's request?

Proposed that if  we don 't have a use case for this and one is
not forthcoming, that we discard this requirement. Further discussion
deferred to list.

Noted that we expect to go to WGLC with the next rev of the dratf.

Topic: Outbound Connections

Discussion led by Cullen Jennings

Slides presented.

Changes in terminology since last draft reviewed. Critical terms are
"flow" and "flow ID".

Comment: The terminology is still confusing. Some definition changes
were discussed, including use of the term "epoch" to refer to a set of
TCP and UDP connections.

Issue: default max retry time is 30 minutes. Does this need to change?
No changes were suggested.

Issue: Keepalive. Proposed that we use STUN keepalives for both TCP and
UDP. This would require changes to the STUN document.

Comment: ICE also uses STUN over TCP.

Comment: The client needs to know that this is supported. Currently,
this is done as a URI parameter.

Discussion of this followed, without conclusion.

Issue; Keepalive Times? Proposed that this be 30s for UDP and 10
minutes for TCP. Noted that 1% of one operator's boxes have UDP
timeouts of 15s on their NAT bindings.

Comment: We are not doing this because TCP's keepalive does not work,
but because the feedback is not delivered fast enough to the SIP system

Comment: Need to make sure that the document shows that the timer
resets on each instance of normal traffic.

Comment: Do we know enough about the performance and congestion impact
of this?

Proposed:  30s for UDP and 2min for TCP.

Comment: If UAs do this at startup, we have a potential for a restart
avalanche. Discussion on this is deferred.

Issue: Flow questions:

Noted that we cannot assume that all UAs using this will have multiple
flows.

Issue:  Transport integrity for flow matching.

Do we want the security section say that this only works with integrity
protection? general consensus on "no".

Further issues taken to list, including route construction logic.

Session 2

Topic: Refer: Feature Tags

Discussion led by Orit Levin

Slides presented

- Topic of discussion: Which feature tags do we want to include

in the REFER? Does the referer include all features
it knows

about? Only the ones that it thinks are relevant for
the call?

- Paul Kyzivat: Allowing the referer to pick which
features

to include is a slippery slope. Doesn't
think disclosing

feature tags is a security risk.
Proposes that the referer

should (or must) include all feature
tags it knows about

- JDR: Disagree with Paul on the security issue.
Also, has

a concern that people will start using
these to bypass normal

SIP negotiation (e.g. not offering video
if the referer does

not indicate support for video).
Further, thinks it is realistic

to pick which feature tags make sense to
include: presumably,

the purpose of the mechanism is to allow
changes in the user

interface, and it should be possible to
identify which features

might have an impact on the interface.

- Paul Kyzivat: Don't feel strongly about the topics
-- seems to

hinge on security. If there are no
security reasons to not

include *all* feature tags, then
including all feature tags

can only be a good thing.

- Cullen Jennings: We need to make sure this isn't
going to rely

on implementors deciding what things to
include. Also, the list

of features can grow to be quite long,
if you include everything.

Propose that we set up a concrete
registry of feature parameters

that should be included in REFER
requests.

- Rohan Mahy: Would it be reasonable to include only
those features

that cannot be discovered via SIP
negotiation?

- Proposal: Use MAY and SHOULD recommendations
around which official

tags are to be included in REFER
requests. The text will be vetted

on the list.

- Cullen: This is tricky; as an implementor, I can't
tell which tags

I should include in a REFER -- and I
can't count on what other people

will send.

- Rohan: There are really only two options. You can
either have an

explicit list of what must be included.
This will always be out

of date (and consequently always wrong).
Alternately, you can leave

it up to the discretion of the
implementors, in which case it will

only sometimes be wrong, which is better
than always being wrong.

- Cullen: That doesn't make sense. An IANA registry
makes a lot more

sense.

- Paul Kyzivat: I don't know why we need this at
all. How does knowing

ahead of time that the thing to be
invited is a focus make a

difference?

- Orit: Consider isfocus. Most of the time, you're
not going to be

talking to a focus. But somtimes you
are, and you can either

find out ahead of time, or have to query
for it.

- Paul: No, you don't. You get that fact in the 180
or 200 response

to the INVITE.

- Dean Willis: I'm confused and my head hurts. Are
we reaching a

consensus?

- Consensus: no.

- Chair proposal: We will have a group of interested
parties get

together after the meeting to come up
with a plan to conclude the

document.

Topic Refer: Norefersub

Discussion led by Orit Levin

Slides presented

- Should we use a "Refer-Sub: false" mechanism, or a
Supported/Require

alternative?

- Adam Roach: We already decided this. Let's not
re-open this.

- RjS: This is not the timme to do this.

- JDR: The new proposal doesn't seem to be general
in any way.

- Consensus: Leave it as we defined previously.

- Should remove the use-case discussing single-hop? There was an

explicit request to do this.

- RjS: This seems to work.

- JDR: It's impractical.

- RjS: I've seen deployments that do this.

- JDR: Okay. It's not worth debating.

- Cullen: Is this a recommendation, or simply an
observation?

- Consensus: Just an observation. The draft should
reflect this fact.

Topic: Location Conveyance

Discussion led by James Polk

- Topic: Location Header Option-tags

- HGS: This seems to be a table of contents for the
body. If

we're going to do that, it should be
more generic. We would

basically want this for any non-SDP body
type. (Some discussion

around this point, but basically results
in agreement with

Henning's comments)

- Dave Oran: I'm not sure how these specific option
tags allow

a user agent that doesn't know its
location but having the

wherewithal to select, e.g., between
civic or geoloc

information. (Longer discussion, taken
offline).

- Cullen: SHould look at whether this can be based
on the

SIP identity work. (James expresses some
concerns that the

ECRIT work shouldn't block on SIP
identity).

- Unknown Speaker 1: Is it possible to include
information both

from the terminal and by the proxy?

- James: What do you do in the case of conflicts?

- Unknown 1: Use what the UA provides.

- James: Service providers don't want to trust that.

- Topic: Dean doesn't like using OPTIONS to fetch UAC's location.

- Several: Dean isn't the only one.

- Consensus: This should be a SUB/NOT mechanism.
(e.g. UA

subscribes to own presence).

- Open Issue: Which event package should be used?
(Presence,

new one defined in SIPPING, or new one
defined somewhere else)

- Several Speakers: Presence is done, filtering has
had a lot

of work done on it. It makes no sense to
do this work all over

again with the same end result.

- Others: It may be too heavy to expect people to
deploy presence

just for emergency services. It's a bit
complicated.

- Rohan: I will put together an email discussing why
presence

isn't the right way to do this.

- Proposal: Take this text out of the draft, put it
elsewhere,

and progress it separately.

- Will be taken to the list. If we can't close
quickly, we will

split the draft.

Topic: Response Identity

Discussion led by Feng Cao

Slides presented

- HGS: This appears to be reinventing TLS using HTTP-digest-like

authentication.

- JDR: We need a way to figure out a way to verify that the

connected party is who they say they are.

- Jon Peterson: Don't conflate the party or parties who respond

with the party to whom you are connected.

- General discussion: It's not clear what this document solves

that TLS does not. The response authentication stuff
simply

doesn't make sense, given that SIP mandates TLS.

Topic: SIP SAML

Discussion led by Jon Peterson

Slides presented

- Several people spoke up in support of role-based authorization.

This was followed by a dogpile of varying use cases.

- HGS: The barrier to entry seems to be high -- doing the work

to put in the first installation is wasted, since
there's no

one to talk to.

- High level issue: should we split framework from mechanism?

- Cullen: We don't want to freeze the framework
before we start

on the mechanism.

- Poll for consensus: Should we take this on as a working group

item?

- Cullen: Where does this go in our schedule?

- Result: Rough consensus to add as a working group
item.

Topic: Answer and Alert Mode Extensions

Discussion led by Dean Willis

Slides presented

- Paul Kyzivat: The emphasis thing doesn't seem to make much
sense.

Semantics are unclear.

- Dave Oran: I'm not confused. I'm sure it's bogus. You can use

an "Alert-Info" header that specifies a different
mode of

ringing operation. You can use "Priority" if you
want to emphasize

a call.

- Andrew Allen: We're not sure how priority is getting used.

- JDR: This presumes a discrete set of policies, which need to be

well-defined at the UAS -- otherwise, this is pretty
useless.

- Francois Audet: We definitely need to have better defined

semantics for this, including examples.

- JDR: Yes, this does need to have applicablity outside the OMA.

Also, note that this benefits from role-based
authorization.

- Paul Kyzivat: In the general case, this has significant ability

to be abused. Loopback and push-to-talk don't allow
covert listening.

Once it is applied to two-way calls, you need to
have much stronger

security considerations.

- Several others spoke in favor of having stronger requirements

around security and policy.

- JDR: There are two seperable issues here. First, the policy
needs

to be clearer, so that we understand how the
override and emphasis

stuff works precisely. As a separate issue, we need
to be able to

determine how users are authorized to request these
kinds of

overrides.

- Comment: OMA has an authorization model around this mechanism
that it may be possible to

leverage.

[Meeting Ends]

---------------------------------------------------------------------------

Key:

RjS = Robert Sparks

JDR = Jonathan Rosenberg

HGS = Henning Schulzrinne

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip