Subject: [Sip] First Draft Minutes, SIP WG IETF 51

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 Aug 2001 17:04:39 -0500

Here's my very first rough draft of minutes for SIP WG at IETF 51, based on
mine and Tom Taylor's notes. Please send suggestions for corrections.
Note that minutes and notes are being accumulated at:
http://www.softarmor.com/sipwg/meets/ietf51/minutes/

--
Dean
----------------

Minutes prepared by Dean Willis, based mostly on notes by Tom Taylor,
without whom we would cease to report.

SIP Working Group met at IETF 51 for two long sessions, a total of 5 hours
of meeting time. The revised was completed, with the exception that several
of the Rosenberg drafts listed in conjunction with alternative views were
not discussed in detail. Instead, Jonathan addressed only the significant
differences between his approach and the alternative presented.

We also scheduled three adhoc after-hours sessions:  1) Security, 2) Privacy
and Outbound Services from Non-Adjacent Proxies, and 3) Firewall Traversal.
A fourth adhoc on call Control was proposed by Rohan Mahy, but the proposal
was withdrawn before the meeting.

Slides are posted at: http://www.softarmor.com/sipwg/meets/ietf51/slides/

Work Plan status
-----------------

Approximately half of the extant SIP drafts have been tentatively moved to
SIPPING.  The managed Last Call process is now starting to flow, and it
looks like we'll be able to work through the backlog. We have a near-term
requirement to reset several milestones, which will be executed on-list.

REFER Method
-----------------

This is part of the "call control" work, which addresses call transfers and
thrid-part all control. The existing draft draft-ietf-sip-refer-00.txt was
recently split off from the "transfer" draft. Open issues: 1) The "referred
by" information is similar to the Remote-Party-ID of the Privacy work. Can
these two share a general mechanism? 2) The draft defines a crude integrity
mechanism for referred-by, but this should use a general-purpose header
integrity mechanism. Consensus to advance draft by deleting integrity
mechanism and referring to SIP Security work. 3) The MIME-type of the REFER
body remains unresolved, and a number of security questions were raised with
various proposals.

Replaces Header
-----------------

This header indicates which call leg the call leg mentioned in a REFER is to
replace. This work is fairly mature, and no issues were raised.

SIP Events
-----------

Issues with authentication, 1) DoS attacks, and amplification, 2) Forking,
3) Record-Route, 4) Expires, 5) event package names, and 6) Call-leg
correlation, 7) partial-vs-full state transmission  were raised.

1 ) DoS/Amplification: Each SUBSCRIBE produces one response and one
notification, which could make a 2-to-1 amplifiier. Consensus to define
general "anonymous" authentication mechanism in bis.

2) Forking: No technical problems preclude support for forking of SUBSCRIBE
if forking of INVITES is supported.

3) Record-Route: current draft's wording seems ambiguos and has resulted in
variant interpretations. Consensus to clarify in revised draft.

4) Expires: Current draft overloads Expires header in NOTIFY to indicate
when subscription will expire. This is an overload of header. There is a
proposal to use a new header, Subscription-Expires, which may offeer
semantic advnatge in subscription migration. Weak consensus for propsal.

5) Event Package Names: Debate is to whether to allow private event package
names. Consenus seems to be to establish IANA registry on a first-served
basis, no RFC or expert review.

6) Call-Leg Correlation: Question is how to correlate a NOTIFY -- is it with
a "call" or a "call leg".  This is mostly an issue on whether or not
SUBSCRIPTIONS are initated within an extsing call leg. Current draft
correlates with a call leg, but this may not solve all cases. Conensus to
examine removing prohibition on mapping between notification and specific
call as to whether this affects existing implementation semantics.

7) Partial vs. Full State transmission: Most interpretations of existing
work seem to indicate that NOTIFYs will contain full states (SHOULD). State
deltas may be  important for many applications, but are problemactic in
constructing full state because of possible missed messages. Consensus to
consider body versioning techniques for state deltas.

Early Media
-------------

Many open issues, primarily with telephony interworking and QoS. Fundamental
architecture issue is that early media is "forced" not "offered", and as a
consequence we have no effective negotiation mechanism. This all seems to
derive from need to map PSTN behavior exactly, and can be resolved if
different user interface is allowed. There will be a lot more discussion on
this topic.

NAT Friendliness
------------------

Current proposal includes several techniques for symmetric and semisymmetric
NATS, including new SIP Translate header with semantics of  "I don't know
where I am, please use the address and port this came from".  Consensus to
split into at least two drafts,  including Translate header (question: do we
need a charter adjustment or new milestone declared here?) and seperate "NAT
detection protocol for RTP" to be pursued outside SIP.

SIP SRC Indication
-------------------

Propsal to include source IP address in port in SDP describing sesion, and
to expicitly differentiate RTCP port information. This would allow building
SIP ALGs and firewalls much more easily (esp. "line" as opposed to "cone"
binding devices), as much less information would have to be deduced. It also
reduces the opportunity for RTP port spamming, as attacker would have to
know source IP and port as well as SSRC. However, it poses complications for
current simple-NAT proposals. There will be further discussion of this
topic.

Extended HTTP-type-Authentication
-------------------------------------

Discussion included drafts from Rosenberg and Undery. The basic idea is
finding ways to get more mileage, such as mesage integrity protection, out
of digest autnetication techniques already specified in SIP. This has all
sorts of open isses. Furtehr discussion moved to Security ad-hoc and to
mailing list, with no clear consensus reached in the meeting.

Proxy-Supported Negotation
------------------------------

Idea is to determine whether at least one proxy in signaling path supports a
specific feature. Existing negotiation technique can detect if ALL proxies
in path support a feature. There has been ongoing list debate as to whether
this is needed. Consensus reached in meeting that no requirement for this
behavior, such as a specific application, has been identified and that work
on the approach can be deferred until such time as a requirement has been
identified.

Reliability of Provisional Messages
-----------------------------------

Alternative mechanism to 100Rel proposed. List discussions had been
inconclusive. Consensus from meeting that proposed alternative offers no
significant advantage in general case.

Session Timer
--------------

Two open isses: 1) New draft allows lower-bounding on sesssion-timer.
Current proposal is to overload session-expires, with suggestion to
establish new error code like 422-Minimum-Session-Expires. Consenus on
proposal for new error code. 2) Absolute vs. relative timers. Consensus to
deprecate absolute timers.

SIPbis Open Issues
--------------------

A bug tracking system is being used to track the large number of open issues
in the bis draft. The meeting discussed several issues and attempted to get
consensus for various propsed resolutions.

1) Issue 7: Allow CANCEL for non-INVITE methods.  Current spec has muliple
interpretations. Weak consensus to clarify indicating use of CANCEL only
with INVITE.

2) Issue 10: Use of maddr: If client sends INVITE using maddr paremeter from
route, should it strip the maddr off of the generated request URI? Consensus
is yes, as documented in rfc2453-bis-03.

3) Issue 11: Record-routing for mid-call methods other than INVITE.  This is
intertwingled with Issue 138. Conensus is to allow mid-call record
record-route on a case by case basis.

4) Issue 138: Forking of non-INVITE requests: Consensus to allow forking for
non-INVITE methods on a case-by-case basis.

5) Issue 20: Mixing unicast & multicast in offer/answer . If offer SDP
contains uni, can response contain multi? Proposal: general rule: answer
should be something offeror can do.  Hence don't send multicast in respons
to unicats. If required, re-INVITE. Conensus to acdept proposal and add
scenario to conferencing models draft.

6) Issue 23: dynamic PT reuse. SDP usage in 2543 says you can't reuse a
dynamic PT number used previously for a different codec type. This limits
number of codecs in a call to 127. It should be possible to reuse a PT once
the transaction in which it was used has been completed. Consensus that this
is not yet an issue for SIP and therefore there is no need to change.

7) Issue 146: Reuse disabled streams. SDP usage spec says once you have
disabled a stream by setting port = 0that hat stream cannot be reused. This
is important to maintain exlpicit ordering of codecs, but means the SDP size
keeps increasing in on-off hold operations. Proposal: cannot remove disabled
stream  But if new one added, can take disabled stream's slot within SDP.
No restriction on media type. This preserves ordering without increasing
size of SDP. FID discussed as possible solution, but this doesn't seem to
work completely. Further discussion is required.

8) Issue 58: Rejected mid-call SDP in 2xx: Question is what to "fall back
to".  Proposal to use general approach of using some signalling means to say
that previous session description should be rtetained.  Jonathan will
consider in revised draft.

9) Issue 133: on-hold indication: Current SDP usage for on-hold is to set
address/port number of all 0. This turns out to break RTCP, is IPv4
specific, and is generally ugly. Proposal to use a=inactive for non-sending
codecs and a=sendonly for sending codecs, and preserve backward
compatibility by accepting but not sending all-zeroes.  This may have
implications for QoS, and requires further analysis.

SIP Security Work Plan
------------------------

We are beginning to see common themes in security questons that suggest a
possible path for generalization. Proposal to seperate discussion of
"outside" vs. "inside" attacks and advance independently. This would include
basic "outside" defenses like IPSec and TLS in rfc2543bis. The HTTP-derived
authentiation mechanisms would be reqtined in bis, and all other security
considerations seperated. Individual extensions would be constrained from
proposing cryptosolutions pending general solutions.

Work Program: Develop Threats and Requirments draft. Finalize base
requirments in bis and feeze. Define framework for popular auth mechnisms
and focus on simple scheme provising UA-Proxy and Proxy-Proxy protections
aliged with SRTP and SDP work.

_______________________________________________
Sip mailing list  http://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