Notes, SIP Session 1, IETF 63
Reported by Dean Willis
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.