From sip-bounces@ietf.org Thu Nov 01 06:17:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InX49-0007qw-2k; Thu, 01 Nov 2007 06:14:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1InX47-0007pW-4m for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 06:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InX46-0007mn-OT; Thu, 01 Nov 2007 06:14:18 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InX3q-0001sn-Q3; Thu, 01 Nov 2007 06:14:08 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lA1ADvcA018261; Thu, 1 Nov 2007 05:13:57 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 05:13:56 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 11:13:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Nov 2007 11:13:53 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180018867C7@DEEXC1U01.de.lucent.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgaGKH+zp3EvtG8TLeDyez69R12VQAQbavAAD12KJAAQbDz8A== References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> From: "DRAGE, Keith \(Keith\)" To: "Francois Audet" , "Avshalom Houri" , , , X-OriginalArrivalTime: 01 Nov 2007 10:13:54.0333 (UTC) FILETIME=[E83D2CD0:01C81C6F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f44ec47f6ebd2aaf0f97ba9529b3ca5 Cc: Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1107892904==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1107892904== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81C6F.E7E3EF9F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81C6F.E7E3EF9F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the risk of committing myself - definitely in. =20 Apart from one issue that I need to respond to Francois on which is about documentation of Warning headers (i.e. adequately documenting the changes as far as RFC 3261 and IANA are concerned, and anything the PROTO shepherd (Dean) finds during his writeup, this document is finished by the WG. =20 The outbound reference is not going to prevent the submission to IESG, or the IESG approving it, merely delay the publication until outbound gets an RFC number assigned.=20 =20 regards =20 Keith ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Tuesday, October 30, 2007 11:56 PM To: DRAGE, Keith (Keith); Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 What about SIPS, which is already in hitchiker's guide, and which is waiting on outbound because of a normative reference? ________________________________ From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Tuesday, October 30, 2007 01:01 To: Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 (As WG chair) =20 Just a note that I should have included with the WGLC. =20 The intention with this document is to republish on a recurring basis, and therefore to keep it up to date (say once a year or so). =20 The 1st versions is intended to include gruu, outbound and ice, but apart from that, anything that is not published in that timeframe will probably be removed unless there is exceptional justification for keeping it, with the idea that it will appear in the next version. =20 regards =20 Keith ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Monday, October 29, 2007 10:40 AM To: rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03=20 from the perspective of presence and the SIMPLE group but ended up in=20 commenting on the whole document at the end.=20 =09 For background on RAI-ART, please see the FAQ at =09 http://www.softarmor.com/rai/art/rai-art-FAQ.html =20 =09 Please resolve these comments along with any other Last Call comments=20 you may receive.=20 =09 In my opinion this draft is basically ready for publication, but has=20 nits that should be fixed before publication.=20 =09 Citations from the draft are marked by <<< text from draft >>>=20 =09 General comments=20 ----------------=20 =09 By its nature there are a lot of reference to drafts in the document.=20 It will take a lot of time for these documents to become and RFC.=20 So how we are going to publish this as an RFC? Since when the=20 referenced drafts will become an RFC, this draft would have to be=20 updated with new drafts, will it be held in the=20 RFC ED queue for ever?=20 =09 How do we gauge the usage of an RFC or a draft? There are many places=20 here that it is said that this or that RFC/draft got widely implemented=20 or not.=20 How it is measured? The wide implementation test is used to decide=20 whether an RFC or draft are core or not and therefore there should be=20 some text explaining how the wide implementation was determined.=20 =09 Better change RFC XXXX (before the reference number in []) to the name=20 of the draft (with no version number), it will make the ride smoother.=20 =09 An introduction that details the various grouping should be added. It=20 should include additional text on the group and what was the criteria=20 for putting an RFC/draft in the group.=20 =09 2. Scope of this Document=20 --------------------------=20 =09 <<<=20 o Any specification that defines an extension to SIP itself, where=20 an extension is a mechanism that changes or updates in some way a=20 behavior specified in RFC 3261=20 >>>=20 =09 "to SIP itself" sounds vague. It will be better to say:"to RFC 3261"=20 instead.=20 Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus=20 (or the president of the galaxy) and that RFCs/drafts mentioned in this=20 document are based on their relation to it.=20 =09 <<<=20 Excluded from this list are requirements, architectures, registry=20 definitions, non-normative frameworks, and processes. Best Current=20 Practices are included when they normatively define mechanisms for=20 accomplishing a task.=20 >>>=20 =20 "normatively define" not sure what is meant by normative with=20 respect to BCP. Seems like a contradiction in terms.=20 =09 3. Core SIP Specifications=20 ---------------------------=20 =09 If we think on presence as eventually replacing registration, since it=20 carries much more information about the availability of the user,=20 should we consider also presence as a towel?=20 =09 <<<=20 RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the=20 core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9].=20 It is the president of the galaxy [42] as far as the suite of SIP=20 specifications is concerned.=20 >>>=20 =09 RFC 3261 is a very big document. Should it be treated as one or it can=20 be divided into parts in this document e.g. proxy, client etc.? I am not=20 sure what would be better.=20 =09 4. Public Switched Telephone Network (PSTN) Interworking=20 =09 ---------------------------------------------------------=20 =09 Regarding RFC 3578=20 Ugly in one corner of the galaxy may be beautiful on the other of it :-)=20 =09 7. Minor Extensions=20 --------------------=20 =09 <<<=20 RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44]=20 allows a UA sending a REFER to ask the recipient of the REFER to=20 generate multiple SIP requests, not just one. This is useful for=20 conferencing, where a client would like to ask a conference server=20 to eject multiple users.=20 >>>=20 =09 Should not this be referred to in the conferencing section also?=20 =09 <<<=20 RFC 4483, A Mechanism for Content Indirection in Session Initiation=20 Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for=20 content indirection. Instead of carrying an object within a SIP=20 body, a URL reference is carried instead, and the recipient=20 dereferences the URL to obtain the object. The specification has=20 potential applicability for sending large instant messages, but=20 has yet to find much actual use.=20 >>>=20 =09 The specification has also potential for sending large presence=20 documents via a URL.=20 =09 <<<=20 RFC 4583, Session Description Protocol (SDP) Format for Binary Floor=20 Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a=20 mechanism in SDP to signal floor control streams that use BFCP.=20 It is used for Push-To-Talk and conference floor control.=20 >>>=20 =09 Should not this be referred to in the conferencing section also?=20 =09 <<<=20 RFC XXXX, Connectivity Preconditions for Session Description Protocol=20 Media Streams (S): RFC XXXX [93] defines a usage of the precondition=20 framework [59]. The connectivity precondition makes sure that the=20 session doesn't get established until actual packet connectivity=20 is checked.=20 >>>=20 =09 Should not this be referred to in the QoS section also?=20 =09 8. Conferencing=20 ----------------=20 =09 The Conferencing section should be before or after "Instant Messaging,=20 Presence and Multimedia" as it is also an application. See the comment=20 on whether presence is an application or not later.=20 =09 10. Event Framework and Packages=20 ----------------------------------=20 =09 Suggest to divide this section to event framework section and to=20 packages section. The event framework should include 3265, 3903, 4662=20 and subnot-etags which define the event framework itself.=20 The other section will the packages sections that will list the=20 packages.=20 =09 Alternatively, many of the packages are mentioned in their proper=20 section so it may be that all the event packages can be fit into=20 their relevant section and there is not a need for packages section.=20 =09 11. Quality of Service=20 -----------------------=20 =09 <<<=20 RFC 3313, Private SIP Extensions for Media Authorization (I): RFC=20 3313 [61] defines a P-header that provides a mechanism for passing=20 an authorization token between SIP and a network QoS reservation=20 protocol like RSVP. Its purpose is to make sure network QoS is=20 only granted if a client has made a SIP call through the same=20 providers network. This specification is sometimes referred to as=20 the SIP walled garden specification by the truly paranoid androids=20 in the SIP community. This is because it requires coupling of=20 signaling and the underlying IP network.=20 >>> =20 =09 Understand that being a "truly paranoid" is a virtue? :-)=20 =09 15. Security Mechanisms=20 ------------------------=20 =09 Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474=20 (Identity) be mentioned here also? =20 =09 16. Instant Messaging, Presence and Multimedia=20 -----------------------------------------------=20 =09 Maybe create an applications section and put also conferencing as a type=20 of an application.=20 =09 Including presence here with IM and multimedia seems that presence is=20 regarded as an additional type of media. I am not sure that I agree with=20 this. Presence is an enabler for many other applications and it deserves=20 a section of its own.=20 =09 It is very tempting to include the simple-simple content here=20 (as an appendix?). If simple-simple is not to be included here, there=20 should be at least a reference to simple-simple as for presence=20 there are so many documents that are essential for doing presence and=20 are not mentioned here (e.g. watcher format, RPID, presence rules,=20 partial notify and publish and many many more). Roughly counting, there=20 are about 20-25 RFCs/drafts that are very relevant to presence that are=20 mentioned in simple-simple in addition to the ones that are mentioned here.=20 =09 The MSRP drafts seem to be forgotten?=20 =09 Thanks=20 --Avshalom =09 ------_=_NextPart_001_01C81C6F.E7E3EF9F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
At the risk of committing myself - definitely=20 in.
 
Apart from one issue that I need to respond to = Francois on=20 which is about documentation of Warning headers (i.e. adequately = documenting the=20 changes as far as RFC 3261 and IANA are concerned, and anything the = PROTO=20 shepherd (Dean) finds during his writeup, this document is finished by = the=20 WG.
 
The outbound reference is not going to prevent = the=20 submission to IESG, or the IESG approving it, merely delay the = publication until=20 outbound gets an RFC number assigned.
 
regards
 
Keith

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Tuesday, October 30, 2007 11:56 PM
To: = DRAGE, Keith=20 (Keith); Avshalom Houri; rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: RE: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03

What=20 about SIPS, which is already in hitchiker's guide, and which is = waiting on=20 outbound because of a normative reference?

From: DRAGE, Keith (Keith)=20 [mailto:drage@alcatel-lucent.com]
Sent: Tuesday, October = 30, 2007=20 01:01
To: Avshalom Houri; rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: RE: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03

(As WG chair)
 
Just a note that I should have included = with the=20 WGLC.
 
The intention with this document is to = republish on a=20 recurring basis, and therefore to keep it up to date (say once a = year or=20 so).
 
The 1st versions is intended to include = gruu, outbound=20 and ice, but apart from that, anything that is not published in that = timeframe will probably be removed unless there is exceptional = justification=20 for keeping it, with the idea that it will appear in the next=20 version.
 
regards
 
Keith

From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: Monday, October 29, = 2007=20 10:40 AM
To: rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03


I have been = assigned to=20 review of draft-ietf-sip-hitchhikers-guide-03
from the perspective of presence and = the SIMPLE=20 group but ended up in
commenting on the whole document at the end. =

For background on RAI-ART, please = see the FAQ=20 at
http://www.softarmor.com/rai/art/rai-art-FAQ.html<= /A>=20

Please resolve these = comments=20 along with any other Last Call comments
you may receive. =

In my opinion this draft is = basically ready for=20 publication, but has
nits that=20 should be fixed before publication.

Citations from the draft are marked = by=20 <<< text from draft >>>

General comments
---------------- =

By its nature there are a lot of = reference to=20 drafts in the document.
It will=20 take a lot of time for these documents to become and RFC. =
So how we are going to publish this = as an RFC?=20 Since when the
referenced=20 drafts will become an RFC, this draft would have to be =
updated with new drafts, will it be = held in=20 the
RFC ED queue = for=20 ever?

How do we = gauge the=20 usage of an RFC or a draft? There are many places
here that it is said that this or = that RFC/draft=20 got widely implemented
or=20 not.
How it is = measured? The=20 wide implementation test is used to decide
whether an RFC or draft are core or = not and=20 therefore there should be
some=20 text explaining how the wide implementation was determined. =

Better change RFC XXXX = (before the=20 reference number in []) to the name
of the draft (with no version number), it will make the = ride=20 smoother.

An = introduction=20 that details the various grouping should be added. It =
should include additional text on = the group and=20 what was the criteria
for=20 putting an RFC/draft in the group.

2.  Scope of this Document
--------------------------

<<<
 =20  o  Any specification that defines an extension to SIP = itself,=20 where
    =   an=20 extension is a mechanism that changes or updates in some way = a=20
      = behavior=20 specified in RFC 3261
>>>

"to SIP=20 itself" sounds vague. It will be better to say:"to RFC = 3261"=20
instead.
Maybe there should be an earlier = definition of=20 RFC 3261 as the SIP nucleus
(or=20 the president of the galaxy) and that RFCs/drafts mentioned in = this=20
document are based on = their relation=20 to it.

<<<=20
   Excluded from = this list=20 are requirements, architectures, registry
   definitions, = non-normative=20 frameworks, and processes.  Best Current
   Practices are included = when they=20 normatively define mechanisms for
   accomplishing a task.
>>>
   
"normatively define" not sure what is meant by normative=20 with
respect to = BCP. Seems like=20 a contradiction in terms.

3.  Core SIP Specifications
--------------------------- =

If we think on presence as = eventually replacing=20 registration, since it
carries=20 much more information about the availability of the user, =
should we consider also presence as = a=20 towel?

<<<=20
   RFC 3261, The = Session=20 Initiation Protocol (S):  RFC 3261 [1] is the =
      core SIP = protocol itself.=20  RFC 3261 is an update to RFC 2543 [9].
      It is the = president of the=20 galaxy [42] as far as the suite of SIP
      specifications is concerned. =
>>>

RFC 3261 is a very big document. = Should it be=20 treated as one or it can
be=20 divided into parts in this document e.g. proxy, client etc.? I am=20 not
sure what would = be=20 better.

4. =  Public=20 Switched Telephone Network (PSTN) Interworking
---------------------------------------------------------= =20

Regarding RFC = 3578=20
Ugly in one corner of the = galaxy may=20 be beautiful on the other of it :-)

7.  Minor Extensions =
-------------------- =

<<<
   RFC XXXX, Referring to Multiple Resources in = SIP (S):=20  RFC XXXX [44]
 =20     allows a UA sending a REFER to ask the recipient of = the=20 REFER to
  =    =20 generate multiple SIP requests, not just one.  This is useful = for
    =  =20 conferencing, where a client would like to ask a conference = server=20
      to = eject multiple=20 users.
>>>=20

Should not this be = referred to in=20 the conferencing section also?

<<<
 =20  RFC 4483, A Mechanism for Content Indirection in Session=20 Initiation
 =20  Protocol (SIP) Messages (S):  RFC 4483 [89] defines a = mechanism=20 for
    =  =20 content indirection.  Instead of carrying an object within a=20 SIP
    =   body,=20 a URL reference is carried instead, and the recipient =
      dereferences = the URL to=20 obtain the object.  The specification has
      potential = applicability for=20 sending large instant messages, but
      has yet to find much actual = use.=20
>>> =

The specification has also potential = for sending=20 large presence
documents via a=20 URL.

<<<=20
   RFC 4583, = Session=20 Description Protocol (SDP) Format for Binary Floor =
   Control Protocol (BFCP) = Streams=20 (S):  RFC 4583 [91] defines a
      mechanism in SDP to signal floor = control=20 streams that use BFCP.
 =20     It is used for Push-To-Talk and conference floor=20 control.
>>>=20

Should not this be = referred to in=20 the conferencing section also?

<<<
 =20  RFC XXXX, Connectivity Preconditions for Session Description = Protocol
  =  Media=20 Streams (S):  RFC XXXX [93] defines a usage of the=20 precondition
  =  =20   framework [59].  The connectivity precondition makes = sure that=20 the
    =  =20 session doesn't get established until actual packet = connectivity=20
      is=20 checked.
>>>=20

Should not this be = referred to in=20 the QoS section also?

8.=20  Conferencing
----------------

The=20 Conferencing section should be before or after "Instant = Messaging,=20
Presence and Multimedia" = as it is also=20 an application. See the comment
on whether presence is an application or not = later.=20

10.  Event = Framework and=20 Packages
----------------------------------

Suggest to divide this section to = event=20 framework section and to
packages section. The event framework should include = 3265, 3903,=20 4662
and = subnot-etags which=20 define the event framework itself.
The other section will the packages sections that will = list=20 the
packages.=20

Alternatively, many of = the=20 packages are mentioned in their proper
section so it may be that all the event packages can be = fit=20 into
their relevant = section and=20 there is not a need for packages section.

11.  Quality of Service =
----------------------- =

<<<
   RFC 3313, Private SIP Extensions for Media=20 Authorization (I):  RFC
      3313 [61] defines a P-header that = provides a=20 mechanism for passing
 =20     an authorization token between SIP and a network QoS = reservation
  =  =20   protocol like RSVP.  Its purpose is to make sure = network QoS=20 is
    =   only=20 granted if a client has made a SIP call through the same =
      providers = network.=20  This specification is sometimes referred to as =
      the SIP walled = garden=20 specification by the truly paranoid androids
      in the SIP = community.=20  This is because it requires coupling of
      signaling and = the=20 underlying IP network.
>>>      

Understand that being a "truly = paranoid" is a=20 virtue? :-)

15. =  Security Mechanisms
------------------------

Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and = RFC=20 4474
(Identity) be = mentioned=20 here also?    

16.  Instant Messaging, Presence and = Multimedia=20
-----------------------------------------------=20

Maybe create an = applications=20 section and put also conferencing as a type
of an application. =

Including presence here with IM and = multimedia=20 seems that presence is
regarded=20 as an additional type of media. I am not sure that I agree = with=20
this. Presence is an = enabler for many=20 other applications and it deserves
a section of its own.

It is very tempting to include the simple-simple content=20 here
(as an = appendix?). If=20 simple-simple is not to be included here, there
should be at least a reference to = simple-simple=20 as for presence
there are so=20 many documents that are essential for doing presence and =
are not mentioned here (e.g. watcher = format,=20 RPID, presence rules,
partial=20 notify and publish and many many more). Roughly counting, = there=20
are about 20-25 = RFCs/drafts that are=20 very relevant to presence that are
mentioned in simple-simple in addition to the ones that = are=20 mentioned here.

The MSRP=20 drafts seem to be forgotten?

Thanks
--Avshalom
------_=_NextPart_001_01C81C6F.E7E3EF9F-- --===============1107892904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1107892904==-- From sip-bounces@ietf.org Thu Nov 01 07:17:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXyf-0002Tk-NX; Thu, 01 Nov 2007 07:12:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1InXyd-0002Td-LS for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 07:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXyd-0002TR-5j for sip@ietf.org; Thu, 01 Nov 2007 07:12:43 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InXyX-0004PY-0G for sip@ietf.org; Thu, 01 Nov 2007 07:12:43 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQT00A3PQWH6B@siemenscomms.co.uk> for sip@ietf.org; Thu, 01 Nov 2007 11:07:30 +0000 (GMT) Date: Thu, 01 Nov 2007 11:07:52 +0000 From: "Elwell, John" Subject: RE: [Sip] INFO: A recap,sense of consensus and a proposal for direction. In-reply-to: To: Hadriel Kaplan , Paul Kyzivat , Adam Roach Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO: A recap,sense of consensus and a proposal for direction. Thread-Index: AcgbIJVUInoHC1EDRMKSwOUf4UpyOQATTxRAAEI9V3A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <472756C2.1010205@nostrum.com> <47277440.3050707@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadrial, You wrote: > The sticky part in my mind has always been what to do if both > info-dtmf were negotiated and 2833/4733 was offered/answered. > Or even what to do with in-audio tones. I *think* the > answer is info-dtmf should trump 2833 - i.e., if you > negotiated info-dtmf only do that, for a variety of reasons; > but with delayed SDP offers that would mean you'd always end > up using info-dtmf when you could have done 2833 instead. > And I can see the argument for "do both", and that's what > kpml did except it has the suppression/
 concept, but I 
> assumed that was due to pattern matching being inconsistent 
> with in-band event sending one-at-a-time.  But I still think 
> info-dtmf trumping would be right, because the tones will get 
> to the far end if they should.
[JRE] Performance is a consideration with DTMF, because the speed with
which the user receives a response from the server can have impact on
the user experience. RFC 2833 is always likely to get through quicker.

John


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 10:41:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inb9e-000685-Pm; Thu, 01 Nov 2007 10:36:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Inb9d-00067V-5O
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 10:36:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inb9c-00066F-J8; Thu, 01 Nov 2007 10:36:16 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Inb9W-0003nR-Cg; Thu, 01 Nov 2007 10:36:16 -0400
X-IronPort-AV: E=Sophos;i="4.21,358,1188802800"; d="scan'208";a="29234125"
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-1.cisco.com with ESMTP; 01 Nov 2007 07:36:04 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lA1Ea2Qx002058; 
	Thu, 1 Nov 2007 07:36:02 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA1Ea2ZU013825;
	Thu, 1 Nov 2007 14:36:02 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 1 Nov 2007 07:35:40 -0700
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 1 Nov 2007 07:35:40 -0700
Message-ID: <4729E458.6030703@cisco.com>
Date: Thu, 01 Nov 2007 10:36:08 -0400
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Francois Audet 
References: 
	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>
	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Nov 2007 14:35:40.0251 (UTC)
	FILETIME=[79B212B0:01C81C94]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2436; t=1193927762;
	x=1194791762; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[RAI]=20RAI=20review=20of=20draft-ietf-sip-hitchhiker
	s-guide-03 |Sender:=20;
	bh=xIm0hf0iugRdtr70SuT9jDa0YUHxN1uiuVEaCPTuF78=;
	b=dEcgZ+IaO/+QNOpxEBY+EN/EGE8AvFvz/wKbCRfaHgdtBqjPLZ0j8Ql7WdiCBV4VxGCV8Duh
	/BUXvYrFHU+npw58J7m8VDXsmOlGgIAd+2+ZNEnqPKUQSvJ2GHTTflH6;
Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: sip@ietf.org, Avshalom Houri , "DRAGE,
	Keith \(Keith\)" , rai@ietf.org
Subject: [Sip] Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

inline:

Francois Audet wrote:
> What about SIPS, which is already in hitchiker's guide, and which is 
> waiting on outbound because of a normative reference?
> 
>     ------------------------------------------------------------------------
>     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
>     *Sent:* Tuesday, October 30, 2007 01:01
>     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com
>     *Subject:* RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
> 
>     (As WG chair)
>      
>     Just a note that I should have included with the WGLC.
>      
>     The intention with this document is to republish on a recurring
>     basis, and therefore to keep it up to date (say once a year or so).
>      
>     The 1st versions is intended to include gruu, outbound and ice, but
>     apart from that, anything that is not published in that timeframe
>     will probably be removed unless there is exceptional justification
>     for keeping it, with the idea that it will appear in the next version.

This is news to me...

What I thought would happen is that we have references to everything in 
the guide, and when the guide appears as an RFC, whatever references are 
at RFC status at that time, get RFC numbers. Everything else is 
referenced as an I-D.

I think you are suggesting that, instead, when we send this to IESG, we 
remove any content and references associated with documents which are 
not on track to publication around the same timeframe as hitchhikers 
guide itself. Indeed it will require us to change those references to 
normative in order to get rfc-editor to do a REF hold on hitchhikers 
till its dependencies clear.

If my interpretation is correct, my next question is whether this 
applies to just the core specs or all of the specs.

I personally would rather leave the document as is - include everything, 
and recognize that some references will be drafts rather than RFCs when 
hitchhikers is published. Next round of hitchhikers will have more of 
them as RFCs.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 10:59:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InbUe-0005KN-QV; Thu, 01 Nov 2007 10:58:00 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InbUd-0005HP-27
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 10:57:59 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InbUc-0005HH-NN; Thu, 01 Nov 2007 10:57:58 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1InbUc-000378-4z; Thu, 01 Nov 2007 10:57:58 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lA1Evkk18529; Thu, 1 Nov 2007 14:57:46 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 1 Nov 2007 09:57:40 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4729E458.6030703@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
Thread-Index: AcgclWSXcUNjORGwTPG/Q8fZUb7hqQAATCig
References: 
	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>
	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
	<4729E458.6030703@cisco.com>
From: "Brian Stucker" 
To: "Jonathan Rosenberg" ,
	"Francois Audet" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: sip@ietf.org, rai@ietf.org, Avshalom Houri 
Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I would also prefer that I-D references be left in the document. It's
very helpful to the community to not only know where SIP is at when you
read the guide, but to know where it's headed. If for no other reason
than it prevents someone from thinking they've discovered a novel
problem and go off implementing a solution parallel to what will soon
(hopefully) be an RFC. Likewise, if they find that the I-D is
incomplete, it gives them a reference to make comments against that they
may not have otherwise discovered.

It's an informative document. What if we just copy paragraphs two and
three of from the boilerplate "status of this memo" into the
introduction as a warning to those who read the document later as an RFC
that I-D's referenced by the guide can change.=20

Is there any harm in doing this?

Regards,
Brian=20

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
> Sent: Thursday, November 01, 2007 9:36 AM
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>=20
> inline:
>=20
> Francois Audet wrote:
> > What about SIPS, which is already in hitchiker's guide, and=20
> which is=20
> > waiting on outbound because of a normative reference?
> >=20
> >    =20
> --------------------------------------------------------------
> ----------
> >     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> >     *Sent:* Tuesday, October 30, 2007 01:01
> >     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;=20
> jdrosen@cisco.com
> >     *Subject:* RE: [RAI] RAI review of=20
> > draft-ietf-sip-hitchhikers-guide-03
> >=20
> >     (As WG chair)
> >     =20
> >     Just a note that I should have included with the WGLC.
> >     =20
> >     The intention with this document is to republish on a recurring
> >     basis, and therefore to keep it up to date (say once a=20
> year or so).
> >     =20
> >     The 1st versions is intended to include gruu, outbound=20
> and ice, but
> >     apart from that, anything that is not published in that=20
> timeframe
> >     will probably be removed unless there is exceptional=20
> justification
> >     for keeping it, with the idea that it will appear in=20
> the next version.
>=20
> This is news to me...
>=20
> What I thought would happen is that we have references to=20
> everything in the guide, and when the guide appears as an=20
> RFC, whatever references are at RFC status at that time, get=20
> RFC numbers. Everything else is referenced as an I-D.
>=20
> I think you are suggesting that, instead, when we send this=20
> to IESG, we remove any content and references associated with=20
> documents which are not on track to publication around the=20
> same timeframe as hitchhikers guide itself. Indeed it will=20
> require us to change those references to normative in order=20
> to get rfc-editor to do a REF hold on hitchhikers till its=20
> dependencies clear.
>=20
> If my interpretation is correct, my next question is whether=20
> this applies to just the core specs or all of the specs.
>=20
> I personally would rather leave the document as is - include=20
> everything, and recognize that some references will be drafts=20
> rather than RFCs when hitchhikers is published. Next round of=20
> hitchhikers will have more of them as RFCs.
>=20
> -Jonathan R.
>=20
> --=20
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ=20
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>=20
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www1.ietf.org/mailman/listinfo/rai
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 11:12:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inbgv-0005J4-LJ; Thu, 01 Nov 2007 11:10:41 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Inbgu-0005Hl-3G
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 11:10:40 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inbgt-0005Hb-OW; Thu, 01 Nov 2007 11:10:39 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Inbgt-0003Tl-7m; Thu, 01 Nov 2007 11:10:39 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0JQU00LRQ25Q20@usaga01-in.huawei.com>; Thu,
	01 Nov 2007 08:10:38 -0700 (PDT)
Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006))
	with ESMTPA id <0JQU00MZB25OV3@usaga01-in.huawei.com>; Thu,
	01 Nov 2007 08:10:38 -0700 (PDT)
Date: Thu, 01 Nov 2007 10:09:58 -0500
From: Spencer Dawkins 
Subject: Re: [Sip] Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
To: rai@ietf.org, sip@ietf.org
Message-id: <0b5a01c81c99$447b1470$6401a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1;
	reply-type=response
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: 
	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>
	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
	<4729E458.6030703@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I was going to respond offlist, but Brian's already onlist with followups, 
so...

I would like to support Jonathan's understanding here.

I thought the Hitchhiker's Guide was very useful when it appeared, and have 
reviewed multiple versions of the draft since then. I would like for it to 
be "out there", and I would like for each revision to be as helpful as we 
can make it.

(1) delaying publication due to REF-HOLD for completed-and-approved 
specifications to pass through RFC Editor processing doesn't seem helpful, 
while

(2) removing references to completed-and-approved specifications that don't 
have RFC numbers assigned seems even LESS helpful.

I see no problem with references to completed-and-approved IDs in an 
Informational RFC that we expect to update anyway. My understanding is that 
these IDs really ARE stable references - they no longer expire, and are 
replaced with "was published as RFC XXXX" boilerplate when an RFC IS 
available.

One recent redirection looks like this (appears as 
http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-04.txt)

"This Internet-Draft, draft-ietf-mip6-dsmip-problem-03.txt, was published as 
an Informational RFC, RFC 4977 (http://www.ietf.org/rfc/rfc4977.txt), on 
2007-8-29."

As long as we publish specifications the way we publish them, there's going 
to be a delay, measured in months, for significant specifications in RFC 
Editor processing/Auth48/etc. REF-HOLD for the Hitchhiker's Guide makes no 
sense.

Thanks,

Spencer

From: "Jonathan Rosenberg" 

> inline:
>
> Francois Audet wrote:
>> What about SIPS, which is already in hitchiker's guide, and which is 
>> waiting on outbound because of a normative reference?
>>
>>     ------------------------------------------------------------------------
>>     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
>>     *Sent:* Tuesday, October 30, 2007 01:01
>>     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com
>>     *Subject:* RE: [RAI] RAI review of 
>> draft-ietf-sip-hitchhikers-guide-03
>>
>>     (As WG chair)
>>      Just a note that I should have included with the WGLC.
>>      The intention with this document is to republish on a recurring
>>     basis, and therefore to keep it up to date (say once a year or so).
>>      The 1st versions is intended to include gruu, outbound and ice, but
>>     apart from that, anything that is not published in that timeframe
>>     will probably be removed unless there is exceptional justification
>>     for keeping it, with the idea that it will appear in the next 
>> version.
>
> This is news to me...
>
> What I thought would happen is that we have references to everything in 
> the guide, and when the guide appears as an RFC, whatever references are 
> at RFC status at that time, get RFC numbers. Everything else is referenced 
> as an I-D.
>
> I think you are suggesting that, instead, when we send this to IESG, we 
> remove any content and references associated with documents which are not 
> on track to publication around the same timeframe as hitchhikers guide 
> itself. Indeed it will require us to change those references to normative 
> in order to get rfc-editor to do a REF hold on hitchhikers till its 
> dependencies clear.
>
> If my interpretation is correct, my next question is whether this applies 
> to just the core specs or all of the specs.
>
> I personally would rather leave the document as is - include everything, 
> and recognize that some references will be drafts rather than RFCs when 
> hitchhikers is published. Next round of hitchhikers will have more of them 
> as RFCs. 




_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 11:13:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inbij-0007Pv-8e; Thu, 01 Nov 2007 11:12:33 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Inbih-0007NZ-NA
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 11:12:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inbih-0007NN-By; Thu, 01 Nov 2007 11:12:31 -0400
Received: from mtagate1.de.ibm.com ([195.212.29.150])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1InbiZ-00050P-W5; Thu, 01 Nov 2007 11:12:31 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id lA1FCNrC105466;
	Thu, 1 Nov 2007 15:12:23 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with
	ESMTP id lA1FCNsS2166952; Thu, 1 Nov 2007 16:12:23 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP
	id lA1FCM33005124; Thu, 1 Nov 2007 16:12:23 +0100
Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com
	[9.149.167.114])
	by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP
	id lA1FCMbS005121; Thu, 1 Nov 2007 16:12:22 +0100
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
References: 
	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>
	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
	<4729E458.6030703@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
To: "Brian Stucker" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.0NP August 02, 2007
From: Avshalom Houri 
Message-ID: 
Date: Thu, 1 Nov 2007 17:12:19 +0200
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 |
	November 3, 2006) at 01/11/2007 17:12:22,
	Serialize complete at 01/11/2007 17:12:22
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8
Cc: sip@ietf.org, Francois Audet , rai@ietf.org
Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0487295357=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0487295357==
Content-Type: multipart/alternative;
	boundary="=_alternative 005387EDC2257386_="

This is a multipart message in MIME format.
--=_alternative 005387EDC2257386_=
Content-Type: text/plain; charset="US-ASCII"

I also think that leaving the references to the drafts is important.
I do not know what should be the actual mechanism but it will be like
hitchhiking a space ship that has many of its windows covered,
it will be hard to see where we are flying to.

--Avshalom








"Brian Stucker"  
01/11/2007 16:57

To
"Jonathan Rosenberg" , "Francois Audet" 

cc
, Avshalom Houri/Haifa/IBM@IBMIL, 
Subject
RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03






I would also prefer that I-D references be left in the document. It's
very helpful to the community to not only know where SIP is at when you
read the guide, but to know where it's headed. If for no other reason
than it prevents someone from thinking they've discovered a novel
problem and go off implementing a solution parallel to what will soon
(hopefully) be an RFC. Likewise, if they find that the I-D is
incomplete, it gives them a reference to make comments against that they
may not have otherwise discovered.

It's an informative document. What if we just copy paragraphs two and
three of from the boilerplate "status of this memo" into the
introduction as a warning to those who read the document later as an RFC
that I-D's referenced by the guide can change. 

Is there any harm in doing this?

Regards,
Brian 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] 
> Sent: Thursday, November 01, 2007 9:36 AM
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
> 
> inline:
> 
> Francois Audet wrote:
> > What about SIPS, which is already in hitchiker's guide, and 
> which is 
> > waiting on outbound because of a normative reference?
> > 
> > 
> --------------------------------------------------------------
> ----------
> >     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> >     *Sent:* Tuesday, October 30, 2007 01:01
> >     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; 
> jdrosen@cisco.com
> >     *Subject:* RE: [RAI] RAI review of 
> > draft-ietf-sip-hitchhikers-guide-03
> > 
> >     (As WG chair)
> > 
> >     Just a note that I should have included with the WGLC.
> > 
> >     The intention with this document is to republish on a recurring
> >     basis, and therefore to keep it up to date (say once a 
> year or so).
> > 
> >     The 1st versions is intended to include gruu, outbound 
> and ice, but
> >     apart from that, anything that is not published in that 
> timeframe
> >     will probably be removed unless there is exceptional 
> justification
> >     for keeping it, with the idea that it will appear in 
> the next version.
> 
> This is news to me...
> 
> What I thought would happen is that we have references to 
> everything in the guide, and when the guide appears as an 
> RFC, whatever references are at RFC status at that time, get 
> RFC numbers. Everything else is referenced as an I-D.
> 
> I think you are suggesting that, instead, when we send this 
> to IESG, we remove any content and references associated with 
> documents which are not on track to publication around the 
> same timeframe as hitchhikers guide itself. Indeed it will 
> require us to change those references to normative in order 
> to get rfc-editor to do a REF hold on hitchhikers till its 
> dependencies clear.
> 
> If my interpretation is correct, my next question is whether 
> this applies to just the core specs or all of the specs.
> 
> I personally would rather leave the document as is - include 
> everything, and recognize that some references will be drafts 
> rather than RFCs when hitchhikers is published. Next round of 
> hitchhikers will have more of them as RFCs.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www1.ietf.org/mailman/listinfo/rai
> 


--=_alternative 005387EDC2257386_=
Content-Type: text/html; charset="US-ASCII"



I also think that leaving the references
to the drafts is important.

I do not know what should be the actual
mechanism but it will be like

hitchhiking a space ship that has many
of its windows covered,

it will be hard to see where we are
flying to.



--Avshalom




















"Brian Stucker"
<bstucker@nortel.com> 

01/11/2007 16:57








To

"Jonathan Rosenberg" <jdrosen@cisco.com>,
"Francois Audet" <audet@nortel.com>




cc

<sip@ietf.org>, Avshalom Houri/Haifa/IBM@IBMIL,
<rai@ietf.org>




Subject

RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03

















I would also prefer that I-D references be left in
the document. It's

very helpful to the community to not only know where SIP is at when you

read the guide, but to know where it's headed. If for no other reason

than it prevents someone from thinking they've discovered a novel

problem and go off implementing a solution parallel to what will soon

(hopefully) be an RFC. Likewise, if they find that the I-D is

incomplete, it gives them a reference to make comments against that they

may not have otherwise discovered.



It's an informative document. What if we just copy paragraphs two and

three of from the boilerplate "status of this memo" into the

introduction as a warning to those who read the document later as an RFC

that I-D's referenced by the guide can change. 



Is there any harm in doing this?



Regards,

Brian 



> -----Original Message-----

> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]


> Sent: Thursday, November 01, 2007 9:36 AM

> To: Audet, Francois (SC100:3055)

> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org

> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03

> 

> inline:

> 

> Francois Audet wrote:

> > What about SIPS, which is already in hitchiker's guide, and 

> which is 

> > waiting on outbound because of a normative reference?

> > 

> >     

> --------------------------------------------------------------

> ----------

> >     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]

> >     *Sent:* Tuesday, October 30, 2007 01:01

> >     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;


> jdrosen@cisco.com

> >     *Subject:* RE: [RAI] RAI review of 

> > draft-ietf-sip-hitchhikers-guide-03

> > 

> >     (As WG chair)

> >      

> >     Just a note that I should have included with the
WGLC.

> >      

> >     The intention with this document is to republish
on a recurring

> >     basis, and therefore to keep it up to date (say
once a 

> year or so).

> >      

> >     The 1st versions is intended to include gruu, outbound


> and ice, but

> >     apart from that, anything that is not published
in that 

> timeframe

> >     will probably be removed unless there is exceptional


> justification

> >     for keeping it, with the idea that it will appear
in 

> the next version.

> 

> This is news to me...

> 

> What I thought would happen is that we have references to 

> everything in the guide, and when the guide appears as an 

> RFC, whatever references are at RFC status at that time, get 

> RFC numbers. Everything else is referenced as an I-D.

> 

> I think you are suggesting that, instead, when we send this 

> to IESG, we remove any content and references associated with 

> documents which are not on track to publication around the 

> same timeframe as hitchhikers guide itself. Indeed it will 

> require us to change those references to normative in order 

> to get rfc-editor to do a REF hold on hitchhikers till its 

> dependencies clear.

> 

> If my interpretation is correct, my next question is whether 

> this applies to just the core specs or all of the specs.

> 

> I personally would rather leave the document as is - include 

> everything, and recognize that some references will be drafts 

> rather than RFCs when hitchhikers is published. Next round of 

> hitchhikers will have more of them as RFCs.

> 

> -Jonathan R.

> 

> -- 

> Jonathan D. Rosenberg, Ph.D.            
      600 Lanidex Plaza

> Cisco Fellow                
                  Parsippany,
NJ 

> 07054-2711

> Cisco Systems

> jdrosen@cisco.com              
               FAX:   (973)
952-5050

> http://www.jdrosen.net
                     
  PHONE: (973) 952-5000

> http://www.cisco.com

> 

> _______________________________________________

> RAI mailing list

> RAI@ietf.org

> https://www1.ietf.org/mailman/listinfo/rai

> 




--=_alternative 005387EDC2257386_=--



--===============0487295357==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0487295357==--





From sip-bounces@ietf.org Thu Nov 01 12:30:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Incrg-0005cm-4H; Thu, 01 Nov 2007 12:25:52 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Incrf-0005cD-7p
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 12:25:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Incre-0005c5-UH; Thu, 01 Nov 2007 12:25:50 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IncrX-00080a-Rf; Thu, 01 Nov 2007 12:25:50 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lA1GPJk13657; Thu, 1 Nov 2007 16:25:19 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 1 Nov 2007 11:25:10 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
Thread-Index: AcgclWSXcUNjORGwTPG/Q8fZUb7hqQAATCigAAM/CvA=
References: 
	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>
	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
	<4729E458.6030703@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
From: "Francois Audet" 
To: "Brian Stucker" ,
	"Jonathan Rosenberg" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: sip@ietf.org, rai@ietf.org, Avshalom Houri 
Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Same here. I prefer the whole list.

I checked again the list in the current document, and I didn't see
anything that was "controversial" (i.e., all the drafts quoted are
mature working group items).

If some of them were considered immature, we should remove them. But
otherwise, I'd rather we keep them in.=20

> -----Original Message-----
> From: Stucker, Brian (RICH1:AR00)=20
> Sent: Thursday, November 01, 2007 07:58
> To: Jonathan Rosenberg; Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>=20
> I would also prefer that I-D references be left in the=20
> document. It's very helpful to the community to not only know=20
> where SIP is at when you read the guide, but to know where=20
> it's headed. If for no other reason than it prevents someone=20
> from thinking they've discovered a novel problem and go off=20
> implementing a solution parallel to what will soon=20
> (hopefully) be an RFC. Likewise, if they find that the I-D is=20
> incomplete, it gives them a reference to make comments=20
> against that they may not have otherwise discovered.
>=20
> It's an informative document. What if we just copy paragraphs=20
> two and three of from the boilerplate "status of this memo"=20
> into the introduction as a warning to those who read the=20
> document later as an RFC that I-D's referenced by the guide=20
> can change.=20
>=20
> Is there any harm in doing this?
>=20
> Regards,
> Brian=20
>=20
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> > Sent: Thursday, November 01, 2007 9:36 AM
> > To: Audet, Francois (SC100:3055)
> > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
> >=20
> > inline:
> >=20
> > Francois Audet wrote:
> > > What about SIPS, which is already in hitchiker's guide, and
> > which is
> > > waiting on outbound because of a normative reference?
> > >=20
> > >    =20
> > --------------------------------------------------------------
> > ----------
> > >     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > >     *Sent:* Tuesday, October 30, 2007 01:01
> > >     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;
> > jdrosen@cisco.com
> > >     *Subject:* RE: [RAI] RAI review of
> > > draft-ietf-sip-hitchhikers-guide-03
> > >=20
> > >     (As WG chair)
> > >     =20
> > >     Just a note that I should have included with the WGLC.
> > >     =20
> > >     The intention with this document is to republish on a=20
> recurring
> > >     basis, and therefore to keep it up to date (say once a
> > year or so).
> > >     =20
> > >     The 1st versions is intended to include gruu, outbound
> > and ice, but
> > >     apart from that, anything that is not published in that
> > timeframe
> > >     will probably be removed unless there is exceptional
> > justification
> > >     for keeping it, with the idea that it will appear in
> > the next version.
> >=20
> > This is news to me...
> >=20
> > What I thought would happen is that we have references to=20
> everything=20
> > in the guide, and when the guide appears as an RFC, whatever=20
> > references are at RFC status at that time, get RFC numbers.=20
> Everything=20
> > else is referenced as an I-D.
> >=20
> > I think you are suggesting that, instead, when we send this=20
> to IESG,=20
> > we remove any content and references associated with=20
> documents which=20
> > are not on track to publication around the same timeframe as=20
> > hitchhikers guide itself. Indeed it will require us to change those=20
> > references to normative in order to get rfc-editor to do a=20
> REF hold on=20
> > hitchhikers till its dependencies clear.
> >=20
> > If my interpretation is correct, my next question is whether this=20
> > applies to just the core specs or all of the specs.
> >=20
> > I personally would rather leave the document as is - include=20
> > everything, and recognize that some references will be=20
> drafts rather=20
> > than RFCs when hitchhikers is published. Next round of hitchhikers=20
> > will have more of them as RFCs.
> >=20
> > -Jonathan R.
> >=20
> > --=20
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Cisco Fellow                                   Parsippany, NJ=20
> > 07054-2711
> > Cisco Systems
> > jdrosen@cisco.com                              FAX:   (973) 952-5050
> > http://www.jdrosen.net                         PHONE: (973) 952-5000
> > http://www.cisco.com
> >=20
> > _______________________________________________
> > RAI mailing list
> > RAI@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rai
> >=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 13:33:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Indrn-00024k-J3; Thu, 01 Nov 2007 13:30:03 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Indrm-000248-9Q
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 13:30:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Indrl-000240-Vk; Thu, 01 Nov 2007 13:30:01 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Indrk-0001qH-OI; Thu, 01 Nov 2007 13:30:01 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0JQU00LJT8M020@usaga01-in.huawei.com>; Thu,
	01 Nov 2007 10:30:00 -0700 (PDT)
Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006))
	with ESMTPA id <0JQU00HCJ8LY5B@usaga01-in.huawei.com>; Thu,
	01 Nov 2007 10:30:00 -0700 (PDT)
Date: Thu, 01 Nov 2007 12:29:19 -0500
From: Spencer Dawkins 
Subject: Re: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
To: sip@ietf.org, rai@ietf.org
Message-id: <0bde01c81cac$bc7e0ff0$6401a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1;
	reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: 
	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>
	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
	<4729E458.6030703@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
	<1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

OK, two categories of drafts here.

If it's completed/approved, absolutely treat it like an RFC.

If it's mature but hasn't been completed/approved, it seems reasonable to 
put this in an "upcoming" section, where it's easier to provide guidance 
about "subject to change".

Thanks,

Spencer

----- Original Message ----- 
From: "Francois Audet" 
To: "Brian Stucker" ; "Jonathan Rosenberg" 

Cc: ; ; "Avshalom Houri" 
Sent: Thursday, November 01, 2007 11:25 AM
Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03


Same here. I prefer the whole list.

I checked again the list in the current document, and I didn't see
anything that was "controversial" (i.e., all the drafts quoted are
mature working group items).

If some of them were considered immature, we should remove them. But
otherwise, I'd rather we keep them in.

> -----Original Message-----
> From: Stucker, Brian (RICH1:AR00)
> Sent: Thursday, November 01, 2007 07:58
> To: Jonathan Rosenberg; Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>
> I would also prefer that I-D references be left in the
> document. It's very helpful to the community to not only know
> where SIP is at when you read the guide, but to know where
> it's headed. If for no other reason than it prevents someone
> from thinking they've discovered a novel problem and go off
> implementing a solution parallel to what will soon
> (hopefully) be an RFC. Likewise, if they find that the I-D is
> incomplete, it gives them a reference to make comments
> against that they may not have otherwise discovered.
>
> It's an informative document. What if we just copy paragraphs
> two and three of from the boilerplate "status of this memo"
> into the introduction as a warning to those who read the
> document later as an RFC that I-D's referenced by the guide
> can change.
>
> Is there any harm in doing this?
>
> Regards,
> Brian
>
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> > Sent: Thursday, November 01, 2007 9:36 AM
> > To: Audet, Francois (SC100:3055)
> > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
> >
> > inline:
> >
> > Francois Audet wrote:
> > > What about SIPS, which is already in hitchiker's guide, and
> > which is
> > > waiting on outbound because of a normative reference?
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > >     *Sent:* Tuesday, October 30, 2007 01:01
> > >     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;
> > jdrosen@cisco.com
> > >     *Subject:* RE: [RAI] RAI review of
> > > draft-ietf-sip-hitchhikers-guide-03
> > >
> > >     (As WG chair)
> > >
> > >     Just a note that I should have included with the WGLC.
> > >
> > >     The intention with this document is to republish on a
> recurring
> > >     basis, and therefore to keep it up to date (say once a
> > year or so).
> > >
> > >     The 1st versions is intended to include gruu, outbound
> > and ice, but
> > >     apart from that, anything that is not published in that
> > timeframe
> > >     will probably be removed unless there is exceptional
> > justification
> > >     for keeping it, with the idea that it will appear in
> > the next version.
> >
> > This is news to me...
> >
> > What I thought would happen is that we have references to
> everything
> > in the guide, and when the guide appears as an RFC, whatever
> > references are at RFC status at that time, get RFC numbers.
> Everything
> > else is referenced as an I-D.
> >
> > I think you are suggesting that, instead, when we send this
> to IESG,
> > we remove any content and references associated with
> documents which
> > are not on track to publication around the same timeframe as
> > hitchhikers guide itself. Indeed it will require us to change those
> > references to normative in order to get rfc-editor to do a
> REF hold on
> > hitchhikers till its dependencies clear.
> >
> > If my interpretation is correct, my next question is whether this
> > applies to just the core specs or all of the specs.
> >
> > I personally would rather leave the document as is - include
> > everything, and recognize that some references will be
> drafts rather
> > than RFCs when hitchhikers is published. Next round of hitchhikers
> > will have more of them as RFCs.
> >
> > -Jonathan R.
> >
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Cisco Fellow                                   Parsippany, NJ
> > 07054-2711
> > Cisco Systems
> > jdrosen@cisco.com                              FAX:   (973) 952-5050
> > http://www.jdrosen.net                         PHONE: (973) 952-5000
> > http://www.cisco.com
> >
> > _______________________________________________
> > RAI mailing list
> > RAI@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rai
> >
>


_______________________________________________
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




_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 13:42:30 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ine1y-00066v-Ue; Thu, 01 Nov 2007 13:40:34 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ine1w-00065T-LO
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 13:40:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ine1w-00062p-8o
	for sip@ietf.org; Thu, 01 Nov 2007 13:40:32 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ine1m-0002TQ-2x
	for sip@ietf.org; Thu, 01 Nov 2007 13:40:30 -0400
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA1He0gj006471
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 1 Nov 2007 12:40:01 -0500
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net>
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>
	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>
	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>
	
	<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>
	<472505F8.5090401@nostrum.com>
	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>
	<47255D1A.30206@nostrum.com>
	
	<472756C2.1010205@nostrum.com> <47277440.3050707@cisco.com>
	
	<0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6A5ECF04-A5D5-494A-8542-79993361AC05@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: DTMF timing (was Re: [Sip] INFO ...)
Date: Thu, 1 Nov 2007 12:39:52 -0500
To: "Elwell, John" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: sip List , Paul Kyzivat ,
	Adam Roach 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 1, 2007, at 6:07 AM, Elwell, John wrote:
> [JRE] Performance is a consideration with DTMF, because the speed with
> which the user receives a response from the server can have impact on
> the user experience. RFC 2833 is always likely to get through quicker.

That's an interesting assertion. While I'm inclined to agree that  
your assertion is likely to prove correct, I'm wondering: Does  
anybody out there have real-world measurements on this?

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 14:02:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IneLp-0004Lz-0h; Thu, 01 Nov 2007 14:01:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IneLn-0004Kd-PP
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 14:01:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IneLn-0004Hx-EX
	for sip@ietf.org; Thu, 01 Nov 2007 14:01:03 -0400
Received: from nf-out-0910.google.com ([64.233.182.191])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IneLh-0003Mf-8C
	for sip@ietf.org; Thu, 01 Nov 2007 14:01:03 -0400
Received: by nf-out-0910.google.com with SMTP id d21so425975nfb
	for ; Thu, 01 Nov 2007 11:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language;
	bh=vLGEGQuYDSWHqosnthmR3k0NplX1c9B+lN8JJLo9JbU=;
	b=hP3iJOOm+bZf06QkZKapugGNF+o3Fv0Nyy/3XR+9MPn4AA5Ca0tZLy5aH2GuaefacEcf4sgQpLrdQGosMqy8/MdRjivAHRaTv9tTPAtO8Y3i1SqUyZmB4S5pexJsEOFXrswzzUM3l2PZqutjoqHewfpRkkCvpVTadxunM4SwwN4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language;
	b=dy6IImzNrG40wgfRhPDOlKZw6lV+AZcEh68DyA2hng+K9sHvozywkCzWs0e8dRJTrmYsFw+Wjm1N5pJsXDokkoWeAC9iJPSGeRFI5/356CHW8XXNGpt8MuzDewmr/tEC3EOIEuZhkhBvrWLBsk5IhPyZ49mw/5uQWoTPbX2jWfA=
Received: by 10.78.179.12 with SMTP id b12mr666295huf.1193940035972;
	Thu, 01 Nov 2007 11:00:35 -0700 (PDT)
Received: from KACZ61M ( [85.232.206.212])
	by mx.google.com with ESMTPS id 39sm1076410hug.2007.11.01.11.00.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Nov 2007 11:00:34 -0700 (PDT)
From: "Kevin Attard Compagno" 
To: 
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>		<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>	<472505F8.5090401@nostrum.com>	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>	<47255D1A.30206@nostrum.com>		<472756C2.1010205@nostrum.com>
	<47277440.3050707@cisco.com>		<0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net>
	<6A5ECF04-A5D5-494A-8542-79993361AC05@softarmor.com>
In-Reply-To: <6A5ECF04-A5D5-494A-8542-79993361AC05@softarmor.com>
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)
Date: Thu, 1 Nov 2007 19:00:07 +0100
Message-ID: <006d01c81cb1$0ba65b60$22f31220$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcgcrwilLgMahtJeRXefgbnI8ImiFgAAQj3Q
Content-Language: en-gb
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Apologies for butting in, it's my first post to this list...

My understanding is:

It's not that RFC2833 DTMF delivery arrives quicker that is the point, =
but that it gets delivered with the rest of the real-time audio inside =
the RTP stream, timestamped appropriately to insert the tone at the =
correct point in time within the stream.

---
Kevin Attard Compagno


-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]=20
Sent: 01 November 2007 18:40
To: Elwell, John
Cc: sip List; Paul Kyzivat; Adam Roach
Subject: DTMF timing (was Re: [Sip] INFO ...)


On Nov 1, 2007, at 6:07 AM, Elwell, John wrote:
> [JRE] Performance is a consideration with DTMF, because the speed with
> which the user receives a response from the server can have impact on
> the user experience. RFC 2833 is always likely to get through quicker.

That's an interesting assertion. While I'm inclined to agree that =20
your assertion is likely to prove correct, I'm wondering: Does =20
anybody out there have real-world measurements on this?

--
Dean


_______________________________________________
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



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 14:26:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inehe-0001HF-2r; Thu, 01 Nov 2007 14:23:38 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Inehd-0001Gv-GI
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 14:23:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Inehd-0001Gn-6h
	for sip@ietf.org; Thu, 01 Nov 2007 14:23:37 -0400
Received: from bender-mail.tigertech.net ([64.62.209.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InehX-0004Ft-19
	for sip@ietf.org; Thu, 01 Nov 2007 14:23:37 -0400
Received: from localhost (localhost [127.0.0.1])
	by bender.tigertech.net (Postfix) with ESMTP id 4ECEC7DEA
	for ; Thu,  1 Nov 2007 11:23:15 -0700 (PDT)
Received: from JMHLap3.joelhalpern.com
	(pool-162-83-78-52.culp.east.verizon.net [162.83.78.52])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bender.tigertech.net (Postfix) with ESMTP id 6B6597DA8
	for ; Thu,  1 Nov 2007 11:23:13 -0700 (PDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 01 Nov 2007 14:23:09 -0400
To: sip@ietf.org
From: "Joel M. Halpern" 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <20071101182313.6B6597DA8@bender.tigertech.net>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net
X-Spam-Status: No, hits=4.3 tagged_above=-999.0 required=7.0
	tests=MSGID_FROM_MTA_ID, RCVD_IN_SORBS_DUL, SPF_NEUTRAL
X-Spam-Level: ****
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Subject: [Sip] Resource Priority Header namespaces
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I read over the draft in last call requesting new RPH namespace assignments.
In and of itself it looks non-objectionable.  While I don't 
understand the need for that many name spaces, or those specific 
values, my first reaction is to say "okay" anyway.

However, I went and looked at RFC4412, which defines the header 
namespace registration.
That RFC calls for a standard track RFC for defining namespaces.
And the text is quite explicit that one should not create a 
multiplicity of namespaces, but should try to use existing spaces first.

So, unless we want to check RFC4412, it seems that the request for 32 
namespaces in
	draft-ietf-sip-rph-new-namespaces-00.txt
really needs more explanation / justification.

Yours,
Joel M. Halpern



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 16:25:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IngXP-0006iu-7s; Thu, 01 Nov 2007 16:21:11 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IngXN-0006hI-OZ
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 16:21:09 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IngXN-0006Va-DS
	for sip@ietf.org; Thu, 01 Nov 2007 16:21:09 -0400
Received: from sea02-mxf01.citel.com ([205.234.66.116])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IngX9-0005Sk-JU
	for sip@ietf.org; Thu, 01 Nov 2007 16:20:56 -0400
Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com)
	by sea02-mxf01.citel.com with smtp (Exim 4.43)
	id 1IngX8-0004AA-Oj; Thu, 01 Nov 2007 13:20:54 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)
Date: Thu, 1 Nov 2007 13:20:54 -0700
Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C0E5A3D@sea02-mxc01.citel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DTMF timing (was Re: [Sip] INFO ...)
thread-index: AcgcrwilLgMahtJeRXefgbnI8ImiFgAAQj3QAATScmM=
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>		<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>	<472505F8.5090401@nostrum.com>	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>	<47255D1A.30206@nostrum.com>		<472756C2.1010205@nostrum.com>
	<47277440.3050707@cisco.com>		<0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net>
	<6A5ECF04-A5D5-494A-8542-79993361AC05@softarmor.com>
	<006d01c81cb1$0ba65b60$22f31220$@com>
From: "Michael Procter" 
To: "Kevin Attard Compagno" ,
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Whilst having the RFC2833 arriving in the timestamped audio stream is =
certainly beneficial, it is also true to say that the RTP stream =
generally travels quicker than signalling.  One of the main reasons for =
this is that the RTP usually travels point-to-point, whilst the =
signalling path often includes a couple of proxies.  Even if the proxies =
process the messages in zero time (which they don't), there are still =
multiple network hops introduced as a consequence.  Additional delays =
incurred by the proxies/other intermediate signalling elements swiftly =
add up too.
=20
Regards,
=20
Michael

________________________________

From: Kevin Attard Compagno [mailto:kampagnol@gmail.com]
Sent: Thu 01/11/2007 18:00
To: sip@ietf.org
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)



Apologies for butting in, it's my first post to this list...

My understanding is:

It's not that RFC2833 DTMF delivery arrives quicker that is the point, =
but that it gets delivered with the rest of the real-time audio inside =
the RTP stream, timestamped appropriately to insert the tone at the =
correct point in time within the stream.

---
Kevin Attard Compagno


-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 01 November 2007 18:40
To: Elwell, John
Cc: sip List; Paul Kyzivat; Adam Roach
Subject: DTMF timing (was Re: [Sip] INFO ...)


On Nov 1, 2007, at 6:07 AM, Elwell, John wrote:
> [JRE] Performance is a consideration with DTMF, because the speed with
> which the user receives a response from the server can have impact on
> the user experience. RFC 2833 is always likely to get through quicker.

That's an interesting assertion. While I'm inclined to agree that=20
your assertion is likely to prove correct, I'm wondering: Does=20
anybody out there have real-world measurements on this?

--
Dean


_______________________________________________
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



_______________________________________________
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




_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 16:49:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IngvX-00019d-3U; Thu, 01 Nov 2007 16:46:07 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IngvV-00018Y-QE
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 16:46:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IngvV-00018Q-Gb; Thu, 01 Nov 2007 16:46:05 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IngvU-0001be-2g; Thu, 01 Nov 2007 16:46:05 -0400
X-IronPort-AV: E=Sophos;i="4.21,359,1188802800"; d="scan'208";a="245677252"
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 01 Nov 2007 13:46:03 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lA1Kk35h031204; 
	Thu, 1 Nov 2007 13:46:03 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA1KjxXt012564;
	Thu, 1 Nov 2007 20:46:03 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 1 Nov 2007 13:46:00 -0700
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 1 Nov 2007 13:46:00 -0700
Message-ID: <472A3B25.7090008@cisco.com>
Date: Thu, 01 Nov 2007 16:46:29 -0400
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Francois Audet 
References: 
	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>
	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
	<4729E458.6030703@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
	<1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Nov 2007 20:46:00.0717 (UTC)
	FILETIME=[36201BD0:01C81CC8]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5475; t=1193949963;
	x=1194813963; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[RAI]=20RAI=20review=20of=20draft-ietf-sip-hitchhiker
	s-guide-03 |Sender:=20;
	bh=yt77iIsD8hcpISNjaD7QdFhmf1Kzw2XvyGzoLN9gH6g=;
	b=qjjUmHBhNNPhe33NFPet57i1oYAkLYQHQclVzoyEehSn/BN2WSnbDYxzZ1s0Nbgs6CBFXBIB
	pgIrgb3hMplKdKEBdGbOBzRBeNdSckXC3QMpvOCsvJ2LPRDX7TYRJeXL;
Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Cc: sip@ietf.org, rai@ietf.org, Avshalom Houri ,
	Brian Stucker 
Subject: [Sip] Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

The document includes any normative sip extension once it has been 
adopted as a WG Item. So this does include stuff that is "earlier" in 
the process; for example the sip-saml stuff which (IMHO) is still a 
little on the early side. But once it is a wg item it gets in there. I 
still think its fine to publish hitchhikers as an RFC with those as 
references (to drafts).

-Jonathan R.

Francois Audet wrote:
> Same here. I prefer the whole list.
> 
> I checked again the list in the current document, and I didn't see
> anything that was "controversial" (i.e., all the drafts quoted are
> mature working group items).
> 
> If some of them were considered immature, we should remove them. But
> otherwise, I'd rather we keep them in. 
> 
>> -----Original Message-----
>> From: Stucker, Brian (RICH1:AR00) 
>> Sent: Thursday, November 01, 2007 07:58
>> To: Jonathan Rosenberg; Audet, Francois (SC100:3055)
>> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
>> Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>>
>> I would also prefer that I-D references be left in the 
>> document. It's very helpful to the community to not only know 
>> where SIP is at when you read the guide, but to know where 
>> it's headed. If for no other reason than it prevents someone 
>> from thinking they've discovered a novel problem and go off 
>> implementing a solution parallel to what will soon 
>> (hopefully) be an RFC. Likewise, if they find that the I-D is 
>> incomplete, it gives them a reference to make comments 
>> against that they may not have otherwise discovered.
>>
>> It's an informative document. What if we just copy paragraphs 
>> two and three of from the boilerplate "status of this memo" 
>> into the introduction as a warning to those who read the 
>> document later as an RFC that I-D's referenced by the guide 
>> can change. 
>>
>> Is there any harm in doing this?
>>
>> Regards,
>> Brian 
>>
>>> -----Original Message-----
>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
>>> Sent: Thursday, November 01, 2007 9:36 AM
>>> To: Audet, Francois (SC100:3055)
>>> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
>>> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>>>
>>> inline:
>>>
>>> Francois Audet wrote:
>>>> What about SIPS, which is already in hitchiker's guide, and
>>> which is
>>>> waiting on outbound because of a normative reference?
>>>>
>>>>     
>>> --------------------------------------------------------------
>>> ----------
>>>>     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
>>>>     *Sent:* Tuesday, October 30, 2007 01:01
>>>>     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;
>>> jdrosen@cisco.com
>>>>     *Subject:* RE: [RAI] RAI review of
>>>> draft-ietf-sip-hitchhikers-guide-03
>>>>
>>>>     (As WG chair)
>>>>      
>>>>     Just a note that I should have included with the WGLC.
>>>>      
>>>>     The intention with this document is to republish on a 
>> recurring
>>>>     basis, and therefore to keep it up to date (say once a
>>> year or so).
>>>>      
>>>>     The 1st versions is intended to include gruu, outbound
>>> and ice, but
>>>>     apart from that, anything that is not published in that
>>> timeframe
>>>>     will probably be removed unless there is exceptional
>>> justification
>>>>     for keeping it, with the idea that it will appear in
>>> the next version.
>>>
>>> This is news to me...
>>>
>>> What I thought would happen is that we have references to 
>> everything 
>>> in the guide, and when the guide appears as an RFC, whatever 
>>> references are at RFC status at that time, get RFC numbers. 
>> Everything 
>>> else is referenced as an I-D.
>>>
>>> I think you are suggesting that, instead, when we send this 
>> to IESG, 
>>> we remove any content and references associated with 
>> documents which 
>>> are not on track to publication around the same timeframe as 
>>> hitchhikers guide itself. Indeed it will require us to change those 
>>> references to normative in order to get rfc-editor to do a 
>> REF hold on 
>>> hitchhikers till its dependencies clear.
>>>
>>> If my interpretation is correct, my next question is whether this 
>>> applies to just the core specs or all of the specs.
>>>
>>> I personally would rather leave the document as is - include 
>>> everything, and recognize that some references will be 
>> drafts rather 
>>> than RFCs when hitchhikers is published. Next round of hitchhikers 
>>> will have more of them as RFCs.
>>>
>>> -Jonathan R.
>>>
>>> -- 
>>> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>>> Cisco Fellow                                   Parsippany, NJ 
>>> 07054-2711
>>> Cisco Systems
>>> jdrosen@cisco.com                              FAX:   (973) 952-5050
>>> http://www.jdrosen.net                         PHONE: (973) 952-5000
>>> http://www.cisco.com
>>>
>>> _______________________________________________
>>> RAI mailing list
>>> RAI@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/rai
>>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 16:52:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inh13-0005I0-Ur; Thu, 01 Nov 2007 16:51:49 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Inh12-0005Fn-4O
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 16:51:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Inh11-0005Ff-Qx; Thu, 01 Nov 2007 16:51:47 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Inh0v-0001o2-L9; Thu, 01 Nov 2007 16:51:47 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lA1KpMk12309; Thu, 1 Nov 2007 20:51:22 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 1 Nov 2007 15:51:01 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF12EAE461@zrc2hxm0.corp.nortel.com>
In-Reply-To: <472A3B25.7090008@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
Thread-Index: AcgcyFs1FpUX8ixjRlyFwQxl1vV4NgAAF65A
References: 
	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>
	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>
	<4729E458.6030703@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
	<1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com>
	<472A3B25.7090008@cisco.com>
From: "Francois Audet" 
To: "Jonathan Rosenberg" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: sip@ietf.org, rai@ietf.org, Avshalom Houri ,
	Brian Stucker 
Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I'm fine with it.


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
> Sent: Thursday, November 01, 2007 13:46
> To: Audet, Francois (SC100:3055)
> Cc: Stucker, Brian (RICH1:AR00); sip@ietf.org; Avshalom=20
> Houri; rai@ietf.org
> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>=20
> The document includes any normative sip extension once it has=20
> been adopted as a WG Item. So this does include stuff that is=20
> "earlier" in the process; for example the sip-saml stuff=20
> which (IMHO) is still a little on the early side. But once it=20
> is a wg item it gets in there. I still think its fine to=20
> publish hitchhikers as an RFC with those as references (to drafts).


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 17:21:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InhRQ-0007vZ-M9; Thu, 01 Nov 2007 17:19:04 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InhRP-0007ur-8i
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 17:19:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InhRO-0007uY-VC
	for sip@ietf.org; Thu, 01 Nov 2007 17:19:02 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InhRI-0002qZ-Ou
	for sip@ietf.org; Thu, 01 Nov 2007 17:19:02 -0400
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA1LIfDg008248
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 1 Nov 2007 16:18:42 -0500
In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011C0E5A3D@sea02-mxc01.citel.com>
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>		<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>	<472505F8.5090401@nostrum.com>	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>	<47255D1A.30206@nostrum.com>		<472756C2.1010205@nostrum.com>
	<47277440.3050707@cisco.com>		<0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net>
	<6A5ECF04-A5D5-494A-8542-79993361AC05@softarmor.com>
	<006d01c81cb1$0ba65b60$22f31220$@com>
	<0D4E483A0E6E0A46861409E5D6C2011C0E5A3D@sea02-mxc01.citel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1C0CC329-89F4-4A07-A163-8C893A329E96@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: DTMF timing (was Re: [Sip] INFO ...)
Date: Thu, 1 Nov 2007 16:18:33 -0500
To: Michael Procter 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 1, 2007, at 3:20 PM, Michael Procter wrote:

> Whilst having the RFC2833 arriving in the timestamped audio stream  
> is certainly beneficial, it is also true to say that the RTP stream  
> generally travels quicker than signalling.  One of the main reasons  
> for this is that the RTP usually travels point-to-point, whilst the  
> signalling path often includes a couple of proxies.  Even if the  
> proxies process the messages in zero time (which they don't), there  
> are still multiple network hops introduced as a consequence.   
> Additional delays incurred by the proxies/other intermediate  
> signalling elements swiftly add up too.

I agree that this sounds correct in theory.

What I'm wondering about is those deployments that use media-path  
control elements (aka SBCs that police media) and/or decoupled media  
and signaling processors.

I suspect that that SBCs slow down RTP about as much as they slow  
down SIP. COuld be more, could be less -- I don't really know.

Then there's the question of decoding the 2833 stream and backhauling  
it from the RTP-processing DSP element up to the application that's  
running at the control layer. From what the people who build  
decomposed gateways sometimes tell me, I've surmised that this may  
not be the easiest thing to do efficiently. This also applies to  
application built using a control "application servers" and a media  
server, since we don't generally bother to negotiate different  
endpoints for the 2833 stream, so it just follows the path to the  
media server.

We don't really use DTMF much between "traditional SIP endpoints" --  
the kind of all-in-one device that does everything in a dedicated  
general-purpose processor. It seems that in practice we use it more  
frequently in transactions that involve large-scale decoupled  
gateways and decoupled media servers, at least at one end of the  
call. I wouldn't be surprised to see the practical reality collide  
with the theory around 2833.

So, that's why I'd like to see real-world measurements in real-world  
large-scale applications that actually use DTMF.

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 01 18:19:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IniJq-0006Av-T8; Thu, 01 Nov 2007 18:15:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IniJo-00067k-V1
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 18:15:16 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IniJo-00063j-JD
	for sip@ietf.org; Thu, 01 Nov 2007 18:15:16 -0400
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IniJj-0000pN-4f
	for sip@ietf.org; Thu, 01 Nov 2007 18:15:11 -0400
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0;
	Thu, 1 Nov 2007 18:15:10 -0400
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Thu, 1 Nov 2007 18:15:10 -0400
From: Hadriel Kaplan 
To: Dean Willis , Michael Procter
	
Date: Thu, 1 Nov 2007 18:15:07 -0400
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)
Thread-Topic: DTMF timing (was Re: [Sip] INFO ...)
Thread-Index: AcgczZpKg16KWcQMSX65Iplw2Bm2XwABIPmw
Message-ID: 
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>
	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>
	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>
	
	<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>
	<472505F8.5090401@nostrum.com>
	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>
	<47255D1A.30206@nostrum.com>
	
	<472756C2.1010205@nostrum.com>	<47277440.3050707@cisco.com>
	
	<0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net>
	<6A5ECF04-A5D5-494A-8542-79993361AC05@softarmor.com>
	<006d01c81cb1$0ba65b60$22f31220$@com>
	<0D4E483A0E6E0A46861409E5D6C2011C0E5A3D@sea02-mxc01.citel.com>
	<1C0CC329-89F4-4A07-A163-8C893A329E96@softarmor.com>
In-Reply-To: <1C0CC329-89F4-4A07-A163-8C893A329E96@softarmor.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: "sip@ietf.org" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
>
> On Nov 1, 2007, at 3:20 PM, Michael Procter wrote:
>
> > Whilst having the RFC2833 arriving in the timestamped audio stream
> > is certainly beneficial, it is also true to say that the RTP stream
> > generally travels quicker than signalling.  One of the main reasons
> > for this is that the RTP usually travels point-to-point, whilst the
> > signalling path often includes a couple of proxies.  Even if the
> > proxies process the messages in zero time (which they don't), there
> > are still multiple network hops introduced as a consequence.
> > Additional delays incurred by the proxies/other intermediate
> > signalling elements swiftly add up too.
>
> I agree that this sounds correct in theory.
>
> What I'm wondering about is those deployments that use media-path
> control elements (aka SBCs that police media) and/or decoupled media
> and signaling processors.
>
> I suspect that that SBCs slow down RTP about as much as they slow
> down SIP. COuld be more, could be less -- I don't really know.

Uh, nope.  There are such things as software-based SBCs, for enterprises an=
d such, but most of the provider ones use dedicated hardware to handle RTP/=
RTCP. (using NPs/ASICS/whatever)  It's not discernibly slower than a router=
, depending on the vendor.


> We don't really use DTMF much between "traditional SIP endpoints" --
> the kind of all-in-one device that does everything in a dedicated
> general-purpose processor. It seems that in practice we use it more
> frequently in transactions that involve large-scale decoupled
> gateways and decoupled media servers, at least at one end of the
> call. I wouldn't be surprised to see the practical reality collide
> with the theory around 2833.

Yeah, I buy that.
My worry though isn't about speed.  It's about use.  One of the obvious use=
 cases for signaling-based DTMF is it follows the signaling, and the media =
doesn't need to.  For an info-dtmf model, that essentially means something =
in the middle that wants dtmf (an app-server, for example) has to act as a =
b2bua for signaling, but doesn't need to be in the media path.  So even if =
both info-dtmf and 2833 get negotiated, you'd want to use the info-dtmf.  A=
lthough I guess if the app-server needed it that way, it would have to have=
 removed 2833 from SDP (yuck), 'cause otherwise as a UA it's essentially ly=
ing by offering 2833.

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 03 12:04:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IoLTT-0001LN-TH; Sat, 03 Nov 2007 12:03:51 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IoLTS-0001Ko-Kp
	for sip-confirm+ok@megatron.ietf.org; Sat, 03 Nov 2007 12:03:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IoLTS-0001JZ-AN; Sat, 03 Nov 2007 12:03:50 -0400
Received: from ihemail4.lucent.com ([135.245.0.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IoLTR-0004JA-1Q; Sat, 03 Nov 2007 12:03:50 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lA3G3bui012703;
	Sat, 3 Nov 2007 11:03:45 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 3 Nov 2007 11:03:42 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 3 Nov 2007 17:03:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 3 Nov 2007 17:03:40 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918001886B88@DEEXC1U01.de.lucent.com>
In-Reply-To: <472A3B25.7090008@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
Thread-Index: AcgcyI5xeMQlnEj7RTemjya+DxQtbQBaFyXw
References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com><4729E458.6030703@cisco.com><1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com>
	<472A3B25.7090008@cisco.com>
From: "DRAGE, Keith \(Keith\)" 
To: "Jonathan Rosenberg" ,
	"Francois Audet" 
X-OriginalArrivalTime: 03 Nov 2007 16:03:40.0623 (UTC)
	FILETIME=[19DE65F0:01C81E33]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121
Cc: sip@ietf.org, Avshalom Houri , rai@ietf.org
Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I guess I got this wrong.

My starting point was a misinterpretation of Jonathan's indication way =
back that we were waiting for outbound, gruu and ice before we pushed =
this forward.=20

Having thought about this some more:

-	Yes we should include internet drafts, but with some sort of =
explanation that they are included to encourage early implementation and =
demonstrations of interoperability of the protocol, and thus aid in the =
standards setting process; also that they identify were the WG is =
targetting a solution at a particular problem space and thus aid work =
towards a common solution. Additionally a warning that final IANA =
assignment of codepoints does not take place until shortly before =
publication, and thus codepoint assignments may change.

-	No we should not automatically include all WG drafts, but should =
assert some form of expert review. We seem to have somewhere up to 25% =
of working group documents that never make it to completion, and another =
fair average that still are not going to be there in the the next 3 =
years, judging by past performance. We are never obviously going to get =
this 100% right, and I don't think we should spill any blood arguing =
about the inclusion or exclusion of any draft, but I do think we should =
attempt to preguess this and miss some of these out. We want the market =
to try out the drafts in the document, but not get put off by us =
marketing to them something that will never fulfil their product =
timescales.

-	Yes we should include some author drafts, probably on the basis that =
an AD has sponsored them, or is about to sponsor them, through the IESG, =
and certainly if they have reached the RFC editor's queue.

I suspect the above is pretty much what is in the hitchhiker draft now, =
but I thought it worth at least putting it down on paper.

Regards

Keith

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
> Sent: Thursday, November 01, 2007 8:46 PM
> To: Francois Audet
> Cc: sip@ietf.org; rai@ietf.org; Avshalom Houri
> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>=20
> The document includes any normative sip extension once it has=20
> been adopted as a WG Item. So this does include stuff that is=20
> "earlier" in the process; for example the sip-saml stuff=20
> which (IMHO) is still a little on the early side. But once it=20
> is a wg item it gets in there. I still think its fine to=20
> publish hitchhikers as an RFC with those as references (to drafts).
>=20
> -Jonathan R.
>=20
> Francois Audet wrote:
> > Same here. I prefer the whole list.
> >=20
> > I checked again the list in the current document, and I didn't see=20
> > anything that was "controversial" (i.e., all the drafts quoted are=20
> > mature working group items).
> >=20
> > If some of them were considered immature, we should remove=20
> them. But=20
> > otherwise, I'd rather we keep them in.
> >=20
> >> -----Original Message-----
> >> From: Stucker, Brian (RICH1:AR00)
> >> Sent: Thursday, November 01, 2007 07:58
> >> To: Jonathan Rosenberg; Audet, Francois (SC100:3055)
> >> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> >> Subject: RE: [RAI] RAI review of=20
> draft-ietf-sip-hitchhikers-guide-03
> >>
> >> I would also prefer that I-D references be left in the=20
> document. It's=20
> >> very helpful to the community to not only know where SIP=20
> is at when=20
> >> you read the guide, but to know where it's headed. If for no other=20
> >> reason than it prevents someone from thinking they've discovered a=20
> >> novel problem and go off implementing a solution parallel to what=20
> >> will soon
> >> (hopefully) be an RFC. Likewise, if they find that the I-D is=20
> >> incomplete, it gives them a reference to make comments=20
> against that=20
> >> they may not have otherwise discovered.
> >>
> >> It's an informative document. What if we just copy=20
> paragraphs two and=20
> >> three of from the boilerplate "status of this memo"
> >> into the introduction as a warning to those who read the document=20
> >> later as an RFC that I-D's referenced by the guide can change.
> >>
> >> Is there any harm in doing this?
> >>
> >> Regards,
> >> Brian
> >>
> >>> -----Original Message-----
> >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> >>> Sent: Thursday, November 01, 2007 9:36 AM
> >>> To: Audet, Francois (SC100:3055)
> >>> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> >>> Subject: Re: [RAI] RAI review of=20
> draft-ietf-sip-hitchhikers-guide-03
> >>>
> >>> inline:
> >>>
> >>> Francois Audet wrote:
> >>>> What about SIPS, which is already in hitchiker's guide, and
> >>> which is
> >>>> waiting on outbound because of a normative reference?
> >>>>
> >>>>    =20
> >>> --------------------------------------------------------------
> >>> ----------
> >>>>     *From:* DRAGE, Keith (Keith)=20
> [mailto:drage@alcatel-lucent.com]
> >>>>     *Sent:* Tuesday, October 30, 2007 01:01
> >>>>     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;
> >>> jdrosen@cisco.com
> >>>>     *Subject:* RE: [RAI] RAI review of
> >>>> draft-ietf-sip-hitchhikers-guide-03
> >>>>
> >>>>     (As WG chair)
> >>>>     =20
> >>>>     Just a note that I should have included with the WGLC.
> >>>>     =20
> >>>>     The intention with this document is to republish on a
> >> recurring
> >>>>     basis, and therefore to keep it up to date (say once a
> >>> year or so).
> >>>>     =20
> >>>>     The 1st versions is intended to include gruu, outbound
> >>> and ice, but
> >>>>     apart from that, anything that is not published in that
> >>> timeframe
> >>>>     will probably be removed unless there is exceptional
> >>> justification
> >>>>     for keeping it, with the idea that it will appear in
> >>> the next version.
> >>>
> >>> This is news to me...
> >>>
> >>> What I thought would happen is that we have references to
> >> everything
> >>> in the guide, and when the guide appears as an RFC, whatever=20
> >>> references are at RFC status at that time, get RFC numbers.
> >> Everything
> >>> else is referenced as an I-D.
> >>>
> >>> I think you are suggesting that, instead, when we send this
> >> to IESG,
> >>> we remove any content and references associated with
> >> documents which
> >>> are not on track to publication around the same timeframe as=20
> >>> hitchhikers guide itself. Indeed it will require us to=20
> change those=20
> >>> references to normative in order to get rfc-editor to do a
> >> REF hold on
> >>> hitchhikers till its dependencies clear.
> >>>
> >>> If my interpretation is correct, my next question is whether this=20
> >>> applies to just the core specs or all of the specs.
> >>>
> >>> I personally would rather leave the document as is - include=20
> >>> everything, and recognize that some references will be
> >> drafts rather
> >>> than RFCs when hitchhikers is published. Next round of=20
> hitchhikers=20
> >>> will have more of them as RFCs.
> >>>
> >>> -Jonathan R.
> >>>
> >>> --=20
> >>> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> >>> Cisco Fellow                                   Parsippany, NJ=20
> >>> 07054-2711
> >>> Cisco Systems
> >>> jdrosen@cisco.com                              FAX:  =20
> (973) 952-5050
> >>> http://www.jdrosen.net                         PHONE:=20
> (973) 952-5000
> >>> http://www.cisco.com
> >>>
> >>> _______________________________________________
> >>> RAI mailing list
> >>> RAI@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/rai
> >>>
> >=20
>=20
> --=20
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ=20
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>=20
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www1.ietf.org/mailman/listinfo/rai
>=20


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 04 09:22:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IogMn-0006yq-BX; Sun, 04 Nov 2007 09:22:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IogMl-0006w3-KK
	for sip-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 09:22:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IogMl-0006vo-Ai
	for sip@ietf.org; Sun, 04 Nov 2007 09:22:19 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IogMk-00061g-31
	for sip@ietf.org; Sun, 04 Nov 2007 09:22:19 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lA4EMCQ8018736;
	Sun, 4 Nov 2007 08:22:16 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 4 Nov 2007 08:22:11 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 4 Nov 2007 15:22:09 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Resource Priority Header namespaces
Date: Sun, 4 Nov 2007 15:22:09 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918001886BD9@DEEXC1U01.de.lucent.com>
In-Reply-To: <20071101182313.6B6597DA8@bender.tigertech.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Resource Priority Header namespaces
Thread-Index: AcgctRbDlDMmiPiST+2E/iNn974ZfQCGPS5A
References: <20071101182313.6B6597DA8@bender.tigertech.net>
From: "DRAGE, Keith \(Keith\)" 
To: "Joel M. Halpern" , 
X-OriginalArrivalTime: 04 Nov 2007 14:22:09.0902 (UTC)
	FILETIME=[15EDE0E0:01C81EEE]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I will leave James to respond to this as it impacts the draft, but
assuming we reach that stage, I will remember this point for the PROTO
writeup.

Regards

Keith=20

> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20
> Sent: Thursday, November 01, 2007 6:23 PM
> To: sip@ietf.org
> Subject: [Sip] Resource Priority Header namespaces
>=20
> I read over the draft in last call requesting new RPH=20
> namespace assignments.
> In and of itself it looks non-objectionable.  While I don't=20
> understand the need for that many name spaces, or those=20
> specific values, my first reaction is to say "okay" anyway.
>=20
> However, I went and looked at RFC4412, which defines the=20
> header namespace registration.
> That RFC calls for a standard track RFC for defining namespaces.
> And the text is quite explicit that one should not create a=20
> multiplicity of namespaces, but should try to use existing=20
> spaces first.
>=20
> So, unless we want to check RFC4412, it seems that the=20
> request for 32 namespaces in
> 	draft-ietf-sip-rph-new-namespaces-00.txt
> really needs more explanation / justification.
>=20
> Yours,
> Joel M. Halpern
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 04 09:31:01 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IogV9-0006nZ-3r; Sun, 04 Nov 2007 09:30:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IncbU-0000NO-CM
	for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 12:09:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IncbU-0000NG-2h; Thu, 01 Nov 2007 12:09:08 -0400
Received: from ottgw.pt.com ([209.217.107.194] helo=grandpa.ottawa.pt.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IncbQ-0007SL-SS; Thu, 01 Nov 2007 12:09:08 -0400
Received: from [10.81.15.111] (unknown [10.81.15.111])
	by grandpa.ottawa.pt.com (Postfix) with ESMTP id 5258DD71A3;
	Thu,  1 Nov 2007 11:45:07 -0400 (EDT)
Message-ID: <4729FA13.1060409@pt.com>
Date: Thu, 01 Nov 2007 12:08:51 -0400
From: Andrew Booth 
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Avshalom Houri 
References: 	<5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com>	<1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com>	<4729E458.6030703@cisco.com>	<1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
X-Mailman-Approved-At: Sun, 04 Nov 2007 09:30:57 -0500
Cc: sip@ietf.org, rai@ietf.org, Brian Stucker 
Subject: [Sip] Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I appologise in advance if this comment is not helpful.

In the SIGTRAN mailing list there was a similar issue for some RFC, and 
if I recall correctly the compromize was that I-D's could be listed as 
Informational References but not Normative References.  Is this an 
option here?

Andrew

Avshalom Houri wrote:
>
> I also think that leaving the references to the drafts is important.
> I do not know what should be the actual mechanism but it will be like
> hitchhiking a space ship that has many of its windows covered,
> it will be hard to see where we are flying to.
>
> --Avshalom
>
>
>
>
>
>
>
> *"Brian Stucker" *
>
> 01/11/2007 16:57
>
> 	
> To
> 	"Jonathan Rosenberg" , "Francois Audet" 
> 
> cc
> 	, Avshalom Houri/Haifa/IBM@IBMIL, 
> Subject
> 	RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>
>
>
> 	
>
>
>
>
>
> I would also prefer that I-D references be left in the document. It's
> very helpful to the community to not only know where SIP is at when you
> read the guide, but to know where it's headed. If for no other reason
> than it prevents someone from thinking they've discovered a novel
> problem and go off implementing a solution parallel to what will soon
> (hopefully) be an RFC. Likewise, if they find that the I-D is
> incomplete, it gives them a reference to make comments against that they
> may not have otherwise discovered.
>
> It's an informative document. What if we just copy paragraphs two and
> three of from the boilerplate "status of this memo" into the
> introduction as a warning to those who read the document later as an RFC
> that I-D's referenced by the guide can change.
>
> Is there any harm in doing this?
>
> Regards,
> Brian
>
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> > Sent: Thursday, November 01, 2007 9:36 AM
> > To: Audet, Francois (SC100:3055)
> > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
> >
> > inline:
> >
> > Francois Audet wrote:
> > > What about SIPS, which is already in hitchiker's guide, and
> > which is
> > > waiting on outbound because of a normative reference?
> > >
> > >    
> > --------------------------------------------------------------
> > ----------
> > >     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > >     *Sent:* Tuesday, October 30, 2007 01:01
> > >     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;
> > jdrosen@cisco.com
> > >     *Subject:* RE: [RAI] RAI review of
> > > draft-ietf-sip-hitchhikers-guide-03
> > >
> > >     (As WG chair)
> > >      
> > >     Just a note that I should have included with the WGLC.
> > >      
> > >     The intention with this document is to republish on a recurring
> > >     basis, and therefore to keep it up to date (say once a
> > year or so).
> > >      
> > >     The 1st versions is intended to include gruu, outbound
> > and ice, but
> > >     apart from that, anything that is not published in that
> > timeframe
> > >     will probably be removed unless there is exceptional
> > justification
> > >     for keeping it, with the idea that it will appear in
> > the next version.
> >
> > This is news to me...
> >
> > What I thought would happen is that we have references to
> > everything in the guide, and when the guide appears as an
> > RFC, whatever references are at RFC status at that time, get
> > RFC numbers. Everything else is referenced as an I-D.
> >
> > I think you are suggesting that, instead, when we send this
> > to IESG, we remove any content and references associated with
> > documents which are not on track to publication around the
> > same timeframe as hitchhikers guide itself. Indeed it will
> > require us to change those references to normative in order
> > to get rfc-editor to do a REF hold on hitchhikers till its
> > dependencies clear.
> >
> > If my interpretation is correct, my next question is whether
> > this applies to just the core specs or all of the specs.
> >
> > I personally would rather leave the document as is - include
> > everything, and recognize that some references will be drafts
> > rather than RFCs when hitchhikers is published. Next round of
> > hitchhikers will have more of them as RFCs.
> >
> > -Jonathan R.
> >
> > --
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Cisco Fellow                                   Parsippany, NJ
> > 07054-2711
> > Cisco Systems
> > jdrosen@cisco.com                              FAX:   (973) 952-5050
> > http://www.jdrosen.net                      
>     PHONE: (973) 952-5000
> > http://www.cisco.com 
> >
> > _______________________________________________
> > RAI mailing list
> > RAI@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rai
> >
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www1.ietf.org/mailman/listinfo/rai
>   


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 04 09:31:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IogVV-0007Em-9A; Sun, 04 Nov 2007 09:31:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InCxY-0003Gr-Qs
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 08:46:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InCxY-0003F4-6F; Wed, 31 Oct 2007 08:46:12 -0400
Received: from keskus.netlab.hut.fi ([130.233.154.176] helo=smtp.netlab.hut.fi)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1InCxL-0003AJ-Un; Wed, 31 Oct 2007 08:46:06 -0400
Received: from localhost (webserver.netlab.hut.fi [130.233.154.187])
	by smtp.netlab.hut.fi (Postfix) with ESMTP id 6160EC50E5;
	Wed, 31 Oct 2007 14:45:38 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at TKK Netlab
Received: from smtp.netlab.hut.fi ([130.233.154.176])
	by localhost (webserver.netlab.hut.fi [130.233.154.187]) (amavisd-new,
	port 10024)
	with ESMTP id etSUWyIti1mV; Wed, 31 Oct 2007 14:45:31 +0200 (EET)
Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176])
	by smtp.netlab.hut.fi (Postfix) with ESMTP id 44BC8C50E2;
	Wed, 31 Oct 2007 14:45:31 +0200 (EET)
Message-ID: <472878ED.9070009@netlab.hut.fi>
Date: Wed, 31 Oct 2007 14:45:33 +0200
From: Joerg Ott 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg , sip ietf , 
	Dean Willis ,
	drage@alcatel-lucent.com,  rai@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
X-Mailman-Approved-At: Sun, 04 Nov 2007 09:31:19 -0500
Cc: 
Subject: [Sip] RAI-ART review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,

I am the assigned RAI-ART reviewer for draft-ietf-sip-hitchhikers-guide-03

For background on RAI-ART, please see the FAQ at 
.

Please resolve the comments below along with any other
Last Call comments you may receive.

It may be worthwhile to include the advice in the beginning:

"Do not print all the specs cited here at once, as they
might share the fate of the rules of Brockian Ultracricket
when bound together: collapse under their own gravity and
form a black hole. [42]"

Joerg


Review of draft-ietf-sip-hitchhikers-guide-03:


This draft is ready for publication as an Informational RFC.
Please consider the suggestions and nits listed below.


Observations and suggestions:

Sect. 5, p10, RFC4244:

     "Its primary purpose _was_ in support of voicemail services."

     This reads like the document became obsolete already.
     Is this intentional?  If so, would it be useful to also
     indicate which other purposes it now serves (or none
     at all)?


Sect. 7, p13, RFC4583:

     This should go to the conferencing section (sect. 8).


Sect. 7, p13, RFCXXXX [59]:

     This should explicitly state that it builds upon the general
     mechanisms of RFC 3312 (which only is described later).


Sect. 9, p14, RFC3515:

     It may be useful to add a warning clause concerning REFER,
     e.g., along the following lines:

     "Beware that not all potential uses of REFER (neither for all
      methods nor for all URI schemes) are well defined.  Be advised
      to use only the well-defined ones and not to second guess or
      freely assume behavior for the others to avoid unexpected
      behavior of remote UAs, interoperability issues, and other
      bad surprises."



Nits:

Sect. 9, p14, RFC3515:

     2nd sentence: "Its" -> "It is"




_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 04 11:13:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ioi6O-000165-Nd; Sun, 04 Nov 2007 11:13:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ioi6N-00015n-PH
	for sip-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 11:13:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioi6N-00015f-Fh
	for sip@ietf.org; Sun, 04 Nov 2007 11:13:31 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ioi6L-00028k-Ut
	for sip@ietf.org; Sun, 04 Nov 2007 11:13:31 -0500
Received: (qmail invoked by alias); 04 Nov 2007 16:13:28 -0000
Received: from p549869EC.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.105.236]
	by mail.gmx.net (mp018) with SMTP; 04 Nov 2007 17:13:28 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+Fu0AYp/mFu8DOxnfbpM8aN2TPoMjHbs+/VmUwdI
	gB9MmT4msY+dY2
Message-ID: <472DEFAE.2080107@gmx.net>
Date: Sun, 04 Nov 2007 17:13:34 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "DRAGE, Keith \(Keith\)" 
Subject: Re: [Sip] Resource Priority Header namespaces
References: <20071101182313.6B6597DA8@bender.tigertech.net>
	<5D1A7985295922448D5550C94DE2918001886BD9@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE2918001886BD9@DEEXC1U01.de.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: sip@ietf.org, "Joel M. Halpern" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

This document seems to have its origin in a single or a small number of 
customers.

 From the text in the draft it seems the priority values for each 
namespace are used totally independently. I wonder whether someone has 
actually thought what this means for a real system when priority values 
of 50+ namespaces are used together.
Does anyone know how the use cases are going to look like?

Ciao
Hannes

DRAGE, Keith (Keith) wrote:
> I will leave James to respond to this as it impacts the draft, but
> assuming we reach that stage, I will remember this point for the PROTO
> writeup.
>
> Regards
>
> Keith 
>
>   
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] 
>> Sent: Thursday, November 01, 2007 6:23 PM
>> To: sip@ietf.org
>> Subject: [Sip] Resource Priority Header namespaces
>>
>> I read over the draft in last call requesting new RPH 
>> namespace assignments.
>> In and of itself it looks non-objectionable.  While I don't 
>> understand the need for that many name spaces, or those 
>> specific values, my first reaction is to say "okay" anyway.
>>
>> However, I went and looked at RFC4412, which defines the 
>> header namespace registration.
>> That RFC calls for a standard track RFC for defining namespaces.
>> And the text is quite explicit that one should not create a 
>> multiplicity of namespaces, but should try to use existing 
>> spaces first.
>>
>> So, unless we want to check RFC4412, it seems that the 
>> request for 32 namespaces in
>> 	draft-ietf-sip-rph-new-namespaces-00.txt
>> really needs more explanation / justification.
>>
>> Yours,
>> Joel M. Halpern
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>     
>
>
> _______________________________________________
> 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
>   



_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 04 12:17:36 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ioj6I-00022V-3U; Sun, 04 Nov 2007 12:17:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ioj6G-00020k-Q4
	for sip-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 12:17:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioj6G-0001zv-Df
	for sip@ietf.org; Sun, 04 Nov 2007 12:17:28 -0500
Received: from repmmg02.bea.com ([66.248.192.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ioj6F-0006Pr-Nr
	for sip@ietf.org; Sun, 04 Nov 2007 12:17:28 -0500
Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72])
	by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id
	lA4HHQkE003614; Sun, 4 Nov 2007 09:17:26 -0800
Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98])
	by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id
	lA4HHO9R003336; Sun, 4 Nov 2007 09:17:24 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)
Date: Sun, 4 Nov 2007 09:17:19 -0800
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DTMF timing (was Re: [Sip] INFO ...)
Thread-Index: AcgczZpKg16KWcQMSX65Iplw2Bm2XwABIPmwAIzYJGA=
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com><63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com><9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com><20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com><472505F8.5090401@nostrum.com><8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com><47255D1A.30206@nostrum.com><472756C2.1010205@nostrum.com>	<47277440.3050707@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net><6A5ECF04-A5D5-494A-8542-79993361AC05@softarmor.com><006d01c81cb1$0ba65b60$22f31220$@com><0D4E483A0E6E0A46861409E5D6C2011C0E5A3D@sea02-mxc01.citel.com><1C0CC329-89F4-4A07-A163-8C893A329E96@softarmor.com>
	
From: "Eric Burger" 
To: "Dean Willis" 
x-BEA-PMX-Instructions: AV
x-BEA-MM: Internal-To-External
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Review KPML and the Application Interaction Framework.

RTP (RFC 4733/2833) is for the *timely*, _unreliable_, delivery of
TONES.

SIP (RFC 4730) is for the _reliable_, *soon-enough*, delivery of
SIGNALING.

Please don't confuse signaling with tones.  Sometimes, we do use tones
for signaling.  That was from the days of analog transmission of user
input.  We have moved beyond that, one hopes...
 

-----Original Message-----
From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] 
Sent: Thursday, November 01, 2007 6:15 PM
To: Dean Willis; Michael Procter
Cc: sip@ietf.org
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
>
> On Nov 1, 2007, at 3:20 PM, Michael Procter wrote:
>
> > Whilst having the RFC2833 arriving in the timestamped audio stream 
> > is certainly beneficial, it is also true to say that the RTP stream 
> > generally travels quicker than signalling.  One of the main reasons 
> > for this is that the RTP usually travels point-to-point, whilst the 
> > signalling path often includes a couple of proxies.  Even if the 
> > proxies process the messages in zero time (which they don't), there 
> > are still multiple network hops introduced as a consequence.
> > Additional delays incurred by the proxies/other intermediate 
> > signalling elements swiftly add up too.
>
> I agree that this sounds correct in theory.
>
> What I'm wondering about is those deployments that use media-path 
> control elements (aka SBCs that police media) and/or decoupled media 
> and signaling processors.
>
> I suspect that that SBCs slow down RTP about as much as they slow down

> SIP. COuld be more, could be less -- I don't really know.

Uh, nope.  There are such things as software-based SBCs, for enterprises
and such, but most of the provider ones use dedicated hardware to handle
RTP/RTCP. (using NPs/ASICS/whatever)  It's not discernibly slower than a
router, depending on the vendor.


> We don't really use DTMF much between "traditional SIP endpoints" -- 
> the kind of all-in-one device that does everything in a dedicated 
> general-purpose processor. It seems that in practice we use it more 
> frequently in transactions that involve large-scale decoupled gateways

> and decoupled media servers, at least at one end of the call. I 
> wouldn't be surprised to see the practical reality collide with the 
> theory around 2833.

Yeah, I buy that.
My worry though isn't about speed.  It's about use.  One of the obvious
use cases for signaling-based DTMF is it follows the signaling, and the
media doesn't need to.  For an info-dtmf model, that essentially means
something in the middle that wants dtmf (an app-server, for example) has
to act as a b2bua for signaling, but doesn't need to be in the media
path.  So even if both info-dtmf and 2833 get negotiated, you'd want to
use the info-dtmf.  Although I guess if the app-server needed it that
way, it would have to have removed 2833 from SDP (yuck), 'cause
otherwise as a UA it's essentially lying by offering 2833.

-hadriel



_______________________________________________
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

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 04 12:21:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IojAH-0005Sc-9n; Sun, 04 Nov 2007 12:21:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IojAF-0005RN-TE
	for sip-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 12:21:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IojAF-0005RC-IR
	for sip@ietf.org; Sun, 04 Nov 2007 12:21:35 -0500
Received: from repmmg02.bea.com ([66.248.192.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IojAF-0006YR-3n
	for sip@ietf.org; Sun, 04 Nov 2007 12:21:35 -0500
Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72])
	by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id
	lA4HLR15010511; Sun, 4 Nov 2007 09:21:27 -0800
Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98])
	by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id
	lA4HLPhS009746; Sun, 4 Nov 2007 09:21:26 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: RE: [Sip] INFO: A recap,
	sense of consensus and a proposal for direction.
Date: Sun, 4 Nov 2007 09:21:20 -0800
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] INFO: A recap,
	sense of consensus and a proposal for direction.
Thread-Index: AcgbIY00oS2TP5mKSYi+xw3th4CDlAAHhxNhAPHWPgA=
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>		<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>	<472505F8.5090401@nostrum.com>	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>	<47255D1A.30206@nostrum.com>	<472756C2.1010205@nostrum.com>
	<47277440.3050707@cisco.com>
	
From: "Eric Burger" 
To: "Christer Holmberg" 
x-BEA-PMX-Instructions: AV
x-BEA-MM: Internal-To-External
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Wasn't this why we were going to publish the perils of INFO? 

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
Sent: Tuesday, October 30, 2007 6:02 PM
[snip]
I also know that other SDOs are looking into using INFO for certain
things, so I think it would be really good to define a proper mechanism
before they also start to use INFO as it's used today (with all the
problems people have listed).
[snip]

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 05 10:15:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ip3fx-00030P-95; Mon, 05 Nov 2007 10:15:41 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ip3fw-0002zF-24
	for sip-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 10:15:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3fv-0002z1-Og
	for sip@ietf.org; Mon, 05 Nov 2007 10:15:39 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip3ft-0000vS-TQ
	for sip@ietf.org; Mon, 05 Nov 2007 10:15:39 -0500
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly27f.srv.mailcontrol.com (MailControl) with ESMTP id
	lA5FFalq011765 for ; Mon, 5 Nov 2007 15:15:36 GMT
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 5 Nov 2007 15:14:20 +0000
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] namespaces in RFC 4411,
	4412 and draft-ietf-sip-rph-new-namespaces-00
Date: Mon, 5 Nov 2007 15:13:44 -0000
Message-ID: <680808427CF931459462C3D78CB5EC607C6863@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] namespaces in RFC 4411,
	4412 and draft-ietf-sip-rph-new-namespaces-00
Thread-Index: Acge/eqrZJnyHBzIRGCduFxXB59HMQAwCWGw
From: "Attila Sipos" 
To: 
X-OriginalArrivalTime: 05 Nov 2007 15:14:20.0890 (UTC)
	FILETIME=[8A8E7BA0:01C81FBE]
X-Scanned-By: MailControl A-08-00-00 (www.mailcontrol.com) on 10.70.0.137
X-Spam-Score: -0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

I have tried asking these questions on SIP-implementors
but not getting any responses.  Are these silly questions...?




-----Original Message-----
From: sip-implementors-bounces@lists.cs.columbia.edu
[mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of
Attila Sipos
Sent: 01 November 2007 08:52
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] namespaces in RFC 4411,4412 and
draft-ietf-sip-rph-new-namespaces-00



Are namespaces just a way to group together different users across
different DNS domains?

What if a.com is using namespaces "dsn-000000" to "dsn-000009"
and b.com is using the same namespaces?
Then if A@a.com calls B@b.com, wouldn't the namespaces interfere?


What looks after or checks the namespaces?
Is it that a proxy knows what everyone's namespace should be?
So if someone wants to do "UA Preemption" and tries to use a resource
priority level higher than they should have, then will the domain's
proxy downgrade it back to the correct permitted level?


Regards,

Attila


_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 05 10:24:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ip3ok-00037n-TN; Mon, 05 Nov 2007 10:24:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ip3oj-0002sV-MM
	for sip-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 10:24:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3oj-0002nx-AO
	for sip@ietf.org; Mon, 05 Nov 2007 10:24:45 -0500
Received: from demumfd002.nsn-inter.net ([217.115.75.234])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip3oh-00017E-Od
	for sip@ietf.org; Mon, 05 Nov 2007 10:24:45 -0500
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56])
	by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id
	lA5FOevV005692
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 5 Nov 2007 16:24:42 +0100
Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35])
	by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP
	id lA5FOelX017991; Mon, 5 Nov 2007 16:24:40 +0100
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by
	demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 5 Nov 2007 16:24:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Sip] namespaces in RFC 4411,
	4412 and draft-ietf-sip-rph-new-namespaces-00
Date: Mon, 5 Nov 2007 16:24:39 +0100
Message-ID: <5FB585F183235B42A9E70095055136FB4C515E@DEMUEXC012.nsn-intra.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC607C6863@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] namespaces in RFC 4411,
	4412 and draft-ietf-sip-rph-new-namespaces-00
Thread-Index: Acge/eqrZJnyHBzIRGCduFxXB59HMQAwCWGwAABr3VA=
References: <680808427CF931459462C3D78CB5EC607C6863@EXVS02.nasstar-t1.net>
From: "Tschofenig, Hannes (NSN - DE/Munich)" 
To: "ext Attila Sipos" , 
X-OriginalArrivalTime: 05 Nov 2007 15:24:40.0862 (UTC)
	FILETIME=[FC16B3E0:01C81FBF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Theoreticallly, there is no relationship between namespaces and domains. =


However, it is possible that different domains use different namespaces. =
When a SIP message travels along different providers then one would have =
to map the different priorities someone ....

Ciao
Hannes

> -----Urspr=FCngliche Nachricht-----
> Von: ext Attila Sipos [mailto:attila.sipos@vegastream.com]=20
> Gesendet: Montag, 5. November 2007 16:14
> An: sip@ietf.org
> Betreff: RE: [Sip] namespaces in RFC 4411,4412 and=20
> draft-ietf-sip-rph-new-namespaces-00
>=20
>=20
> Hi,
>=20
> I have tried asking these questions on SIP-implementors
> but not getting any responses.  Are these silly questions...?
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: sip-implementors-bounces@lists.cs.columbia.edu
> [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of
> Attila Sipos
> Sent: 01 November 2007 08:52
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] namespaces in RFC 4411,4412 and
> draft-ietf-sip-rph-new-namespaces-00
>=20
>=20
>=20
> Are namespaces just a way to group together different users across
> different DNS domains?
>=20
> What if a.com is using namespaces "dsn-000000" to "dsn-000009"
> and b.com is using the same namespaces?
> Then if A@a.com calls B@b.com, wouldn't the namespaces interfere?
>=20
>=20
> What looks after or checks the namespaces?
> Is it that a proxy knows what everyone's namespace should be?
> So if someone wants to do "UA Preemption" and tries to use a resource
> priority level higher than they should have, then will the domain's
> proxy downgrade it back to the correct permitted level?
>=20
>=20
> Regards,
>=20
> Attila
>=20
>=20
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>=20
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>=20
>=20
> _______________________________________________
> 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
>=20


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 05 11:36:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ip4vo-00017o-Af; Mon, 05 Nov 2007 11:36:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ip4vm-00014i-Km
	for sip-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 11:36:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip4vm-00013k-AZ
	for sip@ietf.org; Mon, 05 Nov 2007 11:36:06 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip4vl-0002cG-1m
	for sip@ietf.org; Mon, 05 Nov 2007 11:36:06 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lA5GZYqm018866;
	Mon, 5 Nov 2007 10:36:04 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 5 Nov 2007 10:36:03 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 5 Nov 2007 17:36:00 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] namespaces in RFC 4411,
	4412 and draft-ietf-sip-rph-new-namespaces-00
Date: Mon, 5 Nov 2007 17:36:00 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918001886FC0@DEEXC1U01.de.lucent.com>
In-Reply-To: <680808427CF931459462C3D78CB5EC607C6863@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] namespaces in RFC 4411,
	4412 and draft-ietf-sip-rph-new-namespaces-00
Thread-Index: Acge/eqrZJnyHBzIRGCduFxXB59HMQAwCWGwAAGfeGA=
References: <680808427CF931459462C3D78CB5EC607C6863@EXVS02.nasstar-t1.net>
From: "DRAGE, Keith \(Keith\)" 
To: "Attila Sipos" , 
X-OriginalArrivalTime: 05 Nov 2007 16:36:00.0668 (UTC)
	FILETIME=[F30D45C0:01C81FC9]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I don't think it is explicitly covered in the RFC 4412, but there are
clear pointers to what needs to be done.

There needs to be agreement between the administrative domains as to
what is passed across the boundaries between the adminstrative domains.
This could take a number of forms:

-	the header is not passed at all because there is no agreement
between the administrations. Any priority handling only exists in the
source domain.
-	the header is passed and the two administrations agree to use
the same namespace in a compatible fashion.
-	by agreement, different namespaces are conveyed by the two
adminstrations, and two Resource-Priority headers are included that are
each used by the owning administration.=20

Regards

Keith

> -----Original Message-----
> From: Attila Sipos [mailto:attila.sipos@vegastream.com]=20
> Sent: Monday, November 05, 2007 3:14 PM
> To: sip@ietf.org
> Subject: RE: [Sip] namespaces in RFC 4411,4412 and=20
> draft-ietf-sip-rph-new-namespaces-00
>=20
>=20
> Hi,
>=20
> I have tried asking these questions on SIP-implementors but=20
> not getting any responses.  Are these silly questions...?
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: sip-implementors-bounces@lists.cs.columbia.edu
> [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On=20
> Behalf Of Attila Sipos
> Sent: 01 November 2007 08:52
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] namespaces in RFC 4411,4412 and=20
> draft-ietf-sip-rph-new-namespaces-00
>=20
>=20
>=20
> Are namespaces just a way to group together different users=20
> across different DNS domains?
>=20
> What if a.com is using namespaces "dsn-000000" to "dsn-000009"
> and b.com is using the same namespaces?
> Then if A@a.com calls B@b.com, wouldn't the namespaces interfere?
>=20
>=20
> What looks after or checks the namespaces?
> Is it that a proxy knows what everyone's namespace should be?
> So if someone wants to do "UA Preemption" and tries to use a=20
> resource priority level higher than they should have, then=20
> will the domain's proxy downgrade it back to the correct=20
> permitted level?
>=20
>=20
> Regards,
>=20
> Attila
>=20
>=20
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>=20
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 05 15:10:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ip8Ge-0005Vz-R8; Mon, 05 Nov 2007 15:09:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ip8Gd-0005UT-QV
	for sip-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 15:09:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip8Gd-0005UL-GP
	for sip@ietf.org; Mon, 05 Nov 2007 15:09:51 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip8Gc-0000l9-2O
	for sip@ietf.org; Mon, 05 Nov 2007 15:09:51 -0500
X-IronPort-AV: E=Sophos;i="4.21,374,1188802800"; d="scan'208";a="14659243"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-4.cisco.com with ESMTP; 05 Nov 2007 12:09:50 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA5K9mSQ003933; 
	Mon, 5 Nov 2007 12:09:48 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA5K9gZU022720;
	Mon, 5 Nov 2007 20:09:46 GMT
From: "Dan Wing" 
To: "'Richard Barnes'" , "'IETF SIP List'" 
References: <47080AF8.9060303@bbn.com>
Date: Mon, 5 Nov 2007 12:09:41 -0800
Message-ID: <033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgIZ6+N9Sbh2H5aQmCLtTvCNRhDCwXesavg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
In-Reply-To: <47080AF8.9060303@bbn.com>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8262; t=1194293388;
	x=1195157388; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20Review=20of=20draft-ietf-sip-media-security-requireme
	nts-00 |Sender:=20;
	bh=pWG7X+u2/yN+GF3VtkNt9AbKzpkmauel6ut9/GYy4vQ=;
	b=mJU+c5UR2XtUfGcB0YFpnSMLsvfM7b74z4B6F3OE8r6aN4urqDC6XKzrgm6f0k43d0t8h5NO
	chrQhDRVLqDAAjmO+bXc1UmExZEJT3lTRgWAG00jdWNmFPyCVY2phWeubFWzNco/+ouYfKRxnm
	5XEgEr7pMBTtJ6dmqso+1lX+A=;
Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e
Cc: 'Francois Audet' , "'Fries,
	Steffen'" 
Subject: [Sip] RE: Review of draft-ietf-sip-media-security-requirements-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com] 
> Sent: Saturday, October 06, 2007 3:24 PM
> To: IETF SIP List; 'Dan Wing'; Hannes Tschofenig; Fries, 
> Steffen; Francois Audet
> Subject: Review of draft-ietf-sip-media-security-requirements-00
> 
> High-level comments are in the body of this message.  More detailed 
> comments in the attached RTF file.

Thanks, and please accept my apologies for my delay.

I believe the only outstanding issues are around requirements R23-R25;
see below for details.

> --Richard
> 
> -------------------------------------------------------
> Document: draft-ietf-sip-media-security-requirements-00
> Reviewer: Richard Barnes, BBN
> Review Date: 06 September 2007
> -------------------------------------------------------
> 
> 1. As a document proposing requirements for a security protocol,
>    this document needs more discussion of the system being protected
>    and the level of protection that the desired protocol is to
>    support. Section 5 is a good start on this, and it should be
>    moved forward to be just after the Terminology section.

I have moved this section in -01.


> 2. I think the fundamental security requirement that you're driving
>    at is that the protocol should have a mode of operation in which
>    an attacker must mount active attacks on BOTH the signaling and
>    media path in order to gain access to the keys being negotiated
>    by the protocol, and that even in this case, the attack should be
>    detectable by the endpoints.  This is essentially what's being
>    encoded in requirements R1, R2, and R17, but this should be made
>    clearer in these requirements, and in the security analysis
>    section (i.e., Section 5).

R17 in -00 said:

	The media security key management protocol SHOULD require 
	the adversary to have access to the data as well as the 
	signaling path for a successful attack to be launched.  An 
	adversary that is located only along the data or only along 
	the signaling path MUST NOT be able to successfully mount 
	an attack.  A successful attack refers to the ability for 
	the adversary to obtain keying material to decrypt the SRTP 
	encrypted media traffic.

which I think is sufficiently clear on this point.  Let me know if
you still feel it should be repeated elsewhere.


> 3. Requirements R23, R24, R25 are inappropriate for this document,
>    in that they conflict directly with the security requirements
>    (R1, R2, R17).  A well-designed key-exchange protocol *should* be
>    able to detect a middle-man, authorized or not.  Lawful intercept
>    should be handled outside of the key management protocol, as in
>    draft-wing-sipping-srtp-key.

For reference in this response, R23, R24, and R25 are:

  R23:   The media security key management protocol SHOULD support
          recording of decrypted media.

          Media recording may be realized by an intermediate nodes.  An
          example for those intermediate nodes are devices, which could
          be used in banking applications or for quality monitoring in
          call centers.  Here, it must be ensured, that the media
          security is ensured by the intermediate nodes on the
          connections to the involved endpoints as originally
          negotiated.  The endpoints need to be informed that there is
          an intermediate device and need to cooperate.  A solution
          approach for this is described in [I-D.wing-sipping-srtp-key].

R23 refers only to recording of media.  This is necessary in many 
business environments such as banks, stock brokers, catalog ordering call
centers, and so on.  This is a requirement for many businesses.  It
is not yet clear if draft-wing-sipping-srtp-key (or something like it) 
meets requirement R23.

   R24:   The media security key management protocol SHOULD NOT allow
          end users to determine whether their end-to-end interaction is
          subject to lawful interception.

I agree R24 refers to lawful intercept.  This is a requirement from
other SDOs that need to provide lawful intercept with their solutions.

Another email on R24 lawful intercept will be forthcoming shortly.

   R25:   The media security key management protocol MUST work when
          there are intermediate nodes, terminating or processing media,
          between the end points."

R25 reference to 'intermediate nodes' is to transcoders and SBCs which
handle signaling and media traffic.  It seems important that any keying
mechanism work with such intermediate nodes, as those intermediate nodes
are common on many SIP networks.


> 4. This document needs several more terms defined in the
>    Terminology. The three I spotted were: "media path", "signaling
>    path", and "perfect forward secrecy".  PFS is already defined in
>    the requirements; this text should just be moved to the
>    Terminology section.

Added to -01, thanks.


> 5. If we intend this document to move quickly toward RFC status, it
>    seems like the evaluation appendices will have to be deleted, or
>    at least the parts of them that refer to protocols that are not
>    RFCs or not on their way.

This evaluation captures the protocols under consideration at the 
time that this evaluation occurred.  It is valuable to describe why
some protocols were not selected.  If there are specific protocols
you'd like deleted, please enumerate them; each seems to have its
place (although I do agree several are minor tweaks on other 
protocols).


> 6. Section 3.1 and 3.3 do not appear to be directly related to the
>    requirements as stated.  They should be moved to sections B.2 and
>    B.3, respectively (like the text on SSRCs and ROCs).

Section 3.1 is "Clipping Media Before Signaling Answer" and 
refers to requirement R5:

   R5:    The media security key management protocol SHOULD avoid
          clipping media before SDP answer without requiring PRACK
          [RFC3262].

Section 3.2 is "Retargeting and Forking" and refers to requirements
R1, R2, and R3:

   R1:    The media security key management protocol MUST support
          forking and retargeting when all endpoints are willing to use
          SRTP without causing the call setup to fail, unless the
          execution of the authentication and key exchange protocol
          leads to a failure (e.g., an unsuccessful authentication
          attempt).

   R2:    Even when some end points of a forked or retargeted call are
          incapable of using SRTP, the key management protocol MUST
          allow the establishment of SRTP associations with SRTP-capable
          endpoints and / or RTP associations with non-SRTP-capable
          endpoints.

   R3:    The media security key management protocol MUST create
          distinct, independent cryptographic contexts for each endpoint
          in a forked session.

In -01, I have added text to the beginning of 3.1 and 3.2 to make this
clearer.


> 7. Sections C.1 and C.3 should be deleted.  Section C.1. is
>    predicated on the notion that protocols require a PKI to be used,
>    when in reality (as was discussed extensively on rtpsec), any
>    protocol that can be used with a PKI can be used with self-signed
>    certificates if both endpoints are willing.  Section C.3. tries
>    to evaluate whether solutions can do best-effort security, while
>    ignoring the work that has been done on SDP capability
>    negotiation.

Section C.3 ("Best Effort Encryption") has been updated to 
discuss SDP Capability Negotiation; previously it only said:

     "Note: With the ongoing efforts in SDP Capability Negotiation
      [I-D.ietf-mmusic-sdp-capability-negotiation], the conclusions
      reached in this section may no longer be accurate."

which I agree was deficient.


> *. (nit) Throughout, the word "keying" is used to mean the process of 
> key negotiation/exchange or key management.  It should be replaced by 
> those terms as appropriate.

Changed in -01.


Thanks to Steffen for making a significant number of these changes to
the XML.

-d


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 05 17:04:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpA3L-0007LL-CD; Mon, 05 Nov 2007 17:04:15 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpA3J-0007KF-FK
	for sip-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 17:04:13 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpA3J-0007K7-3x
	for sip@ietf.org; Mon, 05 Nov 2007 17:04:13 -0500
Received: from qmta05.westchester.pa.mail.comcast.net ([76.96.62.48])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpA3I-0005w9-Lk
	for sip@ietf.org; Mon, 05 Nov 2007 17:04:12 -0500
Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11])
	by QMTA05.westchester.pa.mail.comcast.net with smtp
	id 99L71Y0080EZKEL0004J00; Mon, 05 Nov 2007 22:04:12 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA01.westchester.pa.mail.comcast.net with comcast
	id 9A4B1Y00K0umElk0000000; Mon, 05 Nov 2007 22:04:12 +0000
X-Authority-Analysis: v=1.0 c=1 a=mLbkgN8gmkxEsmXQtfYA:9
	a=fimCFBeWoCRH2b9VFyoA:7 a=LsxlQw_QxqmMMc8l_XYZYS61i0AA:4
	a=0a1BeuFvlBEA:10 a=tlK-OJsYmR4A:10 a=lNxDZue6IIMA:10
	a=CDGxlOTZlHAA:10 a=GDpXhxC-ij4A:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lA5M4BSV023216
	for ; Mon, 5 Nov 2007 17:04:11 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lA5M4Bta023212;
	Mon, 5 Nov 2007 17:04:11 -0500
Date: Mon, 5 Nov 2007 17:04:11 -0500
Message-Id: <200711052204.lA5M4Bta023212@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <680808427CF931459462C3D78CB5EC607C6863@EXVS02.nasstar-t1.net>
	(attila.sipos@vegastream.com)
Subject: Re: [Sip] namespaces in RFC 4411,
	4412 and draft-ietf-sip-rph-new-namespaces-00
References: <680808427CF931459462C3D78CB5EC607C6863@EXVS02.nasstar-t1.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Attila Sipos" 

   Are namespaces just a way to group together different users across
   different DNS domains?

   What if a.com is using namespaces "dsn-000000" to "dsn-000009"
   and b.com is using the same namespaces?
   Then if A@a.com calls B@b.com, wouldn't the namespaces interfere?

   What looks after or checks the namespaces?
   Is it that a proxy knows what everyone's namespace should be?
   So if someone wants to do "UA Preemption" and tries to use a resource
   priority level higher than they should have, then will the domain's
   proxy downgrade it back to the correct permitted level?

The primary thing is that resource-priority namespaces are registered
with IANA (RFC 4412, section 3.1).

Within any administrative domain, if it processes resource-priorities
at all, it will generally sanitize any incoming SIP messages to match
the policy of the domain.  As a default, this means that it is going
to strip any resource-priority identification.  Above that, it may
respect resource-priority identification if the domain has a suitable
working relationsip with the terminal or domain from which the message
is entering -- but that relationship will explicitly or implicitly
define how the resource-priority identifications will be preserved or
transformed at the boundary.

This is pretty much how *any* priority-identification system has to be
operated.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 05 17:27:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpAPV-0000nC-Mj; Mon, 05 Nov 2007 17:27:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpAPU-0000mu-D3
	for sip-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 17:27:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpAPU-0000lS-0u
	for sip@ietf.org; Mon, 05 Nov 2007 17:27:08 -0500
Received: from mail130.messagelabs.com ([216.82.250.163])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpAPS-0006kP-Ry
	for sip@ietf.org; Mon, 05 Nov 2007 17:27:07 -0500
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-3.tower-130.messagelabs.com!1194301622!5745560!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [20.137.52.151]
Received: (qmail 29402 invoked from network); 5 Nov 2007 22:27:03 -0000
Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151)
	by server-3.tower-130.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Nov 2007 22:27:03 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	lA5MRSDI002438
	for ; Mon, 5 Nov 2007 17:27:28 -0500 (EST)
In-Reply-To: <200711052204.lA5M4Bta023212@dragon.ariadne.com>
To: Dale.Worley@comcast.net
Subject: Re: [Sip] namespaces in RFC 4411,	4412 and
	draft-ietf-sip-rph-new-namespaces-00
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn 
Message-ID: 
Date: Mon, 5 Nov 2007 17:26:58 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF180|March 29, 2007) at 11/05/2007 05:25:30 PM,
	Serialize complete at 11/05/2007 05:25:30 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0521232520=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0521232520==
Content-Type: multipart/alternative;
	boundary="=_alternative 007B51618525738A_="

This is a multipart message in MIME format.
--=_alternative 007B51618525738A_=
Content-Type: text/plain; charset="US-ASCII"

In line

Janet

Dale.Worley@comcast.net wrote on 11/05/2007 05:04:11 PM:

>    From: "Attila Sipos" 
> 
>    Are namespaces just a way to group together different users across
>    different DNS domains?
> 
>    What if a.com is using namespaces "dsn-000000" to "dsn-000009"
>    and b.com is using the same namespaces?
>    Then if A@a.com calls B@b.com, wouldn't the namespaces interfere?
> 
>    What looks after or checks the namespaces?
>    Is it that a proxy knows what everyone's namespace should be?
>    So if someone wants to do "UA Preemption" and tries to use a resource
>    priority level higher than they should have, then will the domain's
>    proxy downgrade it back to the correct permitted level?
> 
> The primary thing is that resource-priority namespaces are registered
> with IANA (RFC 4412, section 3.1).
> 
> Within any administrative domain, if it processes resource-priorities
> at all, it will generally sanitize any incoming SIP messages to match
> the policy of the domain.  As a default, this means that it is going
> to strip any resource-priority identification.  Above that, it may
> respect resource-priority identification if the domain has a suitable
> working relationsip with the terminal or domain from which the message
> is entering -- but that relationship will explicitly or implicitly
> define how the resource-priority identifications will be preserved or
> transformed at the boundary.

I am not so sure about that ( the stripping as a default). 

I would think that (consistent with RFC 4412 
and RFC 3261)the default (when the edge device at a new domain receives an 

RPH with an unrecognized namespace) would be to pass and ignore the 
unrecognized name space. 

This is described in section 4.6.2 of RFC 4412:
"4.6.2.  No Known Namespace or Priority Value

   If an RP actor does not understand any of the resource values in the
   request, the treatment depends on the presence of the 'Require'
   'resource-priority' option tag:

   1.  Without the option tag, the RP actor treats the request as if it
       contained no 'Resource-Priority' header field and processes it
       with default priority.  Resource values that are not understood
       MUST NOT be modified or deleted.

   2.  With the option tag, it MUST reject the request with a 417
       (Unknown Resource-Priority) response code.

   Making case (1) the default is necessary since otherwise there would
   be no way to successfully complete any calls in the case where a
   proxy on the way to the UAS shares no common namespaces with the UAC,
   but the UAC and UAS do have such a namespace in common.

   In general, as noted, a SIP request can contain more than one
   'Resource-Priority' header field.  This is necessary if a request
   needs to traverse different administrative domains, each with its own
   set of valid resource values.  For example, the ETS namespace might
   be enabled for United States government networks that also support
   the DSN and/or DRSN namespaces for most individuals in those domains."

Your suggested behavior would seem to violate this.

> 
> This is pretty much how *any* priority-identification system has to be
> operated.
> 
> Dale
> 
> 
> _______________________________________________
> 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

--=_alternative 007B51618525738A_=
Content-Type: text/html; charset="US-ASCII"



In line



Janet



Dale.Worley@comcast.net wrote on 11/05/2007 05:04:11
PM:



>    From: "Attila Sipos" <attila.sipos@vegastream.com>

> 

>    Are namespaces just a way to group together different
users across

>    different DNS domains?

> 

>    What if a.com is using namespaces "dsn-000000"
to "dsn-000009"

>    and b.com is using the same namespaces?

>    Then if A@a.com calls B@b.com, wouldn't the namespaces
interfere?

> 

>    What looks after or checks the namespaces?

>    Is it that a proxy knows what everyone's namespace should
be?

>    So if someone wants to do "UA Preemption" and
tries to use a resource

>    priority level higher than they should have, then will
the domain's

>    proxy downgrade it back to the correct permitted level?

> 

> The primary thing is that resource-priority namespaces are registered

> with IANA (RFC 4412, section 3.1).

> 

> Within any administrative domain, if it processes resource-priorities

> at all, it will generally sanitize any incoming SIP messages to match

> the policy of the domain.  As a default, this means that it is
going

> to strip any resource-priority identification.  Above that, it
may

> respect resource-priority identification if the domain has a suitable

> working relationsip with the terminal or domain from which the message

> is entering -- but that relationship will explicitly or implicitly

> define how the resource-priority identifications will be preserved
or

> transformed at the boundary.



I am not so sure about that ( the stripping as a default).
 



I would think that (consistent with RFC 4412 

and RFC 3261)the default (when the edge device at
a new domain receives an 

RPH with an unrecognized namespace) would be to pass
and ignore the 

unrecognized name space. 



This is described in section 4.6.2 of RFC 4412:

"4.6.2.  No Known Namespace or Priority
Value



   If an RP actor does not understand any
of the resource values in the

   request, the treatment depends on the
presence of the 'Require'

   'resource-priority' option tag:



   1.  Without the option tag, the
RP actor treats the request as if it

       contained no 'Resource-Priority'
header field and processes it

       with default priority.
 Resource values that are not understood

       MUST NOT be modified or
deleted.



   2.  With the option tag, it MUST
reject the request with a 417

       (Unknown Resource-Priority)
response code.



   Making case (1) the default is necessary
since otherwise there would

   be no way to successfully complete any
calls in the case where a

   proxy on the way to the UAS shares no
common namespaces with the UAC,

   but the UAC and UAS do have such a namespace
in common.



   In general, as noted, a SIP request can
contain more than one

   'Resource-Priority' header field.  This
is necessary if a request

   needs to traverse different administrative
domains, each with its own

   set of valid resource values.  For
example, the ETS namespace might

   be enabled for United States government
networks that also support

   the DSN and/or DRSN namespaces for most
individuals in those domains."



Your suggested behavior would seem to violate this.



> 

> This is pretty much how *any* priority-identification system has to
be

> operated.

> 

> Dale

> 

> 

> _______________________________________________

> 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


--=_alternative 007B51618525738A_=--



--===============0521232520==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0521232520==--





From sip-bounces@ietf.org Mon Nov 05 18:10:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpB4x-0006rY-4p; Mon, 05 Nov 2007 18:09:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpB4w-0006rO-Iz
	for sip-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 18:09:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpB4w-0006rG-9I
	for sip@ietf.org; Mon, 05 Nov 2007 18:09:58 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpB4t-0007fI-F0
	for sip@ietf.org; Mon, 05 Nov 2007 18:09:58 -0500
X-IronPort-AV: E=Sophos;i="4.21,374,1188802800"; d="scan'208";a="247126087"
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 05 Nov 2007 15:09:55 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lA5N9ssv025350; 
	Mon, 5 Nov 2007 15:09:54 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lA5N9o8Y009829;
	Mon, 5 Nov 2007 23:09:54 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 5 Nov 2007 15:09:54 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.146.111]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 5 Nov 2007 15:09:54 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 05 Nov 2007 17:09:49 -0600
To: Janet P Gunn , Dale.Worley@comcast.net
From: "James M. Polk" 
Subject: Re: [Sip] namespaces in RFC 4411,	4412 and
	draft-ietf-sip-rph-new-namespaces-00
In-Reply-To: 
References: <200711052204.lA5M4Bta023212@dragon.ariadne.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 05 Nov 2007 23:09:54.0286 (UTC)
	FILETIME=[F9C930E0:01C82000]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4706; t=1194304194;
	x=1195168194; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20[Sip]=20namespaces=20in=20RFC=204411,
	=094412=20and=0A =20=20draft-ietf-sip-rph-new-namespaces-00
	|Sender:=20; bh=thwGF1hwoi/hGF++/d4vR+HHo8v3YxXOa+yfnIt9Abw=;
	b=pi1JLMIUA7PGpgUtvL4kWQtYBTKGCqzHYqknkDfrQ87sjDc7jRgFF68A0x7CMgudoXLl5zE0
	9Cqf8Dibxxbc+njERvbuBYVmHqhcFQnLywV7rZfrN3XJo1CAa9hPv9zE;
Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Janet

I think Dale is pointing out a common practice wrt cross-boundary 
priority indications.  What you want, and why this is in RFC 4412, is 
a special case - one in which adjacent SPs (or domains) agree the 
same marking means the same across these boundaries, and that 
existing indications, regardless of whether they are acted upon, 
remain in the message at these boundary crossing points.

I don't believe where each of you are coming from are inconsistent to 
the other.

Time will tell how well this mechanism works where more than one 
domain is involved.

James

At 04:26 PM 11/5/2007, Janet P Gunn wrote:

>In line
>
>Janet
>
>Dale.Worley@comcast.net wrote on 11/05/2007 05:04:11 PM:
>
> >    From: "Attila Sipos" 
> >
> >    Are namespaces just a way to group together different users across
> >    different DNS domains?
> >
> >    What if a.com is using namespaces "dsn-000000" to "dsn-000009"
> >    and b.com is using the same namespaces?
> >    Then if A@a.com calls B@b.com, wouldn't the namespaces interfere?
> >
> >    What looks after or checks the namespaces?
> >    Is it that a proxy knows what everyone's namespace should be?
> >    So if someone wants to do "UA Preemption" and tries to use a resource
> >    priority level higher than they should have, then will the domain's
> >    proxy downgrade it back to the correct permitted level?
> >
> > The primary thing is that resource-priority namespaces are registered
> > with IANA (RFC 4412, section 3.1).
> >
> > Within any administrative domain, if it processes resource-priorities
> > at all, it will generally sanitize any incoming SIP messages to match
> > the policy of the domain.  As a default, this means that it is going
> > to strip any resource-priority identification.  Above that, it may
> > respect resource-priority identification if the domain has a suitable
> > working relationsip with the terminal or domain from which the message
> > is entering -- but that relationship will explicitly or implicitly
> > define how the resource-priority identifications will be preserved or
> > transformed at the boundary.
>
>I am not so sure about that ( the stripping as a default).
>
>I would think that (consistent with RFC 4412
>and RFC 3261)the default (when the edge device at a new domain receives an
>RPH with an unrecognized namespace) would be to pass and ignore the
>unrecognized name space.
>
>This is described in section 4.6.2 of RFC 4412:
>"4.6.2.  No Known Namespace or Priority Value
>
>    If an RP actor does not understand any of the resource values in the
>    request, the treatment depends on the presence of the 'Require'
>    'resource-priority' option tag:
>
>    1.  Without the option tag, the RP actor treats the request as if it
>        contained no 'Resource-Priority' header field and processes it
>        with default priority.  Resource values that are not understood
>        MUST NOT be modified or deleted.
>
>    2.  With the option tag, it MUST reject the request with a 417
>        (Unknown Resource-Priority) response code.
>
>    Making case (1) the default is necessary since otherwise there would
>    be no way to successfully complete any calls in the case where a
>    proxy on the way to the UAS shares no common namespaces with the UAC,
>    but the UAC and UAS do have such a namespace in common.
>
>    In general, as noted, a SIP request can contain more than one
>    'Resource-Priority' header field.  This is necessary if a request
>    needs to traverse different administrative domains, each with its own
>    set of valid resource values.  For example, the ETS namespace might
>    be enabled for United States government networks that also support
>    the DSN and/or DRSN namespaces for most individuals in those domains."
>
>Your suggested behavior would seem to violate this.
>
> >
> > This is pretty much how *any* priority-identification system has to be
> > operated.
> >
> > Dale
> >
> >
> > _______________________________________________
> > 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
>_______________________________________________
>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


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 10:26:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpQJT-0003Z4-Pu; Tue, 06 Nov 2007 10:25:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpQJR-0003YE-KA
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 10:25:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQJR-0003Y4-8k
	for sip@ietf.org; Tue, 06 Nov 2007 10:25:57 -0500
Received: from mx11.bbn.com ([128.33.0.80])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpQJQ-0002Fd-NH
	for sip@ietf.org; Tue, 06 Nov 2007 10:25:57 -0500
Received: from mail.bbn.com ([128.33.1.19])
	by mx11.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1IpQJQ-0000iJ-4L; Tue, 06 Nov 2007 10:25:56 -0500
Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1])
	by mail.bbn.com with esmtp (Exim 4.67)
	(envelope-from )
	id 1IpQJN-00046v-31; Tue, 06 Nov 2007 10:25:54 -0500
Message-ID: <47308710.3040807@bbn.com>
Date: Tue, 06 Nov 2007 10:24:00 -0500
From: Matt Lepinski 
Organization: BBN
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dan Wing 
Subject: Re: [Sip] RE: Review of draft-ietf-sip-media-security-requirements-00
References: <47080AF8.9060303@bbn.com>
	<033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
In-Reply-To: <033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: 'IETF SIP List' , 'Francois Audet' ,
	"'Fries, Steffen'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dan,

Thanks for moving quickly towards a -01 version of the draft.

I couple of comments R23, R24, and R25:

>For reference in this response, R23, R24, and R25 are:
>
>  R23:   The media security key management protocol SHOULD support
>          recording of decrypted media.
>
>          Media recording may be realized by an intermediate nodes.  An
>          example for those intermediate nodes are devices, which could
>          be used in banking applications or for quality monitoring in
>          call centers.  Here, it must be ensured, that the media
>          security is ensured by the intermediate nodes on the
>          connections to the involved endpoints as originally
>          negotiated.  The endpoints need to be informed that there is
>          an intermediate device and need to cooperate.  A solution
>          approach for this is described in [I-D.wing-sipping-srtp-key].
>
>R23 refers only to recording of media.  This is necessary in many 
>business environments such as banks, stock brokers, catalog ordering call
>centers, and so on.  This is a requirement for many businesses.  It
>is not yet clear if draft-wing-sipping-srtp-key (or something like it) 
>meets requirement R23.
>  
>
[MBL]: I understand the need for media recording (with the concent and 
cooperation of the end-point) in many environments. However, it is not 
clear to me that the media security key management protocol is the right 
place to solve the media recording problem. That is, regardless of which 
key management protocol I use between the endpoints, each endpoint is 
going to end up with the SRTP key. Once an endpoint who consents to 
media recording has the SRTP key, he can use a separate mechanism to 
support media recording. My fear is that integrating the media recording 
as part of the key management protocol will add significant complexity 
to the key management protocol to solve a problem that could easily be 
solved with a separate protocol mechanism.

>   R24:   The media security key management protocol SHOULD NOT allow
>          end users to determine whether their end-to-end interaction is
>          subject to lawful interception.
>
>I agree R24 refers to lawful intercept.  This is a requirement from
>other SDOs that need to provide lawful intercept with their solutions.
>  
>
[MBL]: I understand that other SDOs have requirements for lawful 
intercept. However, my understanding from reading RFC 2804 is that the 
IETF does not include such requirements in its documents.

>Another email on R24 lawful intercept will be forthcoming shortly.
>
>   R25:   The media security key management protocol MUST work when
>          there are intermediate nodes, terminating or processing media,
>          between the end points."
>
>R25 reference to 'intermediate nodes' is to transcoders and SBCs which
>handle signaling and media traffic.  It seems important that any keying
>mechanism work with such intermediate nodes, as those intermediate nodes
>are common on many SIP networks.
>  
>
[MBL]: I am confused by this requirement. Clearly, in many environments 
SBCs (and other intermediate nodes) are used to terminate and process 
media (e.g. to translate between two different codecs). However, in any 
environment where an intermediate node is processing the media, there is 
no way that end-to-end security of media can be achieved. (Indeed, from 
a security point of the view, the intermediate node who that processes 
the media stream is playing the role of a man-in-the-middle.) Therefore, 
I'm not sure what R25 is trying to require.




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 10:56:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpQn8-0003FF-WD; Tue, 06 Nov 2007 10:56:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpQn6-0003C7-Ot
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 10:56:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQn6-0003Bw-FH
	for sip@ietf.org; Tue, 06 Nov 2007 10:56:36 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IpQn2-0007iI-OR for sip@ietf.org; Tue, 06 Nov 2007 10:56:36 -0500
X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="413793587"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 07:56:32 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA6FuTb0021456; 
	Tue, 6 Nov 2007 07:56:29 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA6FuSvW022787;
	Tue, 6 Nov 2007 15:56:29 GMT
From: "Dan Wing" 
To: "'Matt Lepinski'" 
References: <47080AF8.9060303@bbn.com>
	<033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
	<47308710.3040807@bbn.com>
Subject: RE: [Sip] RE: Review of draft-ietf-sip-media-security-requirements-00
Date: Tue, 6 Nov 2007 07:56:28 -0800
Message-ID: <04ee01c8208d$9825c9b0$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcggiVgO4nudR9nSTYq4sj629O3pyQAAg1IA
In-Reply-To: <47308710.3040807@bbn.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5343; t=1194364589;
	x=1195228589; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20RE=3A=20Review=20of=20draft-ietf-sip-media-se
	curity-requirements-00 |Sender:=20;
	bh=TajF9fRfV5bunWo/zMWu/nfSQKbZbnwk2jLYDWix+5w=;
	b=H8jDo/WCGc5wZ3qa7QsihLJofXdYOe6cytiuGeWuX0JzYTlTL6BD+5L5EkzJdR8V3D5nw+3o
	J/Es+w+NuHLBqk8Oo6jkho5XDHnWMgctUf87d1EEcueZS7ROZUJrsysYWUnb8CWJnRDEoeDiuX
	b0QyWzj6/DgFxA5Bnl7KlHbsQ=;
Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Cc: 'IETF SIP List' , 'Francois Audet' ,
	"'Fries, Steffen'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> >For reference in this response, R23, R24, and R25 are:
> >
> >  R23:   The media security key management protocol SHOULD support
> >          recording of decrypted media.
> >
> >          Media recording may be realized by an intermediate 
> >          nodes.  An
> >          example for those intermediate nodes are devices, 
> >          which could
> >          be used in banking applications or for quality 
> >          monitoring in
> >          call centers.  Here, it must be ensured, that the media
> >          security is ensured by the intermediate nodes on the
> >          connections to the involved endpoints as originally
> >          negotiated.  The endpoints need to be informed 
> >          that there is
> >          an intermediate device and need to cooperate.  A solution
> >          approach for this is described in 
> >          [I-D.wing-sipping-srtp-key].
> >
> >R23 refers only to recording of media.  This is necessary in many 
> >business environments such as banks, stock brokers, catalog 
> >ordering call
> >centers, and so on.  This is a requirement for many businesses.  It
> >is not yet clear if draft-wing-sipping-srtp-key (or 
> >something like it) meets requirement R23.
>
> [MBL]: I understand the need for media recording (with the concent
> and cooperation of the end-point) in many environments. However, it
> is not clear to me that the media security key management protocol
> is the right place to solve the media recording problem.  That is,
> regardless of which key management protocol I use between the
> endpoints, each endpoint is going to end up with the SRTP key. Once
> an endpoint who consents to media recording has the SRTP key, he can
> use a separate mechanism to support media recording. My fear is that
> integrating the media recording as part of the key management
> protocol will add significant complexity to the key management
> protocol to solve a problem that could easily be solved with a
> separate protocol mechanism.

I agree solving the problem within the key management protocol
may not be the right place to solve it.  However, the requirement
to have it solved remains necessary.  I don't know where
else to capture this requirement, and am open to suggestions.

I am co-author of draft-wing-sipping-srtp-key, which proposes
one solution to meet requirement R23, using PUBLISH.

> >   R24:   The media security key management protocol SHOULD NOT allow
> >          end users to determine whether their end-to-end 
> >          interaction is
> >          subject to lawful interception.
> >
> >I agree R24 refers to lawful intercept.  This is a requirement from
> >other SDOs that need to provide lawful intercept with their 
> solutions.
>
> [MBL]: I understand that other SDOs have requirements for lawful 
> intercept. However, my understanding from reading RFC 2804 is 
> that the IETF does not include such requirements in its documents.

That is also my understanding from RFC1984 and RFC2804.

Yet, IETF has stated that it owns SIP standards.  This leaves IETF
in an interesting position which I, as an author, am unable to 
reconcile.

> >Another email on R24 lawful intercept will be forthcoming shortly.
> >
> >   R25:   The media security key management protocol MUST work when
> >          there are intermediate nodes, terminating or 
> >          processing media,
> >          between the end points."
> >
> >R25 reference to 'intermediate nodes' is to transcoders and 
> >SBCs which
> >handle signaling and media traffic.  It seems important that 
> >any keying
> >mechanism work with such intermediate nodes, as those 
> >intermediate nodes
> >are common on many SIP networks.
>
> [MBL]: I am confused by this requirement. Clearly, in many
> environments SBCs (and other intermediate nodes) are used to
> terminate and process media (e.g. to translate between two different
> codecs). However, in any environment where an intermediate node is
> processing the media, there is no way that end-to-end security of
> media can be achieved. (Indeed, from a security point of the view,
> the intermediate node who that processes the media stream is playing
> the role of a man-in-the-middle.) Therefore, I'm not sure what R25
> is trying to require.

Transcoding of media by a device outside of the endpoint.  For
example, a device might be on a bandwidth-constrained link but
due to peering or interoperability requirements (such as those
that are born out of SPEERMINT), it might be necessary for the
initial Invite to offer both the highly-compressed codec and a
'typical' codec for interoperability (say, G.711).  However,
G.711 takes up too much bandwidth for the bandwidth-constrained
link.

Today, this is solvable with RTP, and being done with RTP.

We also want this solvable with SRTP.  It is well-known how
to solve this with Security Descriptions [RFC4568]; what is 
important is to provide solutions for this with other key
management protocols, such as DTLS-SRTP.

I have added "transcoding and SBC" as examples to R25, but if
there is additional wording that would be helpful, please let 
me know; perhaps we should add a section at the top (which we 
have done for some of the more complicated requirements)??

-d


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 11:52:05 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpRea-0003YF-J9; Tue, 06 Nov 2007 11:51:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpReZ-0003V0-A2
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 11:51:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpReY-0003Ts-V0
	for sip@ietf.org; Tue, 06 Nov 2007 11:51:51 -0500
Received: from mx11.bbn.com ([128.33.0.80])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpReY-0004XB-G8
	for sip@ietf.org; Tue, 06 Nov 2007 11:51:50 -0500
Received: from dommiel.bbn.com ([192.1.122.15] helo=localhost.localdomain)
	by mx11.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1IpReV-0002SQ-5I; Tue, 06 Nov 2007 11:51:47 -0500
Message-ID: <47309BA1.7090405@bbn.com>
Date: Tue, 06 Nov 2007 11:51:45 -0500
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.5 (X11/20070727)
MIME-Version: 1.0
To: Dan Wing 
References: <47080AF8.9060303@bbn.com>
	<033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
In-Reply-To: <033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 'IETF SIP List' , 'Francois Audet' ,
	"'Fries, Steffen'" 
Subject: [Sip] Re: Review of draft-ietf-sip-media-security-requirements-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dan,

I agree that R23 and R25 aren't necessarily related to lawful intercept, 
but all three requirements are related to third parties having access to 
plain-text media -- and the whole point of encrypting data is to protect 
it against access by unauthorized third parties.  In order to provide 
access to these parties (quality of service, law enforcement, or 
middleboxes) and still provide security, either (1) the protocol needs 
to have some mechanism for explicitly authorizing these users, or (2) 
there needs to be an out-of-band mechanism like draft-wing-sipping-srtp-key.

Option (1) (explicit authorization) is (IMO) the much less appealing option:
1. It directly conflicts with R24, since it enables the endpoints to be 
aware that another party is being given access.
2. It means that the requirements can only be satisfied by a multi-party 
/ multicast keying protocol (since it has to assume that there are at 
least three parties to a call).
3. It adds hard authentication requirements (so that not just anyone can 
be the listening party), which will hinder deployment

Option (2), on the other hand, requires no text in the media security 
requirements.  It provides the same functionality, with two caveats:
1. One endpoint has to be willing to transmit the keys to the listener. 
  In a enterprise network, this isn't a problem, since endpoints are 
tightly controlled.  A VSP that wants to provide lawful intercept can 
just block SRTP calls that don't provide a key.
2. The listener has to be willing to tolerate the delay induced by 
routing the keys through SIP.  AFAIK, there are no requirements for 
real-time recording or lawful intercept, but this may be a small problem 
for middleboxes.

So on the whole, it seems to me like option (2) covers at least two of 
the three use cases you've proposed.

--Richard


> R23 refers only to recording of media.  This is necessary in many 
> business environments such as banks, stock brokers, catalog ordering call
> centers, and so on.  This is a requirement for many businesses.  It
> is not yet clear if draft-wing-sipping-srtp-key (or something like it) 
> meets requirement R23.

It seems like does, provided that (1) endpoints are willing to send key 
to authorized listeners, and (2) the delay induced by SIP is tolerable. 
  Both of these would seem to be true in the enterprise environments you 
describe.

> I agree R24 refers to lawful intercept.  This is a requirement from
> other SDOs that need to provide lawful intercept with their solutions.
> 
> Another email on R24 lawful intercept will be forthcoming shortly.

> R25 reference to 'intermediate nodes' is to transcoders and SBCs which
> handle signaling and media traffic.  It seems important that any keying
> mechanism work with such intermediate nodes, as those intermediate nodes
> are common on many SIP networks.


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 12:50:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpSZd-0004HT-EW; Tue, 06 Nov 2007 12:50:49 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpSZb-0004H8-Qt
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 12:50:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSZb-0004H0-HH
	for sip@ietf.org; Tue, 06 Nov 2007 12:50:47 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IpSZY-0002Mk-6H for sip@ietf.org; Tue, 06 Nov 2007 12:50:47 -0500
X-IronPort-AV: E=Sophos;i="4.21,379,1188802800"; d="scan'208";a="30535905"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-1.cisco.com with ESMTP; 06 Nov 2007 09:50:43 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA6HohpQ000837
	for ; Tue, 6 Nov 2007 09:50:43 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA6HohQ6028499
	for ; Tue, 6 Nov 2007 17:50:43 GMT
From: "Dan Wing" 
To: "'IETF SIP List'" 
Date: Tue, 6 Nov 2007 09:50:42 -0800
Message-ID: <06c101c8209d$8d543700$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcggnYz0vr1y5PPGSTSoHa6HBVInvw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1191; t=1194371443;
	x=1195235443; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20media-security-requirements=20and=20lawful=20intercept
	|Sender:=20; bh=XikQeHRa5pJOI8YS69TpGNianY0wNsq4Yg7ixhs41Y8=;
	b=BbSrO5XPn+tHIfWXeWEjQf13dDKrbbjHgElFohKh7jnY1gP1L5ojJbPRMiD3+TrdsbyuHJPw
	XjhzUV/ib0j2/zuQJldQTw4rXjymjmQRT136ZyzVZ2DIWeODvy4d82gk3kuNYtPcQOjXRKE8XI
	Ep2kUbQ2MohJ+XNCmEQC1PvmU=;
Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Sip] media-security-requirements and lawful intercept
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Other SDOs have lawful intercept requirements, which are currently
captured in requirement R24 in 
draft-ietf-sip-media-security-requirements-00:

   "R24:   The media security key management protocol SHOULD 
           NOT allow end users to determine whether their 
           end-to-end interaction is subject to lawful 
           interception."

DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
to establish SRTP keys for unicast, point-to-point SRTP sessions.

There appear to be two methods to meet R24 with DTLS-SRTP.  They
are:

   a. provide a network element on every SRTP call which relays
      media, performs a DTLS handshake, and decrypts and re-encrypts
      SRTP, or;

   b. have endpoints perform key disclosure for every call (using a 
      technique similar to draft-wing-sipping-srtp-key), and perform
      validation of that disclosed key on every call.

If these methods to meet R24 are deemed acceptable to other SDOs,
we don't find any reason for those SDOs to reject IETF's decision
to use DTLS-SRTP as the preferred mechanism to establish SRTP
keys for unicast, point-to-point SRTP sessions.

Comments welcome.
-d


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 13:00:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpSiw-00048W-QN; Tue, 06 Nov 2007 13:00:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpSiv-000467-Du
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 13:00:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSiv-00045y-01
	for sip@ietf.org; Tue, 06 Nov 2007 13:00:25 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpSiu-0006Sm-2M
	for sip@ietf.org; Tue, 06 Nov 2007 13:00:24 -0500
X-IronPort-AV: E=Sophos;i="4.21,379,1188802800"; d="scan'208";a="30538513"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-1.cisco.com with ESMTP; 06 Nov 2007 10:00:23 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lA6I0NUI023949; 
	Tue, 6 Nov 2007 10:00:23 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA6I0Mfb028123;
	Tue, 6 Nov 2007 18:00:22 GMT
From: "Dan Wing" 
To: "'Richard Barnes'" 
References: <47080AF8.9060303@bbn.com>
	<033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
	<47309BA1.7090405@bbn.com>
Date: Tue, 6 Nov 2007 10:00:22 -0800
Message-ID: <06d301c8209e$e6dbdf70$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgglVZKjUZ1MLTBQRK+HNgFMD4RbgACEdgQ
In-Reply-To: <47309BA1.7090405@bbn.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5204; t=1194372023;
	x=1195236023; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20Review=20of=20draft-ietf-sip-media-security-requireme
	nts-00 |Sender:=20;
	bh=80Hkryfp1hjHY8t3EEkcipvUP564MeesyIf4uwCO5c0=;
	b=pw+f2YtuhiOZ/BdaZb/lXx/CkJt257AhvQEKIe0WjgsW+I6wASBXADVrRTNk62aQNI5Vd5g0
	AEqsvPaTV1VlX8MvMef14N6o4K32l9fgiOqaTqyOZZeVxQutQ0AkytOZ;
Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Cc: 'IETF SIP List' , 'Francois Audet' ,
	"'Fries, Steffen'" 
Subject: [Sip] RE: Review of draft-ietf-sip-media-security-requirements-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

 

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com] 
> Sent: Tuesday, November 06, 2007 8:52 AM
> To: Dan Wing
> Cc: 'IETF SIP List'; 'Hannes Tschofenig'; 'Fries, Steffen'; 
> 'Francois Audet'
> Subject: Re: Review of draft-ietf-sip-media-security-requirements-00
> 
> Dan,
> 

> I agree that R23 and R25 aren't necessarily related to lawful
> intercept, but all three requirements are related to third parties
> having access to plain-text media -- and the whole point of
> encrypting data is to protect it against access by unauthorized
> third parties.  In order to provide access to these parties (quality
> of service, law enforcement, or middleboxes) and still provide
> security, either (1) the protocol needs to have some mechanism for
> explicitly authorizing these users, or (2) there needs to be an
> out-of-band mechanism like draft-wing-sipping-srtp-key.
>
> Option (1) (explicit authorization) is (IMO) the much less 
> appealing option:
> 1. It directly conflicts with R24, since it enables the 
> endpoints to be aware that another party is being given access.

Disclosing the SRTP via PUBLISH (option (2)) also creates the same 
awareness.

> 2. It means that the requirements can only be satisfied by a 
> multi-party / multicast keying protocol (since it has to assume that 
> there are at least three parties to a call).

Not necessarily.  It could be accomplished with DTLS-SRTP with two
DTLS handshakes, like this diagram:

   endpoint            middlebox           remote endpoint
      |                     |                     | 
      |                     |<--DTLS ClientHello--|
      |                     |---DTLS SrvrHello--->|
      |                     | ...                 |
      |                     |<--finished--        |
      |                     |---finished--------->|
      |                     |<-SRTP with key "A"->|
      |<--DTLS ClientHello--|                     |
      |---DTLS SrvrHello--->|                     |
      | ...                 |                     |
      |<--finished----------|                     |
      |---finished--------->|                     |
      |<-SRTP with key "B"->|                     |

There are two SRTP keys (A and B), and the middlebox would need
to decrypt SRTP and re-encrypt SRTP.  I expect this is not terribly
desirable due to the computational effort to decrypt and re-encrypt
the SRTP traffic.

> 3. It adds hard authentication requirements (so that not just 
> anyone can be the listening party), which will hinder deployment

That's probably true.

> Option (2), on the other hand, requires no text in the media security 
> requirements.  It provides the same functionality, with two caveats:
> 1. One endpoint has to be willing to transmit the keys to the 
> listener. 
>   In a enterprise network, this isn't a problem, since endpoints are 
> tightly controlled.  A VSP that wants to provide lawful intercept can 
> just block SRTP calls that don't provide a key.
> 2. The listener has to be willing to tolerate the delay induced by 
> routing the keys through SIP.  AFAIK, there are no requirements for 
> real-time recording or lawful intercept, but this may be a 
> small problem for middleboxes.

(2) isn't a significant problem, assuming DTLS-SRTP is allowed to
complete before the call is answered (and SRTP wants to start flowing).

> So on the whole, it seems to me like option (2) covers at 
> least two of the three use cases you've proposed.

I agree, which is why I have co-authored draft-wing-sipping-srtp-key.

But I'm trying to step back and ensure that it meets with everyone's
requirements regarding recording (for banks, stock brokers, etc.), 
and transcoding (compressed codecs to 'standard' codecs).  I don't
yet have a message flow for how draft-wing-sipping-srtp-key would
work well with transcoding; what I have sketched out is far 
uglier (more messages) than what everyone does for RTP transcoding 
today.

-d

> --Richard
> 
> 
> > R23 refers only to recording of media.  This is necessary in many 
> > business environments such as banks, stock brokers, catalog 
> ordering call
> > centers, and so on.  This is a requirement for many businesses.  It
> > is not yet clear if draft-wing-sipping-srtp-key (or 
> something like it) 
> > meets requirement R23.
> 
> It seems like does, provided that (1) endpoints are willing 
> to send key 
> to authorized listeners, and (2) the delay induced by SIP is 
> tolerable. 
>   Both of these would seem to be true in the enterprise 
> environments you 
> describe.
> 
> > I agree R24 refers to lawful intercept.  This is a requirement from
> > other SDOs that need to provide lawful intercept with their 
> solutions.
> > 
> > Another email on R24 lawful intercept will be forthcoming shortly.
> 
> > R25 reference to 'intermediate nodes' is to transcoders and 
> SBCs which
> > handle signaling and media traffic.  It seems important 
> that any keying
> > mechanism work with such intermediate nodes, as those 
> intermediate nodes
> > are common on many SIP networks.


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 14:01:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpTfP-0002yK-7B; Tue, 06 Nov 2007 14:00:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpTfN-0002sq-VT
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:00:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTfN-0002sg-KA
	for sip@ietf.org; Tue, 06 Nov 2007 14:00:49 -0500
Received: from mx12.bbn.com ([128.33.0.81])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpTfN-0008LT-1g
	for sip@ietf.org; Tue, 06 Nov 2007 14:00:49 -0500
Received: from mail.bbn.com ([128.33.1.19])
	by mx12.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1IpTfI-0001kj-3a; Tue, 06 Nov 2007 14:00:44 -0500
Received: from ros-dhcp233-050-233.bbn.com ([192.233.50.233] helo=[127.0.0.1])
	by mail.bbn.com with esmtp (Exim 4.67)
	(envelope-from )
	id 1IpTfH-0000rY-Ge; Tue, 06 Nov 2007 14:00:43 -0500
Message-ID: <4730B9D9.8000502@bbn.com>
Date: Tue, 06 Nov 2007 14:00:41 -0500
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dan Wing 
References: <47080AF8.9060303@bbn.com>
	<033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
	<47309BA1.7090405@bbn.com>
	<06d301c8209e$e6dbdf70$c4f0200a@cisco.com>
In-Reply-To: <06d301c8209e$e6dbdf70$c4f0200a@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: 'IETF SIP List' , 'Francois Audet' ,
	"'Fries, Steffen'" 
Subject: [Sip] Re: Review of draft-ietf-sip-media-security-requirements-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> Disclosing the SRTP via PUBLISH (option (2)) also creates the same 
> awareness.

Acknowledged.  R24 cannot be satisfied by a protocol with robust 
confidentiality protection, without the cooperation of at least one 
endpoint.  The point of confidentiality protection is to prevent access 
by parties that have not been authorized by the communicants to receive 
access -- and that's exactly what R24 requires.

Conversely, if you want to satisfy R24 with a secure protocol, you need 
at least one endpoint to give access to the communications.  That's not 
a problem for the security protocol to solve; it's more in the domain of 
regulation.

> Not necessarily.  It could be accomplished with DTLS-SRTP with two
> DTLS handshakes, like this diagram:

Here, let me re-label that:

>    endpoint         man-in-the-middle          remote endpoint
>       |                     |                     | 
>       |                     |<-----make keys----->|
>       |<-----make keys----->|                     |

Your diagram is exactly a man-in-the-middle attack, just with a special 
middleman.  So if you allow the above functionality, either the protocol 
can't detect MitM attacks or it can't provide end-to-end authentication.

> There are two SRTP keys (A and B), and the middlebox would need
> to decrypt SRTP and re-encrypt SRTP.  I expect this is not terribly
> desirable due to the computational effort to decrypt and re-encrypt
> the SRTP traffic.

I don't how to transcode encrypted media without decrypting and 
re-encrypting.  I think this is more or less a trade-off you have to accept.

> But I'm trying to step back and ensure that it meets with everyone's
> requirements regarding recording (for banks, stock brokers, etc.), 
> and transcoding (compressed codecs to 'standard' codecs).  I don't
> yet have a message flow for how draft-wing-sipping-srtp-key would
> work well with transcoding; what I have sketched out is far 
> uglier (more messages) than what everyone does for RTP transcoding 
> today.

I'm not sure why you would think that things would be the same as for 
RTP transcoding.  You already have to have a transcoder that does crypto 
(unless there are techniques I'm not aware of).  And there's really only 
one more message to the flow (at least conceptually; two if you include 
a response) for the endpoint to deliver key to the middlbox.  For a 
simple case, just have the middlebox act as the presence server in 
draft-wing-sipping-srtp-key:

UAC         middlebox         UAS
  |              |              |
  |<-------establish keys------>|
  |---PUBLISH--->|              |
  |<----200------|              |
  |              |              |

Again here, UAC compliance is not an issue, since presumably the UAC 
wants the services of the middlebox in order for his call to go through. 
  The single major issue is latency, but since we're talking 1-2 UDP 
messages, that seems like it's about as small as you're going to get. 
Any smaller, and you'd have to communicate with the middlebox via a key 
negotiation message, which really dirty protocol design, and doesn't 
save much (it just makes the keying message bigger/slower).

So, in conclusion:
-- R24 is incompatible with secure operation, and
-- Out-of-band mechanisms seem sufficient for other requirements
-- Ergo, R23-35 don't belong in this document

--Richard




> -d
> 
>> --Richard
>>
>>
>>> R23 refers only to recording of media.  This is necessary in many 
>>> business environments such as banks, stock brokers, catalog 
>> ordering call
>>> centers, and so on.  This is a requirement for many businesses.  It
>>> is not yet clear if draft-wing-sipping-srtp-key (or 
>> something like it) 
>>> meets requirement R23.
>> It seems like does, provided that (1) endpoints are willing 
>> to send key 
>> to authorized listeners, and (2) the delay induced by SIP is 
>> tolerable. 
>>   Both of these would seem to be true in the enterprise 
>> environments you 
>> describe.
>>
>>> I agree R24 refers to lawful intercept.  This is a requirement from
>>> other SDOs that need to provide lawful intercept with their 
>> solutions.
>>> Another email on R24 lawful intercept will be forthcoming shortly.
>>> R25 reference to 'intermediate nodes' is to transcoders and 
>> SBCs which
>>> handle signaling and media traffic.  It seems important 
>> that any keying
>>> mechanism work with such intermediate nodes, as those 
>> intermediate nodes
>>> are common on many SIP networks.
> 
> 



_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 14:54:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpUVP-0000Hv-HV; Tue, 06 Nov 2007 14:54:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpUVN-0000Hi-KB
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:54:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUVN-0000HZ-A2
	for sip@ietf.org; Tue, 06 Nov 2007 14:54:33 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpUVM-0001N6-QW
	for sip@ietf.org; Tue, 06 Nov 2007 14:54:33 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lA6JsPFt025102; 
	Tue, 6 Nov 2007 13:54:25 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lA6JsNj06365; Tue, 6 Nov 2007 13:54:25 -0600 (CST)
Message-ID: <4730C66F.2070803@alcatel-lucent.com>
Date: Tue, 06 Nov 2007 13:54:23 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IETF SIP List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: Brian E Carpenter 
Subject: [Sip] SIP IPv6 ABNF: Essential correction to RFC3261
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Folks: While performing the Gen-ART review of the
draft-ietf-sipping-ipv6-torture-test document, an extant bug in
the IPv6 ABNF production rules of RFC3261 was discovered.

A quick dialog with the chairs resulted in the understanding
that this could potentially be fixed as part of the SIP essential
corrections process, once it was ratified by the WG.

Brian and I have submitted a short draft describing this bug and
its resolution to the IETF.  Until it appears in the archives, you
can get a copy from
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/draft-gurbani-sip-ipv6-abnf-fix-00.txt
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/draft-gurbani-sip-ipv6-abnf-fix-00.html

Thanks.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 17:21:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpWms-0002FV-T9; Tue, 06 Nov 2007 17:20:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpWmr-0002BF-Dd
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 17:20:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWmq-0002Ah-Qb
	for sip@ietf.org; Tue, 06 Nov 2007 17:20:45 -0500
Received: from qmta10.emeryville.ca.mail.comcast.net ([76.96.30.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpWmn-0002Hi-D6
	for sip@ietf.org; Tue, 06 Nov 2007 17:20:44 -0500
Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52])
	by QMTA10.emeryville.ca.mail.comcast.net with smtp
	id 9ZtG1Y00617UAYk0102E00; Tue, 06 Nov 2007 22:20:42 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA13.emeryville.ca.mail.comcast.net with comcast
	id 9aLg1Y00H0umElk0000000; Tue, 06 Nov 2007 22:20:42 +0000
X-Authority-Analysis: v=1.0 c=1 a=QvFbR66aiVExLRDkFgMA:9
	a=pNXjaiB0QKLBqTFyZCAA:7 a=GZA28mwlZr_969IXMJRBQsEIgUUA:4
	a=cMdEYbctpPkA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lA6MKcSV032536
	for ; Tue, 6 Nov 2007 17:20:38 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lA6MKcDY032532;
	Tue, 6 Nov 2007 17:20:38 -0500
Date: Tue, 6 Nov 2007 17:20:38 -0500
Message-Id: <200711062220.lA6MKcDY032532@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: 
	(jgunn6@csc.com)
Subject: Re: [Sip] namespaces in RFC 4411,	4412 and
	draft-ietf-sip-rph-new-namespaces-00
References: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Janet P Gunn 

   Your suggested behavior would seem to violate this.

That's true.  But I think the RFC-compliant behavior doesn't take into
account how the incoming request validates that it is authorized to
use the priority it has claimed.  The practical result is that
whenever a request crosses a trust boundary, the network operator of
the network being entered is going to remove any priority request.

I expect that the rules of the RFC will be followed by any elements
inside a *network*.  But I expect network ingress/egress elements to
violate it by default.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 06 17:34:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpX0P-0001Li-3L; Tue, 06 Nov 2007 17:34:45 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpX0M-0001Gc-87
	for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 17:34:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpX0L-0001GU-TW
	for sip@ietf.org; Tue, 06 Nov 2007 17:34:41 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpX0L-0006rD-Fk
	for sip@ietf.org; Tue, 06 Nov 2007 17:34:41 -0500
X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="scan'208";a="413921529"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 14:34:40 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA6MYeCH009348; 
	Tue, 6 Nov 2007 14:34:40 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA6MYTQM016371;
	Tue, 6 Nov 2007 22:34:38 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 6 Nov 2007 17:34:29 -0500
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 6 Nov 2007 17:34:29 -0500
Message-ID: <4730EBF6.7070904@cisco.com>
Date: Tue, 06 Nov 2007 17:34:30 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] namespaces in RFC 4411,
	4412 and	draft-ietf-sip-rph-new-namespaces-00
References: 
	<200711062220.lA6MKcDY032532@dragon.ariadne.com>
In-Reply-To: <200711062220.lA6MKcDY032532@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 22:34:29.0257 (UTC)
	FILETIME=[31953F90:01C820C5]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002
X-TM-AS-Result: No--10.800000-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1322; t=1194388480;
	x=1195252480; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20namespaces=20in=20RFC=204411,
	=094412=20and=09 draft-ietf-sip-rph-new-namespaces-00
	|Sender:=20; bh=+KbU2xM95KZ48ZyICeEwHITH0S4hyFSfNwU/mZVKhK0=;
	b=W/rGI0fiolGQcLxEAhFd99MOY14alCaE8OYZtgMc6vrn5x2ZVJF5hof/shQmKcu9SWUvL9y0
	zDuMIJX3/HLQUdS+rmwfDLVWxA5ORdKfYkZfDeYZIPX2+0sX3DGErajLHxm5JoC0ZUuFv3f76F
	IWA/C4oOBBSIL1A1aa0sZewHU=;
Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Dale.Worley@comcast.net wrote:
>    From: Janet P Gunn 
> 
>    Your suggested behavior would seem to violate this.
> 
> That's true.  But I think the RFC-compliant behavior doesn't take into
> account how the incoming request validates that it is authorized to
> use the priority it has claimed.  The practical result is that
> whenever a request crosses a trust boundary, the network operator of
> the network being entered is going to remove any priority request.
> 
> I expect that the rules of the RFC will be followed by any elements
> inside a *network*.  But I expect network ingress/egress elements to
> violate it by default.

If the header is truly only a *request*, with no implication of asserted 
authorization, then there is no reason to remove it.

BUT, unless you can authenticate the sender of the request and authorize 
them to receive the priority they have requested, then there is little 
likelihood that it will be granted.

So the key issue is how authorization is determined. If this is a closed 
military network then I imagine they will have some kind of transitive 
trust that will support this.

But if the goal here is for emergency service workers to obtain priority 
over all sorts of networks, then I can't imagine how it can work.

	Paul


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 07 06:21:15 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ipiy2-0006Cd-Fi; Wed, 07 Nov 2007 06:21:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ipiy0-0006BD-GY
	for sip-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 06:21:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipiy0-0006Al-2V
	for sip@ietf.org; Wed, 07 Nov 2007 06:21:04 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipixv-0003Yl-9w
	for sip@ietf.org; Wed, 07 Nov 2007 06:21:04 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JR40025IVBOXU@siemenscomms.co.uk> for sip@ietf.org; Wed,
	07 Nov 2007 11:16:36 +0000 (GMT)
Date: Wed, 07 Nov 2007 11:17:00 +0000
From: "Elwell, John" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
In-reply-to: <06c101c8209d$8d543700$c4f0200a@cisco.com>
To: Dan Wing , IETF SIP List 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcggnYz0vr1y5PPGSTSoHa6HBVInvwAkJuKQ
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dan,

Speaking as an individual (not on behalf of another SDO), I don't
believe it is possible to satisfy R24.

With method a, the network element will not be able to provide
appropriate credentials to satisfy a user that he is in communication
with the remote user. Assuming RFC 4474 is used as the basis for
authentication, the certificate provided by the Authentication Service
acting on behalf of user A will sign the request and any self-signed
certificate from UA that will be used in the DTLS handshake. Any
substitution of that certificate by a network element would break the
signature. Any attempt at changing the From URI and Identity header
field by an Authentication Service acting on behalf of the network
element would presumably use a certificate for that domain, not a
certificate for user A's domain, so it would be clear to user B that the
call has come via that middle domain and is encrypted only as far as
that middle domain.

With method b, as already stated one of the users has to agree to
disclose its key.

John

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com] 
> Sent: 06 November 2007 17:51
> To: 'IETF SIP List'
> Subject: [Sip] media-security-requirements and lawful intercept
> 
> Other SDOs have lawful intercept requirements, which are currently
> captured in requirement R24 in 
> draft-ietf-sip-media-security-requirements-00:
> 
>    "R24:   The media security key management protocol SHOULD 
>            NOT allow end users to determine whether their 
>            end-to-end interaction is subject to lawful 
>            interception."
> 
> DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
> to establish SRTP keys for unicast, point-to-point SRTP sessions.
> 
> There appear to be two methods to meet R24 with DTLS-SRTP.  They
> are:
> 
>    a. provide a network element on every SRTP call which relays
>       media, performs a DTLS handshake, and decrypts and re-encrypts
>       SRTP, or;
> 
>    b. have endpoints perform key disclosure for every call (using a 
>       technique similar to draft-wing-sipping-srtp-key), and perform
>       validation of that disclosed key on every call.
> 
> If these methods to meet R24 are deemed acceptable to other SDOs,
> we don't find any reason for those SDOs to reject IETF's decision
> to use DTLS-SRTP as the preferred mechanism to establish SRTP
> keys for unicast, point-to-point SRTP sessions.
> 
> Comments welcome.
> -d
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 07 10:52:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpnCx-0004MC-5a; Wed, 07 Nov 2007 10:52:47 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpnCu-0004Ik-SA
	for sip-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 10:52:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpnCu-0004IP-GX
	for sip@ietf.org; Wed, 07 Nov 2007 10:52:44 -0500
Received: from web31707.mail.mud.yahoo.com ([68.142.201.187])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpnCr-0005qi-4d
	for sip@ietf.org; Wed, 07 Nov 2007 10:52:44 -0500
Received: (qmail 90648 invoked by uid 60001); 7 Nov 2007 15:52:40 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=n2waBB9XJKyHj6ht+A5xcpSOMcyddeT0YFsxAQmOnGv5ynJoy98VKelbjDWjWSVm2sRjgfIaK3rWudwS0Z/J9N3O69GP5LSw4C9MhzOnRcaAqSZVOKUwc4qZRrUHcApYhCRcCrU1BtqhrElPcvzPYRdF7umADK4gcs7FbsuGu9I=;
X-YMail-OSG: CACahQMVM1lWKWt_x6OkRUHkJCDMVcfj7Kv48dTljjuf9yUqQ.tKZasX6Q3aiaDFUAjuWtsrd4BvaTwPTIlBsFm_4VAWpkog.KRowXKhKBMFzv5i9SQ-
Received: from [216.41.24.3] by web31707.mail.mud.yahoo.com via HTTP;
	Wed, 07 Nov 2007 07:52:39 PST
Date: Wed, 7 Nov 2007 07:52:39 -0800 (PST)
From: Narendra V 
To: IETF SIP List 
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
MIME-Version: 1.0
Message-ID: <467039.90400.qm@web31707.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [Sip] UII to SIP INFO
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0352976178=="
Errors-To: sip-bounces@ietf.org

--===============0352976178==
Content-Type: multipart/alternative; boundary="0-170773213-1194450759=:90400"
Content-Transfer-Encoding: 8bit

--0-170773213-1194450759=:90400
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Hi,
  I have IWF scenario, H323 to SIP call. 
  The H323 endpoint is sending DTMF out of band of type UII 'signal'.
 When the user plays a digit the H323 endpoint sends a UII 'signal' with duration and the gateway translates this message into a SIP INFO containing digit code and duration. 
  Next the H323 endpoint send UII signal update message with change in signal duration. 
  Please let me know what should be the outgoing message (i.e. SIP INFO with new duration or no outgoing message).
  Thanks in advance.
  Regards,
  -Naren.
  
 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-170773213-1194450759=:90400
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  
Hi,
  
I have IWF scenario, H323 to SIP call. 
  
The H323 endpoint is sending DTMF out of band of type UII 'signal'.
 When the user plays a digit the H323 endpoint sends a UII 'signal' with duration and the gateway translates this message into a SIP INFO containing digit code and duration. 
  
Next the H323 endpoint send UII signal update message with change in signal duration. 
  
Please let me know what should be the outgoing message (i.e. SIP INFO with new duration or no outgoing message).
  
Thanks in advance.
  
Regards,
  
-Naren.
  
 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-170773213-1194450759=:90400--



--===============0352976178==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0352976178==--





From sip-bounces@ietf.org Wed Nov 07 10:59:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpnJL-0008Tr-J2; Wed, 07 Nov 2007 10:59:23 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpnJJ-0008QO-TK
	for sip-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 10:59:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpnJJ-0008Or-E9
	for sip@ietf.org; Wed, 07 Nov 2007 10:59:21 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpnJG-00061I-7H
	for sip@ietf.org; Wed, 07 Nov 2007 10:59:21 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA7FxB6U027094
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 7 Nov 2007 09:59:13 -0600
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Wed, 7 Nov 2007 09:59:03 -0600
To: "Elwell, John" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: IETF SIP List , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 7, 2007, at 5:17 AM, Elwell, John wrote:

> Dan,
>
> Speaking as an individual (not on behalf of another SDO), I don't
> believe it is possible to satisfy R24.
>
> With method a, the network element will not be able to provide
> appropriate credentials to satisfy a user that he is in communication
> with the remote user. Assuming RFC 4474 is used as the basis for
> authentication, the certificate provided by the Authentication Service
> acting on behalf of user A will sign the request and any self-signed
> certificate from UA that will be used in the DTLS handshake. Any
> substitution of that certificate by a network element would break the
> signature. Any attempt at changing the From URI and Identity header
> field by an Authentication Service acting on behalf of the network
> element would presumably use a certificate for that domain, not a
> certificate for user A's domain, so it would be clear to user B  
> that the
> call has come via that middle domain and is encrypted only as far as
> that middle domain.
>
> With method b, as already stated one of the users has to agree to
> disclose its key.

Right. I think R24 is awkwardly worded, and should be something like:

    R24:   The media security key management protocol SHOULD NOT allow
           end users to determine whether a specific end-to-end
           interaction is being or will be lawfully intercepted.

We know that all calls in a 3GPP-type network are subject to lawful  
interception. The question is "Is this specific call being  
intercepted or is it more likely to be intercepted than any other call?"

This means that any visible mechanism (keys have to be disclosed or a  
decrypting relay agent) must be exercised for every call, otherwise  
the act of asking for a key on a specific would reveal that there is  
unusual interest in intercepting that specific call.

So, if we (IETF) were to define a mechanism whereby a caller could  
electively disclose session keys to a 3rd party (such as a recorder),  
and some service provider (or national regulator) were to make use of  
this mechanism mandatory for all calls over specific infrastructure,  
I think everybody would be as satisfied as they're going to get.

This does raise all sorts of questions like "What happens when two  
nodes cheat and report invalid session keys to the LI mechanism?",  
something that is obviously doable. But if you ponder it awhile, you  
realize that there's really nothing that can prevent two colluding  
nodes from applying a secondary encryption, just as there is no real  
way to prevent two speakers from talking in code. I once used a  
scrambler that clamped over a regular analog handpiece, did a A to D  
conversion, encrypted, converted the stream into FSK (sounded like  
fax), and inversed the process at the other end. That's why some  
countries made it illegal to use unlicensed fax machines and modems  
for a while -- anybody who was communicating securely needed to be  
investigated. It may also be why some countries originally refused to  
upgrade their filters and echo cancelers to support 14.4 modems. But  
that cat has long since gotten out of the bag and wandered off  
someplace. So the best the LI community can hope for is that the  
majority of nodes will cooperate and that auditing mechanisms will  
have some chance of detecting those that don't.

--
Dean





_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 07 11:19:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IpncJ-0003bO-Fa; Wed, 07 Nov 2007 11:18:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IpncH-0003aY-Ks
	for sip-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 11:18:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IpncH-0003Zo-Ab
	for sip@ietf.org; Wed, 07 Nov 2007 11:18:57 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpncE-0006ml-IF
	for sip@ietf.org; Wed, 07 Nov 2007 11:18:57 -0500
X-IronPort-AV: E=Sophos;i="4.21,385,1188802800"; d="scan'208";a="185392950"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-5.cisco.com with ESMTP; 07 Nov 2007 08:18:54 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA7GIrY9025448; 
	Wed, 7 Nov 2007 08:18:53 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7GIqfb019847;
	Wed, 7 Nov 2007 16:18:52 GMT
From: "Dan Wing" 
To: "'Elwell, John'" ,
	"'IETF SIP List'" 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Wed, 7 Nov 2007 08:18:52 -0800
Message-ID: <101a01c82159$e3202600$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcggnYz0vr1y5PPGSTSoHa6HBVInvwAkJuKQAApfgsA=
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4381; t=1194452333;
	x=1195316333; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=BKpr5eDFy/x0CR8jXXKQq4J0QOGNxAoGX6fBETty8qE=;
	b=rv8s5Ej2I4vFSiZnjUOxToXpaiVRpP3BVNTQquzO0tUw2crrSQVhszgZywyMGEMwmAJHBd1V
	HsZrLxZIuqaRfa1MvvJfRVd0s7AN4iMpYpx0cV1VbVQdhZHcy8rm78nfy9OrA7PPqpiZAKOmRF
	wncNKDzKA3b9K1WqNN3LyRt5w=;
Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com] 
> Sent: Wednesday, November 07, 2007 3:17 AM
> To: Dan Wing; IETF SIP List
> Subject: RE: [Sip] media-security-requirements and lawful intercept
> 
> Dan,
> 
> Speaking as an individual (not on behalf of another SDO), I don't
> believe it is possible to satisfy R24.
> 
> With method a, the network element will not be able to provide
> appropriate credentials to satisfy a user that he is in communication
> with the remote user.

Method 'a' could be achieved if the interception (and DTLS handshake)
occurred within the originating domain, prior to the RFC4474
signature.  This can allow inserting the man in the middle at that
point.  This would need to be done for every call (not just 
calls being intercepted).

> Assuming RFC 4474 is used as the basis for
> authentication, the certificate provided by the Authentication Service
> acting on behalf of user A will sign the request and any self-signed
> certificate from UA that will be used in the DTLS handshake. Any
> substitution of that certificate by a network element would break the
> signature. Any attempt at changing the From URI and Identity header
> field by an Authentication Service acting on behalf of the network
> element would presumably use a certificate for that domain, not a
> certificate for user A's domain, so it would be clear to user 
> B that the
> call has come via that middle domain and is encrypted only as far as
> that middle domain.

I agree that after the RFC4474 signature is created, other domains
can't become a man in the middle.

> With method b, as already stated one of the users has to agree to
> disclose its key.

The network can enforce that by blocking SRTP until the key is 
disclosed.  Some networks that block RTP until 200 Ok for fraud
prevention, and those same networks have LI requirements placed
on them by their government.  Those networks could, similarly, block
SRTP until the key is disclosed, and could validate that the 
supplied key does decrypt SRTP (especially SRTP that is protected
with an authentication tag).

-d

> John
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@cisco.com] 
> > Sent: 06 November 2007 17:51
> > To: 'IETF SIP List'
> > Subject: [Sip] media-security-requirements and lawful intercept
> > 
> > Other SDOs have lawful intercept requirements, which are currently
> > captured in requirement R24 in 
> > draft-ietf-sip-media-security-requirements-00:
> > 
> >    "R24:   The media security key management protocol SHOULD 
> >            NOT allow end users to determine whether their 
> >            end-to-end interaction is subject to lawful 
> >            interception."
> > 
> > DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
> > to establish SRTP keys for unicast, point-to-point SRTP sessions.
> > 
> > There appear to be two methods to meet R24 with DTLS-SRTP.  They
> > are:
> > 
> >    a. provide a network element on every SRTP call which relays
> >       media, performs a DTLS handshake, and decrypts and re-encrypts
> >       SRTP, or;
> > 
> >    b. have endpoints perform key disclosure for every call (using a 
> >       technique similar to draft-wing-sipping-srtp-key), and perform
> >       validation of that disclosed key on every call.
> > 
> > If these methods to meet R24 are deemed acceptable to other SDOs,
> > we don't find any reason for those SDOs to reject IETF's decision
> > to use DTLS-SRTP as the preferred mechanism to establish SRTP
> > keys for unicast, point-to-point SRTP sessions.
> > 
> > Comments welcome.
> > -d
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> 
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 07 12:49:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ipp1x-0002q4-K8; Wed, 07 Nov 2007 12:49:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ipp1v-0002p0-Us
	for sip-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 12:49:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipp1v-0002os-J7
	for sip@ietf.org; Wed, 07 Nov 2007 12:49:31 -0500
Received: from empbedex1.empirix.com ([12.38.203.54])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipp1v-0001Cx-1K
	for sip@ietf.org; Wed, 07 Nov 2007 12:49:31 -0500
Received: from EMPBEDEX.empirix.com ([10.16.0.92]) by empbedex1.empirix.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 7 Nov 2007 12:49:26 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] UII to SIP INFO
Date: Wed, 7 Nov 2007 12:49:22 -0500
Message-ID: 
In-Reply-To: <467039.90400.qm@web31707.mail.mud.yahoo.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] UII to SIP INFO
Thread-Index: AcghVk3kx6GBWsNXQ1CX2FRIfULHkwAD+jqg
References: <0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	<467039.90400.qm@web31707.mail.mud.yahoo.com>
From: "Bhattacharyya, Dipankar" 
To: "Narendra V" ,
	"IETF SIP List" 
X-OriginalArrivalTime: 07 Nov 2007 17:49:26.0728 (UTC)
	FILETIME=[8A182C80:01C82166]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2140258873=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2140258873==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82166.8712E95A"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82166.8712E95A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Naren,

    I would assume that a SIP INFO on the same dialog with an increament
in CSeq and the message body will have the updated Signal Duration.

=20

Regards,

-Dipankar. =20

=20

________________________________

From: Narendra V [mailto:naren_vuppuluri@yahoo.com]=20
Sent: Wednesday, November 07, 2007 9:53 AM
To: IETF SIP List
Subject: [Sip] UII to SIP INFO

=20

Hi,

I have IWF scenario, H323 to SIP call.=20

The H323 endpoint is sending DTMF out of band of type UII 'signal'.
When the user plays a digit the H323 endpoint sends a UII 'signal' with
duration and the gateway translates this message into a SIP INFO
containing digit code and duration.=20

Next the H323 endpoint send UII signal update message with change in
signal duration.=20

Please let me know what should be the outgoing message (i.e. SIP INFO
with new duration or no outgoing message).

Thanks in advance.

Regards,

-Naren.

 __________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20


------_=_NextPart_001_01C82166.8712E95A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















Hello =
Naren,



    I would assume =
that a SIP INFO on the
same dialog with an increament in CSeq and the message body will have =
the
updated Signal Duration.



 



Regards,


-Dipankar. =
 



 















From: =
Narendra V
[mailto:naren_vuppuluri@yahoo.com] 

Sent: Wednesday, November =
07, 2007
9:53 AM

To: IETF SIP List

Subject: [Sip] UII to SIP =
INFO






 






Hi,









I have IWF scenario, H323 to SIP call. =










The H323 endpoint is sending DTMF out of band of =
type UII
'signal'.

When the user plays a digit the H323 endpoint sends a UII 'signal' with
duration and the gateway translates this message into a SIP INFO =
containing
digit code and duration. 









Next the H323 endpoint send UII signal update =
message with
change in signal duration. 









Please let me know what should be the outgoing =
message
(i.e. SIP INFO with new duration or no outgoing =
message).









Thanks in =
advance.









Regards,









-Naren.






 ________________________________________=
__________

Do You Yahoo!?

Tired of spam? Yahoo! Mail has the best spam protection around 

http://mail.yahoo.com 









------_=_NextPart_001_01C82166.8712E95A--



--===============2140258873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============2140258873==--





From sip-bounces@ietf.org Wed Nov 07 14:47:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ipqs4-00077Z-HR; Wed, 07 Nov 2007 14:47:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ipqs3-00074R-1a
	for sip-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:47:27 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipqs2-00074J-MQ
	for sip@ietf.org; Wed, 07 Nov 2007 14:47:26 -0500
Received: from ondar.cablelabs.com ([192.160.73.61])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipqs1-0006E3-Vw
	for sip@ietf.org; Wed, 07 Nov 2007 14:47:26 -0500
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lA7JlOv5018191
	for ; Wed, 7 Nov 2007 12:47:24 -0700
Received: from srvxchg3.cablelabs.com (10.5.0.25)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com);
	Wed, 7 Nov 2007 12:47:24 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 7 Nov 2007 12:47:23 -0700
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C695B6C2@srvxchg3.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Certificate authentication in SIP
Thread-Index: AcghdwQGHvz7SDepRm2pl8kAL/LbuQ==
From: "Steve Dotson" 
To: 
X-Approved: ondar
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Subject: [Sip] Certificate authentication in SIP
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0012349269=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0012349269==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82177.0495179E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82177.0495179E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Based on feedback received at the last IETF SIP WG meeting, I have
updated the Certificate Authentication in SIP requirements draft, which
can be found at:
=20
http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-04
.txt
=20
To summarize the changes made related to comments I received (and these
are not exact quotes):
=20
"Pick one use case, device certificates or user certificates, and bring
that back in"
=20
While I feel that both use cases are needed, I updated the draft to
focus specifically on device certificates, as there are millions of
cable devices with certificates deployed that can be leveraged.
=20
"Since the edge proxy is always trusted, why not do mutual TLS to the
edge proxy and do PAID or Identity to the registrar"
=20
I added this under "existing work". There were some emails between
Anupam and Jonathan a few months back on whether certificate information
needs to be passed from the edge proxy to the registrar. The outcome was
that for user certs, maybe not. However, for device certificates, since
the registrar contains the mapping that would need to exist between the
identity in the device certificate and the public identities authorized
for that device identity, the device identity would need to be passed to
the registrar somehow to make this association.
=20
"We have existing solutions already"
=20
As described in the "existing work" section of the draft, while there
are existing mechanisms (TLS, S/MIME, etc.), there are no documented
procedures on how to use those mechanisms for UA to registrar
authentication.
=20
"Look at what has been done already and put that in the draft"
=20
This was already present in the previous version.
=20

Thanks,

=20

Steve.

=20

=20

------_=_NextPart_001_01C82177.0495179E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Based =
on feedback=20
received at the last IETF SIP WG meeting, I have updated the Certificate =

Authentication in SIP requirements =

draft, which can be found at:


 


http://www.ietf.org/internet-drafts/draft-dotson-sip-certifi=
cate-auth-04.txt


 


To =
summarize the=20
changes made related to comments I received (and these are not exact=20
quotes):


 


"Pick =
one use case,=20
device certificates or user certificates, and bring that back=20
in"


 


While=20
I feel that both use =
cases are needed, I updated the draft to focus specifically on device =
certificates,=20
as there are millions of cable =
devices=20
with certificates deployed that can be=20
leveraged.


 


"Since =
the edge=20
proxy is always trusted, why not do mutual TLS to the edge proxy and do =
PAID or=20
Identity to the registrar"


 


I =
added this under=20
"existing work". There were some emails between Anupam and Jonathan a =
few months=20
back on whether certificate information needs to be passed from the edge =
proxy=20
to the registrar. The outcome was that for user certs, maybe not. =
However,=20
for device certificates, since the registrar contains the mapping that =
would=20
need to exist between the identity in the device certificate and the =
public=20
identities authorized for that device identity, the device identity =
would need=20
to be passed to the registrar somehow to make this=20
association.


 


"We =
have existing=20
solutions already"


 


As =
described in the=20
"existing work" section of the draft, while there are existing =
mechanisms (TLS,=20
S/MIME, etc.), there are no documented procedures on how to use those =
mechanisms=20
for UA to registrar authentication.


 


"Look =
at what has=20
been done already and put that in the draft"


 


This =
was already=20
present in the previous version.


 




Thanks,


 


Steve.


 


 


------_=_NextPart_001_01C82177.0495179E--



--===============0012349269==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0012349269==--





From sip-bounces@ietf.org Thu Nov 08 02:54:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq2DL-0002jo-SK; Thu, 08 Nov 2007 02:54:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq2DJ-0002g7-Uk
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 02:54:09 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2DE-0002bR-P1
	for sip@ietf.org; Thu, 08 Nov 2007 02:54:04 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq2DE-0004U4-8e
	for sip@ietf.org; Thu, 08 Nov 2007 02:54:04 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JR600AAVGLEWT@siemenscomms.co.uk> for sip@ietf.org; Thu,
	08 Nov 2007 07:53:38 +0000 (GMT)
Date: Thu, 08 Nov 2007 07:54:02 +0000
From: "Elwell, John" 
To: IETF SIP List 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E92A3@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for
	Media Control) to Informational RFC
Thread-Index: AcghWNcj3sctBTIfQ9u1JjbzWkdxHAAg0mGQ
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Subject: [Sip] FW: Last Call: draft-levin-mmusic-xml-media-control (XML
 Schema for Media Control) to Informational RFC
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

In view of the ongoing discussions on INFO on this list, are people
aware of this individual draft in IESG last call. It defines a new usage
of INFO.

John

> -----Original Message-----
> From: The IESG [mailto:iesg-secretary@ietf.org] 
> Sent: 07 November 2007 16:09
> To: IETF-Announce
> Subject: Last Call: draft-levin-mmusic-xml-media-control (XML 
> Schema for Media Control) to Informational RFC
> 
> The IESG has received a request from an individual submitter 
> to consider
> the following document:
> 
> - 'XML Schema for Media Control '
>     as an 
> Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive 
> comments to the
> ietf@ietf.org mailing lists by 2007-12-15. Exceptionally, 
> comments may be sent to iesg@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-med
> ia-control-12.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=9391&rfc_flag=0
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 03:20:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq2ct-0005Cv-RB; Thu, 08 Nov 2007 03:20:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq2cs-0005Bh-MF
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 03:20:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2cr-0005Ai-14
	for sip@ietf.org; Thu, 08 Nov 2007 03:20:33 -0500
Received: from thoth.sbs.de ([192.35.17.2])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq2cq-0005P2-C3
	for sip@ietf.org; Thu, 08 Nov 2007 03:20:32 -0500
Received: from mail3.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id lA88KRAR023626;
	Thu, 8 Nov 2007 09:20:27 +0100
Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net
	[139.25.131.193])
	by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id lA88KRbr013835;
	Thu, 8 Nov 2007 09:20:27 +0100
Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by
	mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 8 Nov 2007 09:20:27 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 09:20:26 +0100
Message-ID: <198A10EC585EC74687BCA414E2A5971801E47913@MCHP7RDA.ww002.siemens.net>
In-Reply-To: <101a01c82159$e3202600$c4f0200a@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcggnYz0vr1y5PPGSTSoHa6HBVInvwAkJuKQAApfgsAAIZjeYA==
References: <06c101c8209d$8d543700$c4f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	<101a01c82159$e3202600$c4f0200a@cisco.com>
From: "Fischer, Kai" 
To: "Dan Wing" , "Elwell, John" ,
	"IETF SIP List" 
X-OriginalArrivalTime: 08 Nov 2007 08:20:27.0203 (UTC)
	FILETIME=[37C3D130:01C821E0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]=20
> Sent: Mittwoch, 7. November 2007 17:19
> To: Elwell, John; 'IETF SIP List'
> Subject: RE: [Sip] media-security-requirements and lawful intercept
>=20
> =20
>=20
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens.com]=20
> > Sent: Wednesday, November 07, 2007 3:17 AM
> > To: Dan Wing; IETF SIP List
> > Subject: RE: [Sip] media-security-requirements and lawful intercept
> >=20
> > Dan,
> >=20
> > Speaking as an individual (not on behalf of another SDO), I don't
> > believe it is possible to satisfy R24.
> >=20
> > With method a, the network element will not be able to provide
> > appropriate credentials to satisfy a user that he is in=20
> communication
> > with the remote user.
>=20
> Method 'a' could be achieved if the interception (and DTLS handshake)
> occurred within the originating domain, prior to the RFC4474
> signature.  This can allow inserting the man in the middle at that
> point.  This would need to be done for every call (not just=20
> calls being intercepted).

This might be a solution, but not a very attractive one, since every
call is intercepted and needs to be decrypted and encrypted again. One
argument for DTLS-SRTP is the end-to-end security capability, which will
be weakened for every call in this case.

>=20
> > Assuming RFC 4474 is used as the basis for
> > authentication, the certificate provided by the=20
> Authentication Service
> > acting on behalf of user A will sign the request and any self-signed
> > certificate from UA that will be used in the DTLS handshake. Any
> > substitution of that certificate by a network element would=20
> break the
> > signature. Any attempt at changing the From URI and Identity header
> > field by an Authentication Service acting on behalf of the network
> > element would presumably use a certificate for that domain, not a
> > certificate for user A's domain, so it would be clear to user=20
> > B that the
> > call has come via that middle domain and is encrypted only as far as
> > that middle domain.
>=20
> I agree that after the RFC4474 signature is created, other domains
> can't become a man in the middle.
>=20
> > With method b, as already stated one of the users has to agree to
> > disclose its key.
>=20
> The network can enforce that by blocking SRTP until the key is=20
> disclosed.  Some networks that block RTP until 200 Ok for fraud
> prevention, and those same networks have LI requirements placed
> on them by their government.  Those networks could, similarly, block
> SRTP until the key is disclosed, and could validate that the=20
> supplied key does decrypt SRTP (especially SRTP that is protected
> with an authentication tag).

How is it possible to perform a DTLS handshake if the RTP traffic /
ports are blocked? Are these blocking network components able to analyze
the first byte of the packets and to distinguish between RTP and DTLS
traffic?

Kai


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 04:29:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq3h3-00018j-QZ; Thu, 08 Nov 2007 04:28:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq3h2-000182-8J
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:28:56 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3h0-00015O-Ny
	for sip@ietf.org; Thu, 08 Nov 2007 04:28:55 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq3gz-0007im-ST
	for sip@ietf.org; Thu, 08 Nov 2007 04:28:54 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JR600G2OKZFG5@siemenscomms.co.uk> for sip@ietf.org; Thu,
	08 Nov 2007 09:28:27 +0000 (GMT)
Date: Thu, 08 Nov 2007 09:28:51 +0000
From: "Elwell, John" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
In-reply-to: <101a01c82159$e3202600$c4f0200a@cisco.com>
To: Dan Wing , IETF SIP List 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E92BD@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcggnYz0vr1y5PPGSTSoHa6HBVInvwAkJuKQAApfgsAAJFN84A==
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	<101a01c82159$e3202600$c4f0200a@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

 

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com] 
> Sent: 07 November 2007 16:19
> To: Elwell, John; 'IETF SIP List'
> Subject: RE: [Sip] media-security-requirements and lawful intercept
> 
> 
>  
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens.com] 
> > Sent: Wednesday, November 07, 2007 3:17 AM
> > To: Dan Wing; IETF SIP List
> > Subject: RE: [Sip] media-security-requirements and lawful intercept
> > 
> > Dan,
> > 
> > Speaking as an individual (not on behalf of another SDO), I don't
> > believe it is possible to satisfy R24.
> > 
> > With method a, the network element will not be able to provide
> > appropriate credentials to satisfy a user that he is in 
> communication
> > with the remote user.
> 
> Method 'a' could be achieved if the interception (and DTLS handshake)
> occurred within the originating domain, prior to the RFC4474
> signature.  This can allow inserting the man in the middle at that
> point.  This would need to be done for every call (not just 
> calls being intercepted).
[JRE] This wouldn't work if LI is not being done in the originating
domain. Enterprise UA issues INVITE request, enterprise proxy addes
Identity header field and forwards to public service provider, which
needs the possibility to intercept.

> 
> > Assuming RFC 4474 is used as the basis for
> > authentication, the certificate provided by the 
> Authentication Service
> > acting on behalf of user A will sign the request and any self-signed
> > certificate from UA that will be used in the DTLS handshake. Any
> > substitution of that certificate by a network element would 
> break the
> > signature. Any attempt at changing the From URI and Identity header
> > field by an Authentication Service acting on behalf of the network
> > element would presumably use a certificate for that domain, not a
> > certificate for user A's domain, so it would be clear to user 
> > B that the
> > call has come via that middle domain and is encrypted only as far as
> > that middle domain.
> 
> I agree that after the RFC4474 signature is created, other domains
> can't become a man in the middle.
> 
> > With method b, as already stated one of the users has to agree to
> > disclose its key.
> 
> The network can enforce that by blocking SRTP until the key is 
> disclosed.  Some networks that block RTP until 200 Ok for fraud
> prevention, and those same networks have LI requirements placed
> on them by their government.  Those networks could, similarly, block
> SRTP until the key is disclosed, and could validate that the 
> supplied key does decrypt SRTP (especially SRTP that is protected
> with an authentication tag).
[JRE] I don't see how it could verify a key if the authentication tag is
not used. Maybe it is easier for SRTCP than for SRTP, but that might
involve some unacceptable delay before the first SRTCP packet arrives.
Having said that, I would have thought the authentication tag would
normally be used, since otherwise the security provided is rather
dubious.

> 
> -d
> 
> > John
> > 
> > > -----Original Message-----
> > > From: Dan Wing [mailto:dwing@cisco.com] 
> > > Sent: 06 November 2007 17:51
> > > To: 'IETF SIP List'
> > > Subject: [Sip] media-security-requirements and lawful intercept
> > > 
> > > Other SDOs have lawful intercept requirements, which are currently
> > > captured in requirement R24 in 
> > > draft-ietf-sip-media-security-requirements-00:
> > > 
> > >    "R24:   The media security key management protocol SHOULD 
> > >            NOT allow end users to determine whether their 
> > >            end-to-end interaction is subject to lawful 
> > >            interception."
> > > 
> > > DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
> > > to establish SRTP keys for unicast, point-to-point SRTP sessions.
> > > 
> > > There appear to be two methods to meet R24 with DTLS-SRTP.  They
> > > are:
> > > 
> > >    a. provide a network element on every SRTP call which relays
> > >       media, performs a DTLS handshake, and decrypts and 
> re-encrypts
> > >       SRTP, or;
> > > 
> > >    b. have endpoints perform key disclosure for every 
> call (using a 
> > >       technique similar to draft-wing-sipping-srtp-key), 
> and perform
> > >       validation of that disclosed key on every call.
> > > 
> > > If these methods to meet R24 are deemed acceptable to other SDOs,
> > > we don't find any reason for those SDOs to reject IETF's decision
> > > to use DTLS-SRTP as the preferred mechanism to establish SRTP
> > > keys for unicast, point-to-point SRTP sessions.
> > > 
> > > Comments welcome.
> > > -d
> > > 
> > > 
> > > _______________________________________________
> > > 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
> > > 
> > 
> > 
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 04:41:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq3tJ-00067u-F5; Thu, 08 Nov 2007 04:41:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq3tH-00063h-Oi
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:41:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3tH-00063Q-BL
	for sip@ietf.org; Thu, 08 Nov 2007 04:41:35 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq3tE-0007J6-JT
	for sip@ietf.org; Thu, 08 Nov 2007 04:41:35 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JR600ID0LKIJR@siemenscomms.co.uk> for sip@ietf.org; Thu,
	08 Nov 2007 09:41:06 +0000 (GMT)
Date: Thu, 08 Nov 2007 09:41:30 +0000
From: "Elwell, John" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
In-reply-to: 
To: Dean Willis 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcghV1Qa7k+gtF8kS2+UDRJdxOd5KgAkrpNQ
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: IETF SIP List , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dean,

Yes, I tend to agree that key disclosure to an authority on all calls
passing through a domain with LI capability might be the way to go, but
even then I see problems.

A UA has home domain A that is not required to do LI (an enterprise,
say). On a call by call basis, the UA does not know whether the call
will be routed (directly or indirectly) to a particular domain B that
does LI (a carrier, say), so how does the UA find out that it needs to
report its key to carrier B (or C or D....)?

Also, by doing this, any notion of end-to-end security has gone out of
the window. If the key is disclosed to a third party, can the call
really be used for sending banking details etc.? Surely the business
world needs end-to-end security (or at least end-domain-to-end-domain
security), as we have with HTTPS?

John

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com] 
> Sent: 07 November 2007 15:59
> To: Elwell, John
> Cc: Dan Wing; IETF SIP List
> Subject: Re: [Sip] media-security-requirements and lawful intercept
> 
> 
> On Nov 7, 2007, at 5:17 AM, Elwell, John wrote:
> 
> > Dan,
> >
> > Speaking as an individual (not on behalf of another SDO), I don't
> > believe it is possible to satisfy R24.
> >
> > With method a, the network element will not be able to provide
> > appropriate credentials to satisfy a user that he is in 
> communication
> > with the remote user. Assuming RFC 4474 is used as the basis for
> > authentication, the certificate provided by the 
> Authentication Service
> > acting on behalf of user A will sign the request and any self-signed
> > certificate from UA that will be used in the DTLS handshake. Any
> > substitution of that certificate by a network element would 
> break the
> > signature. Any attempt at changing the From URI and Identity header
> > field by an Authentication Service acting on behalf of the network
> > element would presumably use a certificate for that domain, not a
> > certificate for user A's domain, so it would be clear to user B  
> > that the
> > call has come via that middle domain and is encrypted only as far as
> > that middle domain.
> >
> > With method b, as already stated one of the users has to agree to
> > disclose its key.
> 
> Right. I think R24 is awkwardly worded, and should be something like:
> 
>     R24:   The media security key management protocol SHOULD NOT allow
>            end users to determine whether a specific end-to-end
>            interaction is being or will be lawfully intercepted.
> 
> We know that all calls in a 3GPP-type network are subject to lawful  
> interception. The question is "Is this specific call being  
> intercepted or is it more likely to be intercepted than any 
> other call?"
> 
> This means that any visible mechanism (keys have to be 
> disclosed or a  
> decrypting relay agent) must be exercised for every call, otherwise  
> the act of asking for a key on a specific would reveal that there is  
> unusual interest in intercepting that specific call.
> 
> So, if we (IETF) were to define a mechanism whereby a caller could  
> electively disclose session keys to a 3rd party (such as a 
> recorder),  
> and some service provider (or national regulator) were to 
> make use of  
> this mechanism mandatory for all calls over specific infrastructure,  
> I think everybody would be as satisfied as they're going to get.
> 
> This does raise all sorts of questions like "What happens when two  
> nodes cheat and report invalid session keys to the LI mechanism?",  
> something that is obviously doable. But if you ponder it awhile, you  
> realize that there's really nothing that can prevent two colluding  
> nodes from applying a secondary encryption, just as there is no real  
> way to prevent two speakers from talking in code. I once used a  
> scrambler that clamped over a regular analog handpiece, did a A to D  
> conversion, encrypted, converted the stream into FSK (sounded like  
> fax), and inversed the process at the other end. That's why some  
> countries made it illegal to use unlicensed fax machines and modems  
> for a while -- anybody who was communicating securely needed to be  
> investigated. It may also be why some countries originally 
> refused to  
> upgrade their filters and echo cancelers to support 14.4 modems. But  
> that cat has long since gotten out of the bag and wandered off  
> someplace. So the best the LI community can hope for is that the  
> majority of nodes will cooperate and that auditing mechanisms will  
> have some chance of detecting those that don't.
> 
> --
> Dean
> 
> 
> 
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 08:49:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq7kh-00061z-BO; Thu, 08 Nov 2007 08:48:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq7kg-00061o-IX
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 08:48:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq7kf-0005zN-DT
	for sip@ietf.org; Thu, 08 Nov 2007 08:48:57 -0500
Received: from bender-mail.tigertech.net ([64.62.209.30])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq7ke-0006so-Fy
	for sip@ietf.org; Thu, 08 Nov 2007 08:48:57 -0500
Received: from localhost (localhost [127.0.0.1])
	by bender.tigertech.net (Postfix) with ESMTP id 7ED4E7DB5
	for ; Thu,  8 Nov 2007 05:48:55 -0800 (PST)
Received: from [192.168.0.100] (pool-70-104-226-87.fred.east.verizon.net
	[70.104.226.87])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bender.tigertech.net (Postfix) with ESMTP id 5C58D7D93
	for ; Thu,  8 Nov 2007 05:48:53 -0800 (PST)
Message-ID: <473313C2.7040506@joelhalpern.com>
Date: Thu, 08 Nov 2007 08:48:50 -0500
From: "Joel M. Halpern" 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IETF SIP List 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net
X-Spam-Status: No, hits=3.4 tagged_above=-999.0 required=7.0
	tests=RCVD_IN_SORBS_DUL, SPF_NEUTRAL
X-Spam-Level: ***
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I have been watching this discussion and getting confused.  (I tried
asking one person off list, and while I understand that person's
perspective, I am still confused about the discussion.)
I went back and re-read the document.

I also went back and re-read RFC 1984.
IETF policy is very clearly stated.  We are not to weaken security
mechanisms in order to enable interception.

So, as I read it, R24 seems to say that if you provide interception in
the protocol, then the presence or absence of such interception must not
be visible to the end user.  That by itself does not say we must provide
LI.  It certainly constrains any solution that claims to support LI.

Do folks read either R24 or some other requirement as mandating that the
IETF standardize an LI supporting solution?

Yes, I am aware that operators are required to provide LI.  And that if
the operator is providing  and mandating the cell phone, and the SIP
software on the cell phone, then one can argue that the operator must
provide meaningful LI (not just a trace of encrypted packets.)  But that
seems to me to be a choice the of the operator's deployment model.  If
the operator were not mandating the SIP stack, then they would not have
this issue.  (One can argue that we want the mechanism that they deploy
to be interoperable with the rest of the world.  But I think that has to
be done by the operator community chosing to constrain what they do, not
by constraining the internet secure RTP to be interoperable with an LI
regime.

There was some mention that the media recording requirement is relevant
to LI.  By my reading, that is an end-point recording capability
requirement that we want to have.  I doubt that the operators would
consider "ask the customer for the recording" an acceptable LI mechanism.

And asking the customer for the key on every call is clearly a
non-starter as a real-world solution to any of this.

Yours,
Joel M. Halpern

Elwell, John wrote:
> Dean,
> 
> Yes, I tend to agree that key disclosure to an authority on all calls
> passing through a domain with LI capability might be the way to go, but
> even then I see problems.
> 
> A UA has home domain A that is not required to do LI (an enterprise,
> say). On a call by call basis, the UA does not know whether the call
> will be routed (directly or indirectly) to a particular domain B that
> does LI (a carrier, say), so how does the UA find out that it needs to
> report its key to carrier B (or C or D....)?
> 
> Also, by doing this, any notion of end-to-end security has gone out of
> the window. If the key is disclosed to a third party, can the call
> really be used for sending banking details etc.? Surely the business
> world needs end-to-end security (or at least end-domain-to-end-domain
> security), as we have with HTTPS?
> 
> John
> 
>> -----Original Message-----
>> From: Dean Willis [mailto:dean.willis@softarmor.com] 
>> Sent: 07 November 2007 15:59
>> To: Elwell, John
>> Cc: Dan Wing; IETF SIP List
>> Subject: Re: [Sip] media-security-requirements and lawful intercept
>>
>>
>> On Nov 7, 2007, at 5:17 AM, Elwell, John wrote:
>>
>>> Dan,
>>>
>>> Speaking as an individual (not on behalf of another SDO), I don't
>>> believe it is possible to satisfy R24.
>>>
>>> With method a, the network element will not be able to provide
>>> appropriate credentials to satisfy a user that he is in 
>> communication
>>> with the remote user. Assuming RFC 4474 is used as the basis for
>>> authentication, the certificate provided by the 
>> Authentication Service
>>> acting on behalf of user A will sign the request and any self-signed
>>> certificate from UA that will be used in the DTLS handshake. Any
>>> substitution of that certificate by a network element would 
>> break the
>>> signature. Any attempt at changing the From URI and Identity header
>>> field by an Authentication Service acting on behalf of the network
>>> element would presumably use a certificate for that domain, not a
>>> certificate for user A's domain, so it would be clear to user B  
>>> that the
>>> call has come via that middle domain and is encrypted only as far as
>>> that middle domain.
>>>
>>> With method b, as already stated one of the users has to agree to
>>> disclose its key.
>> Right. I think R24 is awkwardly worded, and should be something like:
>>
>>     R24:   The media security key management protocol SHOULD NOT allow
>>            end users to determine whether a specific end-to-end
>>            interaction is being or will be lawfully intercepted.
>>
>> We know that all calls in a 3GPP-type network are subject to lawful  
>> interception. The question is "Is this specific call being  
>> intercepted or is it more likely to be intercepted than any 
>> other call?"
>>
>> This means that any visible mechanism (keys have to be 
>> disclosed or a  
>> decrypting relay agent) must be exercised for every call, otherwise  
>> the act of asking for a key on a specific would reveal that there is  
>> unusual interest in intercepting that specific call.
>>
>> So, if we (IETF) were to define a mechanism whereby a caller could  
>> electively disclose session keys to a 3rd party (such as a 
>> recorder),  
>> and some service provider (or national regulator) were to 
>> make use of  
>> this mechanism mandatory for all calls over specific infrastructure,  
>> I think everybody would be as satisfied as they're going to get.
>>
>> This does raise all sorts of questions like "What happens when two  
>> nodes cheat and report invalid session keys to the LI mechanism?",  
>> something that is obviously doable. But if you ponder it awhile, you  
>> realize that there's really nothing that can prevent two colluding  
>> nodes from applying a secondary encryption, just as there is no real  
>> way to prevent two speakers from talking in code. I once used a  
>> scrambler that clamped over a regular analog handpiece, did a A to D  
>> conversion, encrypted, converted the stream into FSK (sounded like  
>> fax), and inversed the process at the other end. That's why some  
>> countries made it illegal to use unlicensed fax machines and modems  
>> for a while -- anybody who was communicating securely needed to be  
>> investigated. It may also be why some countries originally 
>> refused to  
>> upgrade their filters and echo cancelers to support 14.4 modems. But  
>> that cat has long since gotten out of the bag and wandered off  
>> someplace. So the best the LI community can hope for is that the  
>> majority of nodes will cooperate and that auditing mechanisms will  
>> have some chance of detecting those that don't.
>>
>> --
>> Dean
>>
>>
>>
>>
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 10:10:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq90u-0007WI-Dt; Thu, 08 Nov 2007 10:09:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq90s-0007VX-CO
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:09:46 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq90r-0007VP-UB
	for sip@ietf.org; Thu, 08 Nov 2007 10:09:45 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq90r-0001Uw-DB
	for sip@ietf.org; Thu, 08 Nov 2007 10:09:45 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA8F9goj004216
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 8 Nov 2007 09:09:43 -0600
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 09:09:30 -0600
To: "Elwell, John" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: IETF SIP List , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 8, 2007, at 3:41 AM, Elwell, John wrote:

> Dean,
>
> Yes, I tend to agree that key disclosure to an authority on all calls
> passing through a domain with LI capability might be the way to go,  
> but
> even then I see problems.
>

No doubt.

> A UA has home domain A that is not required to do LI (an enterprise,
> say). On a call by call basis, the UA does not know whether the call
> will be routed (directly or indirectly) to a particular domain B that
> does LI (a carrier, say), so how does the UA find out that it needs to
> report its key to carrier B (or C or D....)?

The domain would have to get (and submit) the key for every call sent  
out through a regulated carrier.

I believe it's OK for a user to know whether a given call is being  
routed over a private network/Internet or is going through a  
regulated carrier, and therefore to know that any call being sent  
over the regulated carrier may be subject to LI.

> Also, by doing this, any notion of end-to-end security has gone out of
> the window. If the key is disclosed to a third party, can the call
> really be used for sending banking details etc.? Surely the business
> world needs end-to-end security (or at least end-domain-to-end-domain
> security), as we have with HTTPS?

Banks take calls over the PSTN every day with less assurance of  
integrity and privacy. The proposed approach provides much better  
security -- with "how much better" being limited by the scope of the  
key distribution. Optionally, one could propose the use of public-key  
or identity based crypto to further defend the session key, for  
example only sending it after encrypting it with the public key of  
the intended recipient.

Many financial and legal operations record every call, and therefore  
need a recorder that is either "in the session with a key" or on a  
second session that gets a twinning of the media. Some courts might  
argue that the second-session recording is inadmissible because it  
might have been undetectably altered (it wasn't exactly the same  
packets as received by the other end), so there are business legal  
reasons to have the recorder in the main media path. Eventually we're  
going to have media-level non-repudiation issues, so if you're  
looking for a Ph. D. project, that would be a good place to look.

I'm sure the auditing organizations will require record keeping on  
where the key goes and which systems have access to it, just as they  
are beginning to require around all credit-card transactions.

Sure, I want my calls to be as secure as possible. But there are  
operational environments where end-to-end crypto just isn't going to  
work.

We're at a decision point here -- do we follow RFC 1984 to the  
fullest extent and design a secure protocol that will have limited  
applicability, or do we design a protocol with broader applicability  
that has explicitly negotiated key sharing?

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 10:34:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq9P0-0004do-P7; Thu, 08 Nov 2007 10:34:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq9Oy-0004dA-Hq
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:34:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9Oy-0004d2-5g
	for sip@ietf.org; Thu, 08 Nov 2007 10:34:40 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9Ov-0000bj-IN
	for sip@ietf.org; Thu, 08 Nov 2007 10:34:40 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA8FYZAq004387
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 8 Nov 2007 09:34:36 -0600
In-Reply-To: <473313C2.7040506@joelhalpern.com>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 09:34:23 -0600
To: "Joel M. Halpern" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 8, 2007, at 7:48 AM, Joel M. Halpern wrote:

...

> Do folks read either R24 or some other requirement as mandating  
> that the
> IETF standardize an LI supporting solution?

No requirement can mandate that the IETF standardize an LI solution  
(since we just can't and won't do that). The requirements draft is  
being revised to describe the related requirements as external to the  
IETF.

Our proposed response to their requirements is to say "With SRTP/ 
DTLS, the endpoints have the keys. If you want it, you have to ask  
them for it. Here's one approach that you might use to do this. We  
may use this same approach to allow recording."

The other alternative is that we do not explain this in the response.  
Then it's either up to them to figure out how to ask for the keys  
(which they can quite well do without us), or to instead use a  
different key negotiation mechanism (such as S-Descriptions). Either  
way, LI is still going to occur. It'll just do so in a manner that  
doesn't interoperate with IETF-standard nodes. And it will cause the  
mobile/regulated community to start writing their own private, not- 
necessarily-publicly documented extensions to or "profiles of"  IETF  
protocols, which is something we've been trying to avoid. This might  
all be acceptable, but we need to understand the consequences.

...

> There was some mention that the media recording requirement is  
> relevant
> to LI.  By my reading, that is an end-point recording capability
> requirement that we want to have.  I doubt that the operators would
> consider "ask the customer for the recording" an acceptable LI  
> mechanism.
>

I'd say that under RFC 1984 a mechanism whereby they can ask the  
customer to allow them to record is the most we can give them. It's  
up to them as to whether their policy allows calls to proceed in the  
absence of that permission.

> And asking the customer for the key on every call is clearly a
> non-starter as a real-world solution to any of this.

Please explain the preceding.

Would the proposal not work?

Would the proposal have too much overhead to be cost-effective? It's  
got less overhead than the alternative of including (for every call)  
one or more media relays that act as  SRTP/DTLS endpoints, maintain  
two session keys per session, and decrypt/re-encrypt every packet. It  
has slightly more overhead than sending the media session key along  
the SIP path. It's also slightly more secure than sending the media  
session key along the SIP path.

Would the proposal fail to inform the user about the security  
constraints? From my POV, it is better for a user to say "Oh, I see  
this call is being routed over a regulated network, so the service  
provider and anybody they give the session key to can listen in"  
rather than to say "Oh, this call is being routed over a regulated  
network, and therefore I cannot use use any cryptography at all and  
anybody who can sniff my 802.11 packets can listen in."

What makes it a non-starter?

--
Dean



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 10:39:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq9TO-00018I-4U; Thu, 08 Nov 2007 10:39:14 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq9TK-000135-Ie
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:39:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9TJ-0000zk-PO
	for sip@ietf.org; Thu, 08 Nov 2007 10:39:09 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9TJ-0000mq-4l
	for sip@ietf.org; Thu, 08 Nov 2007 10:39:09 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns1.neustar.com (Postfix) with ESMTP id E6E8C26E4D;
	Thu,  8 Nov 2007 15:39:08 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1Iq9TI-0006ik-QF; Thu, 08 Nov 2007 10:39:08 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: vkg@alcatel-lucent.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Thu, 08 Nov 2007 10:39:08 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: sip@ietf.org, slawrence@bluesocket.com
Subject: [Sip] New Version Notification for draft-ietf-sip-eku-00 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-eku-00.txt has been successfuly submitted by Vijay Gurbani and posted to the IETF repository.

Filename:	 draft-ietf-sip-eku
Revision:	 00
Title:		 Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates
Creation_date:	 2007-11-08
WG ID:		 sip
Number_of_pages: 10

Abstract:
This memo documents an extended key usage (EKU) X.509 certificate
extension for identifying the holder of a certificate as
authoritative for a Session Initiation Protocol (SIP) service in the
domain named by the DNS name in the certificate.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 10:40:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq9UB-0002M6-Pd; Thu, 08 Nov 2007 10:40:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq9UB-0002Ly-7F
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:40:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq9UA-0002Lp-J2; Thu, 08 Nov 2007 10:40:02 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Iq9UA-0000pk-6w; Thu, 08 Nov 2007 10:40:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1AFD326E4D;
	Thu,  8 Nov 2007 15:40:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Iq9UA-00007N-0f; Thu, 08 Nov 2007 10:40:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Thu, 08 Nov 2007 10:40:02 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-eku-00.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates
	Author(s)       : S. Lawrence, V. Gurbani
	Filename        : draft-ietf-sip-eku-00.txt
	Pages           : 10
	Date            : 2007-11-08

This memo documents an extended key usage (EKU) X.509 certificate
extension for identifying the holder of a certificate as
authoritative for a Session Initiation Protocol (SIP) service in the
domain named by the DNS name in the certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-eku-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-eku-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-08103906.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-eku-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-eku-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-08103906.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Thu Nov 08 10:49:18 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq9cy-00041H-Oq; Thu, 08 Nov 2007 10:49:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq9cx-00040D-Ne
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:49:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9cx-0003zR-C1
	for sip@ietf.org; Thu, 08 Nov 2007 10:49:07 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9cu-0001Hn-Ka
	for sip@ietf.org; Thu, 08 Nov 2007 10:49:07 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lA8Fn3oa008655; 
	Thu, 8 Nov 2007 09:49:03 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lA8Fn2j05001; Thu, 8 Nov 2007 09:49:02 -0600 (CST)
Message-ID: <47332FEE.6020904@alcatel-lucent.com>
Date: Thu, 08 Nov 2007 09:49:02 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IETF SIP List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: "Jeffrey, Alan S A \(Alan\)" ,
	Scott Lawrence , "Drage,
	Keith \(Keith\)" ,
	Dean Willis 
Subject: [Sip] domain-certs and sip-eku drafts
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Folks: At the Chicago IETF, the work being done in domain-certs was
chartered as WG item.  Based on AD feedback since then, we have divided
domain-certs into two drafts:

   draft-ietf-sip-domain-certs and
   draft-ietf-sip-eku

-00 versions of these drafts are now available in the archive.

draft-ietf-sip-domain-certs-00 goes beyond RFC3261 to describe how
to use identities in X.509 certificates and perform mutual
authentication between two SIP domains.

draft-ietf-sip-eku defines an extended key usage extension
that identifies the holder of the certificate as authoritative
for a SIP service in a domain (the material split out from
domain-certs and put in sip-eku draft has been reviewed extensively
by PKIX WG.)

draft-ietf-sip-eku appears to have made it to the IETF archive
(see http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-00.txt).

draft-ietf-sip-domain-certs-00 appears to be stuck somewhere in
the automated IETF I-D submission tool.  Until that is sorted out,
you can get a copy from:
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-ietf-sip-domain-certs-00.txt
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-ietf-sip-domain-certs-00.html

Please review these drafts and let us know of any feedback and
comments.

Thanks.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 10:50:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq9ed-0006Gm-9e; Thu, 08 Nov 2007 10:50:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq9eb-0006GZ-6b
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:50:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9ea-0006GR-RY
	for sip@ietf.org; Thu, 08 Nov 2007 10:50:48 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq9ea-00033P-GF
	for sip@ietf.org; Thu, 08 Nov 2007 10:50:48 -0500
X-IronPort-AV: E=Sophos;i="4.21,389,1188792000"; d="scan'208";a="75478593"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2007 10:50:47 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA8FokIr024408; 
	Thu, 8 Nov 2007 10:50:46 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA8Fnpe2024346; 
	Thu, 8 Nov 2007 15:50:43 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 10:50:19 -0500
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 10:50:18 -0500
Message-ID: <4733303A.4070603@cisco.com>
Date: Thu, 08 Nov 2007 10:50:18 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>		<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
In-Reply-To: <098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2007 15:50:18.0955 (UTC)
	FILETIME=[101A51B0:01C8221F]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002
X-TM-AS-Result: No--11.649100-8.000000-2
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1388; t=1194537046;
	x=1195401046; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20
	|To:=20Dean=20Willis=20;
	bh=LfiZjrMvaXgThonIx8SLfo9mk2aavaEEbwNiL84ba8I=;
	b=jw8A1RKcDKWPOyvRY1DtWpuo/aWZZvvQ2s98pn8RKKLpm70QUm2Em/v4Fn2MRCdaiFrZICSn
	2sWiRgodxWb4C6rlV1fUmPDrI/TawMNCOgn3JDu5YPGiZwJ8WPpNrNCa;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: IETF SIP List , "Elwell, John" ,
	Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:

[snip]

> We're at a decision point here -- do we follow RFC 1984 to the fullest 
> extent and design a secure protocol that will have limited 
> applicability, or do we design a protocol with broader applicability 
> that has explicitly negotiated key sharing?

I don't want to see sip relegated to specialty applications and excluded 
from most common usage.

Having the key disclosure explicit to the UAs seems a better. I guess 
one might ask why a UA would ever agree to disclose its keys, but the 
answer clearly is that it might do so if it has no other option that 
allows making the call.

If it is explicit to the UA, then the UA can indicate to the user that 
the key has been disclosed for this call. (This is another aspect of the 
"lock icon" discussion that is still lurking out there.) Having an 
indication that the call is *eligible for LI* is different from knowing 
that it is being intercepted. It had better be legal to disclose that.

Calls via phones that are directly connected to a carrier would always 
indicate they are eligible for LI, so it might not be a very interesting 
datum. But phones connected to corporate systems might be subject to LI 
only for calls routed via a carrier, not for internal calls. So the 
indicator could be useful for deciding what to discuss or not discuss.

	Thanks,
	Paul


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 11:04:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iq9rq-0003se-83; Thu, 08 Nov 2007 11:04:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iq9ro-0003ox-A1
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 11:04:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9rn-0003ne-DL
	for sip@ietf.org; Thu, 08 Nov 2007 11:04:27 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq9rm-0003XK-Fx
	for sip@ietf.org; Thu, 08 Nov 2007 11:04:27 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JR70026T36RPB@siemenscomms.co.uk> for sip@ietf.org; Thu,
	08 Nov 2007 16:03:15 +0000 (GMT)
Date: Thu, 08 Nov 2007 16:02:56 +0000
From: "Elwell, John" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
In-reply-to: <098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
To: Dean Willis 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E93B7@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgiGX5Bfufk9mDJSw6pP/0xyhqyGAABcfgg
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: IETF SIP List , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dean,

More in-line.

John 

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com] 
> Sent: 08 November 2007 15:10
> To: Elwell, John
> Cc: Dan Wing; IETF SIP List
> Subject: Re: [Sip] media-security-requirements and lawful intercept
> 
> 
> On Nov 8, 2007, at 3:41 AM, Elwell, John wrote:
> 
> > Dean,
> >
> > Yes, I tend to agree that key disclosure to an authority on 
> all calls
> > passing through a domain with LI capability might be the 
> way to go,  
> > but
> > even then I see problems.
> >
> 
> No doubt.
> 
> > A UA has home domain A that is not required to do LI (an enterprise,
> > say). On a call by call basis, the UA does not know whether the call
> > will be routed (directly or indirectly) to a particular 
> domain B that
> > does LI (a carrier, say), so how does the UA find out that 
> it needs to
> > report its key to carrier B (or C or D....)?
> 
> The domain would have to get (and submit) the key for every 
> call sent  
> out through a regulated carrier.
> 
> I believe it's OK for a user to know whether a given call is being  
> routed over a private network/Internet or is going through a  
> regulated carrier, and therefore to know that any call being sent  
> over the regulated carrier may be subject to LI.
[JRE] He would need to be made aware of this somehow. Often he can't
tell in advance whether a call is to be routed via a carrier or not.

> 
> > Also, by doing this, any notion of end-to-end security has 
> gone out of
> > the window. If the key is disclosed to a third party, can the call
> > really be used for sending banking details etc.? Surely the business
> > world needs end-to-end security (or at least 
> end-domain-to-end-domain
> > security), as we have with HTTPS?
> 
> Banks take calls over the PSTN every day with less assurance of  
> integrity and privacy. The proposed approach provides much better  
> security -- with "how much better" being limited by the scope of the  
> key distribution. Optionally, one could propose the use of 
> public-key  
> or identity based crypto to further defend the session key, for  
> example only sending it after encrypting it with the public key of  
> the intended recipient.
[JRE] Yes, of course any key disclosure would itself need to be
protected. I guess I am reasonably happy with submitting a key to a
known law enforcement authority (or perhaps to my enterprise, which then
forwards it to a known law enforcement authority), but I am far less
happy about having to send it to any carrier that happens to get
involved in the routing of that outgoing or incoming call.

> 
> Many financial and legal operations record every call, and therefore  
> need a recorder that is either "in the session with a key" or on a  
> second session that gets a twinning of the media. Some courts might  
> argue that the second-session recording is inadmissible because it  
> might have been undetectably altered (it wasn't exactly the same  
> packets as received by the other end), so there are business legal  
> reasons to have the recorder in the main media path. 
> Eventually we're  
> going to have media-level non-repudiation issues, so if you're  
> looking for a Ph. D. project, that would be a good place to look.
> 
> I'm sure the auditing organizations will require record keeping on  
> where the key goes and which systems have access to it, just as they  
> are beginning to require around all credit-card transactions.
> 
> Sure, I want my calls to be as secure as possible. But there are  
> operational environments where end-to-end crypto just isn't going to  
> work.
[JRE] I agree with most of what you say above, and within an enterprise
this is OK. After all, an RFC 4474 signature by example.com only
guarantees the integrity of the message from the example.com domain
onwards, and what happens in that domain, such as recording for auditing
purposes, is fair game. What I don't want to do is have some
intermediate domain getting in and decrypting the media, unless there is
some assurance that it is for authorised law enforcement purposes only.

> 
> We're at a decision point here -- do we follow RFC 1984 to the  
> fullest extent and design a secure protocol that will have limited  
> applicability, or do we design a protocol with broader applicability  
> that has explicitly negotiated key sharing?
[JRE] I think we have to do the latter, but we should be very careful
what mechanism we select.

> 
> --
> Dean
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 11:36:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqAMx-0007Yc-2P; Thu, 08 Nov 2007 11:36:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqAMv-0007Y0-IC
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 11:36:37 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAMu-0007Wl-Ms
	for sip@ietf.org; Thu, 08 Nov 2007 11:36:36 -0500
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqAMu-0004Tn-FN
	for sip@ietf.org; Thu, 08 Nov 2007 11:36:36 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns3.neustar.com (Postfix) with ESMTP id 180D3175AB;
	Thu,  8 Nov 2007 16:36:36 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IqAMt-00076H-K3; Thu, 08 Nov 2007 11:36:35 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: vkg@alcatel-lucent.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Thu, 08 Nov 2007 11:36:35 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: sip@ietf.org, ajeffrey@alcatel-lucent.com, slawrence@bluesocket.com
Subject: [Sip] New Version Notification for draft-ietf-sip-domain-certs-00 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-domain-certs-00.txt has been successfuly submitted by Vijay Gurbani and posted to the IETF repository.

Filename:	 draft-ietf-sip-domain-certs
Revision:	 00
Title:		 Domain Certificates in the Session Initiation Protocol (SIP)
Creation_date:	 2007-11-08
WG ID:		 sip
Number_of_pages: 15

Abstract:
This document describes how to interpret certain information in a
X.509 PKIX-compliant certificate used in a Transport Layer Security
(TLS) connection.  More specifically, it describes how to find the
right identity for authentication in such certificates and how to use
it for mutual authentication.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 11:40:05 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqAQG-0002yp-Hw; Thu, 08 Nov 2007 11:40:04 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqAQF-0002xf-7P
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 11:40:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqAQE-0002xH-Sk; Thu, 08 Nov 2007 11:40:02 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IqAQE-0002st-D5; Thu, 08 Nov 2007 11:40:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4808126E5C;
	Thu,  8 Nov 2007 16:40:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IqAQE-0003UI-6d; Thu, 08 Nov 2007 11:40:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Thu, 08 Nov 2007 11:40:02 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-domain-certs-00.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Domain Certificates in the Session Initiation Protocol (SIP)
	Author(s)       : V. Gurbani, et al.
	Filename        : draft-ietf-sip-domain-certs-00.txt
	Pages           : 15
	Date            : 2007-11-08

This document describes how to interpret certain information in a
X.509 PKIX-compliant certificate used in a Transport Layer Security
(TLS) connection.  More specifically, it describes how to find the
right identity for authentication in such certificates and how to use
it for mutual authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-domain-certs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-domain-certs-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-08113632.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-domain-certs-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-domain-certs-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-08113632.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Thu Nov 08 11:47:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqAXO-0005wY-1l; Thu, 08 Nov 2007 11:47:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqAXM-0005tg-LO
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 11:47:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAXM-0005sO-Ad
	for sip@ietf.org; Thu, 08 Nov 2007 11:47:24 -0500
Received: from bender-mail.tigertech.net ([64.62.209.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqAXJ-0003H1-Ob
	for sip@ietf.org; Thu, 08 Nov 2007 11:47:24 -0500
Received: from localhost (localhost [127.0.0.1])
	by bender.tigertech.net (Postfix) with ESMTP id E3E187DB5
	for ; Thu,  8 Nov 2007 08:47:20 -0800 (PST)
Received: from [192.168.2.173] (jupiter.inet.qwest.net [67.133.255.125])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bender.tigertech.net (Postfix) with ESMTP id 82D947DB7
	for ; Thu,  8 Nov 2007 08:47:16 -0800 (PST)
Message-ID: <47333D93.8040700@joelhalpern.com>
Date: Thu, 08 Nov 2007 11:47:15 -0500
From: "Joel M. Halpern" 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IETF SIP List 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
	
In-Reply-To: 
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net
X-Spam-Status: No, hits=1.4 tagged_above=-999.0 required=7.0 tests=SPF_NEUTRAL
X-Spam-Level: *
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> I Said:
>> And asking the customer for the key on every call is clearly a
>> non-starter as a real-world solution to any of this.
> 
> and Dean responded:
> Please explain the preceding.

So I will elaborate.

The issue with answering is that there are several different assumptions
that one might make about how this would work.  I am unlikely to cover
the cases other people may be thinking of.

So, assume first that the behavior is that the system asks the client
for the keys, and the client asks the user if it is acceptable to
deliver the keys.
As Dean observed, if you are going to do this and meet R24 (which is
clearly mandatory for any meaningful LI), then any network that might
ask for the key has to ask for it every time, whether it uses it or not.

If the users actually had a choice, then asking them might (barely) make
some sense.  But if the users can say no, then they should be trained to
always say no.  And then we don't have an LI solution.

So, if the user says no, when asked if the device can deliver the key,
then the user will not be permitted to make the call on that network.
Thus, the defined system behavior can be paraphrased as "Make it easy
for the system to ask for the key, and train the users to say yes
whenever they are asked for the key."

As far as I am concerned, that is NOT a secure solution.  That is a
pretense of security.  It would be more honest for such networks to
simply refuse to permit encrypted media at any time.

Yours,
Joel

PS: I don't know how the following complication further plays into it:
What stops the handset from delivering a false key?  I suppose we could
define a solution where there is an interface for the system to ask for
a key, and the system hands over whatever it feels like.  The carriers
can then try to ensure that their "approved handsets" hand over the real
key?



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 12:11:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqAv1-000568-BW; Thu, 08 Nov 2007 12:11:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqAuz-00055p-UK
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:11:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAuz-00055f-JO
	for sip@ietf.org; Thu, 08 Nov 2007 12:11:49 -0500
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqAuv-00042i-IV
	for sip@ietf.org; Thu, 08 Nov 2007 12:11:49 -0500
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lA8HBh1l007484
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 8 Nov 2007 09:11:43 -0800
Received: from [129.46.78.80] (carbuncle.qualcomm.com [129.46.78.80])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	lA8HBfaI018745; Thu, 8 Nov 2007 09:11:41 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4733303A.4070603@cisco.com>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
	<4733303A.4070603@cisco.com>
Date: Thu, 8 Nov 2007 09:11:40 -0800
To: Paul Kyzivat , Dean Willis 
From: Ted Hardie 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -4.0 (----)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: IETF SIP List , "Elwell, John" ,
	Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 10:50 AM -0500 11/8/07, Paul Kyzivat wrote:
>Dean Willis wrote:
>
>[snip]
>
>>We're at a decision point here -- do we follow RFC 1984 to the fullest extent and design a secure protocol that will have limited applicability, or do we design a protocol with broader applicability that has explicitly negotiated key sharing?
>
>I don't want to see sip relegated to specialty applications and excluded from most common usage.
>
>Having the key disclosure explicit to the UAs seems a better. I guess one might ask why a UA would ever agree to disclose its keys, but the answer clearly is that it might do so if it has no other option that allows making the call.

You mention below the "lock icon" problem, but that is a subset of the larger
mental model question.  How is the user who has no choices but: 

1) no call
2) a call for which it must divulge keys

to distinguish between that condition and "The security set-up for this call has failed. 
Do you wish to continue the call anyway?"  From at least one perspective, the
security set-up for the call has failed if the keys have been forced from the user;
they no longer have any assurance as to the confidentiality of the call. 
I strongly believe that the UI revelation of the key sharing would be minimal or
elided; in your scenario, at least, all carrier calls would have this marker as
a  base state.  Any warning that common must be expected to be ignored, and
a good UI designer is simply going to get it out of the attention field of the user.
In other words, this mechanism will likely be invoked with no attention from
the user, with the result that the security characteristics of the call will be
fundamentally different from the users' expectations.

So, what are we left with?  From my perspective, any work on this would have
to be explicitly done in the context of RFC 1984.  That may well mean setting
out a reasoned discussion of why the interoperability of the mechanism justifies
the work here.  If I hear you right, that statement would be something like:

"We judge  having a single signaling system to be of such
over-riding importance that the inclusion of an optional system for
the sharing of keys to support LI is justified.  We further strongly encourage the
development and deployment of systems which notify the end user when these
mechanisms have been invoked, as well as the deployment of systems which
do not include this optional mechanism.  While these latter systems will fail in
the presence of key demands, they will also serve as the most potent possible
reminder of the prevalence of potential surveillance."

But I think that statement needs to be in public, in a context that engages the
rest of the IETF and Internet community in an open discussion as to whether
need for a single signalling system does  over-ride the concerns expressed
in RFC 1984. 

Speaking personally, it does not do so for me.  Recent experience has shown
a tendency toward data mining approaches to interception that make me
believe that the inclusion of this mechanism will support the continuation
of an epic invasion of privacy that is loosely targeted, extraordinarily
easy to abuse, and for which over-sight has been minimal and public debate
gagged.  Hobbling a mechanism which can maintain privacy in such an
environment is irresponsible.  It is also contrary to the expressed wishes of
the IETF, as set forward in a document that was much debated.

Yes, I understand the problems that this presents, both for interoperability
and the action of lawful intercept.  But I believe that forcing a break here
is honestly the better choice for the Internet and for the future of IETF
technologies.  If we do not maintain at least one system capable of maintaining
privacy, we are  pushing  all communications users into a panopticon
future for their personal communications.

Speaking for me, personally, the costs are too high.  If the working group
does decide to move forward here, I will strongly urge early review by
the broader IETF community, as the consequences of this decision are not
light.

My thanks, Paul, for your reasoned statements; please do take my response
to be directed to you personally.
				regards,
					Ted Hardie


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 12:14:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqAxz-0000HU-6L; Thu, 08 Nov 2007 12:14:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqAxx-0000Gh-Ut
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:14:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAxx-0000C9-HD
	for sip@ietf.org; Thu, 08 Nov 2007 12:14:53 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqAxw-0005t9-T4
	for sip@ietf.org; Thu, 08 Nov 2007 12:14:53 -0500
X-IronPort-AV: E=Sophos;i="4.21,390,1188792000"; d="scan'208";a="75487695"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2007 12:14:52 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA8HEpqB007371; 
	Thu, 8 Nov 2007 12:14:51 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA8HEFe4023633; 
	Thu, 8 Nov 2007 17:14:46 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 12:14:41 -0500
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 12:14:40 -0500
Message-ID: <47334400.8090103@cisco.com>
Date: Thu, 08 Nov 2007 12:14:40 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Joel M. Halpern" 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>		<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>	<473313C2.7040506@joelhalpern.com>	
	<47333D93.8040700@joelhalpern.com>
In-Reply-To: <47333D93.8040700@joelhalpern.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2007 17:14:40.0746 (UTC)
	FILETIME=[D92A54A0:01C8222A]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002
X-TM-AS-Result: No--18.551600-8.000000-2
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3294; t=1194542091;
	x=1195406091; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20
	|To:=20=22Joel=20M.=20Halpern=22=20;
	bh=5Sb8SjE8XhGSJ+mSvJbk5fe3RaDj16aRl84FlnLzD6o=;
	b=gUcBBMBEuRMFgBy/jrbEbw9kU+M2pD7j5qdrFMM4tqXxW8OzInJo/qAyEUKN4iW2A/YP7Vze
	mzUQk78InLmDRvMUsUmYcD4uQO55KyCw9wpZkxzY7HI6TNuU4lZ8Ultk;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I think this could evolve into a situation where carriers subject to LI 
always request a key and refuse to carry the call unless they get it. If 
a call path can be found that doesn't involve such a carrier then a key 
won't need to be disclosed. People that want calls that can't be 
intercepted will then seek out a connection point where they can connect 
without giving their key.

A PBX in an office is an example. A worldwide enterprise that maintains 
its own network between offices is another example. (Of course that 
could be tunneled over a carrier network via VPNs and would (I think) 
still bypass the LI requirement of the carrier. But maybe not.)

It would be interesting to see when an organization doing that will be 
required to satisfy the LI requirements. Could the IETF manage its own 
VoIP network for use by ietf participants? Is it a matter of whether 
money changes hands? Or how closely affiliated the users are?

	Paul

Joel M. Halpern wrote:
>> I Said:
>>> And asking the customer for the key on every call is clearly a
>>> non-starter as a real-world solution to any of this.
>> and Dean responded:
>> Please explain the preceding.
> 
> So I will elaborate.
> 
> The issue with answering is that there are several different assumptions
> that one might make about how this would work.  I am unlikely to cover
> the cases other people may be thinking of.
> 
> So, assume first that the behavior is that the system asks the client
> for the keys, and the client asks the user if it is acceptable to
> deliver the keys.
> As Dean observed, if you are going to do this and meet R24 (which is
> clearly mandatory for any meaningful LI), then any network that might
> ask for the key has to ask for it every time, whether it uses it or not.
> 
> If the users actually had a choice, then asking them might (barely) make
> some sense.  But if the users can say no, then they should be trained to
> always say no.  And then we don't have an LI solution.
> 
> So, if the user says no, when asked if the device can deliver the key,
> then the user will not be permitted to make the call on that network.
> Thus, the defined system behavior can be paraphrased as "Make it easy
> for the system to ask for the key, and train the users to say yes
> whenever they are asked for the key."
> 
> As far as I am concerned, that is NOT a secure solution.  That is a
> pretense of security.  It would be more honest for such networks to
> simply refuse to permit encrypted media at any time.
> 
> Yours,
> Joel
> 
> PS: I don't know how the following complication further plays into it:
> What stops the handset from delivering a false key?  I suppose we could
> define a solution where there is an interface for the system to ask for
> a key, and the system hands over whatever it feels like.  The carriers
> can then try to ensure that their "approved handsets" hand over the real
> key?
> 
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 13:32:01 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqCAM-0006Ci-BJ; Thu, 08 Nov 2007 13:31:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqCAL-0006Cc-Bb
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 13:31:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCAL-0006CT-1P
	for sip@ietf.org; Thu, 08 Nov 2007 13:31:45 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IqCAI-0007Da-3k for sip@ietf.org; Thu, 08 Nov 2007 13:31:45 -0500
X-IronPort-AV: E=Sophos;i="4.21,391,1188802800"; d="scan'208";a="544646156"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-3.cisco.com with ESMTP; 08 Nov 2007 10:31:19 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA8IVJqJ007027; 
	Thu, 8 Nov 2007 10:31:19 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8IVIej004229;
	Thu, 8 Nov 2007 18:31:19 GMT
From: "Dan Wing" 
To: "'Elwell, John'" ,
	"'IETF SIP List'" 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	<101a01c82159$e3202600$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E92BD@GBNTHT12009MSX.gb002.siemens.net>
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 10:31:18 -0800
Message-ID: <3a3c01c82235$8dd1d810$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcggnYz0vr1y5PPGSTSoHa6HBVInvwAkJuKQAApfgsAAJFN84AANzxgQ
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03E92BD@GBNTHT12009MSX.gb002.siemens.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5719; t=1194546679;
	x=1195410679; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=p3bm3ic4J3birWosfIhlsJZI0b7GmnV+sDaECRxUelU=;
	b=NK2r18o/0cHZ4113okM9xmNGCQM8XAOtfEwaeFXtLx8VH2UqFlolj/EbbaOQ1D9yFQKYTn1n
	XgtQDQ+A3dtOVl9MV5ItFUrG7ELmOtC0CUMgeNx4+xDtd46tMvuq+3fx;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


> > Method 'a' could be achieved if the interception (and DTLS 
> > handshake)
> > occurred within the originating domain, prior to the RFC4474
> > signature.  This can allow inserting the man in the middle at that
> > point.  This would need to be done for every call (not just 
> > calls being intercepted).
>
> [JRE] This wouldn't work if LI is not being done in the originating
> domain. Enterprise UA issues INVITE request, enterprise proxy addes
> Identity header field and forwards to public service provider, which
> needs the possibility to intercept.

Good point; I had only been considering handsets in IMS (3GPP)
networks.  I'll give that some more thought.

> > > Assuming RFC 4474 is used as the basis for
> > > authentication, the certificate provided by the 
> > Authentication Service
> > > acting on behalf of user A will sign the request and any 
> self-signed
> > > certificate from UA that will be used in the DTLS handshake. Any
> > > substitution of that certificate by a network element would 
> > break the
> > > signature. Any attempt at changing the From URI and 
> Identity header
> > > field by an Authentication Service acting on behalf of the network
> > > element would presumably use a certificate for that domain, not a
> > > certificate for user A's domain, so it would be clear to user 
> > > B that the
> > > call has come via that middle domain and is encrypted 
> only as far as
> > > that middle domain.
> > 
> > I agree that after the RFC4474 signature is created, other domains
> > can't become a man in the middle.
> > 
> > > With method b, as already stated one of the users has to agree to
> > > disclose its key.
> > 
> > The network can enforce that by blocking SRTP until the key is 
> > disclosed.  Some networks that block RTP until 200 Ok for fraud
> > prevention, and those same networks have LI requirements placed
> > on them by their government.  Those networks could, similarly, block
> > SRTP until the key is disclosed, and could validate that the 
> > supplied key does decrypt SRTP (especially SRTP that is protected
> > with an authentication tag).
>
> [JRE] I don't see how it could verify a key if the 
> authentication tag is not used.  Maybe it is easier for SRTCP than for SRTP,

> but that might
> involve some unacceptable delay before the first SRTCP packet arrives.
> Having said that, I would have thought the authentication tag would
> normally be used, since otherwise the security provided is rather
> dubious.

Agreed.  And, today, all of the SRTP crypto suites in RFC3711 have an 
authentication tag and as far as I know everyone is using it.

However, it is my understanding that SRTP with Galois/Counter Mode (GCM) 
would not need (or use) an authentication tag.  I don't know how a GCM
key would be validated.  That was my concern there.

-d

 
> > 
> > -d
> > 
> > > John
> > > 
> > > > -----Original Message-----
> > > > From: Dan Wing [mailto:dwing@cisco.com] 
> > > > Sent: 06 November 2007 17:51
> > > > To: 'IETF SIP List'
> > > > Subject: [Sip] media-security-requirements and lawful intercept
> > > > 
> > > > Other SDOs have lawful intercept requirements, which 
> are currently
> > > > captured in requirement R24 in 
> > > > draft-ietf-sip-media-security-requirements-00:
> > > > 
> > > >    "R24:   The media security key management protocol SHOULD 
> > > >            NOT allow end users to determine whether their 
> > > >            end-to-end interaction is subject to lawful 
> > > >            interception."
> > > > 
> > > > DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
> > > > to establish SRTP keys for unicast, point-to-point SRTP 
> sessions.
> > > > 
> > > > There appear to be two methods to meet R24 with DTLS-SRTP.  They
> > > > are:
> > > > 
> > > >    a. provide a network element on every SRTP call which relays
> > > >       media, performs a DTLS handshake, and decrypts and 
> > re-encrypts
> > > >       SRTP, or;
> > > > 
> > > >    b. have endpoints perform key disclosure for every 
> > call (using a 
> > > >       technique similar to draft-wing-sipping-srtp-key), 
> > and perform
> > > >       validation of that disclosed key on every call.
> > > > 
> > > > If these methods to meet R24 are deemed acceptable to 
> other SDOs,
> > > > we don't find any reason for those SDOs to reject 
> IETF's decision
> > > > to use DTLS-SRTP as the preferred mechanism to establish SRTP
> > > > keys for unicast, point-to-point SRTP sessions.
> > > > 
> > > > Comments welcome.
> > > > -d
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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
> > 
> > 
> > _______________________________________________
> > 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
> > 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 13:33:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqCBd-0007Sw-Vf; Thu, 08 Nov 2007 13:33:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqCBc-0007Sq-IY
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 13:33:04 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCBc-0007S9-57
	for sip@ietf.org; Thu, 08 Nov 2007 13:33:04 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqCBb-0000R2-HO
	for sip@ietf.org; Thu, 08 Nov 2007 13:33:03 -0500
X-IronPort-AV: E=Sophos;i="4.21,391,1188802800"; d="scan'208";a="414560621"
Received: from syd-dkim-1.cisco.com ([64.104.193.116])
	by sj-iport-2.cisco.com with ESMTP; 08 Nov 2007 10:33:02 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA8IWv5i011964; 
	Fri, 9 Nov 2007 05:32:58 +1100
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA8IWufb027025;
	Thu, 8 Nov 2007 18:32:56 GMT
From: "Dan Wing" 
To: "'Fischer, Kai'" ,
	"'Elwell, John'" ,
	"'IETF SIP List'" 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	<101a01c82159$e3202600$c4f0200a@cisco.com>
	<198A10EC585EC74687BCA414E2A5971801E47913@MCHP7RDA.ww002.siemens.net>
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 10:32:55 -0800
Message-ID: <3a3d01c82235$c807bae0$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcggnYz0vr1y5PPGSTSoHa6HBVInvwAkJuKQAApfgsAAIZjeYAAQRcCA
In-Reply-To: <198A10EC585EC74687BCA414E2A5971801E47913@MCHP7RDA.ww002.siemens.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3460; t=1194546778;
	x=1195410778; c=relaxed/simple; s=syddkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=NaKbllm1UACTKHEu1LhTVbiuGpYitde1wEx4TVO4xF4=;
	b=botOi1cDtUq2OoDWutYQZap2G7U+kxK+YpaBFqxdzqw2BlrhAusGf2OC9vjbjxuLvjp6yNTF
	bBmg+8bI4kZdyimbtXl3jJdIHR6dKN+V5WHEpOCO6M/5DT2Qhg+EGL+1vMEFr7wMIGl/6UHOvu
	m4ew7x4CDMgwyCW+jfrH3V2qU=;
Authentication-Results: syd-dkim-1; header.From=dwing@cisco.com; dkim=pass (
	sig from cisco.com/syddkim1002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


> > Method 'a' could be achieved if the interception (and DTLS 
> > handshake)
> > occurred within the originating domain, prior to the RFC4474
> > signature.  This can allow inserting the man in the middle at that
> > point.  This would need to be done for every call (not just 
> > calls being intercepted).
> 
> This might be a solution, but not a very attractive one, since every
> call is intercepted and needs to be decrypted and encrypted again.

Yes, I agree it is computationally expensive.

> One
> argument for DTLS-SRTP is the end-to-end security capability, 
> which will be weakened for every call in this case.

LI weakens end-to-end security, no matter the technique chosen.  Today
things are very weak (media is unencrypted).  Security Descriptions 
places trust on every SIP signaling element on the path.  DTLS-SRTP,
with the "a" technique, doesn't place trust on every element, but just
one.

> > 
> > > Assuming RFC 4474 is used as the basis for
> > > authentication, the certificate provided by the 
> > > Authentication Service
> > > acting on behalf of user A will sign the request and any 
> > > self-signed
> > > certificate from UA that will be used in the DTLS handshake. Any
> > > substitution of that certificate by a network element would 
> > > break the
> > > signature. Any attempt at changing the From URI and 
> > > Identity header
> > > field by an Authentication Service acting on behalf of the network
> > > element would presumably use a certificate for that domain, not a
> > > certificate for user A's domain, so it would be clear to user 
> > > B that the
> > > call has come via that middle domain and is encrypted 
> > > only as far as
> > > that middle domain.
> > 
> > I agree that after the RFC4474 signature is created, other domains
> > can't become a man in the middle.
> > 
> > > With method b, as already stated one of the users has to agree to
> > > disclose its key.
> > 
> > The network can enforce that by blocking SRTP until the key is 
> > disclosed.  Some networks that block RTP until 200 Ok for fraud
> > prevention, and those same networks have LI requirements placed
> > on them by their government.  Those networks could, similarly, block
> > SRTP until the key is disclosed, and could validate that the 
> > supplied key does decrypt SRTP (especially SRTP that is protected
> > with an authentication tag).
> 
> How is it possible to perform a DTLS handshake if the RTP traffic /
> ports are blocked?

It isn't.  You would need to perform the DTLS handshake when the
RTP path is open, or you would need to perform the DTLS handshake
over RTCP (which is not part of the DTLS-SRTP specification set
at this point in time; there is an offline discussion about this
very problem with DTLS-SRTP and some solutions to that problem.  I
expect to see some email traffic on this specific issue shortly.)

> Are these blocking network components able to analyze
> the first byte of the packets and to distinguish between RTP and DTLS
> traffic?

Today, they do not do that, because they do not need to do that.  
They could become capable of doing that.  It is my understanding that,
because today there is no need for those elements to do such
content-based filtering, only simple filters (allow/deny) have been
defined in the relevant specifications and only simple filters
have been implemented by vendors in product.

-d


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 13:33:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqCC7-0007lb-9a; Thu, 08 Nov 2007 13:33:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqCC6-0007lR-1M
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 13:33:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCC5-0007lI-Lt
	for sip@ietf.org; Thu, 08 Nov 2007 13:33:33 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqCC5-0000SP-49
	for sip@ietf.org; Thu, 08 Nov 2007 13:33:33 -0500
X-IronPort-AV: E=Sophos;i="4.21,391,1188802800"; d="scan'208";a="31214627"
Received: from syd-dkim-1.cisco.com ([64.104.193.116])
	by sj-iport-1.cisco.com with ESMTP; 08 Nov 2007 10:33:31 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA8IXUWI013369; 
	Fri, 9 Nov 2007 05:33:30 +1100
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA8IXOfb027565;
	Thu, 8 Nov 2007 18:33:29 GMT
From: "Dan Wing" 
To: "'Ted Hardie'" ,
	"'Paul Kyzivat'" ,
	"'Dean Willis'" 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
	<4733303A.4070603@cisco.com> 
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 10:33:23 -0800
Message-ID: <3a3e01c82235$db788960$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgiKnXGGin2CipBQAuikn6bUJlZ/gABmCAg
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2869; t=1194546810;
	x=1195410810; c=relaxed/simple; s=syddkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=FooUptjh9i5O5SjtCh7aRNkDof5OXdSj+nnOph3wx8g=;
	b=DWqXqFgQN3yXypKcrj7cEtEAZEAvW4DpTcLTEa7fN0agxW4mqFlPr7CKxlcodbsSd5G2dgEj
	b3uOJKluZFdQlJczUgA4ZEKbX4DQKaFo9s9B4SHZ5XQrHpHjmRR202ESeZAO8/El/Gd6aoUWN0
	OZoNqTfvPH6HXpKU9DfJWFQu4=;
Authentication-Results: syd-dkim-1; header.From=dwing@cisco.com; dkim=pass (
	sig from cisco.com/syddkim1002 verified; ); 
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 'IETF SIP List' , "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Ted,

> ...
> Speaking for me, personally, the costs are too high.  If the 
> working group does decide to move forward here, I will strongly 
> urge early review by the broader IETF community, as the consequences 
> of this decision are not light.
> ...

Thanks for your email.  I agree this needs wider discussion and the
WG (and probably RAI as a whole) needs to decide what it wants to do.

The wider consequence, however, is not increased "epic invasion of 
privacy", as you state.  The wider consequence is that, without a
suitable mechanism that meets the needs of LI for SRTP, networks 
subject to LI will only ever be able to do RTP.  The choices, as I
see them, are (in order of least secure to most secure):

 1. everyone can listen to the call.  This is what we have today
    with RTP.  This allows 'epic invasion of privacy' by all 
    parties (governments, criminals, and anyone who is able to
    receive your RTP)
 2. every SIP entity learns the SRTP keys.  This is what would
    happen with Security Descriptions.  This allows 'epic 
    invasion of privacy' by any party that has control of any
    SIP entity your Invite (or its response) traversed.  That
    control could be legitimate or could be illegitimate 
    (government or criminal hacked into the SIP proxy).
 3. only a specific SIP entity learns the SRTP key.  This is
    what would happen in the two techniques I proposed at the
    beginning of this thread.  This allows 'epic invasion of
    privacy' by any party that has control of that specific
    SIP entity.  That control could be legitimate or could be
    illegitimate (government or criminal hacked into that 
    specific SIP proxy).
 4. IETF sticks with only doing DTLS-SRTP and provides no 
    guidance for how to meet LI requirements.

The choice, as IETF has always seen it, is to stick with IETF's first
principles [RFC1984, RFC2804] which is end-to-end crypto is best (4) and
market and legal requirements are not relevant to IETF's standards.  I agree
it is a laudable and worthy goal.  I could even agree that we should leave it
to other SDOs, who deal more closely with LI requirements, to determine how
those LI requirements can be met.  

Yet, IETF has also said that IETF owns the SIP standards (and related
standards).  

Taking your suggestion would mean we do (4) and have other SDOs decide if and
how to accomplish a weaker, LI-friendly solution (1, 2, or 3), and IETF should
not provide guidance for the most secure (3) of those remaining LI-friendly
approaches.  The result is undesirable:  millions of users will be unprotected
because they will only have plain RTP (1) or they will be vulnerable to every
SIP proxy on their path (2); (3) is difficult, and (4) will be undeployable by
licensed providers in many countries around the world.

-d


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 14:06:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqChd-0003tV-Aq; Thu, 08 Nov 2007 14:06:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqChb-0003qV-R0
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 14:06:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqChb-0003qN-DD
	for sip@ietf.org; Thu, 08 Nov 2007 14:06:07 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqCha-0001ch-Ed
	for sip@ietf.org; Thu, 08 Nov 2007 14:06:07 -0500
X-IronPort-AV: E=Sophos;i="4.21,391,1188792000"; d="scan'208";a="75499198"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2007 14:06:06 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA8J65tu022514; 
	Thu, 8 Nov 2007 14:06:05 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8J5rWZ024089; 
	Thu, 8 Nov 2007 19:06:04 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 14:05:57 -0500
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 14:05:57 -0500
Message-ID: <47335E14.1020105@cisco.com>
Date: Thu, 08 Nov 2007 14:05:56 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Hardie 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
	<4733303A.4070603@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2007 19:05:57.0124 (UTC)
	FILETIME=[6498C440:01C8223A]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002
X-TM-AS-Result: No--17.974900-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7086; t=1194548765;
	x=1195412765; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20
	|To:=20Ted=20Hardie=20;
	bh=Z9OwSOlAx3wGWiDMyxmpUwhJjaSF62/vT07AtHTcrMs=;
	b=Bz/Day2eBQvS4KARMxaAK46tJB7PEDukYwjtEpbQicBdDc74sV9j+0ZmZv1skOfXX4Xghjy3
	JkWTF2HaKtm7W/IcvpMfJcyrQ+qEdIReO4RvwE0OXPEhx1L5mrXbLTKO;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: IETF SIP List , "Elwell, John" ,
	Dan Wing , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Ted - inline...

Ted Hardie wrote:
> At 10:50 AM -0500 11/8/07, Paul Kyzivat wrote:
>> Dean Willis wrote:
>>
>> [snip]
>>
>>> We're at a decision point here -- do we follow RFC 1984 to the fullest extent and design a secure protocol that will have limited applicability, or do we design a protocol with broader applicability that has explicitly negotiated key sharing?
>> I don't want to see sip relegated to specialty applications and excluded from most common usage.
>>
>> Having the key disclosure explicit to the UAs seems a better. I guess one might ask why a UA would ever agree to disclose its keys, but the answer clearly is that it might do so if it has no other option that allows making the call.
> 
> You mention below the "lock icon" problem, but that is a subset of the larger
> mental model question.  How is the user who has no choices but: 
> 
> 1) no call
> 2) a call for which it must divulge keys
> 
> to distinguish between that condition and "The security set-up for this call has failed. 
> Do you wish to continue the call anyway?"  From at least one perspective, the
> security set-up for the call has failed if the keys have been forced from the user;
> they no longer have any assurance as to the confidentiality of the call. 
> I strongly believe that the UI revelation of the key sharing would be minimal or
> elided; in your scenario, at least, all carrier calls would have this marker as
> a  base state.  Any warning that common must be expected to be ignored, and
> a good UI designer is simply going to get it out of the attention field of the user.
> In other words, this mechanism will likely be invoked with no attention from
> the user, with the result that the security characteristics of the call will be
> fundamentally different from the users' expectations.

I agree with you that the UI for this is of critical importance for any 
of it to mean anything. That in fact is why I keep returning to the 
"lock icon" issue.

Its a difficult issue here because while it is critical, UIs are 
typically outside the scope that IETF deals with.

If the UI designs end up not displaying this information, or displaying 
it in such a way that it is not noticed, or is incomprehensible, then 
you are correct that the enemies of confidentiality will have won.

I can certainly *imagine* ways of building UIs for many devices that 
would comparable in effectiveness of the lock icon in browsers. (But not 
for *all* devices. Its unlikely that a good solution is possible for a 
black phone.)

It may indeed mean that some classes of devices, which are intended for 
use only on contexts where LI is universal, won't show an indication. I 
don't know that there is anything that can or should be done about that.

Its devices that have the chance to operate with/without LI that can 
benefit from an indicator.

> So, what are we left with?  From my perspective, any work on this would have
> to be explicitly done in the context of RFC 1984.  That may well mean setting
> out a reasoned discussion of why the interoperability of the mechanism justifies
> the work here.  If I hear you right, that statement would be something like:
> 
> "We judge  having a single signaling system to be of such
> over-riding importance that the inclusion of an optional system for
> the sharing of keys to support LI is justified.  We further strongly encourage the
> development and deployment of systems which notify the end user when these
> mechanisms have been invoked, as well as the deployment of systems which
> do not include this optional mechanism.  While these latter systems will fail in
> the presence of key demands, they will also serve as the most potent possible
> reminder of the prevalence of potential surveillance."
> 
> But I think that statement needs to be in public, in a context that engages the
> rest of the IETF and Internet community in an open discussion as to whether
> need for a single signalling system does  over-ride the concerns expressed
> in RFC 1984. 

I don't pretend to understand the procedural issues here. I'll take your 
word for it.

> Speaking personally, it does not do so for me.  Recent experience has shown
> a tendency toward data mining approaches to interception that make me
> believe that the inclusion of this mechanism will support the continuation
> of an epic invasion of privacy that is loosely targeted, extraordinarily
> easy to abuse, and for which over-sight has been minimal and public debate
> gagged.  Hobbling a mechanism which can maintain privacy in such an
> environment is irresponsible.  It is also contrary to the expressed wishes of
> the IETF, as set forward in a document that was much debated.

I expect that I am philosophically in a position near to yours. I would 
prefer a world where all the communications were e2e encrypted with no 
possibility of interception, in spite of the class of problems that enables.

But I think that we are on the losing end of that argument, and that 
doing nothing about it is comparable to the ietf history of doing 
nothing about NAT. Better the evil we understand than the one that 
evolves without us.

> Yes, I understand the problems that this presents, both for interoperability
> and the action of lawful intercept.  But I believe that forcing a break here
> is honestly the better choice for the Internet and for the future of IETF
> technologies.  If we do not maintain at least one system capable of maintaining
> privacy, we are  pushing  all communications users into a panopticon
> future for their personal communications.

Suppose we refused to bend here. Then the carriers that are subject to 
LI will either switch to a non-standard variant of our protocols that 
supports the key access, or will use some entirely different protocol.

And then, either I need one device to talk via carriers and a different 
device to talk using IETF means without the carriers, or else I need a 
device that supports both protocols. Requiring distinct devices seems 
impractical. If a single device supports both protocols, then we are 
back to the same UI issue.

But it gets worse. The choice to go over a carrier is often not made by 
the initiating device. The tendency will simply be to bury anchor the 
media in an SBC at the enterprise/carrier boundary and have the SBC 
disclose the key, totally masking the two cases. So this whole 
discussion seems moot unless it is possible to verify that you have 
negotiated keys with actual device of the person you are talking with, 
and not with some intermediary.

	Thanks,
	Paul

> Speaking for me, personally, the costs are too high.  If the working group
> does decide to move forward here, I will strongly urge early review by
> the broader IETF community, as the consequences of this decision are not
> light.
> 
> My thanks, Paul, for your reasoned statements; please do take my response
> to be directed to you personally.
> 				regards,
> 					Ted Hardie
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 14:21:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqCwj-0002uT-Ts; Thu, 08 Nov 2007 14:21:45 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqCwi-0002u9-N7
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 14:21:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCwi-0002ti-Ah
	for sip@ietf.org; Thu, 08 Nov 2007 14:21:44 -0500
Received: from numenor.qualcomm.com ([129.46.51.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqCwh-00025B-IT
	for sip@ietf.org; Thu, 08 Nov 2007 14:21:44 -0500
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lA8JLf6Y025177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 8 Nov 2007 11:21:42 -0800
Received: from [129.46.78.80] (vpn-10-50-0-39.qualcomm.com [10.50.0.39])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	lA8JLeWx028345; Thu, 8 Nov 2007 11:21:41 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <3a3e01c82235$db788960$c4f0200a@cisco.com>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
	<4733303A.4070603@cisco.com> 
	<3a3e01c82235$db788960$c4f0200a@cisco.com>
Date: Thu, 8 Nov 2007 11:21:38 -0800
To: "Dan Wing" , "'Paul Kyzivat'" ,
	"'Dean Willis'" 
From: Ted Hardie 
Subject: RE: [Sip] media-security-requirements and lawful intercept
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: 'IETF SIP List' , "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

>
>The wider consequence, however, is not increased "epic invasion of
>privacy", as you state.

This isn't actually what I said; I said we currently see an epic invasion
of privacy and key compromise supports that.  The meat of that section
of my email is probably:
 
"Hobbling a mechanism which can maintain privacy in such an
environment is irresponsible."


I agree with you that failing to provide any mechanism that maintains
privacy is not only worse than hobbling the available mechanism
but equally irresponsible.  If that wasn't clear before, I'm sorry, and
thanks for giving me the chance to make it clear now.


>



>The choice, as IETF has always seen it, is to stick with IETF's first
>principles [RFC1984, RFC2804] which is end-to-end crypto is best (4) and
>market and legal requirements are not relevant to IETF's standards.  I agree
>it is a laudable and worthy goal.

I don't think it is quite as bad as "market and legal requirements are
not relevant to IETF's standards".  I think it is closer to those requirements
being balanced against the usefulness of the network to its actual users.
By insisting that what we specify is actually able to meet the security
needs of the users, we make sure that there is at least one option on the
table that does.  Folks can implement and deploy that solution, possibly
without the carrier supported infrastructure of other solutions, and get
a clear expectation of the security available.

> I could even agree that we should leave it
>to other SDOs, who deal more closely with LI requirements, to determine how
>those LI requirements can be met. 
>
>Yet, IETF has also said that IETF owns the SIP standards (and related
>standards). 

Yes, it has.  It has said that in the context of RFC 1984, though, which was
written with lawful intercept clearly in view.  As I said before to Paul,
a considered review of whether this problem is sufficient to warrant revisiting
that may be in order; a part of that review would certainly be a review of
the hierarchy of issues such as you put forward.  I'm glad we agree that such
a discussion would involve the wider community.

>Taking your suggestion would mean we do (4) and have other SDOs decide if and
>how to accomplish a weaker, LI-friendly solution (1, 2, or 3), and IETF should
>not provide guidance for the most secure (3) of those remaining LI-friendly
>approaches.  The result is undesirable:  millions of users will be unprotected
>because they will only have plain RTP (1) or they will be vulnerable to every
>SIP proxy on their path (2); (3) is difficult, and (4) will be undeployable by
>licensed providers in many countries around the world.

One consequence of specifying (4), at least in my mind, is that some deployments
actually use (4) as specified.  If we don't do what we can to keep that level of
security on the table, who will? 

That does have to be balanced against the possibility that the situation will
remain dire for an even larger number than if we specified 3; the
"mental model" problem there is how we express 3.  It's a little be compromised,
and that's like a little be pregnant.

Thanks very much for message and considered response.  As before,
this represents my personal opinion,
					regards,
						Ted Hardie


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 14:57:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqDVI-0007RS-Hq; Thu, 08 Nov 2007 14:57:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqDVH-0007QR-1y
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 14:57:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDVG-0007QJ-Om
	for sip@ietf.org; Thu, 08 Nov 2007 14:57:26 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqDVD-0001bI-Bn
	for sip@ietf.org; Thu, 08 Nov 2007 14:57:26 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA8JvCpB006387
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 8 Nov 2007 13:57:14 -0600
In-Reply-To: <47334400.8090103@cisco.com>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>		<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>	<473313C2.7040506@joelhalpern.com>	
	<47333D93.8040700@joelhalpern.com> <47334400.8090103@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 13:57:00 -0600
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: IETF SIP List , "Joel M. Halpern" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 8, 2007, at 11:14 AM, Paul Kyzivat wrote:

>
> It would be interesting to see when an organization doing that will  
> be required to satisfy the LI requirements. Could the IETF manage  
> its own VoIP network for use by ietf participants? Is it a matter  
> of whether money changes hands? Or how closely affiliated the users  
> are?

It all depends on which jurisdiction the people and machines happen  
to be in when served with a warrant, and who is doing the serving.

I've had to cough up student traffic at a university, employee  
traffic at a company, and customer traffic at an ISP. IETF would  
likely have the same experience.

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 16:09:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqEd7-0006zv-05; Thu, 08 Nov 2007 16:09:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqEd4-0006xh-N2
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:09:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqEd4-0006vV-5c; Thu, 08 Nov 2007 16:09:34 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IqEd3-0005PD-4X; Thu, 08 Nov 2007 16:09:33 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lA8L9Si07406; Thu, 8 Nov 2007 21:09:28 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 Nov 2007 15:09:18 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
Thread-Index: AcgiS6A1W9zkQlycR82+duJ9ODvL9g==
From: "Brian Stucker" 
To: "Jonathan Rosenberg" , ,
	"sip" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90
Cc: 
Subject: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Jonathan,

Thanks for putting the document together. It took quite awhile to just
review it!=20

Here are the comments that I have as part of the RAI-ART review of the
document. Apologies for the probable repeats in here from list comments,
I was not able to try to correlate my comments with others on the
various reflectors.

I tried to break my comments up by section and document so hopefully
it's coherent in plain-text.

Regards,
Brian

----

Section 1:


   This document itself is not an update to RFC 3261
  or an extension to
   SIP.  It is an informational document, meant to guide newcomers,
   implementors and deployers to the SIP suite of specifications.

May want to change "meant to guide newcomers, implementors and deployers
to the SIP suite of specifications" since many of the documents are not
predicated upon SIP itself. For example, RFC-4566, 3388, 3264. Also, I
don't think we want to imply that this document is exhaustive. Perhaps
"It is an information document, meant to introduce newcomers,
implementors and deployers to many of the important IETF specifications
associated with SIP. Specifications referenced by this document were
chosen based on working group consensus and the list presented here is
not intended to be exhaustive or confer any special status over
documents not included."

Might also want to include some pointers to the relevant WG webpages to
give newcomers a place to go for further information. As well as include
some boilerplate about the dangers of implementing I-D's before they
become RFCs (I think this was already discussed somewhat on the RAI
mailing list).



Section 2:

	Although I agree that documents defining relevant registries
should be excluded, what about pointers to the registries themselves?
Seems like some of the interop problems we wind up with are due to
disregard or lack of visibility of the IANA registration process to
implementors.


Section 3:

RFC3261:=20

	I think it would be useful to provide a reverse-lookup list of
RFCs that formally update 3261 under the 3261 entry: RFC-3583, RFC-4320
and RFC-4916. There is a statement under 4320 that it formally updates
3261, but there is no mention under 4916 that it formally updates 3261,
it just looks like any other extension. Putting a pointer to the SIPS
work as a TBD formal update to 3261 would also be good as well as
collapsing the "essential corrections to SIP" under the 3261 entry so
that people don't skip over that material would be good as well.

RFC3264:

	Should we perhaps put a pointer here to the offer/answer draft
for further clarification of 3264 since it seems pretty clear that the
baseline specification did not entirely capture all of the interactions
that arise in implementations?

RFC3325:

	May want to remove the word "secure" from the description of the
P-Asserted-ID header description. P-Asserted-ID does not confer any
security of the caller ID information. It's the trust domain that
provides the security in contrast to a mechanism like RFC-4474.=20

RFC3581:

	Rport is necessary to routing a response through a NAT, but does
not solve NAT traversal for SIP signaling. Perhaps a pointer to outbound
under this RFC would be useful to highlight what you don't get with
rport that you need to fully address NAT traversal issues, or simply
remove it entirely and rely on folks to go to the NAT traversal section
to discover it there as it's not necessary at all if you have no NATs to
traverse (ALGs and SBCs aside).

RFC4474:

	I don't think it's necessary that we should highlight the
deployment size of the various RFCs in this way, especially given that
the RFC is much newer (and has more complicated requirements) than
RFC3325.

SIPS:

	Should note that this will formally update RFC3261 when approved
to highlight that newcomers should ignore what's in RFC3261.



Section 4:

RFC2848/3910:

	If this has seen little deployment and is very narrowly scoped,
then why are we including it in the guide?=20

RFC3372:

	Widespread implementation in a limited deployment model. It
should be noted that it's usage is intended to be temporary as ISUP
endpoints are obviated from the network.

RFC3960:

	Early media is not just generated by the PSTN. We should be fair
here and acknowledge that 3960 does not solve all of the various issues
associated with early media (without enumerating them). We all know this
to be the case, so just a sentence or two should suffice to warn the
reader.

RFC3959:

	We should highlight that this specification has not seen
widespread deployment. As of a few IETFs ago nobody indicated that they
had developed anything with regards to this specification when asked at
a working group meeting. This is only important in that 3960 does not
solve all of the early media issues.


Shouldn't we have an entry in this section for RFC3966 to cover tel
URIs?



Section 5:

RFC3262:

	PRACK is complicated, for sure, but it's used for more than just
PSTN interworking and is more than mildly deployed depending upon the
environment.

RFC3311:

	..but can be used to initiate a reliable request during session
establishment when a re-INVITE is not possible. This is key for
conveying information to an originator that cannot be conveyed in a
response either due to offer/answer complications or because a header is
not allowed in a response message type. We should also point out here
that when UPDATE is used to convey SDP, support for RFC3262 is required
in some scenarios. I don't think this is widely recognized. Should also
call out that it can be used to convey mid-call information as well.

RFC3608:

	You've captured the client perspective of the usage of
service-route, but from a server perspective, it's used by proxies to
capture the route set of a registration to know how to route future
requests on behalf of the client. In this role it has seen greater
deployment and applicability.

RFC 3841:

	Should probably call out the relationship between this RFC and
3840.

Need to remove duplicate entry for SDP negotiation under PSTN
interworking.

RFC4244:

	Should remove reference to voicemail here. It has broader scope.
RFC4758 is intended for this purpose now (later comment).


Shouldn't we have an entry in this section for RFC3880, CPL?



Section 6:

RFC3605:

	Should this be here and under the core specifications section? I
don't see this attribute show up in SDP very often (pre-ICE), but it is
necessary for some NAT traversal solutions. Perhaps only have a
reference to it here? Outside of NAT traversal, is there a primary
reason to have this RFC or ICE in the core specifications section?

OUTBOUND:

	Doesn't outbound satisfy the requirements of a broadly
applicable extension to SIP? Seems like if ICE is a core specification,
that OUTBOUND should be considered one as well?

RFC3890:

	It's used extensively in other SDOs, paricularly wireless.

RFC4730:

	Should probably explain here briefly, that 2833/4733 is most
commonly used to convey DTMF for SIP deployments, but the difference is
that KPML does it on the signaling path as opposed to the media path.
This is somewhat important given the low current deployment of KPML.



Section 13:

	Perhaps we should add an entry here for RFC4896 or make a note
under the entry for RFC3486 that RFC4896 updates both RFC3486 and
RFC3485 which is the static dictionary for SIP (which provides the
explicit coupling between SIGCOMP and SIP eluded to in the draft text).
The important bit for an entry to RFC3485 is that there are a few bugs
in the dictionary such that you'd need to refer to section 12 of RFC4896
to come up with a BCP implementation.



Section 14:

I think we should add an entry for RFC4758 to capture the voicemail
service URI as another important service URI RFC.


Section 15:

RFC3853:

	May want to state that RFC3853 'formally' updates RFC3261, and
put a pointer to this from the core specifications section as a result
since it's a correction to 3261.

RFC3893:

	Should RFC3893 entry simply say something to the effect of 'use
RFC4474', or be dropped altogether?

RFC3329:

	There are now three possible security models now in 3GPP: HTTP
DIGEST, AKA, and early-IMS. As early-IMS doesn't really involve much in
the way of security mechanisms within the SIP protocol, the coexistance
of it with digest or AKA seems to be very probable. Perhaps we should
just remove the last sentence and leave it up to the reader to decide if
it's needed for their purpose.



Section 16:

Shouldn't we perhaps move RFC4796 from section 7 to this section?


Section 17:

Providing a pointer off to ECRIT seems useful here.


That's it!





_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 16:18:36 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqElm-0005Ij-L4; Thu, 08 Nov 2007 16:18:34 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqEll-0005IZ-5m
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:18:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqElk-0005IG-S0
	for sip@ietf.org; Thu, 08 Nov 2007 16:18:32 -0500
Received: from ns7.neustar.com ([156.154.24.88] helo=neustar.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqElh-0003xD-DI
	for sip@ietf.org; Thu, 08 Nov 2007 16:18:32 -0500
Received: from ([10.31.13.50])
	by chihiron1.nc.neustar.com with ESMTP  id 5202942.2432696;
	Thu, 08 Nov 2007 16:18:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 16:18:14 -0500
Message-ID: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
In-Reply-To: <47335E14.1020105@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgiOoNiGO8R/aa2Rvuq+rSsuDTr2AACrenQ
From: "Peterson, Jon" 
To: "Paul Kyzivat" ,
	"Ted Hardie" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: IETF SIP List , "Elwell, John" ,
	Dan Wing , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> I would prefer a world where all the communications were e2e=20
> encrypted with no possibility of interception, in spite of the class =
of=20
> problems that enables.
>=20
> But I think that we are on the losing end of that argument, and that=20
> doing nothing about it is comparable to the ietf history of doing=20
> nothing about NAT. Better the evil we understand than the one that=20
> evolves without us.

If our work here becomes irrelevant, it will be because it doesn't do =
what end users want, not because we've been insufficiently obsequious to =
the tyrant-of-the-month. Carriers, however broadly the definition of =
that term may be creeping in some principalities, have certain =
obligations which are not at all intrinsic to the operation of a =
protocol like SIP, and we cannot assume that SIP's fate is determined by =
its success in that arena alone.

> Suppose we refused to bend here. Then the carriers that are subject to =

> LI will either switch to a non-standard variant of our protocols that=20
> supports the key access, or will use some entirely different protocol.

As has been already pointed out in this thread, RFC4474 (and any larger =
security architecture relying on it) invests the domain responsible for =
your AoR with significant trust and responsibility. That domain can =
insert men-in-the-middle willy-nilly. This seemed architecturally =
reasonable because you need to trust them anyway, for example, to route =
calls to you and so on; the sorts of entities to whom LI requirements =
apply would tend to be the operators of such domains, incidentally. The =
truly paranoid can of course operate their own domains, personally =
administer every device, and as such need only trust themselves to make =
use of RFC4474. This casts the problem exactly how it should be, I think =
- as an administrative problem. How you deploy and use these tools =
determines who you need to trust and where there are potential avenues =
for adversaries to interfere with your security.

Any attempt to cast this as an engineering problem, something that can =
be fixed or broken at a protocol level, is in my opinion misguided.

Speaking more specifically to R24, my opinion is that a SIP user should =
be able to ascertain whether or not a certain set of security features =
have been invoked. If those features have been invoked, then the user =
might draw the conclusion that it is unlikely, barring some breakthrough =
in higher mathematics, that someone is able to listen in on their =
conversation. This is entirely orthogonal to whether or not someone =
might be intercepting and recording ciphertext media (something the user =
cannot hope to ascertain), nor whether or not his administrative domain =
has been compromised (also something the user probably cannot ascertain, =
even if he runs his own server in a sealed bunker in Montana, given the =
potential capabilities of adversaries) and his keys plundered. The =
protocol, and consequently the end user, cannot hope to be privy those =
lapses. As such it's hard for me to see what the problem is with R24.

If, of course, that set of security features cannot be invoked, the user =
might draw the conclusion that it is quite likely that someone is =
listening in on his conversation, and R24-types might find that =
worrisome. But it is no more likely that the baleful eye of surveillance =
is scrutinizing the user in this case, really. Inability to invoke those =
features cannot be said to inform the user that this interaction is =
"subject to lawful interception" or whatever. Lack of the support for =
the security features is a much more likely culprit.

So, my question is, what's the engineering problem?

Jon Peterson
NeuStar, Inc.


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 16:30:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqExH-0004Ik-1S; Thu, 08 Nov 2007 16:30:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqExG-0004Hj-40
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:30:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqExF-0004H8-Na
	for sip@ietf.org; Thu, 08 Nov 2007 16:30:25 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqExB-0004CI-Vk
	for sip@ietf.org; Thu, 08 Nov 2007 16:30:25 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JR700H79IDV6N@siemenscomms.co.uk> for sip@ietf.org; Thu,
	08 Nov 2007 21:29:55 +0000 (GMT)
Date: Thu, 08 Nov 2007 21:30:19 +0000
From: "Elwell, John" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
In-reply-to: <3a3e01c82235$db788960$c4f0200a@cisco.com>
To: Dan Wing , Ted Hardie ,
	Paul Kyzivat , Dean Willis 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E9429@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgiKnXGGin2CipBQAuikn6bUJlZ/gABmCAgAAcUftA=
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
	<4733303A.4070603@cisco.com> 
	<3a3e01c82235$db788960$c4f0200a@cisco.com>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dan,

Thanks for classifying the options. I just wonder whether there is a
subdivision of 3. With 3, I could negotiate keys with a decrypting
relay, but I really have no idea what happens beyond that relay. Or I
can negotiate keys end-to-end where media is sent via a non-decrypting
relay, which copies the encrypted media to a decrypting entity (not
necessarily a SIP entity) to which I have disclosed the key. That
decrypting entity could be in even be in the domain of the law
enforcement authorities rather than a SIP service provider. Of course,
verification that the key is correct then has to be done by the
decrypting entity more or less in real time, with feedback to the SIP
service provider if it believes the key to be incorrect, so that the
call can be stopped. Did you have one of both of these in mind for
option 3?

John

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com] 
> Sent: 08 November 2007 18:33
> To: 'Ted Hardie'; 'Paul Kyzivat'; 'Dean Willis'
> Cc: 'IETF SIP List'; Elwell, John
> Subject: RE: [Sip] media-security-requirements and lawful intercept
> 
> Ted,
> 
> > ...
> > Speaking for me, personally, the costs are too high.  If the 
> > working group does decide to move forward here, I will strongly 
> > urge early review by the broader IETF community, as the 
> consequences 
> > of this decision are not light.
> > ...
> 
> Thanks for your email.  I agree this needs wider discussion and the
> WG (and probably RAI as a whole) needs to decide what it wants to do.
> 
> The wider consequence, however, is not increased "epic invasion of 
> privacy", as you state.  The wider consequence is that, without a
> suitable mechanism that meets the needs of LI for SRTP, networks 
> subject to LI will only ever be able to do RTP.  The choices, as I
> see them, are (in order of least secure to most secure):
> 
>  1. everyone can listen to the call.  This is what we have today
>     with RTP.  This allows 'epic invasion of privacy' by all 
>     parties (governments, criminals, and anyone who is able to
>     receive your RTP)
>  2. every SIP entity learns the SRTP keys.  This is what would
>     happen with Security Descriptions.  This allows 'epic 
>     invasion of privacy' by any party that has control of any
>     SIP entity your Invite (or its response) traversed.  That
>     control could be legitimate or could be illegitimate 
>     (government or criminal hacked into the SIP proxy).
>  3. only a specific SIP entity learns the SRTP key.  This is
>     what would happen in the two techniques I proposed at the
>     beginning of this thread.  This allows 'epic invasion of
>     privacy' by any party that has control of that specific
>     SIP entity.  That control could be legitimate or could be
>     illegitimate (government or criminal hacked into that 
>     specific SIP proxy).
>  4. IETF sticks with only doing DTLS-SRTP and provides no 
>     guidance for how to meet LI requirements.
> 
> The choice, as IETF has always seen it, is to stick with IETF's first
> principles [RFC1984, RFC2804] which is end-to-end crypto is 
> best (4) and
> market and legal requirements are not relevant to IETF's 
> standards.  I agree
> it is a laudable and worthy goal.  I could even agree that we 
> should leave it
> to other SDOs, who deal more closely with LI requirements, to 
> determine how
> those LI requirements can be met.  
> 
> Yet, IETF has also said that IETF owns the SIP standards (and related
> standards).  
> 
> Taking your suggestion would mean we do (4) and have other 
> SDOs decide if and
> how to accomplish a weaker, LI-friendly solution (1, 2, or 
> 3), and IETF should
> not provide guidance for the most secure (3) of those 
> remaining LI-friendly
> approaches.  The result is undesirable:  millions of users 
> will be unprotected
> because they will only have plain RTP (1) or they will be 
> vulnerable to every
> SIP proxy on their path (2); (3) is difficult, and (4) will 
> be undeployable by
> licensed providers in many countries around the world.
> 
> -d
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 16:37:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqF4X-0001Vn-MT; Thu, 08 Nov 2007 16:37:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqF4V-0001VD-GG
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:37:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqF4V-0001V5-66
	for sip@ietf.org; Thu, 08 Nov 2007 16:37:55 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqF4R-0004PE-QA
	for sip@ietf.org; Thu, 08 Nov 2007 16:37:55 -0500
X-IronPort-AV: E=Sophos;i="4.21,391,1188792000"; d="scan'208";a="136396975"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2007 16:37:51 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA8Lbp62013276; 
	Thu, 8 Nov 2007 16:37:51 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8LbjW7015218; 
	Thu, 8 Nov 2007 21:37:45 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 16:37:32 -0500
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 16:37:32 -0500
Message-ID: <4733819A.2010908@cisco.com>
Date: Thu, 08 Nov 2007 16:37:30 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>		<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>	<473313C2.7040506@joelhalpern.com>		<47333D93.8040700@joelhalpern.com>
	<47334400.8090103@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2007 21:37:32.0616 (UTC)
	FILETIME=[91EEB480:01C8224F]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002
X-TM-AS-Result: No--6.790200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=863; t=1194557871;
	x=1195421871; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20
	|To:=20Dean=20Willis=20;
	bh=tQc06ZO4ApCTBO/Td7Fo3zmbM8lx288Ic4472AMiHbM=;
	b=wHWptBYDI6P0uNIc5UrJS5W8d/fDyf5puC5xyQoK6/M7+t1PtIPq3D7JlnUxAla9fc79D3+R
	k4hc7Gk6ezU9gGgSsVu7RNWgcRYGWjHoRX2WhbwsOBpEAasBMdPtQ1iQ;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: IETF SIP List , "Joel M. Halpern" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> 
> On Nov 8, 2007, at 11:14 AM, Paul Kyzivat wrote:
> 
>>
>> It would be interesting to see when an organization doing that will be 
>> required to satisfy the LI requirements. Could the IETF manage its own 
>> VoIP network for use by ietf participants? Is it a matter of whether 
>> money changes hands? Or how closely affiliated the users are?
> 
> It all depends on which jurisdiction the people and machines happen to 
> be in when served with a warrant, and who is doing the serving.
> 
> I've had to cough up student traffic at a university, employee traffic 
> at a company, and customer traffic at an ISP. IETF would likely have the 
> same experience.

It doesn't matter if you don't have the info.

The question is: when can they come and tell you that you must install 
LI hooks into your system?

	Paul


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 16:43:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqF9S-0006vk-F2; Thu, 08 Nov 2007 16:43:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqF9R-0006vQ-S6
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:43:01 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqF9R-0006uo-Gt
	for sip@ietf.org; Thu, 08 Nov 2007 16:43:01 -0500
Received: from zcars04e.nortel.com ([47.129.242.56])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqF9R-000692-4R
	for sip@ietf.org; Thu, 08 Nov 2007 16:43:01 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	lA8LdqH08927; Thu, 8 Nov 2007 21:39:52 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 15:42:42 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF13132C2A@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4733819A.2010908@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgiT6KJONShoUzfR6yETTBnGol/EQAADzkg
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
	
	<47333D93.8040700@joelhalpern.com>	<47334400.8090103@cisco.com>
	
	<4733819A.2010908@cisco.com>
From: "Brian Stucker" 
To: "Paul Kyzivat" ,
	"Dean Willis" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: IETF SIP List , "Joel M. Halpern" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
>=20
> The question is: when can they come and tell you that you=20
> must install LI hooks into your system?
>=20

(9/11) Whenever the (9/11) government decides to do so (9/11).
Otherwise, (9/11) the terrorists (9/11) win.

Seriously. There's no way of knowing when a law may change. The key here
really isn't so much collecting the data, by the way. You can collect
the data, it's reporting the keys to interpret the data.

Regards,
Brian





_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 16:47:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqFE6-0005xV-N9; Thu, 08 Nov 2007 16:47:50 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqFE4-0005wB-Hq
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:47:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFE4-0005w3-8P
	for sip@ietf.org; Thu, 08 Nov 2007 16:47:48 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqFE1-0004hn-1h
	for sip@ietf.org; Thu, 08 Nov 2007 16:47:48 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lA8Llbi12878; Thu, 8 Nov 2007 21:47:37 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 15:47:35 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF13132C67@zrc2hxm0.corp.nortel.com>
In-Reply-To: <198A10EC585EC74687BCA414E2A5971801E47913@MCHP7RDA.ww002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcggnYz0vr1y5PPGSTSoHa6HBVInvwAkJuKQAApfgsAAIZjeYAActuQA
References: <06c101c8209d$8d543700$c4f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	<101a01c82159$e3202600$c4f0200a@cisco.com>
	<198A10EC585EC74687BCA414E2A5971801E47913@MCHP7RDA.ww002.siemens.net>
From: "Brian Stucker" 
To: "Fischer, Kai" , "Dan Wing" ,
	"Elwell, John" , "IETF SIP List" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20

> -----Original Message-----
> From: Fischer, Kai [mailto:kai.fischer@siemens.com]=20
>=20
> How is it possible to perform a DTLS handshake if the RTP=20
> traffic / ports are blocked? Are these blocking network=20
> components able to analyze the first byte of the packets and=20
> to distinguish between RTP and DTLS traffic?
>=20
> Kai

There's a separate document on the way that talks about this. Stay
tuned.

Regards,
Brian


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 16:50:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqFGD-0007vY-AS; Thu, 08 Nov 2007 16:50:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqFGC-0007uR-1a
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:50:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFGB-0007uJ-OC
	for sip@ietf.org; Thu, 08 Nov 2007 16:49:59 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqFG8-0004lM-94
	for sip@ietf.org; Thu, 08 Nov 2007 16:49:59 -0500
X-IronPort-AV: E=Sophos;i="4.21,391,1188802800"; d="scan'208";a="248721040"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 08 Nov 2007 13:49:55 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lA8Lnts8025394; 
	Thu, 8 Nov 2007 13:49:55 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lA8LnNej026462;
	Thu, 8 Nov 2007 21:49:55 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 16:49:45 -0500
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 16:49:44 -0500
Message-ID: <47338479.20000@cisco.com>
Date: Thu, 08 Nov 2007 16:49:45 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Brian Stucker 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
	
	<47333D93.8040700@joelhalpern.com>	<47334400.8090103@cisco.com>
	
	<4733819A.2010908@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132C2A@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF13132C2A@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2007 21:49:44.0943 (UTC)
	FILETIME=[466EEFF0:01C82251]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002
X-TM-AS-Result: No--13.794400-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=968; t=1194558595;
	x=1195422595; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=esrx/lJo54rYlqHZNhfdAKI8vKiLyCuThexMNXLHHHc=;
	b=bpK7LNkZr4u2r7BPWqoW32jJOHwFzPdEaMnk5P1DJn9hOVWR7q7QsZP7GJgHOJw24TryuPEw
	CfE/rKVTj1+gaB4K1au8EoZUflP1MhyPjHpjiHcHC2umqpMxLcNlxq23;
Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: IETF SIP List , "Joel M. Halpern" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Brian Stucker wrote:
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
>>
>> The question is: when can they come and tell you that you 
>> must install LI hooks into your system?
>>
> 
> (9/11) Whenever the (9/11) government decides to do so (9/11).
> Otherwise, (9/11) the terrorists (9/11) win.
> 
> Seriously. There's no way of knowing when a law may change. The key here
> really isn't so much collecting the data, by the way. You can collect
> the data, it's reporting the keys to interpret the data.

Understood. My question was essentially "what kind of usage would be 
found sufficiently offensive that the law would be changed to require a 
new class of network to do LI, including reporting of keys.?"

Apparently at the moment communications within a private enterprise, 
even a distributed one with VPN interconnects via carriers, hasn't 
resulted in demanding that enterprises support LI.

	Paul


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 17:03:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqFTM-0000ZV-Q5; Thu, 08 Nov 2007 17:03:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqFTL-0000YV-5V
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 17:03:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFTK-0000YN-SH
	for sip@ietf.org; Thu, 08 Nov 2007 17:03:34 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqFTH-000588-DL
	for sip@ietf.org; Thu, 08 Nov 2007 17:03:34 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lA8M3GN07947; Thu, 8 Nov 2007 22:03:17 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 16:03:14 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF13132CEB@zrc2hxm0.corp.nortel.com>
In-Reply-To: <47338479.20000@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgiUUlbpEZUsljsQBOehKy/trWQ2gAADnVQ
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
	
	<47333D93.8040700@joelhalpern.com>	<47334400.8090103@cisco.com>
	
	<4733819A.2010908@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132C2A@zrc2hxm0.corp.nortel.com>
	<47338479.20000@cisco.com>
From: "Brian Stucker" 
To: "Paul Kyzivat" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: IETF SIP List , "Joel M. Halpern" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Thursday, November 08, 2007 3:50 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Dean Willis; IETF SIP List; Joel M. Halpern
> Subject: Re: [Sip] media-security-requirements and lawful intercept
>=20
>=20
>=20
> Brian Stucker wrote:
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>
> >> The question is: when can they come and tell you that you must=20
> >> install LI hooks into your system?
> >>
> >=20
> > (9/11) Whenever the (9/11) government decides to do so (9/11).
> > Otherwise, (9/11) the terrorists (9/11) win.
> >=20
> > Seriously. There's no way of knowing when a law may change. The key=20
> > here really isn't so much collecting the data, by the way. You can=20
> > collect the data, it's reporting the keys to interpret the data.
>=20
> Understood. My question was essentially "what kind of usage=20
> would be found sufficiently offensive that the law would be=20
> changed to require a new class of network to do LI, including=20
> reporting of keys.?"

I don't think this is the way governments look at the problem. Voice
traffic, on the face of it, is not a particularly offensive usage but it
obviously has LI requirements. It's more a matter of technical
feasibility. As a common carrier, operators have the only technically
feasible point of collection for this type of data because they are the
transport provider. If all of your voice communications were able to be
collected outside of the provider network, I don't think they'd care so
much to force providers to give them LI capabilities.

I don't think that's as strongly the case with wireline VoIP because
your service provider could be entirely different from your transport
provider in markets where there are a large number of ISPs and they'll
want to collect all of your traffic, not just RTP packets.=20

When you look towards cellular wireless, your service provider is again,
vertically integrated with your transport provider (at least today).

That said, the government certainly isn't going to relax any existing
capabilities to perform legal intercept. So even if a traditional
operator starts providing VoIP service to subscribers that utilize an
ISP not owned by that operator the government isn't going to say "oh,
you don't need to support LI anymore" because there's always the CYA
element to be considered.

As long as they can control the chokepoints in the network to ensure
that they can capture the traffic they need, and they have the keys
reported to them to interpret the material if someone in the network has
them (or is compelled to make sure that they get them if technically
feasible) then there's going to be a requirement to report that
information.


>=20
> Apparently at the moment communications within a private=20
> enterprise, even a distributed one with VPN interconnects via=20
> carriers, hasn't resulted in demanding that enterprises support LI.

No, because their ISPs are required to cooperate with law enforcement
and another aspect of LI is that you don't want the target of the
intercept to be aware that they're being intercepted. It'd have been
pretty tough for the FBI to go to ENRON and tell them that they'd like
to collect all of their VPN traffic as part of an SEC investigation, so
they go to the ISP instead.

>=20
> 	Paul
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 17:12:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqFbg-0007xh-3X; Thu, 08 Nov 2007 17:12:12 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqFbe-0007wu-Fz
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 17:12:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFbe-0007wk-6P
	for sip@ietf.org; Thu, 08 Nov 2007 17:12:10 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqFbZ-0005Lv-J0
	for sip@ietf.org; Thu, 08 Nov 2007 17:12:10 -0500
X-IronPort-AV: E=Sophos;i="4.21,391,1188792000"; d="scan'208";a="75521256"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2007 17:12:05 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA8MC59b030720; 
	Thu, 8 Nov 2007 17:12:05 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8MBcWb002845; 
	Thu, 8 Nov 2007 22:12:00 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 17:11:46 -0500
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 17:11:46 -0500
Message-ID: <473389A1.5000008@cisco.com>
Date: Thu, 08 Nov 2007 17:11:45 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Peterson, Jon" 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
In-Reply-To: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2007 22:11:46.0312 (UTC)
	FILETIME=[5A07D880:01C82254]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002
X-TM-AS-Result: No--1.144600-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4919; t=1194559925;
	x=1195423925; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20
	|To:=20=22Peterson,=20Jon=22=20;
	bh=GyUPAaJVkq18ByNpHf/IU0/KGdTk+8gA/Vu7M1+8UdU=;
	b=NaEYwjCKXsru4R/bxMQcBnDnnD86AIy9E3IUYZF/Gqq+4boa4TDgxkGIWOVojPUQzExYZKOw
	RXcrQP33cKtHaD5YQHEd0mP/Vn/Mc6vhGKccDJ0lTPgw2xmHIDC+5t5w;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: IETF SIP List , "Elwell, John" ,
	Dan Wing , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Jon,

Peterson, Jon wrote:
>> I would prefer a world where all the communications were e2e 
>> encrypted with no possibility of interception, in spite of the class of 
>> problems that enables.
>>
>> But I think that we are on the losing end of that argument, and that 
>> doing nothing about it is comparable to the ietf history of doing 
>> nothing about NAT. Better the evil we understand than the one that 
>> evolves without us.
> 
> If our work here becomes irrelevant, it will be because it doesn't do what end users want, not because we've been insufficiently obsequious to the tyrant-of-the-month. Carriers, however broadly the definition of that term may be creeping in some principalities, have certain obligations which are not at all intrinsic to the operation of a protocol like SIP, and we cannot assume that SIP's fate is determined by its success in that arena alone.
> 
>> Suppose we refused to bend here. Then the carriers that are subject to 
>> LI will either switch to a non-standard variant of our protocols that 
>> supports the key access, or will use some entirely different protocol.
> 
> As has been already pointed out in this thread, RFC4474 (and any larger security architecture relying on it) invests the domain responsible for your AoR with significant trust and responsibility. That domain can insert men-in-the-middle willy-nilly. This seemed architecturally reasonable because you need to trust them anyway, for example, to route calls to you and so on; the sorts of entities to whom LI requirements apply would tend to be the operators of such domains, incidentally. The truly paranoid can of course operate their own domains, personally administer every device, and as such need only trust themselves to make use of RFC4474. This casts the problem exactly how it should be, I think - as an administrative problem. How you deploy and use these tools determines who you need to trust and where there are potential avenues for adversaries to interfere with your security.
> 
> Any attempt to cast this as an engineering problem, something that can be fixed or broken at a protocol level, is in my opinion misguided.
> 
> Speaking more specifically to R24, my opinion is that a SIP user should be able to ascertain whether or not a certain set of security features have been invoked. If those features have been invoked, then the user might draw the conclusion that it is unlikely, barring some breakthrough in higher mathematics, that someone is able to listen in on their conversation. This is entirely orthogonal to whether or not someone might be intercepting and recording ciphertext media (something the user cannot hope to ascertain), nor whether or not his administrative domain has been compromised (also something the user probably cannot ascertain, even if he runs his own server in a sealed bunker in Montana, given the potential capabilities of adversaries) and his keys plundered. The protocol, and consequently the end user, cannot hope to be privy those lapses. As such it's hard for me to see what the problem is with R24.

> If, of course, that set of security features cannot be invoked, the user might draw the conclusion that it is quite likely that someone is listening in on his conversation, and R24-types might find that worrisome. But it is no more likely that the baleful eye of surveillance is scrutinizing the user in this case, really. Inability to invoke those features cannot be said to inform the user that this interaction is "subject to lawful interception" or whatever. Lack of the support for the security features is a much more likely culprit.

The capability you mention here is perhaps a better statement of what I 
was trying to get at.

It has the same properties - namely that I can make the call whether big 
brother is in the picture or not, and then decide what I am willing to 
say based on my degree of confidence that he can't be deciphering what I 
say.

> So, my question is, what's the engineering problem?

We have a growing collection of security components. AFAIK we still 
don't have a combination sufficient for my phone to indicate to me that 
"this is who your are talking to, and nobody can listen in".

I guess we might have "can't say who you are talking with, but nobody 
can listen in". That in itself is of some utility.

And maybe with sip identity we have "somebody you trust says you are 
talking to X, and nobody can listen in to whoever you are talking to".

As you know, I'm not a security wonk, so I might not have this right. 
There is a gap between what the security building blocks provide and 
assertions that are useful for making decisions about if and how to use 
a communication channel without giving away more than you want to. I 
don't know if that is an engineering problem, or whether its an IETF 
problem, but it is a problem.

	Thanks,
	Paul


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 17:17:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqFgS-0005TV-UD; Thu, 08 Nov 2007 17:17:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqFgR-0005ST-5k
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 17:17:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFgQ-0005S2-NQ
	for sip@ietf.org; Thu, 08 Nov 2007 17:17:06 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqFgA-0007Tm-0q
	for sip@ietf.org; Thu, 08 Nov 2007 17:17:06 -0500
X-IronPort-AV: E=Sophos;i="4.21,391,1188792000"; d="scan'208";a="136401431"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2007 17:16:51 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA8MGngQ026884; 
	Thu, 8 Nov 2007 17:16:49 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8MGZWB005606; 
	Thu, 8 Nov 2007 22:16:49 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 17:16:37 -0500
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Nov 2007 17:16:36 -0500
Message-ID: <47338AC4.3000804@cisco.com>
Date: Thu, 08 Nov 2007 17:16:36 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Brian Stucker 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
	
	<47333D93.8040700@joelhalpern.com>	<47334400.8090103@cisco.com>
	
	<4733819A.2010908@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132C2A@zrc2hxm0.corp.nortel.com>
	<47338479.20000@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132CEB@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF13132CEB@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2007 22:16:36.0921 (UTC)
	FILETIME=[073F4290:01C82255]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002
X-TM-AS-Result: No--9.214500-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=944; t=1194560209;
	x=1195424209; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20
	|To:=20Brian=20Stucker=20;
	bh=H5DMf4jD921vgwOqnps3hd2xt7SXJ+xGkDmY96kaIPA=;
	b=VDZIRc2xe7sPNA9oiRT7cF6cnXP6dF4qBPBmP4SRMxGQXGzoUpMd7XelCaG3se10yIuKpldG
	hJobKYArhiEKg2eu2lrKEkHED5YTrKlyF0e3EmJngD2BtOhTWDJzmeht;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: IETF SIP List , "Joel M. Halpern" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Brian Stucker wrote:

>> Apparently at the moment communications within a private 
>> enterprise, even a distributed one with VPN interconnects via 
>> carriers, hasn't resulted in demanding that enterprises support LI.
> 
> No, because their ISPs are required to cooperate with law enforcement
> and another aspect of LI is that you don't want the target of the
> intercept to be aware that they're being intercepted. It'd have been
> pretty tough for the FBI to go to ENRON and tell them that they'd like
> to collect all of their VPN traffic as part of an SEC investigation, so
> they go to the ISP instead.

But the end effect is that if the enterprise starts encrypting all of 
its voice traffic over the VPN then tapping the ISP isn't going to help 
much in getting a tap.

So if that starts happening much will the Feds insist that enterprises 
turn over the keys to their VPNs and to each voice session?

	Paul


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 17:34:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqFxP-0006IV-3V; Thu, 08 Nov 2007 17:34:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqFxN-0006IK-SE
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 17:34:37 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFxM-0006IC-JW
	for sip@ietf.org; Thu, 08 Nov 2007 17:34:36 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqFxM-0000Tw-5e
	for sip@ietf.org; Thu, 08 Nov 2007 17:34:36 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lA8MYPi28477; Thu, 8 Nov 2007 22:34:25 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 16:34:06 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF13132DE8@zrc2hxm0.corp.nortel.com>
In-Reply-To: <47338AC4.3000804@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgiVQv3jChdep78RxGmfCFnKoINcQAAgYAQ
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
	
	<47333D93.8040700@joelhalpern.com>	<47334400.8090103@cisco.com>
	
	<4733819A.2010908@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132C2A@zrc2hxm0.corp.nortel.com>
	<47338479.20000@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132CEB@zrc2hxm0.corp.nortel.com>
	<47338AC4.3000804@cisco.com>
From: "Brian Stucker" 
To: "Paul Kyzivat" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: IETF SIP List , "Joel M. Halpern" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Thursday, November 08, 2007 4:17 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Dean Willis; IETF SIP List; Joel M. Halpern
> Subject: Re: [Sip] media-security-requirements and lawful intercept
>=20
>=20
>=20
> Brian Stucker wrote:
>=20
> >> Apparently at the moment communications within a private=20
> enterprise,=20
> >> even a distributed one with VPN interconnects via carriers, hasn't=20
> >> resulted in demanding that enterprises support LI.
> >=20
> > No, because their ISPs are required to cooperate with law=20
> enforcement=20
> > and another aspect of LI is that you don't want the target of the=20
> > intercept to be aware that they're being intercepted. It'd=20
> have been=20
> > pretty tough for the FBI to go to ENRON and tell them that=20
> they'd like=20
> > to collect all of their VPN traffic as part of an SEC=20
> investigation,=20
> > so they go to the ISP instead.
>=20
> But the end effect is that if the enterprise starts=20
> encrypting all of its voice traffic over the VPN then tapping=20
> the ISP isn't going to help much in getting a tap.
>=20
> So if that starts happening much will the Feds insist that=20
> enterprises turn over the keys to their VPNs and to each=20
> voice session?
>=20
> 	Paul
>=20

Yeah, I'm sure they could. This is all very cat and mouse. I don't know
that it's going to get us anywhere to continue down this path. Everyone
can spot imperfections in the various LI schemes. The bottom line here
is that there are a lot of users out there on networks that have LI
requirements today and the question is, do we want SIP to wind up
reverting to party-line type behaviors on these networks.

Regards,
Brian


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 18:14:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqGZn-0008Vr-Nf; Thu, 08 Nov 2007 18:14:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqGZm-0008Tj-1L
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 18:14:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqGZl-0008Tb-Jx
	for sip@ietf.org; Thu, 08 Nov 2007 18:14:17 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqGZk-0001kM-Lk
	for sip@ietf.org; Thu, 08 Nov 2007 18:14:17 -0500
X-IronPort-AV: E=Sophos;i="4.21,392,1188802800"; d="scan'208";a="414631077"
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-2.cisco.com with ESMTP; 08 Nov 2007 15:14:16 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lA8NEGAg027678; 
	Thu, 8 Nov 2007 15:14:16 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA8NEEQ6015303;
	Thu, 8 Nov 2007 23:14:15 GMT
From: "Dan Wing" 
To: "'Elwell, John'" ,
	"'Ted Hardie'" ,
	"'Paul Kyzivat'" ,
	"'Dean Willis'" 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<098A48F8-525A-4CCD-8554-B1FCF21D7EF2@softarmor.com>
	<4733303A.4070603@cisco.com> 
	<3a3e01c82235$db788960$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9429@GBNTHT12009MSX.gb002.siemens.net>
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 15:14:17 -0800
Message-ID: <43a301c8225d$169f4a20$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgiKnXGGin2CipBQAuikn6bUJlZ/gABmCAgAAcUftAAA+O4MA==
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03E9429@GBNTHT12009MSX.gb002.siemens.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5294; t=1194563656;
	x=1195427656; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=hkjKd8nr3Y3nMruz0dD8eIDWcilq5qvdleGEGe2GdME=;
	b=mvrdJ8NgLRWlx59RgGlEDwZfYcLIRq3ZIE1Usoa1gWcPovQ5wrcejj+mzjoXQEjK1yFyKCpj
	uFE+jt99SLtusQGHK02pYAkVk8f30zAY7tJz+3cnP0mrXhor1Yyog5b8;
Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: 'IETF SIP List' 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com] 
> Sent: Thursday, November 08, 2007 1:30 PM
> To: Dan Wing; Ted Hardie; Paul Kyzivat; Dean Willis
> Cc: IETF SIP List
> Subject: RE: [Sip] media-security-requirements and lawful intercept
> 
> Dan,
> 
> Thanks for classifying the options. I just wonder whether there is a
> subdivision of 3. With 3, I could negotiate keys with a decrypting
> relay, but I really have no idea what happens beyond that relay. Or I
> can negotiate keys end-to-end where media is sent via a non-decrypting
> relay, which copies the encrypted media to a decrypting entity (not
> necessarily a SIP entity) to which I have disclosed the key. That
> decrypting entity could be in even be in the domain of the law
> enforcement authorities rather than a SIP service provider. Of course,
> verification that the key is correct then has to be done by the
> decrypting entity more or less in real time, with feedback to the SIP
> service provider if it believes the key to be incorrect, so that the
> call can be stopped. Did you have one of both of these in mind for
> option 3?

Yes, for (3) I am considering the two cases which you are describing
above.  I believe those are the same two cases I had mentioned at the
beginning of this thread:

   a. provide a network element on every SRTP call which relays
      media, performs a DTLS handshake, and decrypts and re-encrypts
      SRTP, or;

(this is the decrypting relay you describe above.)

   b. have endpoints perform key disclosure for every call (using a 
      technique similar to draft-wing-sipping-srtp-key), and perform
      validation of that disclosed key on every call.

(this is where you disclose SRTP keys and something validates them.)

-d

> John
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@cisco.com] 
> > Sent: 08 November 2007 18:33
> > To: 'Ted Hardie'; 'Paul Kyzivat'; 'Dean Willis'
> > Cc: 'IETF SIP List'; Elwell, John
> > Subject: RE: [Sip] media-security-requirements and lawful intercept
> > 
> > Ted,
> > 
> > > ...
> > > Speaking for me, personally, the costs are too high.  If the 
> > > working group does decide to move forward here, I will strongly 
> > > urge early review by the broader IETF community, as the 
> > consequences 
> > > of this decision are not light.
> > > ...
> > 
> > Thanks for your email.  I agree this needs wider discussion and the
> > WG (and probably RAI as a whole) needs to decide what it 
> wants to do.
> > 
> > The wider consequence, however, is not increased "epic invasion of 
> > privacy", as you state.  The wider consequence is that, without a
> > suitable mechanism that meets the needs of LI for SRTP, networks 
> > subject to LI will only ever be able to do RTP.  The choices, as I
> > see them, are (in order of least secure to most secure):
> > 
> >  1. everyone can listen to the call.  This is what we have today
> >     with RTP.  This allows 'epic invasion of privacy' by all 
> >     parties (governments, criminals, and anyone who is able to
> >     receive your RTP)
> >  2. every SIP entity learns the SRTP keys.  This is what would
> >     happen with Security Descriptions.  This allows 'epic 
> >     invasion of privacy' by any party that has control of any
> >     SIP entity your Invite (or its response) traversed.  That
> >     control could be legitimate or could be illegitimate 
> >     (government or criminal hacked into the SIP proxy).
> >  3. only a specific SIP entity learns the SRTP key.  This is
> >     what would happen in the two techniques I proposed at the
> >     beginning of this thread.  This allows 'epic invasion of
> >     privacy' by any party that has control of that specific
> >     SIP entity.  That control could be legitimate or could be
> >     illegitimate (government or criminal hacked into that 
> >     specific SIP proxy).
> >  4. IETF sticks with only doing DTLS-SRTP and provides no 
> >     guidance for how to meet LI requirements.
> > 
> > The choice, as IETF has always seen it, is to stick with 
> IETF's first
> > principles [RFC1984, RFC2804] which is end-to-end crypto is 
> > best (4) and
> > market and legal requirements are not relevant to IETF's 
> > standards.  I agree
> > it is a laudable and worthy goal.  I could even agree that we 
> > should leave it
> > to other SDOs, who deal more closely with LI requirements, to 
> > determine how
> > those LI requirements can be met.  
> > 
> > Yet, IETF has also said that IETF owns the SIP standards 
> (and related
> > standards).  
> > 
> > Taking your suggestion would mean we do (4) and have other 
> > SDOs decide if and
> > how to accomplish a weaker, LI-friendly solution (1, 2, or 
> > 3), and IETF should
> > not provide guidance for the most secure (3) of those 
> > remaining LI-friendly
> > approaches.  The result is undesirable:  millions of users 
> > will be unprotected
> > because they will only have plain RTP (1) or they will be 
> > vulnerable to every
> > SIP proxy on their path (2); (3) is difficult, and (4) will 
> > be undeployable by
> > licensed providers in many countries around the world.
> > 
> > -d
> > 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 19:17:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqHZC-0008F1-7N; Thu, 08 Nov 2007 19:17:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqHZA-0008CK-Bo
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 19:17:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqHZ9-0008B0-Tg; Thu, 08 Nov 2007 19:17:44 -0500
Received: from dizzyd.com ([207.210.219.225])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IqHZ9-0003ci-Dg; Thu, 08 Nov 2007 19:17:43 -0500
Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5])
	(Authenticated sender: stpeter)
	by dizzyd.com (Postfix) with ESMTP id 06DD240081;
	Thu,  8 Nov 2007 17:17:41 -0700 (MST)
Message-ID: <4733A781.7020906@stpeter.im>
Date: Thu, 08 Nov 2007 17:19:13 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Brian Stucker 
Subject: Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
X-Enigmail-Version: 0.95.5
OpenPGP: id=7BBD0573;
	url=http://www.saint-andre.com/me/stpeter.asc
Jabber-ID: stpeter@jabber.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Cc: sip , rai@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0745957610=="
Errors-To: sip-bounces@ietf.org

This is a cryptographically signed message in MIME format.

--===============0745957610==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms090607030803080007020200"

This is a cryptographically signed message in MIME format.

--------------ms090607030803080007020200
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Brian Stucker wrote:



Sorry to hijack this thread, but I'd like to second a comment that Mary
Barnes made during the WGLC:

http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html

***

It seems that all the call flow BCPs are missing and I do think those
are really important and should be included in this document.  The only
BCP (type (B) document) listed in this document is 3PCC.  The basic call
flow document (RFC 3665) should be listed in section 3 (Core SIP).  The
PSTN call flows (RFC 3666, BCP 76) should be in PSTN Interworking
section 4. The SIPPING NAT scenarios document should be in the NAT
section 6.  These docs are all icing on the cake IMHO and help to guide
implementers in using all the other docs.

***

I agree that the call flow documents are very useful and that a
reference to them would be a good thing.

Peter

--------------ms090607030803080007020200
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzExMDkwMDE5MTNaMCMGCSqG
SIb3DQEJBDEWBBSe/Q5pl4rtHA/JQPoWPZr3TsRCVDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQCDmPqmugKX417yXgTiueNeCjKQprFuXcKRipDvTQECsT+DSZ/uew01Zxts21d0UE0caeaR
VFfXJ+q9+U5erU1y/21Sbasc5imq45poRFRV0LrFNqYO8Dmbq3FdyKeqRe7OD8H3DWJAT0Gq
i9B0rTiCMDSyAMlgTxr2BwRMV3bratnyTXjlPEVEwjb3xxl34tEKNHslYQ2Fsoq5NN0J2qnl
AjgLrC02IZ5kBrCHY+BphQmfSI6f9WZBiVy7pAYjYSfgjyENAJCVvNKWwXXv4SMUPkVa7pxi
LUIaV4n2qBmGIpbcOyHuvuMbRxt76NFuhbiAcT3+k42cPmbHF6yEpPm2AAAAAAAA
--------------ms090607030803080007020200--



--===============0745957610==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0745957610==--





From sip-bounces@ietf.org Thu Nov 08 19:36:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqHra-0003D2-St; Thu, 08 Nov 2007 19:36:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqHra-0003CH-7l
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 19:36:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqHrZ-0003Ay-TS
	for sip@ietf.org; Thu, 08 Nov 2007 19:36:45 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqHrV-0001xv-3Y
	for sip@ietf.org; Thu, 08 Nov 2007 19:36:45 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA90abUr008029
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 8 Nov 2007 18:36:39 -0600
In-Reply-To: <47338479.20000@cisco.com>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
	
	<47333D93.8040700@joelhalpern.com>	<47334400.8090103@cisco.com>
	
	<4733819A.2010908@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132C2A@zrc2hxm0.corp.nortel.com>
	<47338479.20000@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5F101B7B-778D-4C68-B8B5-390D36F3945E@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 18:36:25 -0600
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: IETF SIP List , "Joel M. Halpern" ,
	Brian Stucker 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 8, 2007, at 3:49 PM, Paul Kyzivat wrote:

> Apparently at the moment communications within a private  
> enterprise, even a distributed one with VPN interconnects via  
> carriers, hasn't resulted in demanding that enterprises support LI.

Yes, it has. There's no CALEA requirement for enterprises, but they  
are subject to LI orders. LI may not be useful if the nodes in  
question are "really secure", but few enterprises have "really  
secure" systems. In my consulting days I had to help a number of  
enterprises implement intercept orders. Such orders can be very  
creatively written and darned hard to implement. But if you don't  
convince the issuing judge you're making a good effort, it's off-to- 
jail-for-contempt-of-court time . . .

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 19:39:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqHud-0006SY-G9; Thu, 08 Nov 2007 19:39:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqHub-0006Rr-Fc
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 19:39:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqHub-0006RD-4V
	for sip@ietf.org; Thu, 08 Nov 2007 19:39:53 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqHua-0004cX-M7
	for sip@ietf.org; Thu, 08 Nov 2007 19:39:52 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA90dn6v008079
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 8 Nov 2007 18:39:51 -0600
In-Reply-To: <473389A1.5000008@cisco.com>
References: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
	<473389A1.5000008@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 18:39:37 -0600
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: IETF SIP List , "Elwell, John" ,
	Dan Wing , "Peterson, Jon" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 8, 2007, at 4:11 PM, Paul Kyzivat wrote:

>
> I guess we might have "can't say who you are talking with, but  
> nobody can listen in". That in itself is of some utility.
>
> And maybe with sip identity we have "somebody you trust says you  
> are talking to X, and nobody can listen in to whoever you are  
> talking to".
>

Right. But between "all" and "nothing" there's some middle ground:  
"Nobody who hasn't been authorized to do so by your regulated  
provider can listen in". This is the middle ground they're asking us  
to fill in.

Do we want to go there, or is it all-or-nothing?

--
Dean



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 19:44:24 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqHyx-0004my-2F; Thu, 08 Nov 2007 19:44:23 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqHyv-0004h1-36
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 19:44:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqHyu-0004gk-Pe
	for sip@ietf.org; Thu, 08 Nov 2007 19:44:20 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqHyq-0002Hk-0n
	for sip@ietf.org; Thu, 08 Nov 2007 19:44:20 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lA90iBZJ008118
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 8 Nov 2007 18:44:12 -0600
In-Reply-To: <47338AC4.3000804@cisco.com>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9187@GBNTHT12009MSX.gb002.siemens.net>
	
	<0D5F89FAC29E2C41B98A6A762007F5D03E92CD@GBNTHT12009MSX.gb002.siemens.net>
	<473313C2.7040506@joelhalpern.com>
	
	<47333D93.8040700@joelhalpern.com>	<47334400.8090103@cisco.com>
	
	<4733819A.2010908@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132C2A@zrc2hxm0.corp.nortel.com>
	<47338479.20000@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF13132CEB@zrc2hxm0.corp.nortel.com>
	<47338AC4.3000804@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Thu, 8 Nov 2007 18:43:59 -0600
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: IETF SIP List , "Joel M. Halpern" ,
	Brian Stucker 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 8, 2007, at 4:16 PM, Paul Kyzivat wrote:

>
>
> Brian Stucker wrote:
>
>>> Apparently at the moment communications within a private  
>>> enterprise, even a distributed one with VPN interconnects via  
>>> carriers, hasn't resulted in demanding that enterprises support LI.
>> No, because their ISPs are required to cooperate with law enforcement
>> and another aspect of LI is that you don't want the target of the
>> intercept to be aware that they're being intercepted. It'd have been
>> pretty tough for the FBI to go to ENRON and tell them that they'd  
>> like
>> to collect all of their VPN traffic as part of an SEC  
>> investigation, so
>> they go to the ISP instead.
>
> But the end effect is that if the enterprise starts encrypting all  
> of its voice traffic over the VPN then tapping the ISP isn't going  
> to help much in getting a tap.
>
> So if that starts happening much will the Feds insist that  
> enterprises turn over the keys to their VPNs and to each voice  
> session?
>

Yes. That is exactly how the orders will read. Or, they will insist  
that the IT department hang a black box on a flood port, or that the  
enterprise install a specific software patch. I've also seen orders  
that just demanded clear-text transcripts, recordings, etc. And  
orders for the entire contents of a hard drive. Decrypted. Why do you  
think your IT department restricted which crypto you could use?

What do you think those corporate IT push-the-patch-to-the-user  
packages are about? Sometimes corporate IT gets an order to "install  
this package on the PC used by Joe Smith without him knowing."

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 21:47:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqJuF-00061o-UB; Thu, 08 Nov 2007 21:47:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqJuE-0005z1-Kd
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 21:47:38 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqJuE-0005yq-8U; Thu, 08 Nov 2007 21:47:38 -0500
Received: from mail146.messagelabs.com ([216.82.245.131])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IqJuD-0000T8-QK; Thu, 08 Nov 2007 21:47:38 -0500
X-VirusChecked: Checked
X-Env-Sender: mdolly@att.com
X-Msg-Ref: server-14.tower-146.messagelabs.com!1194576456!6074302!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 15933 invoked from network); 9 Nov 2007 02:47:36 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com)
	(144.160.20.54)
	by server-14.tower-146.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Nov 2007 02:47:36 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	lA92laQd016151; Thu, 8 Nov 2007 21:47:36 -0500
Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	lA92lW9O016145; Thu, 8 Nov 2007 21:47:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
Date: Thu, 8 Nov 2007 20:47:32 -0600
Message-ID: <28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com>
In-Reply-To: <4733A781.7020906@stpeter.im>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RAI-ART Review Comments for
	draft-ietf-sip-hitchhikers-guide
Thread-Index: AcgiZgLRMXrGMq/pSueaEMcVUTpqcgAE5wYg
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
	<4733A781.7020906@stpeter.im>
From: "DOLLY, MARTIN C, ATTLABS" 
To: "Peter Saint-Andre" ,
	"Brian Stucker" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: sip , rai@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Do you believe that the call/session flows are normative or informative?


RFC 3665 call/session flows are very good illustrative examples, but do
not really depict real deployments (measured in number of calls).=20

And further, RFC 3666 does not interoperate with the PSTN, thereby not a
good example.

Cheers,

Martin



-----Original Message-----
From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20
Sent: Thursday, November 08, 2007 7:19 PM
To: Brian Stucker
Cc: sip; rai@ietf.org
Subject: Re: [Sip] RAI-ART Review Comments for
draft-ietf-sip-hitchhikers-guide

Brian Stucker wrote:



Sorry to hijack this thread, but I'd like to second a comment that Mary
Barnes made during the WGLC:

http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html

***

It seems that all the call flow BCPs are missing and I do think those
are really important and should be included in this document.  The only
BCP (type (B) document) listed in this document is 3PCC.  The basic call
flow document (RFC 3665) should be listed in section 3 (Core SIP).  The
PSTN call flows (RFC 3666, BCP 76) should be in PSTN Interworking
section 4. The SIPPING NAT scenarios document should be in the NAT
section 6.  These docs are all icing on the cake IMHO and help to guide
implementers in using all the other docs.

***

I agree that the call flow documents are very useful and that a
reference to them would be a good thing.

Peter


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 08 23:08:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqLAi-000584-Nk; Thu, 08 Nov 2007 23:08:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqLAi-00056x-2T
	for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 23:08:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqLAh-000566-Mp
	for sip@ietf.org; Thu, 08 Nov 2007 23:08:43 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqLAh-0002i6-50
	for sip@ietf.org; Thu, 08 Nov 2007 23:08:43 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Thu, 8 Nov 2007 23:08:42 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Thu, 8 Nov 2007 23:08:42 -0500
From: Hadriel Kaplan 
To: "sip@ietf.org" 
Date: Thu, 8 Nov 2007 23:08:17 -0500
Thread-Topic: I-D Action:draft-kaplan-sip-info-events-00.txt 
Thread-Index: AcgihTtslQ2GUqBjTzWt6u4w0HG/ogAAE+9A
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_E6C2E8958BA59A4FB960963D475F7AC3023157C467mailacmepacke_"
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: Christer Holmberg 
Subject: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--_002_E6C2E8958BA59A4FB960963D475F7AC3023157C467mailacmepacke_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Howdy,
Just an FYI that Christer and I submitted a draft for SIP INFO events, base=
d on the email discussion.  This is on the agenda for Vancouver.
Cheers,
-hadriel

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Thursday, November 08, 2007 11:00 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action:draft-kaplan-sip-info-events-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>         Title           : SIP INFO Event Framework
>         Author(s)       : H. Kaplan, et al.
>         Filename        : draft-kaplan-sip-info-events-00.txt
>         Pages           : 12
>         Date            : 2007-11-08
>
> This document defines a proposed solution for defining, negotiating
> and exchanging info-event notifications in INFO messages, within SIP
> invite-created dialogs, for applications which need to exchange
> session-related information inside the invite-created dialog.  This
> draft addresses issues and open items from RFC 2976, and updates it.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-events-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
>         "get draft-kaplan-sip-info-events-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-kaplan-sip-info-events-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.


--_002_E6C2E8958BA59A4FB960963D475F7AC3023157C467mailacmepacke_
Content-Type: text/plain; name="draft-kaplan-sip-info-events-00.url.txt"
Content-Description: draft-kaplan-sip-info-events-00.url.txt
Content-Disposition: attachment;
	filename="draft-kaplan-sip-info-events-00.url.txt";
	creation-date="Thu, 08 Nov 2007 23:01:40 GMT";
	modification-date="Thu, 08 Nov 2007 23:01:40 GMT"
Content-Transfer-Encoding: base64

VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg==

--_002_E6C2E8958BA59A4FB960963D475F7AC3023157C467mailacmepacke_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--_002_E6C2E8958BA59A4FB960963D475F7AC3023157C467mailacmepacke_--





From sip-bounces@ietf.org Fri Nov 09 03:33:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqPIJ-0003ze-TS; Fri, 09 Nov 2007 03:32:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqPII-0003y4-K4
	for sip-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 03:32:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPID-0003vk-62
	for sip@ietf.org; Fri, 09 Nov 2007 03:32:45 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqPIC-0001Hc-6E
	for sip@ietf.org; Fri, 09 Nov 2007 03:32:45 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JR800K33D1TJB@siemenscomms.co.uk> for sip@ietf.org; Fri,
	09 Nov 2007 08:32:17 +0000 (GMT)
Date: Fri, 09 Nov 2007 08:32:41 +0000
From: "Elwell, John" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
In-reply-to: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
To: "Peterson, Jon" ,
	Paul Kyzivat , Ted Hardie 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E9445@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgiOoNiGO8R/aa2Rvuq+rSsuDTr2AACrenQABcSh3A=
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <47335E14.1020105@cisco.com>
	<31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: IETF SIP List , Dan Wing ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Jon,

I go along with your explanation, but I still think it leaves the
following problem. User A in domain A (e.g., an enterprise) makes a call
to/from user B in domain B, via carrier domain C. What you describe
works if domain A or domain B needs to apply LI (or record the call for
any other reason - there are plenty of legitimate business reasons). I
think we don't regard domains A and B as MitM. After all, we rely on
domains A and B to provide the Authentication Service for RFC 4474. The
issue is when domain C tries to interfere with end-to-end security in
order to support LI. I do have a problem with this, because I think it
undermines legitimate business security needs.

If domain C intervenes only when a LI warrant exists for one of the
users, I don't personally have a problem. But this violates R24, which
some people seem to think is important.

If domain C intervenes all the time (either by terminating encryption in
domain C, so that user A and user B see the source of security keying
material as domain C, or by demanding submission of the key to domain C
before admitting the call), I think this is of real concern. It means
businesses cannot have the security they need when, for various reasons,
they are forced to go via a domain C.

So I don't think we should do anything special towards meeting R24 at a
domain C. Although not the IETF's job, those concerned should work with
carriers and regulators to avoid situations where a domain C can prevent
normal end-to-end security on calls not subject to an LI warrant.

Concerning the engineering problem to be solved, there probably isn't
one if we agree that R24 does not apply to a domain C.

John

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
> Sent: 08 November 2007 21:18
> To: Paul Kyzivat; Ted Hardie
> Cc: IETF SIP List; Elwell, John; Dan Wing; Dean Willis
> Subject: RE: [Sip] media-security-requirements and lawful intercept
> 
> > I would prefer a world where all the communications were e2e 
> > encrypted with no possibility of interception, in spite of 
> the class of 
> > problems that enables.
> > 
> > But I think that we are on the losing end of that argument, 
> and that 
> > doing nothing about it is comparable to the ietf history of doing 
> > nothing about NAT. Better the evil we understand than the one that 
> > evolves without us.
> 
> If our work here becomes irrelevant, it will be because it 
> doesn't do what end users want, not because we've been 
> insufficiently obsequious to the tyrant-of-the-month. 
> Carriers, however broadly the definition of that term may be 
> creeping in some principalities, have certain obligations 
> which are not at all intrinsic to the operation of a protocol 
> like SIP, and we cannot assume that SIP's fate is determined 
> by its success in that arena alone.
> 
> > Suppose we refused to bend here. Then the carriers that are 
> subject to 
> > LI will either switch to a non-standard variant of our 
> protocols that 
> > supports the key access, or will use some entirely 
> different protocol.
> 
> As has been already pointed out in this thread, RFC4474 (and 
> any larger security architecture relying on it) invests the 
> domain responsible for your AoR with significant trust and 
> responsibility. That domain can insert men-in-the-middle 
> willy-nilly. This seemed architecturally reasonable because 
> you need to trust them anyway, for example, to route calls to 
> you and so on; the sorts of entities to whom LI requirements 
> apply would tend to be the operators of such domains, 
> incidentally. The truly paranoid can of course operate their 
> own domains, personally administer every device, and as such 
> need only trust themselves to make use of RFC4474. This casts 
> the problem exactly how it should be, I think - as an 
> administrative problem. How you deploy and use these tools 
> determines who you need to trust and where there are 
> potential avenues for adversaries to interfere with your security.
> 
> Any attempt to cast this as an engineering problem, something 
> that can be fixed or broken at a protocol level, is in my 
> opinion misguided.
> 
> Speaking more specifically to R24, my opinion is that a SIP 
> user should be able to ascertain whether or not a certain set 
> of security features have been invoked. If those features 
> have been invoked, then the user might draw the conclusion 
> that it is unlikely, barring some breakthrough in higher 
> mathematics, that someone is able to listen in on their 
> conversation. This is entirely orthogonal to whether or not 
> someone might be intercepting and recording ciphertext media 
> (something the user cannot hope to ascertain), nor whether or 
> not his administrative domain has been compromised (also 
> something the user probably cannot ascertain, even if he runs 
> his own server in a sealed bunker in Montana, given the 
> potential capabilities of adversaries) and his keys 
> plundered. The protocol, and consequently the end user, 
> cannot hope to be privy those lapses. As such it's hard for 
> me to see what the problem is with R24.
> 
> If, of course, that set of security features cannot be 
> invoked, the user might draw the conclusion that it is quite 
> likely that someone is listening in on his conversation, and 
> R24-types might find that worrisome. But it is no more likely 
> that the baleful eye of surveillance is scrutinizing the user 
> in this case, really. Inability to invoke those features 
> cannot be said to inform the user that this interaction is 
> "subject to lawful interception" or whatever. Lack of the 
> support for the security features is a much more likely culprit.
> 
> So, my question is, what's the engineering problem?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 09 07:55:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqTOm-0000QA-9t; Fri, 09 Nov 2007 07:55:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqTOk-0000PR-R6
	for sip-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 07:55:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqTOj-0000PJ-Vv
	for sip@ietf.org; Fri, 09 Nov 2007 07:55:45 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqTOg-0004v2-LR
	for sip@ietf.org; Fri, 09 Nov 2007 07:55:45 -0500
X-IronPort-AV: E=Sophos;i="4.21,394,1188792000"; d="scan'208";a="136458285"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2007 07:55:42 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA9CtgdF004480; 
	Fri, 9 Nov 2007 07:55:42 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA9CtbdS002308; 
	Fri, 9 Nov 2007 12:55:37 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 9 Nov 2007 07:55:37 -0500
Received: from [10.82.210.142] ([10.82.210.142]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 9 Nov 2007 07:55:36 -0500
Message-ID: <473458C7.50209@cisco.com>
Date: Fri, 09 Nov 2007 07:55:35 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>	<473389A1.5000008@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Nov 2007 12:55:36.0479 (UTC)
	FILETIME=[D2792AF0:01C822CF]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15534.002
X-TM-AS-Result: No--5.003800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1217; t=1194612942;
	x=1195476942; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20
	|To:=20Dean=20Willis=20;
	bh=Qe7NDe7LczFBmLkZbKBXoEvMmMQgXanf0zLxpubOCZ4=;
	b=ZVNzi2IaSIA2eN5ItlHMO+pzv2zUqDmehuj2e6PgfE1IaZJs85ioIbHPbKkA+6aLQq6g74Zf
	PQ2wET8fIJbbcl/mG5TBGAE+xmMzvI73M4cZD7+DSwClxZq8eCsPylQj;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: IETF SIP List , "Elwell, John" ,
	"Peterson, Jon" , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> 
> On Nov 8, 2007, at 4:11 PM, Paul Kyzivat wrote:
> 
>>
>> I guess we might have "can't say who you are talking with, but nobody 
>> can listen in". That in itself is of some utility.
>>
>> And maybe with sip identity we have "somebody you trust says you are 
>> talking to X, and nobody can listen in to whoever you are talking to".
>>
> 
> Right. But between "all" and "nothing" there's some middle ground: 
> "Nobody who hasn't been authorized to do so by your regulated provider 
> can listen in". This is the middle ground they're asking us to fill in.
> 
> Do we want to go there, or is it all-or-nothing?

Well, that is one of the issues isn't it?

I have mixed feelings whether the middle ground is any better and nothing.

So I don't know. But either way, I think these need to be turned into 
meaningful assertions that can be verified.

We have similar situations with callerid. There are a variety of 
mechanisms used to provide info that is presented as "callerid". These 
have a wide range of trustworthiness. I would like to have a way to 
determine the kind of assertion that goes with a callerid when it is 
displayed to me.

	Thanks,
	Paul


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 09 11:40:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqWuK-0000Iv-LV; Fri, 09 Nov 2007 11:40:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqWuJ-0000AT-1w
	for sip-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 11:40:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWuI-0000AL-Oh
	for sip@ietf.org; Fri, 09 Nov 2007 11:40:34 -0500
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqWuF-0004JN-5n
	for sip@ietf.org; Fri, 09 Nov 2007 11:40:34 -0500
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lA9GeSVd026300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 9 Nov 2007 08:40:29 -0800
Received: from [129.46.78.80] (carbuncle.qualcomm.com [129.46.78.80])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA9GeR4M004462;
	Fri, 9 Nov 2007 08:40:27 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03E9445@GBNTHT12009MSX.gb002.siemens.net>
References: <47335E14.1020105@cisco.com>
	<31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com> 
	<0D5F89FAC29E2C41B98A6A762007F5D03E9445@GBNTHT12009MSX.gb002.siemens.net>
Date: Fri, 9 Nov 2007 08:40:26 -0800
To: "Elwell, John" ,
	"Peterson, Jon" ,
	Paul Kyzivat 
From: Ted Hardie 
Subject: RE: [Sip] media-security-requirements and lawful intercept
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: IETF SIP List , Dan Wing ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 8:32 AM +0000 11/9/07, Elwell, John wrote:
>If domain C intervenes only when a LI warrant exists for one of the
>users, I don't personally have a problem. But this violates R24, which
>some people seem to think is important.

And, as some people have pointed out, they may have to intervene
every time if they are to meet a legal demand that the LI not be
detectable by the end user.  


>If domain C intervenes all the time (either by terminating encryption in
>domain C, so that user A and user B see the source of security keying
>material as domain C, or by demanding submission of the key to domain C
>before admitting the call), I think this is of real concern. It means
>businesses cannot have the security they need when, for various reasons,
>they are forced to go via a domain C.
>
>So I don't think we should do anything special towards meeting R24 at a
>domain C. Although not the IETF's job, those concerned should work with
>carriers and regulators to avoid situations where a domain C can prevent
>normal end-to-end security on calls not subject to an LI warrant.
>
>Concerning the engineering problem to be solved, there probably isn't
>one if we agree that R24 does not apply to a domain C.
>

I would personally be happy with that result.  I think the engineering problem
for anyone who believes it *must* apply to C is a hard one:  designing a system
which 1) allows C to intercept encrypted material 2) allows C to present
unencrypted material to the LI requestor 3) does not require C to ask for
the keys to every flow to hide the LI (to maintain the privacy of the flows
not subject to the LI) and 4) does not reveal C's action to A or B. 

I am not sure that it admits of a solution that does not require a lot of computational
power on the part of C (or, if the burden in 2 shifts to the LI requester, on the part of
the LI requester)

			regards,
				Ted


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 09 11:50:24 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqX3h-0003u9-Hf; Fri, 09 Nov 2007 11:50:17 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqX3g-0003pR-34
	for sip-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 11:50:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqX3f-0003pJ-Po; Fri, 09 Nov 2007 11:50:15 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IqX3d-0004hm-Ax; Fri, 09 Nov 2007 11:50:15 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lA9Go8J18750; Fri, 9 Nov 2007 16:50:08 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
Date: Fri, 9 Nov 2007 10:50:00 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF1317953B@zrc2hxm0.corp.nortel.com>
In-Reply-To: <28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RAI-ART Review Comments for
	draft-ietf-sip-hitchhikers-guide
Thread-Index: AcgiZgLRMXrGMq/pSueaEMcVUTpqcgAE5wYgAB2YciA=
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
	<4733A781.7020906@stpeter.im>
	<28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com>
From: "Brian Stucker" 
To: "DOLLY, MARTIN C, ATTLABS" ,
	"Peter Saint-Andre" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: sip , rai@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Callflows: they're such a double-edged sword.

They do a good job of quickly explaining something, but can't cover off
all the vagaries of the spec. They do such a good job, in fact, that
it's not uncommon for implementors to simply implement the
easy-to-understand call flow thinking they've captured all of the
important bits of the underlying specifications; that they never
properly check to see that they've, in fact, actually implemented the
spec correctly at all.

If we're going to include those, then there needs to be a considerable
amount of warning text exhorting the reader to use the callflows as a
study aid for the specifications and not as a substitute.

Regards,
Brian


> -----Original Message-----
> From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20
> Sent: Thursday, November 08, 2007 8:48 PM
> To: Peter Saint-Andre; Stucker, Brian (RICH1:AR00)
> Cc: sip; rai@ietf.org
> Subject: RE: [Sip] RAI-ART Review Comments for=20
> draft-ietf-sip-hitchhikers-guide
>=20
> Do you believe that the call/session flows are normative or=20
> informative?
>=20
>=20
> RFC 3665 call/session flows are very good illustrative=20
> examples, but do not really depict real deployments (measured=20
> in number of calls).=20
>=20
> And further, RFC 3666 does not interoperate with the PSTN,=20
> thereby not a good example.
>=20
> Cheers,
>=20
> Martin
>=20
>=20
>=20
> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
> Sent: Thursday, November 08, 2007 7:19 PM
> To: Brian Stucker
> Cc: sip; rai@ietf.org
> Subject: Re: [Sip] RAI-ART Review Comments for=20
> draft-ietf-sip-hitchhikers-guide
>=20
> Brian Stucker wrote:
>=20
> 
>=20
> Sorry to hijack this thread, but I'd like to second a comment=20
> that Mary Barnes made during the WGLC:
>=20
> http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html
>=20
> ***
>=20
> It seems that all the call flow BCPs are missing and I do=20
> think those are really important and should be included in=20
> this document.  The only BCP (type (B) document) listed in=20
> this document is 3PCC.  The basic call flow document (RFC=20
> 3665) should be listed in section 3 (Core SIP).  The PSTN=20
> call flows (RFC 3666, BCP 76) should be in PSTN Interworking=20
> section 4. The SIPPING NAT scenarios document should be in=20
> the NAT section 6.  These docs are all icing on the cake IMHO=20
> and help to guide implementers in using all the other docs.
>=20
> ***
>=20
> I agree that the call flow documents are very useful and that=20
> a reference to them would be a good thing.
>=20
> Peter
>=20


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 09 12:03:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqXG8-0003pf-NT; Fri, 09 Nov 2007 12:03:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqXG6-0003pC-OZ
	for sip-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 12:03:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXG6-0003p3-F3
	for sip@ietf.org; Fri, 09 Nov 2007 12:03:06 -0500
Received: from tpamail2.verizon.com ([192.76.82.136])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqXG1-0005PR-KI
	for sip@ietf.org; Fri, 09 Nov 2007 12:03:06 -0500
Received: from smtptpa3.verizon.com (smtptpa3.verizon.com [138.83.71.176])
	by tpamail2.verizon.com (8.13.3/8.13.3) with ESMTP id lA9H3055002793
	for ; Fri, 9 Nov 2007 12:03:00 -0500 (EST)
Received: from ftwintrmemf2.verizon.com (ftwintrmemf2.verizon.com
	[138.83.131.184])
	by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id lA9H30x5001342
	for ; Fri, 9 Nov 2007 12:03:00 -0500 (EST)
Received: from ftwintrmemf2.verizon.com (unknown [127.0.0.1])
	by ftwintrmemf2.verizon.com (Symantec Mail Security) with ESMTP id
	8726B528003 for ; Fri,  9 Nov 2007 12:03:00 -0500 (EST)
X-AuditID: 8a5383b8-aefdcbb000000820-27-473492c486e7 
Received: from coregate2.verizon.com (unknown [138.83.34.48])
	by ftwintrmemf2.verizon.com (EMF) with ESMTP id 570224E4007
	for ; Fri,  9 Nov 2007 12:03:00 -0500 (EST)
Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62])
	by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id lA9H54pc008752
	for ; Fri, 9 Nov 2007 11:05:04 -0600 (CST)
From: nabeel.2.cocker@verizon.com
To: sip@ietf.org
Message-ID: 
Date: Fri, 9 Nov 2007 12:02:54 -0500
X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release
	7.0.2FP2HF294 | September 14, 2007) at 11/09/2007 11:02:59
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Subject: [Sip] Nabeel 2. Cocker/EMPL/NY/Bell-Atl is out of the office.
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2146096137=="
Errors-To: sip-bounces@ietf.org

--===============2146096137==
Content-type: multipart/alternative; 
	Boundary="0__=0ABBF91DDFCE20E88f9e8a93df938690918c0ABBF91DDFCE20E8"
Content-Disposition: inline

--0__=0ABBF91DDFCE20E88f9e8a93df938690918c0ABBF91DDFCE20E8
Content-type: text/plain; charset=US-ASCII


I will be out of the office starting  11/09/2007 and will not return until
11/13/2007.

I will respond to your message when I return.

Regards,
Nabeel
--0__=0ABBF91DDFCE20E88f9e8a93df938690918c0ABBF91DDFCE20E8
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline



I will be out of the office starting  11/09/2007 and will not return until 11/13/2007.



I will respond to your message when I return.



Regards,

Nabeel
--0__=0ABBF91DDFCE20E88f9e8a93df938690918c0ABBF91DDFCE20E8--




--===============2146096137==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============2146096137==--






From sip-bounces@ietf.org Fri Nov 09 12:07:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqXK0-000689-VE; Fri, 09 Nov 2007 12:07:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqXJz-00067Q-IU
	for sip-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 12:07:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqXJz-00067I-7h; Fri, 09 Nov 2007 12:07:07 -0500
Received: from mail121.messagelabs.com ([216.82.241.195])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IqXJy-0002QX-Mo; Fri, 09 Nov 2007 12:07:07 -0500
X-VirusChecked: Checked
X-Env-Sender: mdolly@att.com
X-Msg-Ref: server-9.tower-121.messagelabs.com!1194628023!22665561!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 23387 invoked from network); 9 Nov 2007 17:07:04 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com)
	(144.160.20.54)
	by server-9.tower-121.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Nov 2007 17:07:04 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	lA9H72Bc029448; Fri, 9 Nov 2007 12:07:03 -0500
Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	lA9H6xID029406; Fri, 9 Nov 2007 12:06:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
Date: Fri, 9 Nov 2007 11:06:59 -0600
Message-ID: <28F05913385EAC43AF019413F674A0171246E611@OCCLUST04EVS1.ugd.att.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1317953B@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RAI-ART Review Comments for
	draft-ietf-sip-hitchhikers-guide
Thread-Index: AcgiZgLRMXrGMq/pSueaEMcVUTpqcgAE5wYgAB2YciAAALe8IA==
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
	<4733A781.7020906@stpeter.im>
	<28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com>
	<1ECE0EB50388174790F9694F77522CCF1317953B@zrc2hxm0.corp.nortel.com>
From: "DOLLY, MARTIN C, ATTLABS" 
To: "Brian Stucker" ,
	"Peter Saint-Andre" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: sip , rai@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Brian,

I agree.

Martin=20

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortel.com]=20
Sent: Friday, November 09, 2007 11:50 AM
To: DOLLY, MARTIN C, ATTLABS; Peter Saint-Andre
Cc: sip; rai@ietf.org
Subject: RE: [Sip] RAI-ART Review Comments for
draft-ietf-sip-hitchhikers-guide

Callflows: they're such a double-edged sword.

They do a good job of quickly explaining something, but can't cover off
all the vagaries of the spec. They do such a good job, in fact, that
it's not uncommon for implementors to simply implement the
easy-to-understand call flow thinking they've captured all of the
important bits of the underlying specifications; that they never
properly check to see that they've, in fact, actually implemented the
spec correctly at all.

If we're going to include those, then there needs to be a considerable
amount of warning text exhorting the reader to use the callflows as a
study aid for the specifications and not as a substitute.

Regards,
Brian


> -----Original Message-----
> From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20
> Sent: Thursday, November 08, 2007 8:48 PM
> To: Peter Saint-Andre; Stucker, Brian (RICH1:AR00)
> Cc: sip; rai@ietf.org
> Subject: RE: [Sip] RAI-ART Review Comments for=20
> draft-ietf-sip-hitchhikers-guide
>=20
> Do you believe that the call/session flows are normative or=20
> informative?
>=20
>=20
> RFC 3665 call/session flows are very good illustrative=20
> examples, but do not really depict real deployments (measured=20
> in number of calls).=20
>=20
> And further, RFC 3666 does not interoperate with the PSTN,=20
> thereby not a good example.
>=20
> Cheers,
>=20
> Martin
>=20
>=20
>=20
> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
> Sent: Thursday, November 08, 2007 7:19 PM
> To: Brian Stucker
> Cc: sip; rai@ietf.org
> Subject: Re: [Sip] RAI-ART Review Comments for=20
> draft-ietf-sip-hitchhikers-guide
>=20
> Brian Stucker wrote:
>=20
> 
>=20
> Sorry to hijack this thread, but I'd like to second a comment=20
> that Mary Barnes made during the WGLC:
>=20
> http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html
>=20
> ***
>=20
> It seems that all the call flow BCPs are missing and I do=20
> think those are really important and should be included in=20
> this document.  The only BCP (type (B) document) listed in=20
> this document is 3PCC.  The basic call flow document (RFC=20
> 3665) should be listed in section 3 (Core SIP).  The PSTN=20
> call flows (RFC 3666, BCP 76) should be in PSTN Interworking=20
> section 4. The SIPPING NAT scenarios document should be in=20
> the NAT section 6.  These docs are all icing on the cake IMHO=20
> and help to guide implementers in using all the other docs.
>=20
> ***
>=20
> I agree that the call flow documents are very useful and that=20
> a reference to them would be a good thing.
>=20
> Peter
>=20


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 09 13:13:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqYMZ-0004xT-Ef; Fri, 09 Nov 2007 13:13:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqYMX-0004uN-Me
	for sip-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 13:13:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqYMX-0004tY-AV; Fri, 09 Nov 2007 13:13:49 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IqYMW-0005O1-IX; Fri, 09 Nov 2007 13:13:49 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JR90086P3Y9RF@siemenscomms.co.uk>; Fri,
	09 Nov 2007 18:13:21 +0000 (GMT)
Date: Fri, 09 Nov 2007 18:13:46 +0000
From: "Elwell, John" 
Subject: RE: [RAI] RE: [Sip] RAI-ART Review Comments
	fordraft-ietf-sip-hitchhikers-guide
In-reply-to: <28F05913385EAC43AF019413F674A0171246E611@OCCLUST04EVS1.ugd.att.com>
To: "DOLLY, MARTIN C, ATTLABS" ,
	Brian Stucker , Peter Saint-Andre 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E9577@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [RAI] RE: [Sip] RAI-ART Review Comments
	fordraft-ietf-sip-hitchhikers-guide
Thread-Index: AcgiZgLRMXrGMq/pSueaEMcVUTpqcgAE5wYgAB2YciAAALe8IAACT4/A
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
	<4733A781.7020906@stpeter.im>
	<28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com>
	<1ECE0EB50388174790F9694F77522CCF1317953B@zrc2hxm0.corp.nortel.com>
	<28F05913385EAC43AF019413F674A0171246E611@OCCLUST04EVS1.ugd.att.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: sip , rai@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

So do I. People interpreting call flows as definitive have caused us
lots of grief in the past.

John 

> -----Original Message-----
> From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] 
> Sent: 09 November 2007 17:07
> To: Brian Stucker; Peter Saint-Andre
> Cc: sip; rai@ietf.org
> Subject: [RAI] RE: [Sip] RAI-ART Review Comments 
> fordraft-ietf-sip-hitchhikers-guide
> 
> Brian,
> 
> I agree.
> 
> Martin 
> 
> -----Original Message-----
> From: Brian Stucker [mailto:bstucker@nortel.com] 
> Sent: Friday, November 09, 2007 11:50 AM
> To: DOLLY, MARTIN C, ATTLABS; Peter Saint-Andre
> Cc: sip; rai@ietf.org
> Subject: RE: [Sip] RAI-ART Review Comments for
> draft-ietf-sip-hitchhikers-guide
> 
> Callflows: they're such a double-edged sword.
> 
> They do a good job of quickly explaining something, but can't 
> cover off
> all the vagaries of the spec. They do such a good job, in fact, that
> it's not uncommon for implementors to simply implement the
> easy-to-understand call flow thinking they've captured all of the
> important bits of the underlying specifications; that they never
> properly check to see that they've, in fact, actually implemented the
> spec correctly at all.
> 
> If we're going to include those, then there needs to be a considerable
> amount of warning text exhorting the reader to use the callflows as a
> study aid for the specifications and not as a substitute.
> 
> Regards,
> Brian
> 
> 
> > -----Original Message-----
> > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] 
> > Sent: Thursday, November 08, 2007 8:48 PM
> > To: Peter Saint-Andre; Stucker, Brian (RICH1:AR00)
> > Cc: sip; rai@ietf.org
> > Subject: RE: [Sip] RAI-ART Review Comments for 
> > draft-ietf-sip-hitchhikers-guide
> > 
> > Do you believe that the call/session flows are normative or 
> > informative?
> > 
> > 
> > RFC 3665 call/session flows are very good illustrative 
> > examples, but do not really depict real deployments (measured 
> > in number of calls). 
> > 
> > And further, RFC 3666 does not interoperate with the PSTN, 
> > thereby not a good example.
> > 
> > Cheers,
> > 
> > Martin
> > 
> > 
> > 
> > -----Original Message-----
> > From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
> > Sent: Thursday, November 08, 2007 7:19 PM
> > To: Brian Stucker
> > Cc: sip; rai@ietf.org
> > Subject: Re: [Sip] RAI-ART Review Comments for 
> > draft-ietf-sip-hitchhikers-guide
> > 
> > Brian Stucker wrote:
> > 
> > 
> > 
> > Sorry to hijack this thread, but I'd like to second a comment 
> > that Mary Barnes made during the WGLC:
> > 
> > http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html
> > 
> > ***
> > 
> > It seems that all the call flow BCPs are missing and I do 
> > think those are really important and should be included in 
> > this document.  The only BCP (type (B) document) listed in 
> > this document is 3PCC.  The basic call flow document (RFC 
> > 3665) should be listed in section 3 (Core SIP).  The PSTN 
> > call flows (RFC 3666, BCP 76) should be in PSTN Interworking 
> > section 4. The SIPPING NAT scenarios document should be in 
> > the NAT section 6.  These docs are all icing on the cake IMHO 
> > and help to guide implementers in using all the other docs.
> > 
> > ***
> > 
> > I agree that the call flow documents are very useful and that 
> > a reference to them would be a good thing.
> > 
> > Peter
> > 
> 
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www1.ietf.org/mailman/listinfo/rai
> 


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 09 22:07:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqggS-0005F9-AA; Fri, 09 Nov 2007 22:06:56 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqggQ-0005B2-La
	for sip-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 22:06:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqggQ-0005Au-BZ
	for sip@ietf.org; Fri, 09 Nov 2007 22:06:54 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqggN-000101-Ri
	for sip@ietf.org; Fri, 09 Nov 2007 22:06:54 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAA36ibV017338
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 9 Nov 2007 21:06:45 -0600
In-Reply-To: 
References: <47335E14.1020105@cisco.com>
	<31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
	<0D5F89FAC29E2C41B98A6A762007F5D03E9445@GBNTHT12009MSX.gb002.siemens.net>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <210D1545-1DFE-4A5D-ADE5-6B848D24744D@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Fri, 9 Nov 2007 21:06:38 -0600
To: Ted Hardie 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: IETF SIP List , Paul Kyzivat , "Elwell,
	John" , Dan Wing ,
	"Peterson, Jon" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 9, 2007, at 10:40 AM, Ted Hardie wrote:

> I would personally be happy with that result.  I think the  
> engineering problem
> for anyone who believes it *must* apply to C is a hard one:   
> designing a system
> which 1) allows C to intercept encrypted material 2) allows C to  
> present
> unencrypted material to the LI requestor 3) does not require C to  
> ask for
> the keys to every flow to hide the LI (to maintain the privacy of  
> the flows
> not subject to the LI) and 4) does not reveal C's action to A or B.

I don't think C needs to go to that extent. All C can reasonably do  
is ask A and B for the session key. If A and B are not forthcoming, C  
is free to re-negotiate its peering contract between A and B. And  
that's how the business works today.

If we assume that A and C are also regulated operators, then in most  
jurisdictions they're going to have keys for every session, and it's  
up to their regulators to decide what peers they share keys with and  
what peers they don't.

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 10 08:27:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqqNG-0004A3-7p; Sat, 10 Nov 2007 08:27:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IqqNF-00047r-0p
	for sip-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 08:27:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqqNE-00044B-Ko
	for sip@ietf.org; Sat, 10 Nov 2007 08:27:44 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqqND-0008Oi-J9
	for sip@ietf.org; Sat, 10 Nov 2007 08:27:44 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAADRcZs026683
	for ; Sat, 10 Nov 2007 07:27:38 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 10 Nov 2007 07:27:38 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 10 Nov 2007 14:27:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt 
Date: Sat, 10 Nov 2007 14:27:32 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt 
Thread-Index: AcgQU884Olh/7kRRT9m3/089eJov1QFRFYEQA4EaZeA=
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
From: "DRAGE, Keith \(Keith\)" 
To: 
X-OriginalArrivalTime: 10 Nov 2007 13:27:36.0289 (UTC)
	FILETIME=[752EAD10:01C8239D]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

(As WG chair)

We haven't exactly had the best response to this reissue of the WGLC.

There were a good 10 or 12 of you (at least) in the last IETF meeting
who said you needed this document. That means I am expecting 10 or 12
last call comments from you because you will have read the document.=20

I am going to assume that as there was a delay in one of the critical
references being produced, this gave you problems. These documents are
now at:

http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-00.txt

Note that while comments on these two documents are welcome, please use
a separate thread for such comments, and restrict this thread to WGLC
comments on connect-reuse, which can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-08.txt

I am going to extend this WGLC for a further two weeks until 24th
November - please read and respond on this document by then.

Regards

Keith



> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
> Sent: Tuesday, October 23, 2007 6:24 PM
> To: sip@ietf.org
> Subject: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt=20
>=20
> (As WG chair)
>=20
> Here we have a document that has been floating around for a=20
> while. We had a WGLC on it back on 26th October 2005 to=20
> complete 18th November 2005. After that we got buried in=20
> outbound, and sort of lost direction.
>=20
> At the last IETF meeting, we agreed to rescope this and as a=20
> result decided there support in progressing the document. You=20
> can find the record of that discussion in the proceedings for=20
> IETF#69. This draft reflects those WG decisions.=20
>=20
> We would therefore like to renew the WGLC, and solicit=20
> comments by close of business on Tuesday 6th November on=20
> draft-ietf-sip-connect-reuse-08.
>=20
> Normal rules apply. Comments to the sip mailing list and=20
> authors. Please clearly identify the nature of your comment=20
> (editorial, minor technical, major). Please clearly identify=20
> the text to which your comment relates.
>=20
> Note that of the normative references, domain-certs is in=20
> progress as a WG item, and we should see a first draft of the=20
> WG text in the next few days.
>=20
> Regards
>=20
> Keith
>=20
>=20
>=20
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Wednesday, October 17, 2007 1:15 AM
> > To: i-d-announce@ietf.org
> > Cc: sip@ietf.org
> > Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-08.txt
> >=20
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> > directories.
> > This draft is a work item of the Session Initiation=20
> Protocol Working=20
> > Group of the IETF.
> >=20
> > 	Title		: Connection Reuse in the Session Initiation=20
> >                           Protocol (SIP)
> > 	Author(s)	: R. Mahy, et al.
> > 	Filename	: draft-ietf-sip-connect-reuse-08.txt
> > 	Pages		: 21
> > 	Date		: 2007-10-16
> > =09
> > This document enables a pair of communicating proxies to reuse a
> >    congestion-controlled connection between themselves for sending
> >    requests in the forward and backwards direction.  Because the
> >    connection is essentially aliased for requests going in the=20
> > backwards
> >    direction, reuse should be predicated upon both the communicating
> >    endpoints authenticating themselves using X.509 certificates=20
> > through
> >    TLS.  For this reason, we only consider connection reuse for TLS=20
> > over
> >    TCP and TLS over SCTP.  A single connection cannot be reused for=20
> > the
> >    TCP or SCTP transport between two peers, and this=20
> document provides
> >    insight into why this is the case.  As a remedy, it=20
> suggests using
> >    two TCP connections (or two SCTP associations), each opened pro-
> >    actively towards the recipient by the sender.  Finally, this=20
> > document
> >    also provides guidelines on connection reuse and virtual SIP=20
> > servers
> >    and the interaction of connection reuse and DNS SRV=20
> lookups in SIP.
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu
> > se-08.txt
> >=20
> > To remove yourself from the I-D Announcement list, send a=20
> message to=20
> > i-d-announce-request@ietf.org with the word unsubscribe in=20
> the body of=20
> > the message.
> > You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >=20
> > Internet-Drafts are also available by anonymous FTP. Login with the=20
> > username "anonymous" and a password of your e-mail address. After=20
> > logging in, type "cd internet-drafts" and then "get=20
> > draft-ietf-sip-connect-reuse-08.txt".
> >=20
> > A list of Internet-Drafts directories can be found in=20
> > http://www.ietf.org/shadow.html or=20
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >=20
> > Internet-Drafts can also be obtained by e-mail.
> >=20
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-sip-connect-reuse-08.txt".
> > =09
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >=20
> > Below is the data which will enable a MIME compliant mail reader=20
> > implementation to automatically retrieve the ASCII version of the=20
> > Internet-Draft.
> >=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 10 12:00:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iqtgl-0003gv-5S; Sat, 10 Nov 2007 12:00:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iqtgj-0003dn-C5
	for sip-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 12:00:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqtgi-0003dR-T7
	for sip@ietf.org; Sat, 10 Nov 2007 12:00:05 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iqtgh-0007HX-RD
	for sip@ietf.org; Sat, 10 Nov 2007 12:00:04 -0500
X-IronPort-AV: E=Sophos;i="4.21,399,1188802800"; d="scan'208";a="31559918"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-1.cisco.com with ESMTP; 10 Nov 2007 09:00:03 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAAH03pi024114; 
	Sat, 10 Nov 2007 09:00:03 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAAGxnQ6028799;
	Sat, 10 Nov 2007 16:59:49 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 10 Nov 2007 08:59:49 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 10 Nov 2007 08:59:48 -0800
Message-ID: <4735E3A2.3020100@cisco.com>
Date: Sat, 10 Nov 2007 12:00:18 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Peterson, Jon" 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
In-Reply-To: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Nov 2007 16:59:48.0746 (UTC)
	FILETIME=[1A516EA0:01C823BB]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6839; t=1194714003;
	x=1195578003; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=l1lPdyVGvXw745X9oGKnoIYu9ITCIZ50O/vGR3vITDY=;
	b=PdBEOf4Uuk05jYEjjl+80MSAxpv9uYzUztgst9NelZRy9HWMHccdeftdHQHO+YiNwDL/O5kF
	qcgM70Ym95FyUd6553NpZOnhmkVyDjGlpwJNHVXlBvltXZQvwVKpqceA46mPVOV2w0ZrjWK3H/
	ZGy8FR54YHMjLvMpXvptH/bis=;
Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: IETF SIP List , Paul Kyzivat , "Elwell,
	John" , Dan Wing ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I wish I could agree that the likelihood of the irrelevancy of our work 
is tied to its meeting the needs of end users. Unfortunately, I think 
the reality is more complex than that. Frankly I think the vast majority 
of end users don't care at all about this problem, and will not likely 
choose one provider over another based on the fact that they provide 
security that protects against malicious proxies or what have you. Keep 
in mind that the PSTN provides "security" for voice which is far worse 
even than what sdescriptions provides. My sense of what users probably 
want is enough security to make sure that some kid on the wifi hotspot 
can't pick off their credit card numbers when they call their bank from 
Starbucks. Any of our existing security solutions provide that.

The customers of our protocols are the enterprises and service providers 
that deploy them. If we deliver protocols that they cannot use, because 
they do not meet their needs in terms of LI (or other network 
functions), they'll just use something else that does meet their needs. 
That solution is likely to be what it already is - mostly sdes, along 
with the security weaknesses it comes with. And furthermore it won't 
interoperate since other SP or enterprises will choose MIKEY and we'll 
be in the same mess we are today.

I think our engineering challenge is to provide a solution which gives 
the maximum security possible in an environment where LI exists - 
because it will exist, like it or not. Furthermore, that solution has to 
be relatively cost effective to deploy compared to the alternative. For 
example, if our solution REQUIRES every single call to be decrypted and 
re-encrypted, this is going to be way more expensive to the deployers of 
our protocols than sdescriptions. Also keep in mind that its not just 
voice - but video (ideally hi-def) that is coming down the road, which 
will make that decrypt/re-encrypt function even more expensive. So why 
would they choose this new protocol over sdescriptions? sdes will be 
cheaper to deploy, it will provide security good enough to meet the 
user's needs, and they can deal with interop via SBCs on the boundary. 
If we want to do better than that, we better provide an alternative that 
is more palatable.

Thanks,
Jonathan R.




Peterson, Jon wrote:
>> I would prefer a world where all the communications were e2e 
>> encrypted with no possibility of interception, in spite of the
>> class of problems that enables.
>> 
>> But I think that we are on the losing end of that argument, and
>> that doing nothing about it is comparable to the ietf history of
>> doing nothing about NAT. Better the evil we understand than the one
>> that evolves without us.
> 
> If our work here becomes irrelevant, it will be because it doesn't do
> what end users want, not because we've been insufficiently obsequious
> to the tyrant-of-the-month. Carriers, however broadly the definition
> of that term may be creeping in some principalities, have certain
> obligations which are not at all intrinsic to the operation of a
> protocol like SIP, and we cannot assume that SIP's fate is determined
> by its success in that arena alone.
> 
>> Suppose we refused to bend here. Then the carriers that are subject
>> to LI will either switch to a non-standard variant of our protocols
>> that supports the key access, or will use some entirely different
>> protocol.
> 
> As has been already pointed out in this thread, RFC4474 (and any
> larger security architecture relying on it) invests the domain
> responsible for your AoR with significant trust and responsibility.
> That domain can insert men-in-the-middle willy-nilly. This seemed
> architecturally reasonable because you need to trust them anyway, for
> example, to route calls to you and so on; the sorts of entities to
> whom LI requirements apply would tend to be the operators of such
> domains, incidentally. The truly paranoid can of course operate their
> own domains, personally administer every device, and as such need
> only trust themselves to make use of RFC4474. This casts the problem
> exactly how it should be, I think - as an administrative problem. How
> you deploy and use these tools determines who you need to trust and
> where there are potential avenues for adversaries to interfere with
> your security.
> 
> Any attempt to cast this as an engineering problem, something that
> can be fixed or broken at a protocol level, is in my opinion
> misguided.
> 
> Speaking more specifically to R24, my opinion is that a SIP user
> should be able to ascertain whether or not a certain set of security
> features have been invoked. If those features have been invoked, then
> the user might draw the conclusion that it is unlikely, barring some
> breakthrough in higher mathematics, that someone is able to listen in
> on their conversation. This is entirely orthogonal to whether or not
> someone might be intercepting and recording ciphertext media
> (something the user cannot hope to ascertain), nor whether or not his
> administrative domain has been compromised (also something the user
> probably cannot ascertain, even if he runs his own server in a sealed
> bunker in Montana, given the potential capabilities of adversaries)
> and his keys plundered. The protocol, and consequently the end user,
> cannot hope to be privy those lapses. As such it's hard for me to see
> what the problem is with R24.
> 
> If, of course, that set of security features cannot be invoked, the
> user might draw the conclusion that it is quite likely that someone
> is listening in on his conversation, and R24-types might find that
> worrisome. But it is no more likely that the baleful eye of
> surveillance is scrutinizing the user in this case, really. Inability
> to invoke those features cannot be said to inform the user that this
> interaction is "subject to lawful interception" or whatever. Lack of
> the support for the security features is a much more likely culprit.
> 
> So, my question is, what's the engineering problem?
> 
> Jon Peterson NeuStar, Inc.
> 
> 
> _______________________________________________ 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 10 17:49:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iqz8X-0003t5-3D; Sat, 10 Nov 2007 17:49:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iqz8U-0003rM-Es
	for sip-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 17:49:06 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqz8U-0003rE-3A
	for sip@ietf.org; Sat, 10 Nov 2007 17:49:06 -0500
Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iqz8T-0001zn-36
	for sip@ietf.org; Sat, 10 Nov 2007 17:49:05 -0500
Received: from cornfed (unknown [67.162.139.200])
	(Authenticated sender: fwmiller@cornfed.com)
	by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id
	AD5E31C802C; Sat, 10 Nov 2007 16:16:37 -0600 (CST)
From: "Frank W. Miller" 
To: "'Jonathan Rosenberg'" ,
	"'Peterson, Jon'" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Sat, 10 Nov 2007 15:48:21 -0700
Message-ID: <008201c823eb$cc509920$6901a8c0@cornfed>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <4735E3A2.3020100@cisco.com>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1
Cc: 'IETF SIP List' , 'Paul Kyzivat' ,
	"'Elwell, John'" , 'Dan Wing' ,
	'Dean Willis' 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



I could not disagree more.

The purpose of our work in IETF forums is not to pander to the service
providers and the strongarm tactics that the government uses to control
them.  It is to provide the best possible protocol that enables as many
uses as possible.  You yourself have always stated that SIP is general
and should support a wide variety of uses cases.  Why is that different
now with security?

Our security requirements and implementation MUST include use cases that
involve true end-to-end security that does not include the ability for
eavesdropping of any kind, let alone LI.

To support this, I would point at the applications I am seeing with my
employer, since you have focused on the needs of yours.

We build military radios.  Those radios are moving towards the use of
VoIP and want to leverage SIP for many reasons.  There are MANY
situations in these environments where end-to-end security is an
absolute requirement, in many cases, with NSA Type I encryption to boot.
If the protocol does not include these capabilities, others will be
needed to support these requirements and interoperability will suffer.

While we may provide scenarios where LI can be accomplished, we cannot
define the protocol in a way that precludes the ability to do end-to-end
security.

FM



-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] 
Sent: Saturday, November 10, 2007 10:00 AM
To: Peterson, Jon
Cc: IETF SIP List; Paul Kyzivat; Elwell, John; Dan Wing; Dean Willis
Subject: Re: [Sip] media-security-requirements and lawful intercept

I wish I could agree that the likelihood of the irrelevancy of our work 
is tied to its meeting the needs of end users. Unfortunately, I think 
the reality is more complex than that. Frankly I think the vast majority

of end users don't care at all about this problem, and will not likely 
choose one provider over another based on the fact that they provide 
security that protects against malicious proxies or what have you. Keep 
in mind that the PSTN provides "security" for voice which is far worse 
even than what sdescriptions provides. My sense of what users probably 
want is enough security to make sure that some kid on the wifi hotspot 
can't pick off their credit card numbers when they call their bank from 
Starbucks. Any of our existing security solutions provide that.

The customers of our protocols are the enterprises and service providers

that deploy them. If we deliver protocols that they cannot use, because 
they do not meet their needs in terms of LI (or other network 
functions), they'll just use something else that does meet their needs. 
That solution is likely to be what it already is - mostly sdes, along 
with the security weaknesses it comes with. And furthermore it won't 
interoperate since other SP or enterprises will choose MIKEY and we'll 
be in the same mess we are today.

I think our engineering challenge is to provide a solution which gives 
the maximum security possible in an environment where LI exists - 
because it will exist, like it or not. Furthermore, that solution has to

be relatively cost effective to deploy compared to the alternative. For 
example, if our solution REQUIRES every single call to be decrypted and 
re-encrypted, this is going to be way more expensive to the deployers of

our protocols than sdescriptions. Also keep in mind that its not just 
voice - but video (ideally hi-def) that is coming down the road, which 
will make that decrypt/re-encrypt function even more expensive. So why 
would they choose this new protocol over sdescriptions? sdes will be 
cheaper to deploy, it will provide security good enough to meet the 
user's needs, and they can deal with interop via SBCs on the boundary. 
If we want to do better than that, we better provide an alternative that

is more palatable.

Thanks,
Jonathan R.




Peterson, Jon wrote:
>> I would prefer a world where all the communications were e2e 
>> encrypted with no possibility of interception, in spite of the
>> class of problems that enables.
>> 
>> But I think that we are on the losing end of that argument, and
>> that doing nothing about it is comparable to the ietf history of
>> doing nothing about NAT. Better the evil we understand than the one
>> that evolves without us.
> 
> If our work here becomes irrelevant, it will be because it doesn't do
> what end users want, not because we've been insufficiently obsequious
> to the tyrant-of-the-month. Carriers, however broadly the definition
> of that term may be creeping in some principalities, have certain
> obligations which are not at all intrinsic to the operation of a
> protocol like SIP, and we cannot assume that SIP's fate is determined
> by its success in that arena alone.
> 
>> Suppose we refused to bend here. Then the carriers that are subject
>> to LI will either switch to a non-standard variant of our protocols
>> that supports the key access, or will use some entirely different
>> protocol.
> 
> As has been already pointed out in this thread, RFC4474 (and any
> larger security architecture relying on it) invests the domain
> responsible for your AoR with significant trust and responsibility.
> That domain can insert men-in-the-middle willy-nilly. This seemed
> architecturally reasonable because you need to trust them anyway, for
> example, to route calls to you and so on; the sorts of entities to
> whom LI requirements apply would tend to be the operators of such
> domains, incidentally. The truly paranoid can of course operate their
> own domains, personally administer every device, and as such need
> only trust themselves to make use of RFC4474. This casts the problem
> exactly how it should be, I think - as an administrative problem. How
> you deploy and use these tools determines who you need to trust and
> where there are potential avenues for adversaries to interfere with
> your security.
> 
> Any attempt to cast this as an engineering problem, something that
> can be fixed or broken at a protocol level, is in my opinion
> misguided.
> 
> Speaking more specifically to R24, my opinion is that a SIP user
> should be able to ascertain whether or not a certain set of security
> features have been invoked. If those features have been invoked, then
> the user might draw the conclusion that it is unlikely, barring some
> breakthrough in higher mathematics, that someone is able to listen in
> on their conversation. This is entirely orthogonal to whether or not
> someone might be intercepting and recording ciphertext media
> (something the user cannot hope to ascertain), nor whether or not his
> administrative domain has been compromised (also something the user
> probably cannot ascertain, even if he runs his own server in a sealed
> bunker in Montana, given the potential capabilities of adversaries)
> and his keys plundered. The protocol, and consequently the end user,
> cannot hope to be privy those lapses. As such it's hard for me to see
> what the problem is with R24.
> 
> If, of course, that set of security features cannot be invoked, the
> user might draw the conclusion that it is quite likely that someone
> is listening in on his conversation, and R24-types might find that
> worrisome. But it is no more likely that the baleful eye of
> surveillance is scrutinizing the user in this case, really. Inability
> to invoke those features cannot be said to inform the user that this
> interaction is "subject to lawful interception" or whatever. Lack of
> the support for the security features is a much more likely culprit.
> 
> So, my question is, what's the engineering problem?
> 
> Jon Peterson NeuStar, Inc.
> 
> 
> _______________________________________________ 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 10 21:11:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ir2Hf-0002ck-N8; Sat, 10 Nov 2007 21:10:47 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ir2He-0002aP-4a
	for sip-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 21:10:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir2Hd-0002Zc-No
	for sip@ietf.org; Sat, 10 Nov 2007 21:10:45 -0500
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ir2Ha-0003LX-FI
	for sip@ietf.org; Sat, 10 Nov 2007 21:10:45 -0500
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lAB2AbNV009265
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 10 Nov 2007 18:10:38 -0800
Received: from [98.207.2.111] (vpn-10-50-0-48.qualcomm.com [10.50.0.48])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAB2AZQU004999;
	Sat, 10 Nov 2007 18:10:36 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4735E3A2.3020100@cisco.com>
References: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com>
	<4735E3A2.3020100@cisco.com>
Date: Sat, 10 Nov 2007 18:10:35 -0800
To: Jonathan Rosenberg ,
	"Peterson, Jon" 
From: Ted Hardie 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: IETF SIP List , Paul Kyzivat , "Elwell,
	John" , Dan Wing ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 12:00 PM -0500 11/10/07, Jonathan Rosenberg wrote:
>
>The customers of our protocols are the enterprises and service providers that deploy them.

They may be among the customers of our protocols, but they are neither the
only customers nor the most important ones.  We build end-to-end protocols;
in this case, one which enables person-to-person communications over
extremely varied infrastructures.  If we do not keep that in mind and deliver
a protocol that enables that person-to-person communication to be secure,
our reasoning for that protocol choice will not matter.  We will have failed
our main customer.

Yes, the features may be rarely used, and many end-user customers may neither
know nor care that they are even available.  But there are customers
who would use them if available, and there may well be more as the
feature gets easier to use and the need more evident.  If we do not
build the system with *them* in mind, who will? 

You argue that LI will exist, like it or not.  I don't think anyone here is blind
to that reality.  But there is a serious difference between designing a system
which maximizes the security of its end users, knowing that there are mechanisms
which may still compromise it, and designing a system to be palatable to those
who intend to.  There are increasing numbers of governments who treat any
attempt to maintain personal privacy as thwarting their security interests,
rather than seeing maintaining their citizens' privacy interests as part of their duty.
I have no interest in making their bites at our privacy palatable, and I have no
interest in pretending otherwise.

Again, this is my personal view, and not meant in any way as disrespect to you,

				regards,
					Ted Hardie






_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 10 22:07:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ir3Ah-0004Cr-T2; Sat, 10 Nov 2007 22:07:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ir3Af-0004Cl-QO
	for sip-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 22:07:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ir3Af-0004Cc-HB for sip@ietf.org; Sat, 10 Nov 2007 22:07:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir3AM-000495-QG
	for sip@ietf.org; Sat, 10 Nov 2007 22:07:18 -0500
Received: from host81-143-50-89.in-addr.btopenworld.com ([81.143.50.89]
	helo=mail.thephinix.org) by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Ir3AJ-0004bf-Iz for sip@ietf.org; Sat, 10 Nov 2007 22:07:18 -0500
Received: (qmail 2710 invoked from network); 11 Nov 2007 03:19:39 -0000
Received: from unknown (HELO mail.thephinix.org) (127.0.0.1)
	by localhost with SMTP; 11 Nov 2007 03:19:39 -0000
Received: from 82.34.18.23 (SquirrelMail authenticated user demuel)
	by mail.thephinix.org with HTTP;
	Sun, 11 Nov 2007 03:19:39 -0000 (UTC)
Message-ID: <51962.82.34.18.23.1194751179.squirrel@mail.thephinix.org>
Date: Sun, 11 Nov 2007 03:19:39 -0000 (UTC)
From: demuel@thephinix.org
To: sip@ietf.org
User-Agent: SquirrelMail/1.4.9a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31
X-TMDA-Confirmed: Sat, 10 Nov 2007 22:07:37 -0500
Subject: [Sip] demuel@thephinix.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

demuel@thephinix.org




_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 02:47:16 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ir7X5-0001mo-OX; Sun, 11 Nov 2007 02:47:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ir7X4-0001m4-EF
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 02:47:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir7Wz-0001hc-70
	for sip@ietf.org; Sun, 11 Nov 2007 02:46:57 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ir7Wv-0003jh-Ff
	for sip@ietf.org; Sun, 11 Nov 2007 02:46:57 -0500
Received: from deanwillis (cpe-76-185-251-204.tx.res.rr.com [76.185.251.204])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAB7klo0026405
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);
	Sun, 11 Nov 2007 01:46:49 -0600
Message-Id: <200711110746.lAB7klo0026405@nylon.softarmor.com>
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Sun, 11 Nov 2007 01:47:27 -0600
From: "Dean Willis" 
To: fwmiller@cornfed.com
MIME-Version: 1.0
X-Mailer: Lonely Cat Games ProfiMail
In-Reply-To: <008201c823eb$cc509920$6901a8c0@cornfed>
Content-Type: text/plain; charset=iso-8859-1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Jon Peterson , sip@ietf.org, pkyzivat@cisco.com,
	john.elwell@siemens.com, dwing@cisco.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> Our security requirements and implementation MUST include use cases that
> involve true end-to-end security that does not include the ability for
> eavesdropping of any kind, let alone LI.

So when your service provider asks you for your session key, do not tell them. Whether they allow the call or not, we're all happy because our principles and 
use cases have been upheld. However, some people DO want to use service providers that will require key disclosure. Should we deny their use case?

The approach Dan has suggested allows the user to decide whether or not they wish to disclose their keys. And it allows service providers to decide whether or 
not they will require the disclosure of session keys. It works in enterprises that are subject to auditing. It also works in regulated networks subject to LI. 
And it works in classified networks with maximal security requirements. It does all this with one code base, one protocol, and full interoperability between 
domains.

What use cases does this exclude?

--
dean


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 10:12:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrEUE-0005OF-Ab; Sun, 11 Nov 2007 10:12:34 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrEUC-0005JS-P7
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 10:12:32 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrEUC-0005IO-DN
	for sip@ietf.org; Sun, 11 Nov 2007 10:12:32 -0500
Received: from chip2og55.obsmtp.com ([64.18.13.47])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrEUB-0003ar-RG
	for sip@ietf.org; Sun, 11 Nov 2007 10:12:32 -0500
Received: from source ([192.150.11.134]) by chip2ob55.postini.com
	([64.18.5.12]) with SMTP; Sun, 11 Nov 2007 07:12:26 PST
Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com
	[192.150.20.198] (may be forged))
	by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
	lABFAGOP022060; Sun, 11 Nov 2007 07:10:17 -0800 (PST)
Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99])
	by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id
	lABFCIFV008486; Sun, 11 Nov 2007 07:12:19 -0800 (PST)
Received: from namail5.corp.adobe.com ([10.8.192.88]) by
	apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Nov 2007 00:12:18 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Sun, 11 Nov 2007 07:12:11 -0800
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE27D@namail5.corp.adobe.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgkCC6dD/LUmr8lQwejq6oiou80sQAa0iIg
References: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com><4735E3A2.3020100@cisco.com>
	
From: "Henry Sinnreich" 
To: "Ted Hardie" ,
	"Jonathan Rosenberg" ,
	"Peterson, Jon" 
X-OriginalArrivalTime: 11 Nov 2007 15:12:18.0228 (UTC)
	FILETIME=[3FEC3F40:01C82475]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: IETF SIP List , Paul Kyzivat , "Elwell,
	John" , Dan Wing ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I would like to add another law enforcement perspective with two usage
scenarios to what Ted Hardie says here below about the MUST have e2e
security:

- Law enforcement will not be able to protect us since the bad guys will
find out who they are and kill them first,

- The financial system will have to revert to personal contacts only and
armored carriers for everything. Or do you trust personal banking and
fund transfers through ISPs that do deep packet inspection?

Is this the type of society our engineers feel comfortable to enable?
Or is it our duty to explain these consequences to law makers?

Thanks, Henry



-----Original Message-----
From: Ted Hardie [mailto:hardie@qualcomm.com]=20
Sent: Saturday, November 10, 2007 8:11 PM
To: Jonathan Rosenberg; Peterson, Jon
Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dan Wing; Dean Willis
Subject: Re: [Sip] media-security-requirements and lawful intercept

At 12:00 PM -0500 11/10/07, Jonathan Rosenberg wrote:
>
>The customers of our protocols are the enterprises and service
providers that deploy them.

They may be among the customers of our protocols, but they are neither
the
only customers nor the most important ones.  We build end-to-end
protocols;
in this case, one which enables person-to-person communications over
extremely varied infrastructures.  If we do not keep that in mind and
deliver
a protocol that enables that person-to-person communication to be
secure,
our reasoning for that protocol choice will not matter.  We will have
failed
our main customer.

Yes, the features may be rarely used, and many end-user customers may
neither
know nor care that they are even available.  But there are customers
who would use them if available, and there may well be more as the
feature gets easier to use and the need more evident.  If we do not
build the system with *them* in mind, who will?=20

You argue that LI will exist, like it or not.  I don't think anyone here
is blind
to that reality.  But there is a serious difference between designing a
system
which maximizes the security of its end users, knowing that there are
mechanisms
which may still compromise it, and designing a system to be palatable to
those
who intend to.  There are increasing numbers of governments who treat
any
attempt to maintain personal privacy as thwarting their security
interests,
rather than seeing maintaining their citizens' privacy interests as part
of their duty.
I have no interest in making their bites at our privacy palatable, and I
have no
interest in pretending otherwise.

Again, this is my personal view, and not meant in any way as disrespect
to you,

				regards,
					Ted Hardie






_______________________________________________
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


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 10:37:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrEsk-00039L-1K; Sun, 11 Nov 2007 10:37:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrEsi-00037d-Cc
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 10:37:52 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrEsi-00037C-1r
	for sip@ietf.org; Sun, 11 Nov 2007 10:37:52 -0500
Received: from bender-mail.tigertech.net ([64.62.209.30])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrEsh-0004SK-IQ
	for sip@ietf.org; Sun, 11 Nov 2007 10:37:51 -0500
Received: from localhost (localhost [127.0.0.1])
	by bender.tigertech.net (Postfix) with ESMTP id 23FA27DF1
	for ; Sun, 11 Nov 2007 07:37:50 -0800 (PST)
Received: from [192.168.0.100] (pool-70-104-226-87.fred.east.verizon.net
	[70.104.226.87])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bender.tigertech.net (Postfix) with ESMTP id 3B39E7DB9
	for ; Sun, 11 Nov 2007 07:37:49 -0800 (PST)
Message-ID: <473721C8.1070206@joelhalpern.com>
Date: Sun, 11 Nov 2007 10:37:44 -0500
From: "Joel M. Halpern" 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IETF SIP List 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <200711110746.lAB7klo0026405@nylon.softarmor.com>
In-Reply-To: <200711110746.lAB7klo0026405@nylon.softarmor.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net
X-Spam-Status: No, hits=3.4 tagged_above=-999.0 required=7.0
	tests=RCVD_IN_SORBS_DUL, SPF_NEUTRAL
X-Spam-Level: ***
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

This sounds great.  But the reality seems to me to actually not match
this perspective.

Firstly, a solution with a mechanism for requesting a key by a third
party is clearly introducing security complexity, which seems to imply
security vulnerability from all the things I have read.

More importantly, a solution in which as a practical deployment we teach
the users to say "yes, deliver a copy of my key" when asked seems a
recipe for an insecure system even if each and every protocol component
is secure.  This makes me very uncomfortable.

Yours,
Joel M. Halpern

Dean Willis wrote:
> 
>> Our security requirements and implementation MUST include use cases that
>> involve true end-to-end security that does not include the ability for
>> eavesdropping of any kind, let alone LI.
> 
> So when your service provider asks you for your session key, do not tell them. Whether they allow the call or not, we're all happy because our principles and 
> use cases have been upheld. However, some people DO want to use service providers that will require key disclosure. Should we deny their use case?
> 
> The approach Dan has suggested allows the user to decide whether or not they wish to disclose their keys. And it allows service providers to decide whether or 
> not they will require the disclosure of session keys. It works in enterprises that are subject to auditing. It also works in regulated networks subject to LI. 
> And it works in classified networks with maximal security requirements. It does all this with one code base, one protocol, and full interoperability between 
> domains.
> 
> What use cases does this exclude?
> 
> --
> dean
> 
> 
> _______________________________________________
> 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
> 



_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 10:47:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrF21-0008Tt-OB; Sun, 11 Nov 2007 10:47:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrF1z-0008RC-Ri
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 10:47:27 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrF1z-0008Qn-Gu
	for sip@ietf.org; Sun, 11 Nov 2007 10:47:27 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrF1y-0004rl-Nb
	for sip@ietf.org; Sun, 11 Nov 2007 10:47:27 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lABFlE9m009497;
	Sun, 11 Nov 2007 09:47:14 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 11 Nov 2007 09:47:14 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 11 Nov 2007 16:47:11 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Sun, 11 Nov 2007 16:47:08 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180018C87A1@DEEXC1U01.de.lucent.com>
In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE27D@namail5.corp.adobe.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgkCC6dD/LUmr8lQwejq6oiou80sQAa0iIgAAGcQIA=
References: <31D151A3D66E404AACBBB0247ACA54A7029C9E@STNTEXCH11.cis.neustar.com><4735E3A2.3020100@cisco.com>
	<24CCCC428EFEA2469BF046DB3C7A8D223AE27D@namail5.corp.adobe.com>
From: "DRAGE, Keith \(Keith\)" 
To: "Henry Sinnreich" , "Ted Hardie" ,
	"Jonathan Rosenberg" ,
	"Peterson, Jon" 
X-OriginalArrivalTime: 11 Nov 2007 15:47:11.0828 (UTC)
	FILETIME=[1FCE4140:01C8247A]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: IETF SIP List , Paul Kyzivat , "Elwell,
	John" , Dan Wing ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

This list is NOT for discussing the woes of society at large.

Please go back to the scope of this thread which is discussing the
contents of the media security requirements document.

Regards

Keith=20

> -----Original Message-----
> From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20
> Sent: Sunday, November 11, 2007 3:12 PM
> To: Ted Hardie; Jonathan Rosenberg; Peterson, Jon
> Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dan Wing; Dean Willis
> Subject: RE: [Sip] media-security-requirements and lawful intercept
>=20
> I would like to add another law enforcement perspective with=20
> two usage scenarios to what Ted Hardie says here below about=20
> the MUST have e2e
> security:
>=20
> - Law enforcement will not be able to protect us since the=20
> bad guys will find out who they are and kill them first,
>=20
> - The financial system will have to revert to personal=20
> contacts only and armored carriers for everything. Or do you=20
> trust personal banking and fund transfers through ISPs that=20
> do deep packet inspection?
>=20
> Is this the type of society our engineers feel comfortable to enable?
> Or is it our duty to explain these consequences to law makers?
>=20
> Thanks, Henry
>=20
>=20
>=20
> -----Original Message-----
> From: Ted Hardie [mailto:hardie@qualcomm.com]
> Sent: Saturday, November 10, 2007 8:11 PM
> To: Jonathan Rosenberg; Peterson, Jon
> Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dan Wing; Dean Willis
> Subject: Re: [Sip] media-security-requirements and lawful intercept
>=20
> At 12:00 PM -0500 11/10/07, Jonathan Rosenberg wrote:
> >
> >The customers of our protocols are the enterprises and service
> providers that deploy them.
>=20
> They may be among the customers of our protocols, but they=20
> are neither the only customers nor the most important ones. =20
> We build end-to-end protocols; in this case, one which=20
> enables person-to-person communications over extremely varied=20
> infrastructures.  If we do not keep that in mind and deliver=20
> a protocol that enables that person-to-person communication=20
> to be secure, our reasoning for that protocol choice will not=20
> matter.  We will have failed our main customer.
>=20
> Yes, the features may be rarely used, and many end-user=20
> customers may neither know nor care that they are even=20
> available.  But there are customers who would use them if=20
> available, and there may well be more as the feature gets=20
> easier to use and the need more evident.  If we do not build=20
> the system with *them* in mind, who will?=20
>=20
> You argue that LI will exist, like it or not.  I don't think=20
> anyone here is blind to that reality.  But there is a serious=20
> difference between designing a system which maximizes the=20
> security of its end users, knowing that there are mechanisms=20
> which may still compromise it, and designing a system to be=20
> palatable to those who intend to.  There are increasing=20
> numbers of governments who treat any attempt to maintain=20
> personal privacy as thwarting their security interests,=20
> rather than seeing maintaining their citizens' privacy=20
> interests as part of their duty.
> I have no interest in making their bites at our privacy=20
> palatable, and I have no interest in pretending otherwise.
>=20
> Again, this is my personal view, and not meant in any way as=20
> disrespect to you,
>=20
> 				regards,
> 					Ted Hardie
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 11:49:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrFzn-0002jN-NN; Sun, 11 Nov 2007 11:49:15 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrFzl-0002eO-Sx
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 11:49:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrFzl-0002cR-Ik
	for sip@ietf.org; Sun, 11 Nov 2007 11:49:13 -0500
Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrFzi-0000rK-4P
	for sip@ietf.org; Sun, 11 Nov 2007 11:49:13 -0500
Received: from cornfed (unknown [67.162.139.200])
	(Authenticated sender: fwmiller@cornfed.com)
	by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id
	4BBA21C8032; Sun, 11 Nov 2007 10:16:36 -0600 (CST)
From: "Frank W. Miller" 
To: "'Dean Willis'" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Sun, 11 Nov 2007 09:48:28 -0700
Message-ID: <003a01c82482$af96e770$6901a8c0@cornfed>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <200711110746.lAB7klo0026405@nylon.softarmor.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: 'Jon Peterson' , sip@ietf.org, pkyzivat@cisco.com,
	john.elwell@siemens.com, dwing@cisco.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



I suppose that even if some third-party key management scheme is
adopted, ZRTP will still exist.

My point is that in this requirements, there are so many and they appear
to be fairly random in their ordering and what they are targeting the
way the draft is written that I would be concerned that some requirement
or combination of requirements would preclude and end-to-end solution.
While Section 5 does make an effort to try to group them, it seems a bit
more philosophical rather than focused on actually rounding up sets of
the requirements in Section 4.

At a minimum, I would recommend the following before further discussion
is had.  Move Section 5 before Section 4 and call it Architectural Basis
or something like that.  Then partition the requirements that are
currently in Section 4 based on that discussion.  The goal would be to
make sure there aren't any sneaky interactions between the requirements.

Also, as an aside, I would recommend that anyone that is not familiar
with SCIP should try to become familiar with it.  Those protocols follow
closely what is done currently with PSTN based STU/STEs, bringing that
operational paradigm to the packet world.  The operational approach
described by that protocol design is reflective of one set of
requirements used by the military and intelligence communities for
secure communications.

FM


-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com] 
Sent: Sunday, November 11, 2007 12:47 AM
To: fwmiller@cornfed.com
Cc: Jonathan Rosenberg; Jon Peterson; sip@ietf.org; pkyzivat@cisco.com;
john.elwell@siemens.com; dwing@cisco.com
Subject: Re: [Sip] media-security-requirements and lawful intercept



> Our security requirements and implementation MUST include use cases
that
> involve true end-to-end security that does not include the ability for
> eavesdropping of any kind, let alone LI.

So when your service provider asks you for your session key, do not tell
them. Whether they allow the call or not, we're all happy because our
principles and 
use cases have been upheld. However, some people DO want to use service
providers that will require key disclosure. Should we deny their use
case?

The approach Dan has suggested allows the user to decide whether or not
they wish to disclose their keys. And it allows service providers to
decide whether or 
not they will require the disclosure of session keys. It works in
enterprises that are subject to auditing. It also works in regulated
networks subject to LI. 
And it works in classified networks with maximal security requirements.
It does all this with one code base, one protocol, and full
interoperability between 
domains.

What use cases does this exclude?

--
dean



_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 12:47:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrGuH-00031d-LR; Sun, 11 Nov 2007 12:47:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrGuF-0002zm-Fc
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 12:47:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrGuF-0002yF-5l
	for sip@ietf.org; Sun, 11 Nov 2007 12:47:35 -0500
Received: from qmta01.emeryville.ca.mail.comcast.net ([76.96.30.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrGuB-0003LF-Q8
	for sip@ietf.org; Sun, 11 Nov 2007 12:47:35 -0500
Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12])
	by QMTA01.emeryville.ca.mail.comcast.net with smtp
	id BTuN1Y0010FhH240106300; Sun, 11 Nov 2007 17:47:33 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA08.emeryville.ca.mail.comcast.net with comcast
	id BVnY1Y0010umElk0000000; Sun, 11 Nov 2007 17:47:33 +0000
X-Authority-Analysis: v=1.0 c=1 a=g3m9QHgP0kQfhQhEvDIA:9
	a=otrBTiZNG8HjtH8Jp7jx81x5n7cA:4 a=k4qQewaewV0A:10
	a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lABHlTSV029713
	for ; Sun, 11 Nov 2007 12:47:29 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lABHlTn3029709;
	Sun, 11 Nov 2007 12:47:29 -0500
Date: Sun, 11 Nov 2007 12:47:29 -0500
Message-Id: <200711111747.lABHlTn3029709@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D03E92A3@GBNTHT12009MSX.gb002.siemens.net>
	(john.elwell@siemens.com)
Subject: Re: [Sip] FW: Last Call: draft-levin-mmusic-xml-media-control (XML
	Schema for Media Control) to Informational RFC
References: <0D5F89FAC29E2C41B98A6A762007F5D03E92A3@GBNTHT12009MSX.gb002.siemens.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Elwell, John" 

   In view of the ongoing discussions on INFO on this list, are people
   aware of this individual draft in IESG last call. It defines a new usage
   of INFO.

   John

   > - 'XML Schema for Media Control'
   >     as an 
   > Informational RFC

If I read the Abstract of that I-D correctly, it both defines a new
usage and discourages it:

   New implementations are discouraged from using the described method
   described except for backward compatibility purposes.  New
   Implementations are required to use the new full intra request
   command in the Real-time Transport Control Protocol (RTCP) channel.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 17:10:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrL0I-0003rP-FE; Sun, 11 Nov 2007 17:10:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrL0G-0003qj-8v
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 17:10:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrL0F-0003q7-UZ
	for sip@ietf.org; Sun, 11 Nov 2007 17:10:03 -0500
Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrL0C-00040B-7H
	for sip@ietf.org; Sun, 11 Nov 2007 17:10:03 -0500
Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27])
	by QMTA01.westchester.pa.mail.comcast.net with smtp
	id BUPD1Y00N0bG4ec000NJ00; Sun, 11 Nov 2007 22:10:00 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA03.westchester.pa.mail.comcast.net with comcast
	id Ba8z1Y00P0umElk0000000; Sun, 11 Nov 2007 22:09:00 +0000
X-Authority-Analysis: v=1.0 c=1 a=RQpd4lVbdV0_rVAksLAA:9
	a=s-FwSHrToV5bQ_EuaqQA:7 a=SYImRdU8JsPstYlHf1jGD8oHR8oA:4
	a=6bqG61NMjcsA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lABM8xSV016392;
	Sun, 11 Nov 2007 17:08:59 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lABM8xh5016388;
	Sun, 11 Nov 2007 17:08:59 -0500
Date: Sun, 11 Nov 2007 17:08:59 -0500
Message-Id: <200711112208.lABM8xh5016388@dragon.ariadne.com>
To: sip@ietf.org, rohan@ekabal.com, vkg@acm.org, brett@broadsoft.com
From: Dale.Worley@comcast.net
In-reply-to: <5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	(drage@alcatel-lucent.com)
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Comments on draft-ietf-sip-connect-reuse-08.

Overall:

The mechanism defined in this I-D is sensible and useful.  The writing
could be improved significantly.

Major technical:

Section 10, "Support for Virtual Servers" explains the necessity of
certain elements of the connection-reuse mechanism.  But as far as I
can tell, this explanation is incorrect (although the problem is
real).

It's a bit hard to follow the flow that is described in this section,
it seems to involve five SIP agents, only one of which has a name
("P1") and one a description ("Alice's proxy"), leaving three unnamed.
But it looks like the first step is when a proxy P1 (that is
responsible for two domains) establishes a connection to Alice's
proxy, and Alice's proxy "establishes an alias" for it, that is,
decides that the connection is usable for requests in the reverse
direction.

The second step is when a request originating from a different one of
P1's domains passes through P1 and then to Alice's proxy, causing
Alice's proxy to establish an alias for the second connection, of
course, as an alias for the same address, that of P1.

This is then supposed to lead to the inability of P1 to correctly
route requests that arrive on the connection.  This seems to involve a
binding between the connection and the ultimate destination of the
request.  But that is not possible, because as a proxy, P1 must take
into account the domain-part of the request URIs of the requests.
This seems to be related to this sentence, which is meaningless on the
face of it:  "But that entry is now aliased to a connection with
bob@chicago.example.org."  Of course, a connection is with a host, not
with a SIP URI.  (Might this be a residuum of an older path-oriented
connection reuse concept?)

However, the virtual server problem is quite real.  The fundamental
problem is that making a TLS connection to a destination involves two
distinct steps -- first, using RFC 3263 to find the address of the
destination, then second, using TLS to establish *and authenticate* a
connection.  Only if both steps succeed is the connection available
for sending the message.  As such, the "alias table" must cache not
only which connections go to which destination addresses, but which
connections have authenticated themselves as responsible for which SIP
domains.  If a message is to a *new* SIP domain that resolves to an
address with a cached connection, the cached connection cannot be
used, because the connection is not authenticated for the new domain.

(Which suggests that a proxy serving multiple domains should be able
to present during TLS authentication certificate(s) that include all
the domains that it is responsible for, so that the connection can be
used for requests to all of those domains.)

Editorial:

Overall

Excessive text is spent on the cases of TCP and SCTP without TLS.  As
far as I can see, they are to be handled exactly as previously.  It is
useful to explain why this must be so, and section 9.3 does so, but I
don't see the need for the page-long section 5.2 and 5.3.

The description focuses on the "alias table", making that particular
implementation quasi-standard.  But I don't see the mechanism as being
complex enough to require describing that specific implementation in
order to make the mechanism clear.

A few definitions are given, but various terms that are used with new
meanings are not defined.  E.g., "establish an alias" meaning "the
destination of a connection deciding that the connection can be used
in the reverse direction, that is, for sending requests".

Examples tend to discuss multiple user agents and proxies, when the
entirety of the mechanism can be described by considering only the two
SIP agents at the ends of the connection.  I think the intention is to
make the examples more realistic, but instead the examples get more
complex and hard to follow -- especially because the discussions often
aren't meticulous about specifying which agent sends which message to
which agent.  (Not to mention that the discussion suggests that user
agents and proxies might participate in this mechanism in different
ways, whereas connection-reuse treats user agents and proxies
identically.)

The use of "alias descriptor" is unfortunate.  To start with, it is
confusing -- initially I mistook it for some sort of identification of
the row of the alias table.  But the concept of "descriptor" as being
a small integer identifying a network connection, as well as the very
term "descriptor", are Unix-specific.  Much better would be to use a
neutral term like "internal connection identifier" and to represent
the value by something like "XXXX".

There is an overall conflating of two concepts as "connection reuse".
One is using one connection to send more than one request from one
sender to one recipient.  The second is using one connection to send
requests in both directions.  The first concept is already supported
by RFC 3261; the second is what is being enabled by this I-D.  But the
I-D implements both actions using one alias table, obfuscating the
distinction and so obfuscating the changes that the I-D is
introducing.

Details

Section 5

- "P1 and P2 are proxies responsible for routing SIP requests through
user agents that use them as edge proxies (see Figure 4)."

Should that be "routing SIP requests *to* user agents"?

Section 5.1

- "Upon connection authentication and acceptance, P1 adds P2s to its
alias table."

"P2s" should be "P2".

- The text uses the phrase "items of interest in the alias table" when
it means "description of the values in the alias table".

- In both enumerated lists, the texts starting "At some later time"
should be separated into an independent paragraph, outside of the
enumerated lists, because they concern a different topic than the data
in the alias table.

- "When the server, P2, receives the request, it examines the topmost
Via to determine whether P1 supports aliased connections.  ...  The
presence of the "alias" parameter indicates that P1 does support
aliasing."

This should be rephrased, since the presence of "alias" means that the
initiating SIP agent is willing to use *this* connection in the
reverse direction:  "When the server, P2, receives the request, it
examines the topmost Via to determine whether P1 is willing to use
this connection for an aliased connection.  ...  The presence of the
"alias" parameter indicates that P1 supports aliasing on this
connection."

Section 8.1

- "The implications of placing an "alias" parameter in the topmost Via
header of a request must be understood by the client.  Specifically,
this means that the client MUST keep the connection open for as long
as the resources on the host operating system allow it to, and that it
MUST accept requests over this connection -- in addition to the
default listening port -- from its downstream peer."

It would seem obvious that the implications of inserting "alias" must
be understood by the client that does so.  A better wording would be:
"If the client places an "alias" parameter in the topmost Via header
of a request, the client MUST keep the connection open for as long as
the resources on the host operating system allow it to, and that it
MUST accept requests over this connection -- in addition to the
default listening port -- from its downstream peer."

- "Whether or not to honor an aliased connection ultimately depends on
the policies of the server.  It MAY choose to honor it, and thereby
send subsequent requests over the aliased connection."

This wording suggests that somehow the connection "is aliased" whether
or not the server even understands connection-reuse.  It would be less
awkward to say:  "Whether or not to use in the reverse direction a
connection marked with "alias" ultimately depends on the policies of
the server."

Section 9.3

- "This manner of opening connections, while still not secure, is at
least much more apparent and direct than using the connection reuse
mechanism over TCP or SCTP in an unauthenticated fashion."

What is the technical definition of "apparent and direct"?  I would
suggest "... is at least more secure than ...".

Dale


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 17:52:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrLeo-00087g-JY; Sun, 11 Nov 2007 17:51:58 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrLen-00085V-Jx
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 17:51:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrLen-00085E-9D
	for sip@ietf.org; Sun, 11 Nov 2007 17:51:57 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrLem-0005Bf-Jl
	for sip@ietf.org; Sun, 11 Nov 2007 17:51:57 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 68E5033C21;
	Sun, 11 Nov 2007 14:47:07 -0800 (PST)
Date: Sun, 11 Nov 2007 14:47:06 -0800
From: Eric Rescorla 
To: "Dan Wing" 
Subject: Re: [Sip] media-security-requirements and lawful intercept
In-Reply-To: <06c101c8209d$8d543700$c4f0200a@cisco.com>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071111224707.68E5033C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: 'IETF SIP List' 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At Tue, 6 Nov 2007 09:50:42 -0800,
Dan Wing wrote:
> 
> Other SDOs have lawful intercept requirements, which are currently
> captured in requirement R24 in 
> draft-ietf-sip-media-security-requirements-00:
> 
>    "R24:   The media security key management protocol SHOULD 
>            NOT allow end users to determine whether their 
>            end-to-end interaction is subject to lawful 
>            interception."
>
> DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
> to establish SRTP keys for unicast, point-to-point SRTP sessions.
> 
> There appear to be two methods to meet R24 with DTLS-SRTP.  They
> are:
> 
>    a. provide a network element on every SRTP call which relays
>       media, performs a DTLS handshake, and decrypts and re-encrypts
>       SRTP, or;
> 
>    b. have endpoints perform key disclosure for every call (using a 
>       technique similar to draft-wing-sipping-srtp-key), and perform
>       validation of that disclosed key on every call.
> 
> If these methods to meet R24 are deemed acceptable to other SDOs,
> we don't find any reason for those SDOs to reject IETF's decision
> to use DTLS-SRTP as the preferred mechanism to establish SRTP
> keys for unicast, point-to-point SRTP sessions.

Wow, this sure produced a lot of discussion. I'd like to make a few
points:

1. It's not clear to me that people are correctly parsing LI
   requirements. I'm not an expert on CALEA, let alone laws in other
   countries, but it's not my understanding that there is any
   regulatory requirement that forces carriers of voice or data
   traffic to arrange for disclosure of plaintext when they don't have
   the keys. I.e., if I buy data service from Comcast and choose to
   run a VPN, there is no requirement that Comcast somehow obtain the
   keys to deliver them to the FBI.

   It's less clear to me what the requirements are for 3G-style
   carriers when the endpoints are doing the crypto. I.e., I'm quite
   certain that if AT&T terminates the crypto they need to provide the
   plaintext on request, but a lot less certain that they need to
   provide the plaintext if the crypto is end-to-end.

2. It's extremely difficult to guarantee that the keys for
   communication are being properly escrowed in the face of the
   possibility that one or both of the communicating parties is
   cheating. This is especially difficult if you want to avoid having
   real-time access to the escrow keys used to encrypt the traffic
   keys, which is generally good practice.  So, I would be very
   surprised if there were any regulatory requirement that LI work in
   the face of endpoint cheating.

3. Given (2) above, I don't see how R24 can be achieved, since
   two cooperating peers can always guarantee that their plaintext
   is not subject to LI if they can arrange for any side channel
   for key agreement.

4. I don't actually think there's any protocol engineering required
   here. The problem of how to arrange for TLS traffic key disclosure
   to third parties without modifying the wire protocol has been quite
   extensively studied and a broad variety of approaches exist,
   covering a range of levels of active/passiveness, real-timeness,
   cooperation from the endpoints, etc. Techniques exist which are
   significantly better than those indicated by Dan. For instance,
   consider that if you have the TLS server's private key and you're
   doing RSA, you can do completely passive inspection with no
   cooperation from either side. Another example would be [GBGP03]. 

   Also, as Jon Peterson observed, the owner of the namespace can
   always enforce any restrictions that it wants. It's possible that
   imposes significant performance costs, but it's not clear that
   that's true in all cases with clever implementation. 

   I don't really have time right now to go into any of this stuff
   in more detail, but I'd certainly be happy to sit down with
   anyone who cares in YVR and explain the state of the art. I don't
   really see that this is really relevant to what happens in this
   WG, though.

-Ekr


[GBGP03] E.-J. Goh, D. Boneh, P. Golle, B. Pinkas",
	 The Design and Implementation of Protocol-Based Hidden
	 Key Recovery", 2003.


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 17:55:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrLiJ-0005ut-RW; Sun, 11 Nov 2007 17:55:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrLiI-0005qT-8n
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 17:55:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrLiH-0005nx-3D
	for sip@ietf.org; Sun, 11 Nov 2007 17:55:33 -0500
Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrLiE-0005Na-Nv
	for sip@ietf.org; Sun, 11 Nov 2007 17:55:33 -0500
Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12])
	by QMTA02.emeryville.ca.mail.comcast.net with smtp
	id BX691Y0050FhH24010C500; Sun, 11 Nov 2007 22:55:32 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA08.emeryville.ca.mail.comcast.net with comcast
	id BavW1Y00A0umElk0000000; Sun, 11 Nov 2007 22:55:32 +0000
X-Authority-Analysis: v=1.0 c=1 a=dyyfj9ZdJzc8BqOcytkA:9
	a=R9FjW3-CQIp5mT2XOb0TZYXq4yQA:4 a=oYJ7eK8D3YMA:10
	a=eqxxFxNu-gsA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lABMtRSV019957;
	Sun, 11 Nov 2007 17:55:27 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lABMtRwk019953;
	Sun, 11 Nov 2007 17:55:27 -0500
Date: Sun, 11 Nov 2007 17:55:27 -0500
Message-Id: <200711112255.lABMtRwk019953@dragon.ariadne.com>
To: sip@ietf.org, rohan@ekabal.com, vkg@acm.org, brett@broadsoft.com
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
From: Dale.Worley@comcast.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Additional comment on draft-ietf-sip-connect-reuse-08.

- The address for Rohan Mahy, , does not seem to work.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 21:31:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrP4g-0004mI-NT; Sun, 11 Nov 2007 21:30:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrP4e-0004m0-T5
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 21:30:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrP4e-0004ls-JL
	for sip@ietf.org; Sun, 11 Nov 2007 21:30:52 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrP4b-00039D-IV
	for sip@ietf.org; Sun, 11 Nov 2007 21:30:52 -0500
X-IronPort-AV: E=Sophos;i="4.21,402,1188802800"; d="scan'208";a="250131830"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 11 Nov 2007 18:30:49 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAC2UmwL020940; 
	Sun, 11 Nov 2007 18:30:48 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAC2Umfb028905;
	Mon, 12 Nov 2007 02:30:48 GMT
From: "Dan Wing" 
To: "'Eric Rescorla'" 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<20071111224707.68E5033C21@delta.rtfm.com>
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Sun, 11 Nov 2007 18:30:48 -0800
Message-ID: <008701c824d4$096ca180$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgktXiJyLZmrcU5R2++6HvQPofukAABNnWA
In-reply-to: <20071111224707.68E5033C21@delta.rtfm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6450; t=1194834648;
	x=1195698648; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=JBti3TSZ3lZUuquqhDAwagNjXF8sc05FDygDAj/xoEY=;
	b=MwbRmWuRtNxWIJ58agWlr8aZaldULDejYMJDfoYMtJOJ+eZ1JLmiUEMgc1IMMTWsP6Y3O3a+
	snNEDOqov8uGrjhtAEh74whUsvMRgFCOVGOpyD7biF3aAYc85TpJpJhX;
Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -3.3 (---)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: 'IETF SIP List' 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com] 
> Sent: Sunday, November 11, 2007 2:47 PM
> To: Dan Wing
> Cc: 'IETF SIP List'
> Subject: Re: [Sip] media-security-requirements and lawful intercept
> 
> At Tue, 6 Nov 2007 09:50:42 -0800,
> Dan Wing wrote:
> > 
> > Other SDOs have lawful intercept requirements, which are currently
> > captured in requirement R24 in 
> > draft-ietf-sip-media-security-requirements-00:
> > 
> >    "R24:   The media security key management protocol SHOULD 
> >            NOT allow end users to determine whether their 
> >            end-to-end interaction is subject to lawful 
> >            interception."
> >
> > DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
> > to establish SRTP keys for unicast, point-to-point SRTP sessions.
> > 
> > There appear to be two methods to meet R24 with DTLS-SRTP.  They
> > are:
> > 
> >    a. provide a network element on every SRTP call which relays
> >       media, performs a DTLS handshake, and decrypts and re-encrypts
> >       SRTP, or;
> > 
> >    b. have endpoints perform key disclosure for every call (using a 
> >       technique similar to draft-wing-sipping-srtp-key), and perform
> >       validation of that disclosed key on every call.
> > 
> > If these methods to meet R24 are deemed acceptable to other SDOs,
> > we don't find any reason for those SDOs to reject IETF's decision
> > to use DTLS-SRTP as the preferred mechanism to establish SRTP
> > keys for unicast, point-to-point SRTP sessions.
> 
> Wow, this sure produced a lot of discussion. I'd like to make a few
> points:
> 
> 1. It's not clear to me that people are correctly parsing LI
>    requirements. I'm not an expert on CALEA, let alone laws in other
>    countries, but it's not my understanding that there is any
>    regulatory requirement that forces carriers of voice or data
>    traffic to arrange for disclosure of plaintext when they don't have
>    the keys. I.e., if I buy data service from Comcast and choose to
>    run a VPN, there is no requirement that Comcast somehow obtain the
>    keys to deliver them to the FBI.
> 
>    It's less clear to me what the requirements are for 3G-style
>    carriers when the endpoints are doing the crypto. I.e., I'm quite
>    certain that if AT&T terminates the crypto they need to provide the
>    plaintext on request, but a lot less certain that they need to
>    provide the plaintext if the crypto is end-to-end.

Timothy Dwight posted a followup on 3GPP's requirement that should
be helpful on those points.  What remains unsaid in that quoted text 
is crypto performed by the endpoint itself (as with DTLS-SRTP).

We could navel-gaze how governments might view that, or look at this
from a business perspective:  If you are a service provider, and you're
looking at RTP, SRTP with Security Descriptions, or SRTP with DTLS-SRTP,
what is the business opportunity versus business risk of adopting each
of those technologies.  The business opportunity is pretty straightforward:
would you get more subscribers if you offered a secure service.  The 
business risk is more murky:  will a government agency decide you still
need to provide decryption keys, because you still obstensibly "own" the
endpoint (afterall, a cellular provider does own the radio license for 
that endpoint).

> 2. It's extremely difficult to guarantee that the keys for
>    communication are being properly escrowed in the face of the
>    possibility that one or both of the communicating parties is
>    cheating. This is especially difficult if you want to avoid having
>    real-time access to the escrow keys used to encrypt the traffic
>    keys, which is generally good practice.  So, I would be very
>    surprised if there were any regulatory requirement that LI work in
>    the face of endpoint cheating.
> 
> 3. Given (2) above, I don't see how R24 can be achieved, since
>    two cooperating peers can always guarantee that their plaintext
>    is not subject to LI if they can arrange for any side channel
>    for key agreement.

It is well-acknowledged that two cooperating peers can establish 
their own private communication, over the top of whatever communications
channel they can set up normally.

> 4. I don't actually think there's any protocol engineering required
>    here. The problem of how to arrange for TLS traffic key disclosure
>    to third parties without modifying the wire protocol has been quite
>    extensively studied and a broad variety of approaches exist,
>    covering a range of levels of active/passiveness, real-timeness,
>    cooperation from the endpoints, etc. Techniques exist which are
>    significantly better than those indicated by Dan. For instance,
>    consider that if you have the TLS server's private key and you're
>    doing RSA, you can do completely passive inspection with no
>    cooperation from either side.

I am aware of that technique; however, for SIP calls with the offer
in the in the Invite, you could only intercept outgoing calls, 
because incoming calls cause your intercept target to be the TLS
client.  I don't believe that technique is viable to meet R24.

> Another example would be [GBGP03]. 

I was not aware of that technique; thanks for the pointer.  That
technique seems useful.

(Direct link, 
http://crypto.stanford.edu/~pgolle/papers/escrow.pdf)

>    Also, as Jon Peterson observed, the owner of the namespace can
>    always enforce any restrictions that it wants. It's possible that
>    imposes significant performance costs, but it's not clear that
>    that's true in all cases with clever implementation. 
> 
>    I don't really have time right now to go into any of this stuff
>    in more detail, but I'd certainly be happy to sit down with
>    anyone who cares in YVR and explain the state of the art.

Thanks for the offer.

> I don't
>    really see that this is really relevant to what happens in this
>    WG, though.

If 3GPP decides to use something other than DTLS-SRTP, we will have
two standards for SRTP keying -- the IETF standard and the non-IETF
standard.  I do not consider that desirable.

-d


> -Ekr
> 
> 
> [GBGP03] E.-J. Goh, D. Boneh, P. Golle, B. Pinkas",
> 	 The Design and Implementation of Protocol-Based Hidden
> 	 Key Recovery", 2003.


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 11 23:31:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrQxg-000361-75; Sun, 11 Nov 2007 23:31:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrQxe-0002yD-2t
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 23:31:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQxd-0002y0-PP
	for sip@ietf.org; Sun, 11 Nov 2007 23:31:45 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrQxa-0007Ks-Ce
	for sip@ietf.org; Sun, 11 Nov 2007 23:31:45 -0500
X-IronPort-AV: E=Sophos;i="4.21,403,1188802800"; d="scan'208";a="250177951"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 11 Nov 2007 20:31:41 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAC4Vfdp015217; 
	Sun, 11 Nov 2007 20:31:41 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAC4Vfej005641;
	Mon, 12 Nov 2007 04:31:41 GMT
From: "Dan Wing" 
To: "'IETF SIP List'" 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<20071111224707.68E5033C21@delta.rtfm.com> 
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Sun, 11 Nov 2007 20:31:42 -0800
Message-ID: <011301c824e4$ed253080$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-reply-to: 
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-index: AcgktXiJyLZmrcU5R2++6HvQPofukAABNnWAAAqNKrA=
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2257; t=1194841901;
	x=1195705901; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20media-security-requirements=20and=20lawful=20
	intercept |Sender:=20;
	bh=eOHMlRj4Zx5dbNc9wjZzZy5IRj/5SnFaXHFCDPjMxFc=;
	b=DJD2H2/IhHYoXcESqu/0Az3lTe69v6XTfYRUBensZ45lQVRVB+AX2f2nWDc9UVM+hYC326lS
	PDtLTznWB1+MY1vbi2ABhf7JDxhg/vRlgL9k+aO3Dru1Ayj1FI4sP4cc;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

...
> > 1. It's not clear to me that people are correctly parsing LI
> >    requirements. I'm not an expert on CALEA, let alone laws in other
> >    countries, but it's not my understanding that there is any
> >    regulatory requirement that forces carriers of voice or data
> >    traffic to arrange for disclosure of plaintext when they 
> >    don't have
> >    the keys. I.e., if I buy data service from Comcast and choose to
> >    run a VPN, there is no requirement that Comcast somehow 
> >    obtain the
> >    keys to deliver them to the FBI.
> > 
> >    It's less clear to me what the requirements are for 3G-style
> >    carriers when the endpoints are doing the crypto. I.e., I'm quite
> >    certain that if AT&T terminates the crypto they need to 
> >    provide the
> >    plaintext on request, but a lot less certain that they need to
> >    provide the plaintext if the crypto is end-to-end.
> 
> Timothy Dwight posted a followup on 3GPP's requirement that should
> be helpful on those points.  What remains unsaid in that quoted text 
> is crypto performed by the endpoint itself (as with DTLS-SRTP).

Tim mentioned to me privately that his posting to SIP is being held 
up; here is the content:

    From: Dwight, Timothy M (Tim) 
    To: Eric Rescorla; Dan Wing
    Cc: IETF SIP List
    Subject: RE: [Sip] media-security-requirements and lawful intercept

    On point #1, 3GPP 33.106 says under "Security of Processes":

    "NWOs/APs/SvPs shall not be responsible for decrypting, or
    ensuring the LEA's ability to decrypt, any communication
    encrypted by a subscriber or customer, unless the encryption
    was provided by the NWOs/APs/SvPs and the NWOs/APs/SvPs
    possesses the information necessary to decrypt the
    communication or the NWOs/ APs/SvPs provides encryption keys
    but does not provide the encryption itself. In the case that
    the NWOs/ APs/SvPs provides encryption keys to the subscriber
    or customer but does not provide the encryption itself, the
    NWOs/ APs/SvPs shall provide the keys to the LEA if required
    by national regulations."

    The same text is found in ETSI TISPAN TS 133 106.

    tim

-d


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 00:39:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrS1I-0004wg-6V; Mon, 12 Nov 2007 00:39:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrS1H-0004vT-4g
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 00:39:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrS1G-0004v8-6Z
	for sip@ietf.org; Mon, 12 Nov 2007 00:39:34 -0500
Received: from jaguar.aricent.com ([61.246.186.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrS1D-0001SI-6F
	for sip@ietf.org; Mon, 12 Nov 2007 00:39:34 -0500
Received: from jaguar.aricent.com (localhost [127.0.0.1])
	by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lAC5UCHt028476
	for ; Mon, 12 Nov 2007 11:00:12 +0530
Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21])
	by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lAC5UC3E028463
	for ; Mon, 12 Nov 2007 11:00:12 +0530
To: sip@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: 
From: "B Venkat S.R Swamy" 
Date: Mon, 12 Nov 2007 11:09:19 +0530
X-MIMETrack: S/MIME Sign by Notes Client on B Venkat S.R Swamy/HSS(Release
	6.5.1|January 21, 2004) at 11/12/2007 11:09:26 AM,
	Serialize by Notes Client on B Venkat S.R Swamy/HSS(Release
	6.5.1|January 21, 2004) at 11/12/2007 11:09:26 AM,
	Serialize complete at 11/12/2007 11:09:26 AM,
	S/MIME Sign failed at 11/12/2007 11:09:26 AM: The cryptographic key was
	not found,
	Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30,
	2005) at 12/11/2007 11:14:10 AM,
	Serialize complete at 12/11/2007 11:14:10 AM
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [Sip] Early Dialogue Handling
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1270450605=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============1270450605==
Content-Type: multipart/alternative;
	boundary="=_alternative 001F139665257391_="

This is a multipart message in MIME format.
--=_alternative 001F139665257391_=
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: base64

SGkNCg0KRm9yIGFuIGVhcmx5IGRpYWxvZ3VlIHNlbnQgYWZ0ZXIgMXh4IHJlc3BvbnNlIHRvIElu
dml0ZSBhbmQgYmVmb3JlIHRoZSAyeHggDQpyZXNwb25zZSwgd2hhdCBpcyB0aGUgZXhwZWN0ZWQg
YmVoYXZpb3VyIGZvciByb3V0aW5nIHRoZSBlYXJseSBkaWFsb2d1ZSBpZiANCjF4eChub24tMTAw
KSBkb2VzIG5vdA0KY29udGFpbiBDb250YWN0IEhlYWRlci4NCg0KT3B0aW9uczoNCg0KPiBSb3V0
ZSB0aGUgbWVzc2FnZSB0byB0aGUgc2FtZSBhZGRyZXNzIHdoZXJlIGluaXRpYWwgSW52aXRlIHdh
cyBzZW50Lg0KPiBJdCBpcyBtYW5kYXRvcnkgdG8gZ2l2ZSBDb250YWN0IGhlYWRlciBpbiAxeHgg
aWYgZWFybHkgZGlhbG9ndWUgaXMgdG8gYmUgDQpzZW50LiggVGhpcyB3b3VsZCByZXF1aXJlIGNo
YW5nZSBpbiBSRkMgMzI2MSkuIEdpdmUgYW4gZXJyb3IgcmVzcG9uc2UgdG8gDQp0aGUgZWFybHkg
ZGlhbG9ndWUsIGlmIA0KY29udGFjdCBpcyBub3QgcmVjZWl2ZWQgaW4gMXh4KG5vbi0xMDApLg0K
PiBGYWlsIHRoZSBkaWFsb2d1ZS9jYWxsLg0KDQpyZWdhcmRzDQpWZW5rYXQgDQoNCg0KKioqKioq
KioqKioqKioqKioqKioqKiogIEFyaWNlbnQtUmVzdHJpY3RlZCAgICoqKioqKioqKioqKioqKioq
KioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNl
bnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFs
IHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNv
bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1
c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJ
ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5
IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg
cmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJp
dGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250
ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBm
b3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlv
biB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4i
Cg==
--=_alternative 001F139665257391_=
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpPC9mb250Pg0KPGJyPg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Gb3IgYW4gZWFybHkgZGlhbG9ndWUgc2Vu
dCBhZnRlciAxeHgNCnJlc3BvbnNlIHRvIEludml0ZSBhbmQgYmVmb3JlIHRoZSAyeHggcmVzcG9u
c2UsIHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW91cg0KZm9yIHJvdXRpbmcgdGhlIGVhcmx5
IGRpYWxvZ3VlIGlmIDF4eChub24tMTAwKSBkb2VzIG5vdDwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0ic2Fucy1zZXJpZiI+Y29udGFpbiBDb250YWN0IEhlYWRlci48L2ZvbnQ+DQo8YnI+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9wdGlvbnM6PC9mb250Pg0KPGJy
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFJvdXRlIHRoZSBtZXNz
YWdlIHRvIHRoZSBzYW1lIGFkZHJlc3MNCndoZXJlIGluaXRpYWwgSW52aXRlIHdhcyBzZW50Ljwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBJdCBpcyBtYW5k
YXRvcnkgdG8gZ2l2ZSBDb250YWN0DQpoZWFkZXIgaW4gMXh4IGlmIGVhcmx5IGRpYWxvZ3VlIGlz
IHRvIGJlIHNlbnQuKCBUaGlzIHdvdWxkIHJlcXVpcmUgY2hhbmdlDQppbiBSRkMgMzI2MSkuIEdp
dmUgYW4gZXJyb3IgcmVzcG9uc2UgdG8gdGhlIGVhcmx5IGRpYWxvZ3VlLCBpZiA8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmNvbnRhY3QgaXMgbm90IHJlY2VpdmVk
IGluIDF4eChub24tMTAwKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPiZndDsgRmFpbCB0aGUgZGlhbG9ndWUvY2FsbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPlZlbmthdDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioqKioq
KioqKioqKioqKiogJm5ic3A7QXJpY2VudC1SZXN0cmljdGVkICZuYnNwOyAqKioqKioqKioqKioq
KioqKioqKioqKjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48Zm9udCBj
b2xvcj0jMDAwMDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFy
eSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUg
aW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmls
ZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1
bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBp
bnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxl
YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhl
IGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0
bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2lu
ZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9u
c2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUg
aW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZy
b20gdmlydXMuIgo8L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwvdGFibGU+
--=_alternative 001F139665257391_=--



--===============1270450605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1270450605==--





From sip-bounces@ietf.org Mon Nov 12 00:59:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrSKN-00066Y-Pj; Mon, 12 Nov 2007 00:59:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrSKM-00066R-OG
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 00:59:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSKM-00066J-Eq
	for sip@ietf.org; Mon, 12 Nov 2007 00:59:18 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrSKJ-00022R-8q
	for sip@ietf.org; Mon, 12 Nov 2007 00:59:18 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns0.neustar.com (Postfix) with ESMTP id 29CE232912;
	Mon, 12 Nov 2007 05:59:15 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IrSKJ-0008RA-1U; Mon, 12 Nov 2007 00:59:15 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: jason@counterpath.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Mon, 12 Nov 2007 00:59:15 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: sip@ietf.org, Hannes.Tschofenig@nsn.com
Subject: [Sip] New Version Notification for 
 draft-ietf-sip-dtls-srtp-framework-00 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-dtls-srtp-framework-00.txt has been successfuly submitted by Jason Fischl and posted to the IETF repository.

Filename:	 draft-ietf-sip-dtls-srtp-framework
Revision:	 00
Title:		 Framework for Establishing an SRTP Security Context using DTLS
Creation_date:	 2007-11-12
WG ID:		 sip
Number_of_pages: 28

Abstract:
This document specifies how to use the Session Initiation Protocol
(SIP) to establish an Secure Real-time Transport Protocol (SRTP)
security context using the Datagram Transport Layer Security (DTLS)
protocol.  It describes a mechanism of transporting a fingerprint
attribute in the Session Description Protocol (SDP) that identifies
the key that will be presented during the DTLS handshake.  It relies
on the SIP identity mechanism to ensure the integrity of the
fingerprint attribute.  The key management exchange travels along the
media path as opposed to the signaling path.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 01:00:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrSLd-00079W-2b; Mon, 12 Nov 2007 01:00:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrSLZ-00077f-2e
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 01:00:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrSLY-00076y-Kg; Mon, 12 Nov 2007 01:00:32 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IrSLY-0003xl-2q; Mon, 12 Nov 2007 01:00:32 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id EFF3E2AC5F;
	Mon, 12 Nov 2007 06:00:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IrSL3-0006kt-LG; Mon, 12 Nov 2007 01:00:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Mon, 12 Nov 2007 01:00:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Framework for Establishing an SRTP Security Context using DTLS
	Author(s)       : J. Fischl, et al.
	Filename        : draft-ietf-sip-dtls-srtp-framework-00.txt
	Pages           : 28
	Date            : 2007-11-12

This document specifies how to use the Session Initiation Protocol
(SIP) to establish an Secure Real-time Transport Protocol (SRTP)
security context using the Datagram Transport Layer Security (DTLS)
protocol.  It describes a mechanism of transporting a fingerprint
attribute in the Session Description Protocol (SDP) that identifies
the key that will be presented during the DTLS handshake.  It relies
on the SIP identity mechanism to ensure the integrity of the
fingerprint attribute.  The key management exchange travels along the
media path as opposed to the signaling path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-dtls-srtp-framework-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-dtls-srtp-framework-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-12005912.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-dtls-srtp-framework-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-dtls-srtp-framework-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-12005912.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Mon Nov 12 01:02:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrSN6-0001Do-CW; Mon, 12 Nov 2007 01:02:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrMCY-0005Pv-Qu
	for sip-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 18:26:50 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrMCY-0005Pc-HK for sip@ietf.org; Sun, 11 Nov 2007 18:26:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrMAZ-0001nb-JD
	for sip@ietf.org; Sun, 11 Nov 2007 18:24:47 -0500
Received: from omzesmtp01.mci.com ([199.249.17.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrMAV-000692-7j
	for sip@ietf.org; Sun, 11 Nov 2007 18:24:47 -0500
Received: from pmismtp05.wcomnet.com ([166.37.158.165])
	by firewall.verizonbusiness.com (Iplanet MTA 5.2)
	with ESMTP id <0JRD00J9X7LOR0@firewall.verizonbusiness.com> for
	sip@ietf.org; Sun, 11 Nov 2007 23:22:37 +0000 (GMT)
Received: from pmismtp05.wcomnet.com ([127.0.0.1])
	by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08
	(built Sep
	22 2005)) with SMTP id <0JRD0018Y7LO8R@pmismtp05.mcilink.com> for
	sip@ietf.org; Sun, 11 Nov 2007 23:22:36 +0000 (GMT)
Received: from ASHSRV142.mcilink.com ([153.39.68.168])
	by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08
	(built Sep
	22 2005)) with ESMTP id <0JRD0007A7LOVT@pmismtp05.mcilink.com> for
	sip@ietf.org; Sun, 11 Nov 2007 23:22:36 +0000 (GMT)
Received: from ASHEVS002.mcilink.com ([153.39.71.2])
	by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Sun,
	11 Nov 2007 23:22:36 +0000
Date: Sun, 11 Nov 2007 23:22:33 +0000
From: "Dwight, Timothy M (Tim)" 
Subject: RE: [Sip] media-security-requirements and lawful intercept
In-reply-to: <20071111224707.68E5033C21@delta.rtfm.com>
To: Eric Rescorla , Dan Wing 
Message-id: <092B2658AAB56A4D80836399A4C4703102349BDB@ASHEVS002.mcilink.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable
Content-class: urn:content-classes:message
Thread-topic: [Sip] media-security-requirements and lawful intercept
Thread-index: AcgktYStIqEoBNvpQLybXFu7YknDYAAAk3Qg
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<20071111224707.68E5033C21@delta.rtfm.com>
X-OriginalArrivalTime: 11 Nov 2007 23:22:36.0513 (UTC)
	FILETIME=[BE964D10:01C824B9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
X-TMDA-Confirmed: Sun, 11 Nov 2007 18:26:50 -0500
X-Mailman-Approved-At: Mon, 12 Nov 2007 01:02:07 -0500
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

On point #1, 3GPP 33.106 says under "Security of Processes":

"NWOs/APs/SvPs shall not be responsible for decrypting, or ensuring the
LEA's ability to decrypt, any communication encrypted by a subscriber or
customer, unless the encryption was provided by the NWOs/APs/SvPs and
the NWOs/APs/SvPs possesses the information necessary to decrypt the
communication or the NWOs/ APs/SvPs provides encryption keys but does
not provide the encryption itself. In the case that the NWOs/ APs/SvPs
provides encryption keys to the subscriber or customer but does not
provide the encryption itself, the NWOs/ APs/SvPs shall provide the keys
to the LEA if required by national regulations."

The same text is found in ETSI TISPAN TS 133 106.

tim


> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]=20
> Sent: Sunday, November 11, 2007 4:47 PM
> To: Dan Wing
> Cc: 'IETF SIP List'
> Subject: Re: [Sip] media-security-requirements and lawful intercept
>=20
> At Tue, 6 Nov 2007 09:50:42 -0800,
> Dan Wing wrote:
> >=20
> > Other SDOs have lawful intercept requirements, which are currently
> > captured in requirement R24 in=20
> > draft-ietf-sip-media-security-requirements-00:
> >=20
> >    "R24:   The media security key management protocol SHOULD=20
> >            NOT allow end users to determine whether their=20
> >            end-to-end interaction is subject to lawful=20
> >            interception."
> >
> > DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
> > to establish SRTP keys for unicast, point-to-point SRTP sessions.
> >=20
> > There appear to be two methods to meet R24 with DTLS-SRTP.  They
> > are:
> >=20
> >    a. provide a network element on every SRTP call which relays
> >       media, performs a DTLS handshake, and decrypts and re-encrypts
> >       SRTP, or;
> >=20
> >    b. have endpoints perform key disclosure for every call (using a=20
> >       technique similar to draft-wing-sipping-srtp-key), and perform
> >       validation of that disclosed key on every call.
> >=20
> > If these methods to meet R24 are deemed acceptable to other SDOs,
> > we don't find any reason for those SDOs to reject IETF's decision
> > to use DTLS-SRTP as the preferred mechanism to establish SRTP
> > keys for unicast, point-to-point SRTP sessions.
>=20
> Wow, this sure produced a lot of discussion. I'd like to make a few
> points:
>=20
> 1. It's not clear to me that people are correctly parsing LI
>    requirements. I'm not an expert on CALEA, let alone laws in other
>    countries, but it's not my understanding that there is any
>    regulatory requirement that forces carriers of voice or data
>    traffic to arrange for disclosure of plaintext when they don't have
>    the keys. I.e., if I buy data service from Comcast and choose to
>    run a VPN, there is no requirement that Comcast somehow obtain the
>    keys to deliver them to the FBI.
>=20
>    It's less clear to me what the requirements are for 3G-style
>    carriers when the endpoints are doing the crypto. I.e., I'm quite
>    certain that if AT&T terminates the crypto they need to provide the
>    plaintext on request, but a lot less certain that they need to
>    provide the plaintext if the crypto is end-to-end.
>=20
> 2. It's extremely difficult to guarantee that the keys for
>    communication are being properly escrowed in the face of the
>    possibility that one or both of the communicating parties is
>    cheating. This is especially difficult if you want to avoid having
>    real-time access to the escrow keys used to encrypt the traffic
>    keys, which is generally good practice.  So, I would be very
>    surprised if there were any regulatory requirement that LI work in
>    the face of endpoint cheating.
>=20
> 3. Given (2) above, I don't see how R24 can be achieved, since
>    two cooperating peers can always guarantee that their plaintext
>    is not subject to LI if they can arrange for any side channel
>    for key agreement.
>=20
> 4. I don't actually think there's any protocol engineering required
>    here. The problem of how to arrange for TLS traffic key disclosure
>    to third parties without modifying the wire protocol has been quite
>    extensively studied and a broad variety of approaches exist,
>    covering a range of levels of active/passiveness, real-timeness,
>    cooperation from the endpoints, etc. Techniques exist which are
>    significantly better than those indicated by Dan. For instance,
>    consider that if you have the TLS server's private key and you're
>    doing RSA, you can do completely passive inspection with no
>    cooperation from either side. Another example would be [GBGP03].=20
>=20
>    Also, as Jon Peterson observed, the owner of the namespace can
>    always enforce any restrictions that it wants. It's possible that
>    imposes significant performance costs, but it's not clear that
>    that's true in all cases with clever implementation.=20
>=20
>    I don't really have time right now to go into any of this stuff
>    in more detail, but I'd certainly be happy to sit down with
>    anyone who cares in YVR and explain the state of the art. I don't
>    really see that this is really relevant to what happens in this
>    WG, though.
>=20
> -Ekr
>=20
>=20
> [GBGP03] E.-J. Goh, D. Boneh, P. Golle, B. Pinkas",
> 	 The Design and Implementation of Protocol-Based Hidden
> 	 Key Recovery", 2003.
>=20
>=20
> _______________________________________________
> 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
>=20



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 03:33:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrUjE-0001Si-Ew; Mon, 12 Nov 2007 03:33:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrUjC-0001Pp-Ru
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 03:33:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrUjB-0001Mj-Nm; Mon, 12 Nov 2007 03:33:05 -0500
Received: from mail153.messagelabs.com ([216.82.253.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1IrUj7-0008LQ-By; Mon, 12 Nov 2007 03:33:05 -0500
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-9.tower-153.messagelabs.com!1194856379!8521602!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 12467 invoked from network); 12 Nov 2007 08:33:00 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-9.tower-153.messagelabs.com with SMTP;
	12 Nov 2007 08:33:00 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAC8Wx0F024227;
	Mon, 12 Nov 2007 01:32:59 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142])
	by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lAC8WxIG017293;
	Mon, 12 Nov 2007 02:32:59 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lAC8WvRm017273;
	Mon, 12 Nov 2007 02:32:58 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 12 Nov 2007 16:32:55 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B05133C8C@ZMY16EXM66.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Use of RFC 3840 in REGISTER requests in IMS
thread-index: AcglBp+Jo71XaTSJQfCocwDAeV8UFg==
From: "Avasarala Ranjit-A20990" 
To: 
X-CFilter-Loop: Reflected
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: sip@ietf.org
Subject: [Sip] Use of RFC 3840 in REGISTER requests in IMS
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0905254847=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0905254847==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82506.9FFDB1D6"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82506.9FFDB1D6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi

RFC 3840 specifies the use of media feature tags for use in contact
header of REGISTER request for the UE to indicate its media capabilities
at the time of registration. But I do not see any of the IMS specs
specifying this mechanism for UE. Any reason why?

Also in case IMS UE s do use this for indicating their capabilities,
which entity in IMS stores these values?

Thanks

Regards
Ranjit


------_=_NextPart_001_01C82506.9FFDB1D6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






Use of RFC 3840 in REGISTER requests in IMS





Hi




RFC 3840 specifies =
the use of media feature tags for use in contact header of REGISTER =
request for the UE to indicate its media capabilities at the time of =
registration. But I do not see any of the IMS specs specifying this =
mechanism for UE. Any reason why?



Also in case IMS UE s =
do use this for indicating their capabilities, which entity in IMS =
stores these values?




Thanks




Regards


Ranjit





------_=_NextPart_001_01C82506.9FFDB1D6--



--===============0905254847==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0905254847==--





From sip-bounces@ietf.org Mon Nov 12 03:47:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrUxT-0000yn-Hx; Mon, 12 Nov 2007 03:47:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrUxR-0000xf-Pb
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 03:47:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrUxR-0000xM-4v; Mon, 12 Nov 2007 03:47:49 -0500
Received: from [194.138.202.53] (helo=david.siemens.com.cn)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IrUxQ-000340-8N; Mon, 12 Nov 2007 03:47:49 -0500
Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52])
	by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id lAC8lfn14048;
	Mon, 12 Nov 2007 16:47:41 +0800 (CST)
Received: from pekw905a.cn001.siemens.net (localhost [127.0.0.1])
	by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id lAC8lcm09973;
	Mon, 12 Nov 2007 16:47:38 +0800 (CST)
Received: from PEKW977A.cn001.siemens.net ([139.24.237.131]) by
	pekw905a.cn001.siemens.net with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 16:47:08 +0800
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Use of RFC 3840 in REGISTER requests in IMS
Date: Mon, 12 Nov 2007 16:47:08 +0800
Message-ID: <66DEF58C8D1D904E8BD1AA4799AB54CA0F12D1@PEKW977A.cn001.siemens.net>
Importance: normal
Priority: normal
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B05133C8C@ZMY16EXM66.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Use of RFC 3840 in REGISTER requests in IMS
Thread-Index: AcglBp+Jo71XaTSJQfCocwDAeV8UFgAAJU2w
References: <750BBC72E178114F9DC4872EBFF29A5B05133C8C@ZMY16EXM66.ds.mot.com>
From: "Hu, Bo - Cory SNLB PEK" 
To: "ext Avasarala Ranjit-A20990" 
X-OriginalArrivalTime: 12 Nov 2007 08:47:08.0752 (UTC)
	FILETIME=[9C03CD00:01C82508]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15540.003
X-TM-AS-Result: No--18.872200-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: sip@ietf.org, sipping@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hello,

Just some info regarding feature tags usages in 3gpp IMS:
TS 23.279 and 24.279 specified csi(Combining Circuit Switched (CS) and=20
IP Multimedia Subsystem (IMS) services;) and defined feature tags for
this scenario.

Moreover, I guess, the SIP usage in IMS should be a topic of 3gpp
instead of the ietf list.

Best Regards
Hu Bo=20

>-----Original Message-----
>From: ext Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20
>Sent: Monday, November 12, 2007 4:33 PM
>To: sipping@ietf.org
>Cc: sip@ietf.org
>Subject: [Sip] Use of RFC 3840 in REGISTER requests in IMS
>
>Hi=20
>
>RFC 3840 specifies the use of media feature tags for use in=20
>contact header of REGISTER request for the UE to indicate its=20
>media capabilities at the time of registration. But I do not=20
>see any of the IMS specs specifying this mechanism for UE. Any=20
>reason why?
>
>Also in case IMS UE s do use this for indicating their=20
>capabilities, which entity in IMS stores these values?=20
>
>Thanks=20
>
>Regards=20
>Ranjit=20
>
>


IMPORTANT NOTE: This e-mail and any attachment are confidential and may =
contain trade secrets and may also be legally privileged or otherwise =
protected from disclosure. If you have received it in error, you are =
herewith informed about its status. Please notify us immediately by =
reply e-mail and then delete this e-mail and any attachment from your =
system. You are prohibited from making use of or copying this e-mail or =
any attachment or disclosing the contents to any other person.



????:???????????,???????????????????????????,????????????,???????????????=
??????????????????????,???????????????????????????
=0D


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 06:30:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrXVD-0008Mc-Ah; Mon, 12 Nov 2007 06:30:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrXVC-0008MX-Jh
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 06:30:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXVC-0008MP-AF
	for sip@ietf.org; Mon, 12 Nov 2007 06:30:50 -0500
Received: from gecko.sbs.de ([194.138.37.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrXV8-0006r2-GF
	for sip@ietf.org; Mon, 12 Nov 2007 06:30:50 -0500
Received: from mail1.sbs.de (localhost [127.0.0.1])
	by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id lACBUhM5010008;
	Mon, 12 Nov 2007 12:30:43 +0100
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net
	[157.163.133.222])
	by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id lACBUgSW024938;
	Mon, 12 Nov 2007 12:30:43 +0100
Received: from MCHP7I7A.ww002.siemens.net ([139.25.131.138]) by
	fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 12 Nov 2007 12:30:42 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Mon, 12 Nov 2007 12:30:34 +0100
Message-ID: <454C097A8CB3F14BB73494D0CE053DBE30C573@MCHP7I7A.ww002.siemens.net>
In-Reply-To: <008701c824d4$096ca180$c4f0200a@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgktXiJyLZmrcU5R2++6HvQPofukAABNnWAABky2AA=
References: <06c101c8209d$8d543700$c4f0200a@cisco.com><20071111224707.68E5033C21@delta.rtfm.com>
	<008701c824d4$096ca180$c4f0200a@cisco.com>
From: "Fries, Steffen" 
To: "Dan Wing" , "Eric Rescorla" 
X-OriginalArrivalTime: 12 Nov 2007 11:30:42.0842 (UTC)
	FILETIME=[75AB17A0:01C8251F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> > 4. I don't actually think there's any protocol engineering required
> >    here. The problem of how to arrange for TLS traffic key=20
> disclosure
> >    to third parties without modifying the wire protocol has=20
> been quite
> >    extensively studied and a broad variety of approaches exist,
> >    covering a range of levels of active/passiveness, real-timeness,
> >    cooperation from the endpoints, etc. Techniques exist which are
> >    significantly better than those indicated by Dan. For instance,
> >    consider that if you have the TLS server's private key and you're
> >    doing RSA, you can do completely passive inspection with no
> >    cooperation from either side.
>=20
> I am aware of that technique; however, for SIP calls with the=20
> offer in the in the Invite, you could only intercept outgoing=20
> calls, because incoming calls cause your intercept target to=20
> be the TLS client.  I don't believe that technique is viable=20
> to meet R24.
>=20
> > Another example would be [GBGP03].=20
>=20
> I was not aware of that technique; thanks for the pointer. =20
> That technique seems useful.
>=20
> (Direct link,
> http://crypto.stanford.edu/~pgolle/papers/escrow.pdf)

This is an interesting paper, but doesn't it require also some form of
cooperating client (as required in draft-wing-sipping-srtp-key) as it
would be necessary to exchange at least one of the SSL libs of the
clients?

Ciao
	Steffen

>=20
> >    Also, as Jon Peterson observed, the owner of the namespace can
> >    always enforce any restrictions that it wants. It's possible that
> >    imposes significant performance costs, but it's not clear that
> >    that's true in all cases with clever implementation.=20
> >=20
> >    I don't really have time right now to go into any of this stuff
> >    in more detail, but I'd certainly be happy to sit down with
> >    anyone who cares in YVR and explain the state of the art.
>=20
> Thanks for the offer.
>=20
> > I don't
> >    really see that this is really relevant to what happens in this
> >    WG, though.
>=20
> If 3GPP decides to use something other than DTLS-SRTP, we=20
> will have two standards for SRTP keying -- the IETF standard=20
> and the non-IETF standard.  I do not consider that desirable.
>=20
> -d
>=20
>=20
> > -Ekr
> >=20
> >=20
> > [GBGP03] E.-J. Goh, D. Boneh, P. Golle, B. Pinkas",
> > 	 The Design and Implementation of Protocol-Based Hidden
> > 	 Key Recovery", 2003.
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 07:42:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrYcv-0007H9-EH; Mon, 12 Nov 2007 07:42:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrYct-0007Fk-VK
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 07:42:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYct-0007ET-J9
	for sip@ietf.org; Mon, 12 Nov 2007 07:42:51 -0500
Received: from [74.95.2.169] (helo=delta.rtfm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrYct-0004kb-3u
	for sip@ietf.org; Mon, 12 Nov 2007 07:42:51 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 1EF2033C2B;
	Mon, 12 Nov 2007 04:38:01 -0800 (PST)
Date: Mon, 12 Nov 2007 04:38:00 -0800
From: Eric Rescorla 
To: "Fries, Steffen" 
Subject: Re: [Sip] media-security-requirements and lawful intercept
In-Reply-To: <454C097A8CB3F14BB73494D0CE053DBE30C573@MCHP7I7A.ww002.siemens.net>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<20071111224707.68E5033C21@delta.rtfm.com>
	<008701c824d4$096ca180$c4f0200a@cisco.com>
	<454C097A8CB3F14BB73494D0CE053DBE30C573@MCHP7I7A.ww002.siemens.net>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071112123801.1EF2033C2B@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: IETF SIP List , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At Mon, 12 Nov 2007 12:30:34 +0100,
Fries, Steffen wrote:
> 
> > > 4. I don't actually think there's any protocol engineering required
> > >    here. The problem of how to arrange for TLS traffic key 
> > disclosure
> > >    to third parties without modifying the wire protocol has 
> > been quite
> > >    extensively studied and a broad variety of approaches exist,
> > >    covering a range of levels of active/passiveness, real-timeness,
> > >    cooperation from the endpoints, etc. Techniques exist which are
> > >    significantly better than those indicated by Dan. For instance,
> > >    consider that if you have the TLS server's private key and you're
> > >    doing RSA, you can do completely passive inspection with no
> > >    cooperation from either side.
> > 
> > I am aware of that technique; however, for SIP calls with the 
> > offer in the in the Invite, you could only intercept outgoing 
> > calls, because incoming calls cause your intercept target to 
> > be the TLS client.  I don't believe that technique is viable 
> > to meet R24.
> > 
> > > Another example would be [GBGP03]. 
> > 
> > I was not aware of that technique; thanks for the pointer.  
> > That technique seems useful.
> > 
> > (Direct link,
> > http://crypto.stanford.edu/~pgolle/papers/escrow.pdf)
> 
> This is an interesting paper, but doesn't it require also some form of
> cooperating client (as required in draft-wing-sipping-srtp-key) as it
> would be necessary to exchange at least one of the SSL libs of the
> clients?

I'm not aware of any technical mechanism for secure doing end-to-end
encryption of traffic that also allows key disclosure to some external
entity in the middle without modifying the client (SDESCRIPTIONS
doesn't require modification this because it's not e2e secure: it 
*always* discloses the key to an intermediary).

My point was not that one ought to pursue mechanisms allowed key
disclosure without modifying the client but that one could design
mechanisms that could be implemented solely in the client software
without explicitly modifying the wire protocol. This means that
clients (or, rather vendors) wish wish to enable key disclosure can do
so without any new protocol design work from IETF.

-Ekr


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 08:06:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrYzN-0006Jz-OV; Mon, 12 Nov 2007 08:06:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrYzL-00063u-P8
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:06:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYzL-00062G-E1
	for sip@ietf.org; Mon, 12 Nov 2007 08:06:03 -0500
Received: from lizzard.sbs.de ([194.138.37.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrYzK-00064V-NV
	for sip@ietf.org; Mon, 12 Nov 2007 08:06:03 -0500
Received: from mail2.sbs.de (localhost [127.0.0.1])
	by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id lACD5wgp007923;
	Mon, 12 Nov 2007 14:05:59 +0100
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net
	[157.163.133.201])
	by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id lACD5sN4020213;
	Mon, 12 Nov 2007 14:05:58 +0100
Received: from MCHP7I7A.ww002.siemens.net ([139.25.131.138]) by
	fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 12 Nov 2007 14:05:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Mon, 12 Nov 2007 14:05:02 +0100
Message-ID: <454C097A8CB3F14BB73494D0CE053DBE30C59A@MCHP7I7A.ww002.siemens.net>
In-Reply-To: <20071112123801.1EF2033C2B@delta.rtfm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcglKZe4Yqvk4gp3QLmOLvcyoBalxwAANvZw
References: <06c101c8209d$8d543700$c4f0200a@cisco.com><20071111224707.68E5033C21@delta.rtfm.com><008701c824d4$096ca180$c4f0200a@cisco.com><454C097A8CB3F14BB73494D0CE053DBE30C573@MCHP7I7A.ww002.siemens.net>
	<20071112123801.1EF2033C2B@delta.rtfm.com>
From: "Fries, Steffen" 
To: "Eric Rescorla" 
X-OriginalArrivalTime: 12 Nov 2007 13:05:56.0246 (UTC)
	FILETIME=[C31F5B60:01C8252C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: IETF SIP List , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]=20
> Sent: Monday, November 12, 2007 1:38 PM
> To: Fries, Steffen
> Cc: Dan Wing; Eric Rescorla; IETF SIP List
> Subject: Re: [Sip] media-security-requirements and lawful intercept
>=20
> At Mon, 12 Nov 2007 12:30:34 +0100,
> Fries, Steffen wrote:
> >=20
> > > > 4. I don't actually think there's any protocol=20
> engineering required
> > > >    here. The problem of how to arrange for TLS traffic key
> > > disclosure
> > > >    to third parties without modifying the wire protocol has
> > > been quite
> > > >    extensively studied and a broad variety of approaches exist,
> > > >    covering a range of levels of active/passiveness,=20
> real-timeness,
> > > >    cooperation from the endpoints, etc. Techniques=20
> exist which are
> > > >    significantly better than those indicated by Dan.=20
> For instance,
> > > >    consider that if you have the TLS server's private=20
> key and you're
> > > >    doing RSA, you can do completely passive inspection with no
> > > >    cooperation from either side.
> > >=20
> > > I am aware of that technique; however, for SIP calls with=20
> the offer=20
> > > in the in the Invite, you could only intercept outgoing calls,=20
> > > because incoming calls cause your intercept target to be the TLS=20
> > > client.  I don't believe that technique is viable to meet R24.
> > >=20
> > > > Another example would be [GBGP03].=20
> > >=20
> > > I was not aware of that technique; thanks for the pointer. =20
> > > That technique seems useful.
> > >=20
> > > (Direct link,
> > > http://crypto.stanford.edu/~pgolle/papers/escrow.pdf)
> >=20
> > This is an interesting paper, but doesn't it require also=20
> some form of=20
> > cooperating client (as required in=20
> draft-wing-sipping-srtp-key) as it=20
> > would be necessary to exchange at least one of the SSL libs of the=20
> > clients?
>=20
> I'm not aware of any technical mechanism for secure doing=20
> end-to-end encryption of traffic that also allows key=20
> disclosure to some external entity in the middle without=20
> modifying the client (SDESCRIPTIONS doesn't require=20
> modification this because it's not e2e secure: it
> *always* discloses the key to an intermediary).
agreed


> My point was not that one ought to pursue mechanisms allowed=20
> key disclosure without modifying the client but that one=20
> could design mechanisms that could be implemented solely in=20
> the client software without explicitly modifying the wire=20
> protocol. This means that clients (or, rather vendors) wish=20
> wish to enable key disclosure can do so without any new=20
> protocol design work from IETF.
okay, understood. My fear here would merely be for the explicit case
with DTLS, that if the general functionality of DTLS is included as part
of the operating system, like it has been done in the past with SSL/TLS,
the key disclosure may become available for every application using this
library once somebody enabled key disclosure for one specific
application (taken the approach described in the paper you referenced).
If it is only an application specific functionality not influencing any
other application running on the host, I'm with you.

Steffen


>=20
> -Ekr


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 08:20:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrZDJ-0004yj-FP; Mon, 12 Nov 2007 08:20:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrZDG-0004uX-1p
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:20:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZDF-0004sb-Le
	for sip@ietf.org; Mon, 12 Nov 2007 08:20:25 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrZDB-0002pd-Or
	for sip@ietf.org; Mon, 12 Nov 2007 08:20:25 -0500
X-IronPort-AV: E=Sophos;i="4.21,405,1188792000"; d="scan'208";a="75807505"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 12 Nov 2007 08:20:21 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lACDKIgW015180; 
	Mon, 12 Nov 2007 08:20:18 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lACDKHdQ029859; 
	Mon, 12 Nov 2007 13:20:18 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Nov 2007 08:20:17 -0500
Received: from [10.86.241.101] ([10.86.241.101]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Nov 2007 08:20:17 -0500
Message-ID: <47385310.3010408@cisco.com>
Date: Mon, 12 Nov 2007 08:20:16 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "B Venkat S.R Swamy" 
Subject: Re: [Sip] Early Dialogue Handling
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Nov 2007 13:20:17.0493 (UTC)
	FILETIME=[C4773850:01C8252E]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15540.002
X-TM-AS-Result: No--17.303700-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3448; t=1194873621;
	x=1195737621; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20Early=20Dialogue=20Handling
	|Sender:=20
	|To:=20=22B=20Venkat=20S.R=20Swamy=22=20;
	bh=/CaWYGUXfNFmC35mGdHm70SB7lZX2ReAB9zYRK2w2so=;
	b=L/nG61ebFqoV9HvIbMIJmqjN9QbsHhIPqpHlZjL4GlG1DBAbEZ3/225BamU2cnEPw7myzAUX
	iaeZWZsuDek1QMO/kD9JZzQcMrKx602bpPNlWHE2ztIT5wXvsBcCV8SP;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



B Venkat S.R Swamy wrote:
> 
> Hi
> 
> For an early dialogue sent after 1xx response to Invite

I'm a little confused by your terminolog. A dialog is not something you 
send. It is something that exists, or not. You can have an early dialog 
even if you choose not to send any messages within it.

I guess you are asking how to construct a message to be sent within an 
early dialog if the 1xx response that established the early dialog did 
not contain a Contact header.

> and before the 
> 2xx response, what is the expected behaviour for routing the early 
> dialogue if 1xx(non-100) does not
> contain Contact Header.
> 
> Options:
> 
>  > Route the message to the same address where initial Invite was sent.
>  > It is mandatory to give Contact header in 1xx if early dialogue is to 
> be sent.( This would require change in RFC 3261).

AFAIK it is indeed required to provide a Contact address in responses 
that establish a dialog (early or not). I was thinking 3261 already 
called for this, but I'll have to spend some time looking at 3261 to 
confirm that.

> Give an error response 
> to the early dialogue, if
> contact is not received in 1xx(non-100).

Since the problem is with a response, you can't give an error response 
to it. You will have to make do.

>  > Fail the dialogue/call.

The strongest thing you could do is send a CANCEL, which doesn't require 
the Contact. (You can't send a BYE because that is also an in-dialog 
request.)

If you received an *unreliable* provisional with a to-tag, you can just 
make-do by not trying to send any messages within the dialog until you 
do get a Contact, at least in the 2xx response.

If you received a *reliable* provisional without a Contact then you have 
a problem because you are obligated to send a PRACK within the dialog 
but you don't have the info to do so. In that case I think you must send 
a CANCEL or else just pretend the response was unreliable. (Which 
probably won't work well.)

I suppose you could have a UAS that sends a Contact in one response and 
then fails to send it in subsequent responses. In that case you might 
try to use the most recent one you have received.

	Good luck,
	Paul

> regards
> Venkat
> 
> 
> ***********************  Aricent-Restricted   ***********************
> 
> "DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
> the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
> circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
> please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
> loss or damage arising from the use of the information transmitted by this email including damage from virus."
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 10:21:15 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Irb66-0001S7-FZ; Mon, 12 Nov 2007 10:21:10 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Irb65-0001Rx-3r
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 10:21:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Irb64-0001Rf-Or
	for sip@ietf.org; Mon, 12 Nov 2007 10:21:08 -0500
Received: from mx11.bbn.com ([128.33.0.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irb60-0007lJ-9I
	for sip@ietf.org; Mon, 12 Nov 2007 10:21:08 -0500
Received: from mail.bbn.com ([128.33.1.19])
	by mx11.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1Irb60-0002qJ-3M; Mon, 12 Nov 2007 10:21:04 -0500
Received: from col-dhcp33-244-153.bbn.com ([128.33.244.153] helo=[127.0.0.1])
	by mail.bbn.com with esmtp (Exim 4.67)
	(envelope-from )
	id 1Irb5z-0007fv-VK; Mon, 12 Nov 2007 10:21:04 -0500
Message-ID: <47386F5E.2030502@bbn.com>
Date: Mon, 12 Nov 2007 10:21:02 -0500
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dan Wing 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<20071111224707.68E5033C21@delta.rtfm.com>
	<011301c824e4$ed253080$c4f0200a@cisco.com>
In-Reply-To: <011301c824e4$ed253080$c4f0200a@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: 'IETF SIP List' 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

To paraphrase Tim / 33.106, the entities are only required to provide 
decryption in the following cases:

1. The encryption was provided by NWOs/APs/SvPs AND the NWOs/APs/SvPs 
possesses the information necessary to decrypt the communication.

2. NWOs/APs/SvPs provides the encryption keys but does not provide the 
encryption itself

It seems like neither of these is necessarily the case when the 
endpoints use an end-to-end secure key negotiation mechanism: Since the 
endpoints are agreeing on keys between themselves, you're never in case 
(2).  With regard to case (1), even if the provider builds the 
encryption system into the terminal, without some additional key 
disclosure mechanism, they won't have the information necessary to 
decrypt the communication.

So it doesn't seem like there's any technical issue at all, based on 
this requirement.  The service provider is just required to provide 
access to what he has access to, even if that's just encrypted traffic 
with no keys.

--Richard




Dan Wing wrote:
> ...
>>> 1. It's not clear to me that people are correctly parsing LI
>>>    requirements. I'm not an expert on CALEA, let alone laws in other
>>>    countries, but it's not my understanding that there is any
>>>    regulatory requirement that forces carriers of voice or data
>>>    traffic to arrange for disclosure of plaintext when they 
>>>    don't have
>>>    the keys. I.e., if I buy data service from Comcast and choose to
>>>    run a VPN, there is no requirement that Comcast somehow 
>>>    obtain the
>>>    keys to deliver them to the FBI.
>>>
>>>    It's less clear to me what the requirements are for 3G-style
>>>    carriers when the endpoints are doing the crypto. I.e., I'm quite
>>>    certain that if AT&T terminates the crypto they need to 
>>>    provide the
>>>    plaintext on request, but a lot less certain that they need to
>>>    provide the plaintext if the crypto is end-to-end.
>> Timothy Dwight posted a followup on 3GPP's requirement that should
>> be helpful on those points.  What remains unsaid in that quoted text 
>> is crypto performed by the endpoint itself (as with DTLS-SRTP).
> 
> Tim mentioned to me privately that his posting to SIP is being held 
> up; here is the content:
> 
>     From: Dwight, Timothy M (Tim) 
>     To: Eric Rescorla; Dan Wing
>     Cc: IETF SIP List
>     Subject: RE: [Sip] media-security-requirements and lawful intercept
> 
>     On point #1, 3GPP 33.106 says under "Security of Processes":
> 
>     "NWOs/APs/SvPs shall not be responsible for decrypting, or
>     ensuring the LEA's ability to decrypt, any communication
>     encrypted by a subscriber or customer, unless the encryption
>     was provided by the NWOs/APs/SvPs and the NWOs/APs/SvPs
>     possesses the information necessary to decrypt the
>     communication or the NWOs/ APs/SvPs provides encryption keys
>     but does not provide the encryption itself. In the case that
>     the NWOs/ APs/SvPs provides encryption keys to the subscriber
>     or customer but does not provide the encryption itself, the
>     NWOs/ APs/SvPs shall provide the keys to the LEA if required
>     by national regulations."
> 
>     The same text is found in ETSI TISPAN TS 133 106.
> 
>     tim
> 
> -d
> 
> 
> _______________________________________________
> 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
> 
> 



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 12:09:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ircmc-0005VB-QO; Mon, 12 Nov 2007 12:09:10 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ircmc-0005V5-A1
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 12:09:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ircmc-0005Ux-0C
	for sip@ietf.org; Mon, 12 Nov 2007 12:09:10 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrcmY-0004Nv-NO
	for sip@ietf.org; Mon, 12 Nov 2007 12:09:09 -0500
X-IronPort-AV: E=Sophos;i="4.21,406,1188802800"; d="scan'208";a="250529857"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 12 Nov 2007 09:08:59 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lACH8wK7030306
	for ; Mon, 12 Nov 2007 09:08:58 -0800
Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id lACH8weG019741
	for ; Mon, 12 Nov 2007 17:08:58 GMT
Mime-Version: 1.0 (Apple Message framework v752.3)
Impp: xmpp:cullenfluffyjennings@jabber.org
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Cullen Jennings 
Date: Mon, 12 Nov 2007 09:08:30 -0800
To: SIP 
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=537; t=1194887338;
	x=1195751338; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20
	|Subject:=20media=20security=20requirements=20and=20lawful=20intercept=20
	|Sender:=20; bh=D6dUD7ZLTOcXBmyIpEv0EYxZcJEu7CFdOIcxzptmWUE=;
	b=LA1UqRhc2GNeaQN+UyQuGiVGzU574MUlHLAU3VDGiyy+xqelwo7s3xO+RQ3VW9HugGW1/dTr
	arqPhJeQFZeSq3fJZGaAL8Rxgu1LEYC5Dpyw9VWuH317MX0dSoJ/hhJCONm2NXjK9FvyKqd5m0
	Z+7DrllyDWtTM4EJl6YSJ+rIM=;
Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: [Sip] media security requirements and lawful intercept 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Folks,

The IETF policy on wiretapping as described in RFC 2804 is pretty clear:

    The IETF has decided not to consider requirements for wiretapping
    as part of the process for creating and maintaining IETF standards.

Any document containing such requirements will almost certainly not  
pass the IESG. If you think that we ought to change this policy and  
start considering such requirements, then the right place to have  
that discussion is on the IETF mailing list, not here.

Thanks, Cullen 




_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 13:07:17 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Irdgm-0005BJ-0z; Mon, 12 Nov 2007 13:07:12 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Irdgl-0005B8-7L
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 13:07:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Irdgk-0005At-Pv
	for sip@ietf.org; Mon, 12 Nov 2007 13:07:10 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irdgg-0006ru-Fg
	for sip@ietf.org; Mon, 12 Nov 2007 13:07:10 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lACI74tP008832
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for ; Mon, 12 Nov 2007 12:07:06 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
References: 
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <0D7FABDE-7E88-4D7A-9D53-F2AE5A8EF711@softarmor.com>
Content-Transfer-Encoding: quoted-printable
From: Dean Willis 
Date: Mon, 12 Nov 2007 12:06:49 -0600
To: IETF SIP List 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
Subject: [Sip] Fwd: Call for Papers: SFSIW-1
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


This is close enough with our stated goal of achieving draft standard =20=

status (which requires interoperability) that I felt it reasonable to =20=

forward this announcement to the SIP list. besides, it's happening in =20=

conjunction with the next IETF meeting  (DW).

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

CALL FOR PAPERS AND PARTICIPATION

The 1st SIP Forum SIP Interoperability Workshop (SFSIW-1)

Co-located with the 70th Internet Engineering Task Force Meeting =20
(IETF 70)
http://www.ietf.org/meetings/70-IETF.html


IMPORTANT DATES
Submission deadline: 27 November 2007
Notification of presentation acceptance: 30 November 2007
Workshop date: 3 December 2007, 11am =96 12:30pm Pacific Time


AIMS AND SCOPE
SIP has been gaining traction as a preferred network signaling =20
protocol for
real-time communications networks. There has been a considerable =20
amount of
low-level protocol testing and interoperability, such as provided by =20
the SIP
Interoperability Test event, or SIPit, which is in its seventh year. =20
There
are many independent implementations of clients, servers, proxies,
back-to-back User Agents, registrars, and the like. In addition, =20
there are
significant network deployments, many at scale.

While this is all good, deployment experience is showing that
interoperability is difficult to achieve. Products from a single =20
vendor tend
to work well with each other. However, multi-vendor interoperability,
especially above the basic stack level, has historically been =20
difficult to
achieve. In fact, the proof point of the success of vendors attending =20=

SIPit
indicates interoperability problems may not be due to the specification
itself.

This workshop serves as a forum to bring together researchers, =20
engineers,
and service providers to exchange ideas, share experiences, and propose
approaches to address interoperability problems. Particular focus =20
will be on
systemic or architectural problems, as opposed to simple implementation
errors.

If the workshop identifies concrete proposals to improve =20
interoperability
that would require modifications to the underlying protocols, these
proposals will be forwarded to the appropriate groups in the IETF.

We encourage contributions describing interoperability and SIP. The =20
topics
of interest include but are not limited to:

* Interoperability failures seen in the field or lab
* Deployment experiences
* Development experiences
* Open source projects and experiences
* Failures discovered in the field after successful lab testing
* Common failure modes
* Interoperability test methodologies
* Interoperability test experiences
* Architectural principals
* Proposals for achieving interoperability
* Proposals for improving development
* Proposals for soliciting additional real-world feedback from =20
implementers
and service providers


POSITION PAPERS
Individuals must submit a position paper relevant to SIP =20
interoperability to
participate in the workshop. Acceptable formats are IETF Internet Draft
style (in HTML or plain text), IEEE Computer Society Proceedings =20
Manuscripts
style (in PDF), ACM Transactions style (in PDF), or presentation =20
style (in
PDF). The papers should be no longer than 6 pages if in IEEE or ACM =20
style or
10 pages of text in Internet Draft style. There is no minimum length
requirement. You are allowed to submit relevant, previously published =20=

works.

Papers received by the submission deadline will be posted to the =20
Workshop
web site, unless the author(s) request withholding publication. The
author(s) may retain copyright or assign it to the SIP Forum or the =20
IETF. If
you are submitting a paper that already has a copyright assignment, =20
such as
an IEEE or ACM conference or journal paper, please apply the appropriate
self-publication disclaimers demanded by those organizations.

Submit your position paper using EasyChair at the following address:
http://www.easychair.org/conferences/?conf=3Dsfsiw1


WORKSHOP FORMAT
There is only a limited time available at the venue for this first =20
workshop.
The expectation is this will be a highly interactive workshop. In =20
order to
frame the conversation, the workshop chair will open the discussion. =20
At the
discretion of the Program Committee and dependent upon the quality and
number of position papers received, a limited number of position =20
papers may
be presented. Note that all position papers will be published, unless =20=

the
author(s) request withholding publication.


WORKSHOP FEES
The workshop, including lunch, is free of charge to participants. Stated
differently, submitting a position paper, no matter how brief, pays =20
for your
lunch. The IETF has graciously provided a conference room at the =20
venue. As
such, we will not turn away non-participants. However, it is possible
non-participants may not be allowed to participate and certainly will =20=

not
get lunch.

WORKSHOP CHAIR:
Robert Sparks
Protocol Barbarian, Estacado Systems
rsparks@nostrum.com

PROGRAM CHAIR:
Eric Burger
Deputy CTO, BEA Systems
eburger@sipforum.org

PROGRAM COMMITTEE:
Robert Sparks, rsparks@nostrum.com
Anwar Siddiqui, anwars@avaya.com
Bob Penfield, BPenfield@acmepacket.com
Eric Burger, eburger@bea.com



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 14:16:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Irelg-0005cg-NQ; Mon, 12 Nov 2007 14:16:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ireld-0005U3-DT
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 14:16:17 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ireld-0005Pk-1A
	for sip@ietf.org; Mon, 12 Nov 2007 14:16:17 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irelc-0006Ey-LX
	for sip@ietf.org; Mon, 12 Nov 2007 14:16:16 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lACJGE3Q009386
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for ; Mon, 12 Nov 2007 13:16:16 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: 
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF SIP List 
From: Dean Willis 
Date: Mon, 12 Nov 2007 13:15:59 -0600
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Subject: [Sip] Agenda Requests, IETF 70
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


I'll be putting together this week the starting agenda for our  
upcoming meeting in Vancouver.

The tracker for this meeting is in our wiki at:

http://www.softarmor.com/mediawiki/index.php/SIP_at_IETF_70


Clearly we'll talk a bit about everything on the charter.

For specific additional items, please contact me.

--
Dean



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 12 19:15:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrjQg-0000pS-5v; Mon, 12 Nov 2007 19:14:58 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrjQe-0000nx-DX
	for sip-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 19:14:56 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrjQe-0000n8-2g
	for sip@ietf.org; Mon, 12 Nov 2007 19:14:56 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrjQd-000280-JN
	for sip@ietf.org; Mon, 12 Nov 2007 19:14:55 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAD0Eqx9011162
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Mon, 12 Nov 2007 18:14:54 -0600
In-Reply-To: <20071112123801.1EF2033C2B@delta.rtfm.com>
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>
	<20071111224707.68E5033C21@delta.rtfm.com>
	<008701c824d4$096ca180$c4f0200a@cisco.com>
	<454C097A8CB3F14BB73494D0CE053DBE30C573@MCHP7I7A.ww002.siemens.net>
	<20071112123801.1EF2033C2B@delta.rtfm.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <53D8026C-4460-4004-9D35-98A73E3808AC@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] media-security-requirements and lawful intercept
Date: Mon, 12 Nov 2007 18:14:37 -0600
To: Eric Rescorla 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: IETF SIP List , Dan Wing , "Fries,
	Steffen" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 12, 2007, at 6:38 AM, Eric Rescorla wrote:

>
> My point was not that one ought to pursue mechanisms allowed key
> disclosure without modifying the client but that one could design
> mechanisms that could be implemented solely in the client software
> without explicitly modifying the wire protocol. This means that
> clients (or, rather vendors) wish wish to enable key disclosure can do
> so without any new protocol design work from IETF.
>

That's true, unless they wish to do so using protocols that are  
controlled by the IETF.

For example, let's say we're talking about SIP phones. It's quite  
reasonable to consider using some part of SIP for the key disclosure,  
since SIP has already solved the how-to-find-the-endpoint-across-a- 
NAT problem, and since SIP already has lots of data-transport  
capabilities. One might be tempted to use a SIP EVENT package (under  
RFC 3325) to do this. But according to IETF procedure (RFC 3427),  
defining a SIP EVENT package requires an informational or standards  
track RFC.

So, the regulated operators now have to decide -- do they make their  
own fully-proprietary SIP extension in violation of the agreements we  
have with them about collaboration?

Or do they reinvent a large part of the SIP infrastructure as a new  
protocol in order to meet their requirements?

Once they've gone down either path, what's to keep them from going  
further down that path, resulting in protocol fragmentation and  
lesser value from the Internet?

We can't stop them from doing lawful intercept. We can help them do  
it in the least dangerous way possible. And we can stop (or at least  
delay) fragmentation of the protocol suite. But doing so requires  
some level of compromise of values many of us hold dear.

Personally, I'd be fairly by a show-of-unity that causes the IETF to  
conclude that LI via key disclosure is such a dangerous idea that we  
will neither help the other SDOs do it now allow them to document the  
so-doing using our protocols and extension registration facilities.

But before we make that decision, we need to understand the  
implications and impact of what we're deciding. This is non-trivial,  
and the repercussions will reach the furthest ends of the Internet,  
in both space and time.

--
Dean




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 13 01:15:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Irp3q-0005uO-Tx; Tue, 13 Nov 2007 01:15:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Irp3o-0005uB-OG
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 01:15:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Irp3o-0005u2-3o
	for sip@ietf.org; Tue, 13 Nov 2007 01:15:44 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irp3n-0004VV-2r
	for sip@ietf.org; Tue, 13 Nov 2007 01:15:44 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAD6FQFZ012827
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Tue, 13 Nov 2007 00:15:27 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
To: IETF SIP List 
Message-Id: 
From: Dean Willis 
Date: Tue, 13 Nov 2007 00:15:09 -0600
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10
Cc: Cullen Jennings , Keith Drage 
Subject: [Sip] Draft agenda, SIP at IETF 70
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1819656584=="
Errors-To: sip-bounces@ietf.org


--===============1819656584==
Content-Type: multipart/alternative; boundary=Apple-Mail-1--268539031


--Apple-Mail-1--268539031
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


This is a VERY early draft agenda -- please comment on  
appropriateness and time allocations. I expect there will be  
substantive changes.

Changed will be incrementally posted to:

http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_70


Session 1, Monday December 3, 1740-1950 Salon A/B
Start Time
Topic
Discussion Lead
Reading List
1740
Agenda Bash and Status
Chairs
This document
1750
Outbound
Rohan Mahy
draft-ietf-sip-outbound-10
1820
XCAP Diff Event
Jari Urpalianen
draft-urpalainen-sip-xcap-diff-event-02
1845
Location Conveyance
Brian rosen, James Polk
draft-ietf-sip-location-conveyance-08
1910
Connection Reuse
Vijay Gurbani
draft-ietf-sip-connect-reuse-08
1950
End




Session 2, Wednesday December 5, 0900-1130, Salon A/B
Start Time
Topic
Discussion Lead
Reading List
0900
Agenda Bash
Chairs
This Document
0910
Resource Priority Namespaces
James Polk
draft-ietf-sip-rph-new-namespaces-00
0930
RPH In Responses
James Polk
draft-polk-sip-rph-in-responses-00
0950
Certificate Authentication
Steve Dotson
draft-dotson-sip-certificate-auth-03
1020
INFO Harmful
Eric Burger
draft-burger-sip-info-02
1050
INFO Events
Hadriel Kaplan
draft-kaplan-sip-info-events-00.txt
1130
End





--Apple-Mail-1--268539031
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=US-ASCII



This is a VERY early draft =
agenda -- please comment on appropriateness and time allocations. I =
expect there will be substantive changes.

Changed will be =
incrementally posted to:

h=
ttp://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_70<=
/DIV>


Session 1, Monday December 3, 1740-1950 Salon =
A/B
<=
TD valign=3D"middle" style=3D"width: 64.0px; margin: 0.0px 0.5px 0.0px =
0.5px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; =
border-color: #808080 #808080 #808080 #808080; padding: 0.0px 2.0px =
0.0px 2.0px">
1820
=

Start =
Time
Topic
Discussion =
Lead
Reading =
List
1740
Agenda Bash and Status
Chairs
This =
document
1750
Outbound
Rohan Mahy
XCAP Diff Event
Jari Urpalianen
1845
Location =
Conveyance
Brian rosen, James Polk
1910
Connection =
Reuse
Vijay Gurbani
1950
End




Session 2, Wednesday December 5, 0900-1130, Salon =
A/B
=
=

1050
<=
/TR>
Start =
Time
Topic
Discussion =
Lead
Reading =
List
0900
Agenda Bash
Chairs
This Document
0910
Resource Priority =
Namespaces
James Polk
0930
RPH In =
Responses
James Polk
0950
Certificate =
Authentication
Steve Dotson
1020
INFO Harmful
Eric Burger
INFO Events
Hadriel Kaplan
1130
End




=

--Apple-Mail-1--268539031--



--===============1819656584==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1819656584==--





From sip-bounces@ietf.org Tue Nov 13 03:06:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Irqmz-00008l-DP; Tue, 13 Nov 2007 03:06:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Irqmy-00008X-4T
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 03:06:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Irqmr-0008VR-5q
	for sip@ietf.org; Tue, 13 Nov 2007 03:06:21 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irqmq-00084Y-DF
	for sip@ietf.org; Tue, 13 Nov 2007 03:06:21 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JRF00M0LQHSTW@siemenscomms.co.uk> for sip@ietf.org; Tue,
	13 Nov 2007 08:05:52 +0000 (GMT)
Date: Tue, 13 Nov 2007 08:06:18 +0000
From: "Elwell, John" 
Subject: RE: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt
In-reply-to: 
To: Jason Fischl ,
	Hannes Tschofenig ,
	Eric Rescorla 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E9673@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt
Thread-Index: Acgk8VuOGDukYdUYRu+GADE+jpfRLQAbZkZA
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

In Security Considerations, concerning UPDATE:
"OPEN ISSUE:  Note that there is a window of vulnerability during
   the early media phase of this operation before Alice receives the
   UPDATE (which immediately follows the SDP answer).  During this
   window, Alice cannot be sure of Bob's identity."
There is a vulnerability in any case during the early media phase if the
SDP answer does not arrive until the SIP 200 OK. So the additional
vulnerability is the short window between the 200 OK and the UPDATE
request. Also the UPDATE request can be sent earlier if reliable
provisional responses (RFC 3262) are used.

Concerning use of SIPS:
"The security issue with this approach is that if one of
   the Proxies wished to mount a man-in-the-middle attack, it could
   convince Alice that she was talking to Bob when really the media was
   flowing through a man in the middle media relay."
In fact, even a well-behaved proxy could forward the INVITE request to
Chuck (in accordance with Bob's requirements presumably), so Alice might
think she is talking to Bob when in fact she is talking to Chuck.

Concerning use of S/MIME:
"RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that
   could be used to sign that the fingerprint was from Bob. This would
   be secure.  However, so far there have been no deployments of S/MIME
   for SIP."
It fails to mention that PKIX certs need to be provided on endpoints.

John


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
> Sent: 12 November 2007 06:00
> To: i-d-announce@ietf.org
> Cc: sip@ietf.org
> Subject: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol 
> Working Group of the IETF.
> 
> 
> 	Title           : Framework for Establishing an SRTP 
> Security Context using DTLS
> 	Author(s)       : J. Fischl, et al.
> 	Filename        : draft-ietf-sip-dtls-srtp-framework-00.txt
> 	Pages           : 28
> 	Date            : 2007-11-12
> 
> This document specifies how to use the Session Initiation Protocol
> (SIP) to establish an Secure Real-time Transport Protocol (SRTP)
> security context using the Datagram Transport Layer Security (DTLS)
> protocol.  It describes a mechanism of transporting a fingerprint
> attribute in the Session Description Protocol (SDP) that identifies
> the key that will be presented during the DTLS handshake.  It relies
> on the SIP identity mechanism to ensure the integrity of the
> fingerprint attribute.  The key management exchange travels along the
> media path as opposed to the signaling path.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-f
> ramework-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in 
> the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-sip-dtls-srtp-framework-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE 
> /internet-drafts/draft-ietf-sip-dtls-srtp-framework-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 13 09:46:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Irx1t-0003C6-8b; Tue, 13 Nov 2007 09:46:17 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Irx1r-00036X-BG
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 09:46:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx1q-00036P-Su
	for sip@ietf.org; Tue, 13 Nov 2007 09:46:15 -0500
Received: from jaguar.aricent.com ([61.246.186.17])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irx1m-0006V5-EJ
	for sip@ietf.org; Tue, 13 Nov 2007 09:46:14 -0500
Received: from jaguar.aricent.com (localhost [127.0.0.1])
	by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lADEakXs015039
	for ; Tue, 13 Nov 2007 20:06:46 +0530
Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21])
	by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lADEajk1015024;
	Tue, 13 Nov 2007 20:06:45 +0530
In-Reply-To: <47385310.3010408@cisco.com>
To: Paul Kyzivat 
Subject: Re: [Sip] Early Dialogue Handling
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: 
From: "B Venkat S.R Swamy" 
Date: Tue, 13 Nov 2007 20:15:56 +0530
X-MIMETrack: S/MIME Sign by Notes Client on B Venkat S.R Swamy/HSS(Release
	6.5.1|January 21, 2004) at 11/13/2007 08:15:56 PM,
	Serialize by Notes Client on B Venkat S.R Swamy/HSS(Release
	6.5.1|January 21, 2004) at 11/13/2007 08:15:56 PM,
	Serialize complete at 11/13/2007 08:15:56 PM,
	S/MIME Sign failed at 11/13/2007 08:15:56 PM: The cryptographic key was
	not found,
	Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30,
	2005) at 13/11/2007 08:20:46 PM,
	Serialize complete at 13/11/2007 08:20:46 PM
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2013148909=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============2013148909==
Content-Type: multipart/alternative;
	boundary="=_alternative 00511C2865257392_="

This is a multipart message in MIME format.
--=_alternative 00511C2865257392_=
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: base64

SGkgDQoNCkkgYW0gc29ycnkgZm9yIHRoYXQgY29uZnVzaW5nIHN0YXRlbWVudHMsIGxldCBtZSBj
b3JyZWN0IGFuZCBjbGFyaWZ5IGl0IGFzIA0KZm9sbG93czoNCg0KMT4gSW52aXRlIHNlbnQgdG8g
dGhlIG5ldHdvcmsNCjI+IDF4eCByZXNwb25zZSB0byBJbnZpdGUgcmVjZWl2ZWQgZnJvbSBuZXR3
b3JrIHdpdGhvdXQgYW55IENvbnRhY3QgDQpoZWFkZXIuIERpYWxvZ3VlIGdldHMgZXN0YWJsaXNo
ZWQuDQozPiBBbiBlYXJseSBpbi1kaWFsb2d1ZSB0cmFuc2FjdGlvbiAoc2F5IE9QVElPTi9VUERB
VEUpIGluaXRpYXRlZC4NCg0KcHJvYmxlbTogd2hlcmUgc2hvdWxkIHRoaXMgbmV3IHRyYW5zYWN0
aW9uIGJlIHJvdXRlZC4NCg0KT3B0aW9uczogDQoNCj4gUm91dGUgdGhlIHRyYW5zYWN0aW9uIHRv
IHRoZSBzYW1lIGFkZHJlc3Mgd2hlcmUgaW5pdGlhbCBJbnZpdGUgd2FzIHNlbnQuIA0KDQo+IEdp
dmUgYW4gZXJyb3IgcmVzcG9uc2UgdG8gdGhlIGVhcmx5IGluLWRpYWxvZ3VlKHNheSBPUFRJT04v
VVBEQVRFKSANCnRyYW5zYWN0aW9uLCBpZiBjb250YWN0IGlzIG5vdCByZWNlaXZlZCBpbiAxeHgo
bm9uLTEwMCkgdGlsbCB3ZSByZWNlaXZlIGl0IA0KaW4gMnh4IHJlc3BvbnNlLg0KSXQgaXMgbWFu
ZGF0b3J5IHRvIGdpdmUgQ29udGFjdCBoZWFkZXIgaW4gMXh4IGlmIGVhcmx5IGluLWRpYWxvZ3Vl
IA0KdHJhbnNhY3Rpb24gaXMgdG8gYmUgc2VudC4oIFRoaXMgd291bGQgcmVxdWlyZSBjaGFuZ2Ug
aW4gUkZDIDMyNjEpLiANCj4gRmFpbCB0aGUgZGlhbG9ndWUvY2FsbC4NCg0KDQpJIGNvdWxkIGdl
dCBzb21lIGNsYXJpZmljYXRpb24gZnJvbSB5b3VyIHJlc3BvbnNlcywgYnV0IGZpbmQgbXkgY29t
bWVudHMgDQppbmxpbmVbQlZTXSBiZWxvdw0KDQoNCnJlZ2FyZHMNClZlbmthdA0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQogDQoNCg0KDQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4gDQox
MS8xMi8yMDA3IDA2OjUwIFBNDQoNCg0KVG8NCkIgVmVua2F0IFMuUiBTd2FteS9IU1NASFNTDQpj
Yw0Kc2lwQGlldGYub3JnDQpTdWJqZWN0DQpSZTogW1NpcF0gRWFybHkgRGlhbG9ndWUgSGFuZGxp
bmcNCg0KDQoNCg0KDQoNCg0KDQpCIFZlbmthdCBTLlIgU3dhbXkgd3JvdGU6DQo+IA0KPiBIaQ0K
PiANCj4gRm9yIGFuIGVhcmx5IGRpYWxvZ3VlIHNlbnQgYWZ0ZXIgMXh4IHJlc3BvbnNlIHRvIElu
dml0ZQ0KDQpJJ20gYSBsaXR0bGUgY29uZnVzZWQgYnkgeW91ciB0ZXJtaW5vbG9nLiBBIGRpYWxv
ZyBpcyBub3Qgc29tZXRoaW5nIHlvdSANCnNlbmQuIEl0IGlzIHNvbWV0aGluZyB0aGF0IGV4aXN0
cywgb3Igbm90LiBZb3UgY2FuIGhhdmUgYW4gZWFybHkgZGlhbG9nIA0KZXZlbiBpZiB5b3UgY2hv
b3NlIG5vdCB0byBzZW5kIGFueSBtZXNzYWdlcyB3aXRoaW4gaXQuDQoNCkkgZ3Vlc3MgeW91IGFy
ZSBhc2tpbmcgaG93IHRvIGNvbnN0cnVjdCBhIG1lc3NhZ2UgdG8gYmUgc2VudCB3aXRoaW4gYW4g
DQplYXJseSBkaWFsb2cgaWYgdGhlIDF4eCByZXNwb25zZSB0aGF0IGVzdGFibGlzaGVkIHRoZSBl
YXJseSBkaWFsb2cgZGlkIA0Kbm90IGNvbnRhaW4gYSBDb250YWN0IGhlYWRlci4NCg0KPiBhbmQg
YmVmb3JlIHRoZSANCj4gMnh4IHJlc3BvbnNlLCB3aGF0IGlzIHRoZSBleHBlY3RlZCBiZWhhdmlv
dXIgZm9yIHJvdXRpbmcgdGhlIGVhcmx5IA0KPiBkaWFsb2d1ZSBpZiAxeHgobm9uLTEwMCkgZG9l
cyBub3QNCj4gY29udGFpbiBDb250YWN0IEhlYWRlci4NCj4gDQo+IE9wdGlvbnM6DQo+IA0KPiAg
PiBSb3V0ZSB0aGUgbWVzc2FnZSB0byB0aGUgc2FtZSBhZGRyZXNzIHdoZXJlIGluaXRpYWwgSW52
aXRlIHdhcyBzZW50Lg0KPiAgPiBJdCBpcyBtYW5kYXRvcnkgdG8gZ2l2ZSBDb250YWN0IGhlYWRl
ciBpbiAxeHggaWYgZWFybHkgZGlhbG9ndWUgaXMgdG8gDQoNCj4gYmUgc2VudC4oIFRoaXMgd291
bGQgcmVxdWlyZSBjaGFuZ2UgaW4gUkZDIDMyNjEpLg0KDQpBRkFJSyBpdCBpcyBpbmRlZWQgcmVx
dWlyZWQgdG8gcHJvdmlkZSBhIENvbnRhY3QgYWRkcmVzcyBpbiByZXNwb25zZXMgDQp0aGF0IGVz
dGFibGlzaCBhIGRpYWxvZyAoZWFybHkgb3Igbm90KS4gSSB3YXMgdGhpbmtpbmcgMzI2MSBhbHJl
YWR5IA0KY2FsbGVkIGZvciB0aGlzLCBidXQgSSdsbCBoYXZlIHRvIHNwZW5kIHNvbWUgdGltZSBs
b29raW5nIGF0IDMyNjEgdG8gDQpjb25maXJtIHRoYXQuDQoNCj4gR2l2ZSBhbiBlcnJvciByZXNw
b25zZSANCj4gdG8gdGhlIGVhcmx5IGRpYWxvZ3VlLCBpZg0KPiBjb250YWN0IGlzIG5vdCByZWNl
aXZlZCBpbiAxeHgobm9uLTEwMCkuDQoNClNpbmNlIHRoZSBwcm9ibGVtIGlzIHdpdGggYSByZXNw
b25zZSwgeW91IGNhbid0IGdpdmUgYW4gZXJyb3IgcmVzcG9uc2UgDQp0byBpdC4gWW91IHdpbGwg
aGF2ZSB0byBtYWtlIGRvLg0KDQo+ICA+IEZhaWwgdGhlIGRpYWxvZ3VlL2NhbGwuDQoNClRoZSBz
dHJvbmdlc3QgdGhpbmcgeW91IGNvdWxkIGRvIGlzIHNlbmQgYSBDQU5DRUwsIHdoaWNoIGRvZXNu
J3QgcmVxdWlyZSANCnRoZSBDb250YWN0LiAoWW91IGNhbid0IHNlbmQgYSBCWUUgYmVjYXVzZSB0
aGF0IGlzIGFsc28gYW4gaW4tZGlhbG9nIA0KcmVxdWVzdC4pDQoNCklmIHlvdSByZWNlaXZlZCBh
biAqdW5yZWxpYWJsZSogcHJvdmlzaW9uYWwgd2l0aCBhIHRvLXRhZywgeW91IGNhbiBqdXN0IA0K
bWFrZS1kbyBieSBub3QgdHJ5aW5nIHRvIHNlbmQgYW55IG1lc3NhZ2VzIHdpdGhpbiB0aGUgZGlh
bG9nIHVudGlsIHlvdSANCmRvIGdldCBhIENvbnRhY3QsIGF0IGxlYXN0IGluIHRoZSAyeHggcmVz
cG9uc2UuDQpbQlZTXT4+PiBkb2VzIGl0IG1lYW4gd2UgaWdub3JlIHRoZSBtZXNzYWdlIG9yIGdp
dmUgbmVnYXRpdmUgcmVzcG9uc2UgdG8gDQppdC4NCg0KDQoNCklmIHlvdSByZWNlaXZlZCBhICpy
ZWxpYWJsZSogcHJvdmlzaW9uYWwgd2l0aG91dCBhIENvbnRhY3QgdGhlbiB5b3UgaGF2ZSANCmEg
cHJvYmxlbSBiZWNhdXNlIHlvdSBhcmUgb2JsaWdhdGVkIHRvIHNlbmQgYSBQUkFDSyB3aXRoaW4g
dGhlIGRpYWxvZyANCmJ1dCB5b3UgZG9uJ3QgaGF2ZSB0aGUgaW5mbyB0byBkbyBzby4gSW4gdGhh
dCBjYXNlIEkgdGhpbmsgeW91IG11c3Qgc2VuZCANCmEgQ0FOQ0VMIG9yIGVsc2UganVzdCBwcmV0
ZW5kIHRoZSByZXNwb25zZSB3YXMgdW5yZWxpYWJsZS4gKFdoaWNoIA0KcHJvYmFibHkgd29uJ3Qg
d29yayB3ZWxsLikNCg0KSSBzdXBwb3NlIHlvdSBjb3VsZCBoYXZlIGEgVUFTIHRoYXQgc2VuZHMg
YSBDb250YWN0IGluIG9uZSByZXNwb25zZSBhbmQgDQp0aGVuIGZhaWxzIHRvIHNlbmQgaXQgaW4g
c3Vic2VxdWVudCByZXNwb25zZXMuIEluIHRoYXQgY2FzZSB5b3UgbWlnaHQgDQp0cnkgdG8gdXNl
IHRoZSBtb3N0IHJlY2VudCBvbmUgeW91IGhhdmUgcmVjZWl2ZWQuDQoNCiAgICAgICAgICAgICAg
ICAgR29vZCBsdWNrLA0KICAgICAgICAgICAgICAgICBQYXVsDQoNCj4gcmVnYXJkcw0KPiBWZW5r
YXQNCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKiAgQXJpY2VudC1SZXN0cmljdGVk
ICAgKioqKioqKioqKioqKioqKioqKioqKioNCj4gDQo+ICJESVNDTEFJTUVSOiBUaGlzIG1lc3Nh
Z2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVuZGVkIA0Kc29sZWx5IGZv
ciB0aGUgdXNlIG9mIA0KPiB0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4g
SXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciANCmNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBh
bmQgc2hvdWxkIG5vdCBiZSANCj4gY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBv
dGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgDQo+IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig
aW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCANCnJlY2lwaWVudCwgeW91
IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkNCj4gcHJvaGliaXRlZCBmcm9tIHVz
aW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgDQp0
aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgDQo+IGxv
c3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFu
c21pdHRlZCBieSANCnRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiINCj4g
DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZl
bG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCj4gVXNlIHNpcC1pbXBsZW1lbnRvcnNA
Y3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXANCj4gVXNlIHNpcHBp
bmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNp
cA0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKiogIEFyaWNlbnQtUmVzdHJpY3RlZCAgICoq
KioqKioqKioqKioqKioqKioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3By
aWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg
CnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBw
cml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAK
Y2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0
IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Is
IApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5v
dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBz
dHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNj
bG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyBy
ZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9m
IHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1h
Z2UgZnJvbSB2aXJ1cy4iCg==
--=_alternative 00511C2865257392_=
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIDwvZm9udD4NCjxicj4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhbSBzb3JyeSBmb3IgdGhhdCBjb25m
dXNpbmcgc3RhdGVtZW50cywNCmxldCBtZSBjb3JyZWN0IGFuZCBjbGFyaWZ5IGl0IGFzIGZvbGxv
d3M6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xJmd0
OyBJbnZpdGUgc2VudCB0byB0aGUgbmV0d29yazwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0ic2Fucy1zZXJpZiI+MiZndDsgMXh4IHJlc3BvbnNlIHRvIEludml0ZSByZWNlaXZlZA0KZnJv
bSBuZXR3b3JrIHdpdGhvdXQgYW55IENvbnRhY3QgaGVhZGVyLiBEaWFsb2d1ZSBnZXRzIGVzdGFi
bGlzaGVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MyZndDsg
QW4gZWFybHkgaW4tZGlhbG9ndWUgdHJhbnNhY3Rpb24NCihzYXkgT1BUSU9OL1VQREFURSkgaW5p
dGlhdGVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+
cHJvYmxlbTogd2hlcmUgc2hvdWxkIHRoaXMgbmV3IHRyYW5zYWN0aW9uDQpiZSByb3V0ZWQuPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpPcHRpb25zOjwv
Zm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z
ZXJpZiI+PGJyPg0KJmd0OyBSb3V0ZSB0aGUgdHJhbnNhY3Rpb24gdG8gdGhlIHNhbWUgYWRkcmVz
cyB3aGVyZSBpbml0aWFsIEludml0ZSB3YXMNCnNlbnQuPC9mb250Pjxmb250IHNpemU9Mz4gPC9m
b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQomZ3Q7IEdpdmUgYW4gZXJy
b3IgcmVzcG9uc2UgdG8gdGhlIGVhcmx5IGluLWRpYWxvZ3VlKHNheSBPUFRJT04vVVBEQVRFKQ0K
dHJhbnNhY3Rpb24sIGlmIGNvbnRhY3QgaXMgbm90IHJlY2VpdmVkIGluIDF4eChub24tMTAwKSB0
aWxsIHdlIHJlY2VpdmUNCml0IGluIDJ4eCByZXNwb25zZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6
ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0IGlzIG1hbmRhdG9yeSB0byBnaXZlIENvbnRhY3QgaGVh
ZGVyDQppbiAxeHggaWYgZWFybHkgaW4tZGlhbG9ndWUgdHJhbnNhY3Rpb24gaXMgdG8gYmUgc2Vu
dC4oIFRoaXMgd291bGQgcmVxdWlyZQ0KY2hhbmdlIGluIFJGQyAzMjYxKS4gPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IEZhaWwgdGhlIGRpYWxvZ3VlL2Nh
bGwuPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij5JIGNvdWxkIGdldCBzb21lIGNsYXJpZmljYXRpb24gZnJvbQ0KeW91ciByZXNwb25zZXMsIGJ1
dCBmaW5kIG15IGNvbW1lbnRzIGlubGluZVtCVlNdIGJlbG93PC9mb250Pg0KPGJyPg0KPHRhYmxl
IHdpZHRoPTEwMCU+DQo8dHI+DQo8dGQgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk
Pjxmb250IHNpemU9MSBjb2xvcj0jNjA2MDYwIGZhY2U9IkFyaWFsIj5yZWdhcmRzPC9mb250Pg0K
PGJyPjxmb250IHNpemU9MSBjb2xvcj0jNjA2MDYwIGZhY2U9IkFyaWFsIj5WZW5rYXQ8L2ZvbnQ+
DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRyIHZhbGln
bj10b3A+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk
Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ciB2YWxp
Z249dG9wPg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjxwPjxm
b250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9
MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0i
c2Fucy1zZXJpZiI+PGI+UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7PC9i
Pg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjExLzEyLzIwMDcg
MDY6NTAgUE08L2ZvbnQ+DQo8YnI+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+
DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl
cmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNlPSJz
YW5zLXNlcmlmIj5CIFZlbmthdCBTLlIgU3dhbXkvSFNTQEhTUzwvZm9udD4NCjx0cj4NCjx0ZD4N
CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250
PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnNp
cEBpZXRmLm9yZzwvZm9udD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6
ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRv
cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtTaXBdIEVhcmx5IERpYWxvZ3Vl
DQpIYW5kbGluZzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+
DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250
IHNpemU9Mj48dHQ+PGJyPg0KPGJyPg0KQiBWZW5rYXQgUy5SIFN3YW15IHdyb3RlOjxicj4NCiZn
dDsgPGJyPg0KJmd0OyBIaTxicj4NCiZndDsgPGJyPg0KJmd0OyBGb3IgYW4gZWFybHkgZGlhbG9n
dWUgc2VudCBhZnRlciAxeHggcmVzcG9uc2UgdG8gSW52aXRlPGJyPg0KPGJyPg0KSSdtIGEgbGl0
dGxlIGNvbmZ1c2VkIGJ5IHlvdXIgdGVybWlub2xvZy4gQSBkaWFsb2cgaXMgbm90IHNvbWV0aGlu
ZyB5b3UNCjxicj4NCnNlbmQuIEl0IGlzIHNvbWV0aGluZyB0aGF0IGV4aXN0cywgb3Igbm90LiBZ
b3UgY2FuIGhhdmUgYW4gZWFybHkgZGlhbG9nDQo8YnI+DQpldmVuIGlmIHlvdSBjaG9vc2Ugbm90
IHRvIHNlbmQgYW55IG1lc3NhZ2VzIHdpdGhpbiBpdC48YnI+DQo8YnI+DQpJIGd1ZXNzIHlvdSBh
cmUgYXNraW5nIGhvdyB0byBjb25zdHJ1Y3QgYSBtZXNzYWdlIHRvIGJlIHNlbnQgd2l0aGluIGFu
DQo8YnI+DQplYXJseSBkaWFsb2cgaWYgdGhlIDF4eCByZXNwb25zZSB0aGF0IGVzdGFibGlzaGVk
IHRoZSBlYXJseSBkaWFsb2cgZGlkDQo8YnI+DQpub3QgY29udGFpbiBhIENvbnRhY3QgaGVhZGVy
Ljxicj4NCjxicj4NCiZndDsgYW5kIGJlZm9yZSB0aGUgPGJyPg0KJmd0OyAyeHggcmVzcG9uc2Us
IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW91ciBmb3Igcm91dGluZyB0aGUgZWFybHkNCjxi
cj4NCiZndDsgZGlhbG9ndWUgaWYgMXh4KG5vbi0xMDApIGRvZXMgbm90PGJyPg0KJmd0OyBjb250
YWluIENvbnRhY3QgSGVhZGVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPcHRpb25zOjxicj4NCiZn
dDsgPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFJvdXRlIHRoZSBtZXNzYWdlIHRvIHRoZSBzYW1lIGFk
ZHJlc3Mgd2hlcmUgaW5pdGlhbCBJbnZpdGUNCndhcyBzZW50Ljxicj4NCiZndDsgJm5ic3A7Jmd0
OyBJdCBpcyBtYW5kYXRvcnkgdG8gZ2l2ZSBDb250YWN0IGhlYWRlciBpbiAxeHggaWYgZWFybHkN
CmRpYWxvZ3VlIGlzIHRvIDxicj4NCiZndDsgYmUgc2VudC4oIFRoaXMgd291bGQgcmVxdWlyZSBj
aGFuZ2UgaW4gUkZDIDMyNjEpLjxicj4NCjxicj4NCkFGQUlLIGl0IGlzIGluZGVlZCByZXF1aXJl
ZCB0byBwcm92aWRlIGEgQ29udGFjdCBhZGRyZXNzIGluIHJlc3BvbnNlcyA8YnI+DQp0aGF0IGVz
dGFibGlzaCBhIGRpYWxvZyAoZWFybHkgb3Igbm90KS4gSSB3YXMgdGhpbmtpbmcgMzI2MSBhbHJl
YWR5IDxicj4NCmNhbGxlZCBmb3IgdGhpcywgYnV0IEknbGwgaGF2ZSB0byBzcGVuZCBzb21lIHRp
bWUgbG9va2luZyBhdCAzMjYxIHRvIDxicj4NCmNvbmZpcm0gdGhhdC48YnI+DQo8YnI+DQomZ3Q7
IEdpdmUgYW4gZXJyb3IgcmVzcG9uc2UgPGJyPg0KJmd0OyB0byB0aGUgZWFybHkgZGlhbG9ndWUs
IGlmPGJyPg0KJmd0OyBjb250YWN0IGlzIG5vdCByZWNlaXZlZCBpbiAxeHgobm9uLTEwMCkuPGJy
Pg0KPGJyPg0KU2luY2UgdGhlIHByb2JsZW0gaXMgd2l0aCBhIHJlc3BvbnNlLCB5b3UgY2FuJ3Qg
Z2l2ZSBhbiBlcnJvciByZXNwb25zZQ0KPGJyPg0KdG8gaXQuIFlvdSB3aWxsIGhhdmUgdG8gbWFr
ZSBkby48YnI+DQo8YnI+DQomZ3Q7ICZuYnNwOyZndDsgRmFpbCB0aGUgZGlhbG9ndWUvY2FsbC48
YnI+DQo8YnI+DQpUaGUgc3Ryb25nZXN0IHRoaW5nIHlvdSBjb3VsZCBkbyBpcyBzZW5kIGEgQ0FO
Q0VMLCB3aGljaCBkb2Vzbid0IHJlcXVpcmUNCjxicj4NCnRoZSBDb250YWN0LiAoWW91IGNhbid0
IHNlbmQgYSBCWUUgYmVjYXVzZSB0aGF0IGlzIGFsc28gYW4gaW4tZGlhbG9nIDxicj4NCnJlcXVl
c3QuKTxicj4NCjxicj4NCklmIHlvdSByZWNlaXZlZCBhbiAqdW5yZWxpYWJsZSogcHJvdmlzaW9u
YWwgd2l0aCBhIHRvLXRhZywgeW91IGNhbiBqdXN0DQo8YnI+DQptYWtlLWRvIGJ5IG5vdCB0cnlp
bmcgdG8gc2VuZCBhbnkgbWVzc2FnZXMgd2l0aGluIHRoZSBkaWFsb2cgdW50aWwgeW91DQo8YnI+
DQpkbyBnZXQgYSBDb250YWN0LCBhdCBsZWFzdCBpbiB0aGUgMnh4IHJlc3BvbnNlLjxicj4NCltC
VlNdJmd0OyZndDsmZ3Q7IGRvZXMgaXQgbWVhbiB3ZSBpZ25vcmUgdGhlIG1lc3NhZ2Ugb3IgZ2l2
ZSBuZWdhdGl2ZSByZXNwb25zZQ0KdG8gaXQuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+
PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpJZiB5b3UgcmVjZWl2ZWQgYSAqcmVsaWFibGUqIHByb3Zp
c2lvbmFsIHdpdGhvdXQgYSBDb250YWN0IHRoZW4geW91IGhhdmUNCjxicj4NCmEgcHJvYmxlbSBi
ZWNhdXNlIHlvdSBhcmUgb2JsaWdhdGVkIHRvIHNlbmQgYSBQUkFDSyB3aXRoaW4gdGhlIGRpYWxv
ZyA8YnI+DQpidXQgeW91IGRvbid0IGhhdmUgdGhlIGluZm8gdG8gZG8gc28uIEluIHRoYXQgY2Fz
ZSBJIHRoaW5rIHlvdSBtdXN0IHNlbmQNCjxicj4NCmEgQ0FOQ0VMIG9yIGVsc2UganVzdCBwcmV0
ZW5kIHRoZSByZXNwb25zZSB3YXMgdW5yZWxpYWJsZS4gKFdoaWNoIDxicj4NCnByb2JhYmx5IHdv
bid0IHdvcmsgd2VsbC4pPGJyPg0KPGJyPg0KSSBzdXBwb3NlIHlvdSBjb3VsZCBoYXZlIGEgVUFT
IHRoYXQgc2VuZHMgYSBDb250YWN0IGluIG9uZSByZXNwb25zZSBhbmQNCjxicj4NCnRoZW4gZmFp
bHMgdG8gc2VuZCBpdCBpbiBzdWJzZXF1ZW50IHJlc3BvbnNlcy4gSW4gdGhhdCBjYXNlIHlvdSBt
aWdodCA8YnI+DQp0cnkgdG8gdXNlIHRoZSBtb3N0IHJlY2VudCBvbmUgeW91IGhhdmUgcmVjZWl2
ZWQuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsNCkdvb2QgbHVjayw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KUGF1bDxicj4NCjxicj4NCiZndDsgcmVn
YXJkczxicj4NCiZndDsgVmVua2F0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKioq
KioqKioqKioqKioqKioqKioqKiogJm5ic3A7QXJpY2VudC1SZXN0cmljdGVkICZuYnNwOyAqKioq
KioqKioqKioqKioqKioqKioqKjxicj4NCiZndDsgPGJyPg0KJmd0OyAmcXVvdDtESVNDTEFJTUVS
OiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAmbmJzcDthbmQNCmlzIGlu
dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiA8YnI+DQomZ3Q7IHRoZSBpbmRpdmlkdWFsIHRv
IHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkDQpvciBjb25m
aWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgPGJyPg0KJmd0OyBjaXJjdWxh
dGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50
ZW5kZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIDxicj4N
CiZndDsgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFy
ZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3Ug
YXJlIHN0cmljdGx5PGJyPg0KJmd0OyBwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFs
dGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cw0Kb2YgdGhpcyBtZXNzYWdlLiBBcmlj
ZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIDxicj4NCiZndDsgbG9zcyBvciBkYW1h
Z2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkDQpi
eSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4mcXVvdDs8YnI+DQomZ3Q7
IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IDxicj4NCiZn
dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom
Z3Q7IFNpcCBtYWlsaW5nIGxpc3QgJm5ic3A7aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vc2lwPGJyPg0KJmd0OyBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBv
ZiB0aGUgY29yZSBTSVAgUHJvdG9jb2w8YnI+DQomZ3Q7IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNz
LmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwPGJyPg0KJmd0OyBVc2Ug
c2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24g
b2Ygc2lwPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPjxicj4NCjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqICZuYnNwO0FyaWNlbnQtUmVz
dHJpY3RlZCAmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+DQo8dGFibGU+PHRy
Pjx0ZCBiZ2NvbG9yPSNmZmZmZmY+PGZvbnQgY29sb3I9IzAwMDAwMD48cHJlPiJESVNDTEFJTUVS
OiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVuZGVk
IHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRy
ZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0
aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3Nl
IG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1t
ZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg
bm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29w
eWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2Fn
ZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2Ug
YXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRo
aXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIKPC9wcmU+PC9mb250PjwvdGQ+
PC90cj48L3RhYmxlPg==
--=_alternative 00511C2865257392_=--



--===============2013148909==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============2013148909==--





From sip-bounces@ietf.org Tue Nov 13 10:09:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxOJ-0005FF-LU; Tue, 13 Nov 2007 10:09:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxOH-0005AR-MD
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:09:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxOH-0005AJ-By
	for sip@ietf.org; Tue, 13 Nov 2007 10:09:25 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrxOH-0007W0-4T
	for sip@ietf.org; Tue, 13 Nov 2007 10:09:25 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns4.neustar.com (Postfix) with ESMTP id 001AF2AC6D;
	Tue, 13 Nov 2007 15:08:54 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IrxNm-0004XV-OH; Tue, 13 Nov 2007 10:08:54 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: gonzalo.camarillo@ericsson.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Tue, 13 Nov 2007 10:08:54 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org, oritl@microsoft.com, adam@estacado.net,
	Gonzalo.Camarillo@ericsson.com
Subject: [Sip] New Version Notification for 
 draft-ietf-sip-uri-list-subscribe-02 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-uri-list-subscribe-02.txt has been successfuly submitted by Gonzalo Camarillo and posted to the IETF repository.

Filename:	 draft-ietf-sip-uri-list-subscribe
Revision:	 02
Title:		 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
Creation_date:	 2007-11-13
WG ID:		 sip
Number_of_pages: 11

Abstract:
This document specifies a way to create subscription to a list of
resources in SIP.  This is achieved by including the list of
resources in the body of a SUBSCRIBE request.  Instead of having a
subscriber send a SUBSCRIBE request for each resource individually,
the subscriber defines the resource list, subscribes to it, and gets
notifications about changes in the resources' state using a single
SUBSCRIBE dialog.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 13 10:10:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxOv-0006xn-QG; Tue, 13 Nov 2007 10:10:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxOt-0006vc-RS
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:10:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxOt-0006vO-Dp; Tue, 13 Nov 2007 10:10:03 -0500
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IrxOt-0007Xm-1q; Tue, 13 Nov 2007 10:10:03 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A3002175DF;
	Tue, 13 Nov 2007 15:10:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IrxOs-0001mJ-6G; Tue, 13 Nov 2007 10:10:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Tue, 13 Nov 2007 10:10:02 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-uri-list-subscribe-02.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
	Author(s)       : G. Camarillo, et al.
	Filename        : draft-ietf-sip-uri-list-subscribe-02.txt
	Pages           : 11
	Date            : 2007-11-13

This document specifies a way to create subscription to a list of
resources in SIP.  This is achieved by including the list of
resources in the body of a SUBSCRIBE request.  Instead of having a
subscriber send a SUBSCRIBE request for each resource individually,
the subscriber defines the resource list, subscribes to it, and gets
notifications about changes in the resources' state using a single
SUBSCRIBE dialog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-subscribe-02.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-uri-list-subscribe-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-uri-list-subscribe-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-13100852.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-uri-list-subscribe-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-uri-list-subscribe-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-13100852.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Tue Nov 13 10:11:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxQR-00030M-0q; Tue, 13 Nov 2007 10:11:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxQN-0002px-Nz
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:11:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxQM-0002kL-DX
	for sip@ietf.org; Tue, 13 Nov 2007 10:11:34 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxQK-0005Lv-T7
	for sip@ietf.org; Tue, 13 Nov 2007 10:11:34 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns0.neustar.com (Postfix) with ESMTP id CFDC23290A;
	Tue, 13 Nov 2007 15:11:02 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IrxPq-0004cM-Oi; Tue, 13 Nov 2007 10:11:02 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: miguel.garcia@nsn.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Tue, 13 Nov 2007 10:11:02 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: sip@ietf.org, Gonzalo.Camarillo@ericsson.com
Subject: [Sip] New Version Notification for
	draft-ietf-sip-uri-list-message-02 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-uri-list-message-02.txt has been successfuly submitted by Miguel Garcia-Martin and posted to the IETF repository.

Filename:	 draft-ietf-sip-uri-list-message
Revision:	 02
Title:		 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
Creation_date:	 2007-11-13
WG ID:		 sip
Number_of_pages: 19

Abstract:
This document specifies a mechanism that allows a SIP User Agent
Client (UAC) to request a SIP URI-list (Uniform Resource Identifier
list) service to send a SIP MESSAGE request to a set of destinations.
The client sends a SIP MESSAGE request that includes the payload
along with the URI-list to the MESSAGE URI-list service, which sends
a similar MESSAGE request to each of the URIs included in the list.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 13 10:12:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxRe-0005R6-B0; Tue, 13 Nov 2007 10:12:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxRa-0005L4-GQ
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:12:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxRZ-0005H4-PA
	for sip@ietf.org; Tue, 13 Nov 2007 10:12:49 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrxRZ-0007t2-HC
	for sip@ietf.org; Tue, 13 Nov 2007 10:12:49 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns4.neustar.com (Postfix) with ESMTP id 5F0812AC6D;
	Tue, 13 Nov 2007 15:12:49 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IrxRZ-0004h1-44; Tue, 13 Nov 2007 10:12:49 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: gonzalo.camarillo@ericsson.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Tue, 13 Nov 2007 10:12:49 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: sip@ietf.org, Gonzalo.Camarillo@ericsson.com, dean.willis@softarmor.com
Subject: [Sip] New Version Notification for
	draft-ietf-sip-consent-framework-03 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-consent-framework-03.txt has been successfuly submitted by Gonzalo Camarillo and posted to the IETF repository.

Filename:	 draft-ietf-sip-consent-framework
Revision:	 03
Title:		 A Framework for Consent-based Communications in the Session Initiation Protocol (SIP)
Creation_date:	 2007-11-13
WG ID:		 sip
Number_of_pages: 31

Abstract:
The Session Initiation Protocol (SIP) supports communications across
many media types, including real-time audio, video, text, instant
messaging, and presence.  In its current form, it allows session
invitations, instant messages, and other requests to be delivered
from one party to another without requiring explicit consent of the
recipient.  Without such consent, it is possible for SIP to be used
for malicious purposes, including amplification, and DoS (Denial of
Service) attacks.  This document identifies a framework for consent-
based communications in SIP.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 13 10:12:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxRf-0005V8-PF; Tue, 13 Nov 2007 10:12:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxRe-0005Rs-IF
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:12:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxRc-0005PG-N3
	for sip@ietf.org; Tue, 13 Nov 2007 10:12:53 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxRZ-0005Wi-Az
	for sip@ietf.org; Tue, 13 Nov 2007 10:12:52 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns0.neustar.com (Postfix) with ESMTP id 4A6D9328F8;
	Tue, 13 Nov 2007 15:12:49 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IrxRZ-0004h4-6z; Tue, 13 Nov 2007 10:12:49 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: miguel.garcia@nsn.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Tue, 13 Nov 2007 10:12:49 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: sip@ietf.org, markus.isomaki@nokia.com, Gonzalo.Camarillo@ericsson.com,
	Aki.Niemi@nokia.com
Subject: [Sip] New Version Notification for draft-ietf-sip-multiple-refer-02
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-multiple-refer-02.txt has been successfuly submitted by Miguel Garcia-Martin and posted to the IETF repository.

Filename:	 draft-ietf-sip-multiple-refer
Revision:	 02
Title:		 Referring to Multiple Resources in the Session Initiation Protocol (SIP)
Creation_date:	 2007-11-13
WG ID:		 sip
Number_of_pages: 15

Abstract:
This document defines extensions to the SIP REFER method so that this
method can be used to refer servers to multiple resources.  These
extensions include the use of pointers to Uniform Resource Identifier
(URI)-lists in the Refer-To header field and the "multiple-refer" SIP
option-tag.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 13 10:17:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxVd-0007RV-Sc; Tue, 13 Nov 2007 10:17:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxVa-0007L2-8b
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:16:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxVX-0007Di-Js
	for sip@ietf.org; Tue, 13 Nov 2007 10:16:56 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxVG-0005t3-3d
	for sip@ietf.org; Tue, 13 Nov 2007 10:16:55 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns1.neustar.com (Postfix) with ESMTP id 0276B26E7E;
	Tue, 13 Nov 2007 15:16:38 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IrxVF-0004lx-Tt; Tue, 13 Nov 2007 10:16:37 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: gonzalo.camarillo@ericsson.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Tue, 13 Nov 2007 10:16:37 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: sip@ietf.org, alan@sipstation.com, Gonzalo.Camarillo@ericsson.com
Subject: [Sip] New Version Notification for 
 draft-ietf-sip-uri-list-conferencing-02 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-uri-list-conferencing-02.txt has been successfuly submitted by Gonzalo Camarillo and posted to the IETF repository.

Filename:	 draft-ietf-sip-uri-list-conferencing
Revision:	 02
Title:		 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
Creation_date:	 2007-11-13
WG ID:		 sip
Number_of_pages: 14

Abstract:
This document describes how to create a conference using SIP URI-list
services.  In particular, it describes a mechanism that allows a user
agent client to provide a conference server with the initial list of
participants using an INVITE-contained URI-list.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 13 10:20:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxYc-0001CZ-AR; Tue, 13 Nov 2007 10:20:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxYY-0001BL-VA
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:20:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxYY-0001BD-LU; Tue, 13 Nov 2007 10:20:02 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IrxYY-0006Hf-8w; Tue, 13 Nov 2007 10:20:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2B63826E7E;
	Tue, 13 Nov 2007 15:20:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IrxYY-00029r-0n; Tue, 13 Nov 2007 10:20:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Tue, 13 Nov 2007 10:20:02 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-multiple-refer-02.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Referring to Multiple Resources in the Session Initiation Protocol (SIP)
	Author(s)       : G. Camarillo, et al.
	Filename        : draft-ietf-sip-multiple-refer-02.txt
	Pages           : 15
	Date            : 2007-11-13

This document defines extensions to the SIP REFER method so that this
method can be used to refer servers to multiple resources.  These
extensions include the use of pointers to Uniform Resource Identifier
(URI)-lists in the Refer-To header field and the "multiple-refer" SIP
option-tag.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-multiple-refer-02.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-multiple-refer-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-multiple-refer-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-13101247.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-multiple-refer-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-multiple-refer-02.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-13101247.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Tue Nov 13 10:20:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxYd-0001DK-BX; Tue, 13 Nov 2007 10:20:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxYa-0001Bl-01
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:20:04 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxYZ-0001BV-KN; Tue, 13 Nov 2007 10:20:03 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IrxYZ-0000DQ-7X; Tue, 13 Nov 2007 10:20:03 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3571F2AC76;
	Tue, 13 Nov 2007 15:20:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IrxYX-00029f-Ud; Tue, 13 Nov 2007 10:20:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Tue, 13 Nov 2007 10:20:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-uri-list-message-02.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
	Author(s)       : M. Garcia-Martin, G. Camarillo
	Filename        : draft-ietf-sip-uri-list-message-02.txt
	Pages           : 19
	Date            : 2007-11-13

This document specifies a mechanism that allows a SIP User Agent
Client (UAC) to request a SIP URI-list (Uniform Resource Identifier
list) service to send a SIP MESSAGE request to a set of destinations.
The client sends a SIP MESSAGE request that includes the payload
along with the URI-list to the MESSAGE URI-list service, which sends
a similar MESSAGE request to each of the URIs included in the list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-message-02.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-uri-list-message-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-uri-list-message-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-13101100.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-uri-list-message-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-uri-list-message-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-13101100.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Tue Nov 13 10:20:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxYr-0001u7-2P; Tue, 13 Nov 2007 10:20:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxYb-0001CF-A5
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:20:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxYa-0001C6-TM; Tue, 13 Nov 2007 10:20:04 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IrxYY-0006Hi-De; Tue, 13 Nov 2007 10:20:04 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3A6B0328F0;
	Tue, 13 Nov 2007 15:20:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IrxYY-0002A4-3U; Tue, 13 Nov 2007 10:20:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Tue, 13 Nov 2007 10:20:02 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-uri-list-conferencing-02.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
	Author(s)       : G. Camarillo, A. Johnston
	Filename        : draft-ietf-sip-uri-list-conferencing-02.txt
	Pages           : 14
	Date            : 2007-11-13

This document describes how to create a conference using SIP URI-list
services.  In particular, it describes a mechanism that allows a user
agent client to provide a conference server with the initial list of
participants using an INVITE-contained URI-list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-conferencing-02.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-uri-list-conferencing-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-uri-list-conferencing-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-13101636.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-uri-list-conferencing-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-uri-list-conferencing-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-13101636.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Tue Nov 13 10:58:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxZv-0003HC-DG; Tue, 13 Nov 2007 10:21:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IrxZ6-0002JH-Fk
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:20:36 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxZ3-0002Gu-Lu; Tue, 13 Nov 2007 10:20:34 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IrxZ3-0000Ga-8J; Tue, 13 Nov 2007 10:20:33 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6C12A2AC79;
	Tue, 13 Nov 2007 15:20:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IrxYX-00029l-Vp; Tue, 13 Nov 2007 10:20:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Tue, 13 Nov 2007 10:20:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-consent-framework-03.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : A Framework for Consent-based Communications in the Session Initiation Protocol (SIP)
	Author(s)       : J. Rosenberg, et al.
	Filename        : draft-ietf-sip-consent-framework-03.txt
	Pages           : 31
	Date            : 2007-11-13

The Session Initiation Protocol (SIP) supports communications across
many media types, including real-time audio, video, text, instant
messaging, and presence.  In its current form, it allows session
invitations, instant messages, and other requests to be delivered
from one party to another without requiring explicit consent of the
recipient.  Without such consent, it is possible for SIP to be used
for malicious purposes, including amplification, and DoS (Denial of
Service) attacks.  This document identifies a framework for consent-
based communications in SIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-03.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-consent-framework-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-consent-framework-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-13101246.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-consent-framework-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-consent-framework-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-13101246.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Tue Nov 13 14:51:36 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Is1nG-000728-K4; Tue, 13 Nov 2007 14:51:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Is1nF-0006u9-4l
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 14:51:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1nD-0006jy-HT
	for sip@ietf.org; Tue, 13 Nov 2007 14:51:28 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is1nA-0001uS-2h
	for sip@ietf.org; Tue, 13 Nov 2007 14:51:27 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lADJpLq01232; Tue, 13 Nov 2007 19:51:21 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt
Date: Tue, 13 Nov 2007 13:50:47 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF13290B22@zrc2hxm0.corp.nortel.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt
Thread-Index: Acgk8V2fHCbxxXT4SyStlu+ehCy3BQBOzXCA
References: 
From: "Francois Audet" 
To: , "Jason Fischl" ,
	, 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: Flemming Andreasen 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

(copying Flemming)

Good draft. Very helpful.

On the SDP side of things.

I didn't seen anything in the SDP format that specifically indicated in =
the offer that=20
you are trying to setup DTLS-SRTP.

Is the assumption that if there is no indication besides the RTP/SAVP in =
the tcap, that
DTLS-SRTP may be negotiated, and that therefore we do not need an =
explicit indication
that DTLS-SRTP is supported?

Do we think it's good enough? In other words, is RTP/SAVP without =
a=3Dcrypto or a=3Dkey-mgmt=20
good enough to indicate DTLS-SRTP? Or should we have another attribute?

A side comment is that the example shows usage with Best-Effort SRTP. My =
take is
that it could also be used in "DTLS-SRTP-always" mode by having the =
m-line
use UDP/TLS/RTP/AVP instead of RTP/AVP and not using a a=3Dtcap/a=3Dpcfg =
line. It
would probably be worthwile to describe it in the draft.


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 13 15:15:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Is2Ai-000189-Fy; Tue, 13 Nov 2007 15:15:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Is2AY-0000dp-NO
	for sip-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 15:15:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Is2AY-0000d9-7Y; Tue, 13 Nov 2007 15:15:34 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Is2AW-0006C6-84; Tue, 13 Nov 2007 15:15:34 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0B2C42AC79;
	Tue, 13 Nov 2007 20:15:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Is2A1-0000ZT-Ju; Tue, 13 Nov 2007 15:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Tue, 13 Nov 2007 15:15:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-record-route-fix-01.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Addressing Record-Route issues in the Session Initiation Protocol (SIP)
	Author(s)	: T. Froment, C. Lebel
	Filename	: draft-ietf-sip-record-route-fix-01.txt
	Pages		: 26
	Date		: 2007-11-13
	
A typical function of a Session Initiation Protocol (SIP) Proxy is to
   set a Record-Route header on initial requests in order to make
   subsequent requests pass through it.  This header contains a SIP
   Uniform Resource Identifier (URI) indicating where and how the
   subsequent requests should be sent to reach the proxy.  Like any SIP
   URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and
   URI parameters that could influence the routing like different
   transport parameters (UDP, TCP, SCTP...), or a compression indication
   like "comp=sigcomp".  When a proxy has to change some of those
   parameters between its incoming and outgoing interfaces (multi-homed
   proxies, transport protocol switching, sip to sips or IPV4 to IPV6
   scenarios...), the question arises on what should be put in Record-
   Route header(s).  It is just not possible to make one header having
   the characteristics of both sides at the same time.  This document
   aims to clarify these scenarios and fix bugs already identified on
   this topic; it formally recommends the use of the double Record-Route
   technique as an alternative to the current RFC3261 text, which only
   describes Record-Route rewriting solution.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sip-record-route-fix-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-record-route-fix-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-13140219.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-record-route-fix-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-record-route-fix-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-13140219.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--






From sip-bounces@ietf.org Wed Nov 14 00:12:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsAXz-0001RS-MS; Wed, 14 Nov 2007 00:12:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsAXx-0001NT-Ts
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 00:12:17 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsAXx-0001MI-HO; Wed, 14 Nov 2007 00:12:17 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IsAXw-0002mn-TM; Wed, 14 Nov 2007 00:12:17 -0500
X-IronPort-AV: E=Sophos;i="4.21,413,1188802800"; 
   d="scan'208";a="100314"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 13 Nov 2007 21:12:16 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAE5CGjp025725; 
	Tue, 13 Nov 2007 21:12:16 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lAE5CBFn002005;
	Wed, 14 Nov 2007 05:12:11 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 13 Nov 2007 21:12:11 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 13 Nov 2007 21:12:10 -0800
Message-ID: <473A83C9.6030509@cisco.com>
Date: Wed, 14 Nov 2007 00:12:41 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "DRAGE, Keith \(Keith\)" 
References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com><4729E458.6030703@cisco.com><1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com>
	<472A3B25.7090008@cisco.com>
	<5D1A7985295922448D5550C94DE2918001886B88@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE2918001886B88@DEEXC1U01.de.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2007 05:12:10.0968 (UTC)
	FILETIME=[E929A580:01C8267C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3916; t=1195017136;
	x=1195881136; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[RAI]=20RAI=20review=20of=20draft-ietf-sip-hitchhiker
	s-guide-03 |Sender:=20;
	bh=pWaJ0zvP09pUDSCP1I+mtY14VvwTD+NvibJX7KyOw5s=;
	b=xlC1jeUru3uIReT+8oSA9yD2Wxw86osO9nrGHqSkWex3A5brT/WoFCpsOc+gCZ1dTz6Ufjxx
	ThFGRRRk33nbAKvFM8Ka9az2b9y21Qj4Dj39q0zwTU/FM4o1YL9VUb92;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: sip@ietf.org, Avshalom Houri ,
	Francois Audet , rai@ietf.org
Subject: [Sip] Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Keith,

I'm in the process of trying to revise this before the cutoff on Monday.
  I don't agree with one of your points below:

DRAGE, Keith (Keith) wrote:
> I guess I got this wrong.
> 
> My starting point was a misinterpretation of Jonathan's indication
> way back that we were waiting for outbound, gruu and ice before we
> pushed this forward.

Right, which I meant as, we won't send this off to IESG until those 
drafts are done.

> 
> Having thought about this some more:
> 
> -	Yes we should include internet drafts, but with some sort of
> explanation that they are included to encourage early implementation
> and demonstrations of interoperability of the protocol, and thus aid
> in the standards setting process; also that they identify were the WG
> is targetting a solution at a particular problem space and thus aid
> work towards a common solution. Additionally a warning that final
> IANA assignment of codepoints does not take place until shortly
> before publication, and thus codepoint assignments may change.

I will add such a warning.

> 
> -	No we should not automatically include all WG drafts, but should
> assert some form of expert review. We seem to have somewhere up to
> 25% of working group documents that never make it to completion, and
> another fair average that still are not going to be there in the the
> next 3 years, judging by past performance. We are never obviously
> going to get this 100% right, and I don't think we should spill any
> blood arguing about the inclusion or exclusion of any draft, but I do
> think we should attempt to preguess this and miss some of these out.
> We want the market to try out the drafts in the document, but not get
> put off by us marketing to them something that will never fulfil
> their product timescales.

I disagree here. Pretty much the only thing in this draft that got 
discussed, and agreed upon, was the criteria for draft inclusion. I 
really want that criteria to be objective, so we don't need to debate 
and whine on every single document. This criteria we spelled out is 
captured in the document and it says:



Any specification that defines an extension to SIP
itself, where an extension is a mechanism that changes or updates in
some way a behavior specified in RFC 3261


Any specification that defines an extension to SDP whose primary
purpose is to support SIP


Any specification that defines a MIME object whose primary purpose
is to support SIP





Excluded from this list are
requirements, architectures, registry definitions, non-normative
frameworks, and processes. Best Current Practices are included when
they normatively define mechanisms for accomplishing a task.



I really do not want to revisit this. Based on these rules, I have been 
adding every working group document that meets the criteria above. Period.


> 
> -	Yes we should include some author drafts, probably on the basis
> that an AD has sponsored them, or is about to sponsor them, through
> the IESG, and certainly if they have reached the RFC editor's queue.

As long as they are AD-sponsored and meet the criteria above, they 
should be included. However I am not aware of a single author draft that 
meets the above criteria which is AD-sponsored. Indeed I believe the SIP 
change process would require a SIP WG item for anything that extends 
SIP. If you are aware of any author drafts that meet the criteria above 
please let me know.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 01:18:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsBZc-0006eJ-Hi; Wed, 14 Nov 2007 01:18:04 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsBZY-0006UE-Q4
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 01:18:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsBZY-0006R9-1w; Wed, 14 Nov 2007 01:18:00 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsBZS-0006g6-Cq; Wed, 14 Nov 2007 01:17:59 -0500
X-IronPort-AV: E=Sophos;i="4.21,414,1188802800"; d="scan'208";a="186553015"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-5.cisco.com with ESMTP; 13 Nov 2007 22:17:53 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAE6Hrie029947; 
	Tue, 13 Nov 2007 22:17:53 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lAE6HNYq012577;
	Wed, 14 Nov 2007 06:17:48 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 13 Nov 2007 22:17:41 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 13 Nov 2007 22:17:40 -0800
Message-ID: <473A9323.3010609@cisco.com>
Date: Wed, 14 Nov 2007 01:18:11 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Brian Stucker 
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2007 06:17:40.0931 (UTC)
	FILETIME=[0F9A6930:01C82686]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15852; t=1195021073;
	x=1195885073; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20RAI-ART=20Review=20Comments=20for=20draft-ietf-sip-hi
	tchhikers-guide |Sender:=20;
	bh=XDkdxZqKfx6MMQg8kizDuvx9KnnjJ3KOKx4CZmwgZBU=;
	b=mlt6nvYed/CC9fpYb8RP79syFuX3D+jAvH9/BuC35EFlIjK/Y7uJ1Scl3jJv5cBSmRrXdfql
	OqsYjQ2IeVyrlHA2hR0GHS3NkgCigHanYbfh1bQAPahqfmrJjz+sv6qO;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31
Cc: sip , rai@ietf.org
Subject: [Sip] Re: RAI-ART Review Comments for
	draft-ietf-sip-hitchhikers-guide
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Thanks for the detailed review. Responses below:

Brian Stucker wrote:
> Jonathan,
> 
> Thanks for putting the document together. It took quite awhile to just
> review it! 
> 
> Here are the comments that I have as part of the RAI-ART review of the
> document. Apologies for the probable repeats in here from list comments,
> I was not able to try to correlate my comments with others on the
> various reflectors.
> 
> I tried to break my comments up by section and document so hopefully
> it's coherent in plain-text.
> 
> Regards,
> Brian
> 
> ----
> 
> Section 1:
> 
> 
>    This document itself is not an update to RFC 3261
>   or an extension to
>    SIP.  It is an informational document, meant to guide newcomers,
>    implementors and deployers to the SIP suite of specifications.
> 
> May want to change "meant to guide newcomers, implementors and deployers
> to the SIP suite of specifications" since many of the documents are not
> predicated upon SIP itself. For example, RFC-4566, 3388, 3264. Also, I
> don't think we want to imply that this document is exhaustive. Perhaps
> "It is an information document, meant to introduce newcomers,
> implementors and deployers to many of the important IETF specifications
> associated with SIP. Specifications referenced by this document were
> chosen based on working group consensus and the list presented here is
> not intended to be exhaustive or confer any special status over
> documents not included."

Actually this is not true. The next section provides a concrete criteria 
for inclusion. This is a criteria that was discussed on the mailer and 
in meetings. The idea is NOT to have, on a doc by doc basis, discussion 
and consensus on whether to include it.

I changed the wording in the last sentence to "It is an informational 
document, meant to guide newcomers,
implementors and deployers to the many of the specifications
associated with SIP."

> 
> Might also want to include some pointers to the relevant WG webpages to
> give newcomers a place to go for further information. As well as include
> some boilerplate about the dangers of implementing I-D's before they
> become RFCs (I think this was already discussed somewhat on the RAI
> mailing list).

I'll add the warning per Keiths comment. I'm not sure that the web links 
bring any value in an era of Google.


> 
> 
> 
> Section 2:
> 
> 	Although I agree that documents defining relevant registries
> should be excluded, what about pointers to the registries themselves?
> Seems like some of the interop problems we wind up with are due to
> disregard or lack of visibility of the IANA registration process to
> implementors.

This document isn't meant to be the cure for the interop problems of 
SIP. Its scope is to help people understand what specs form "SIP" and 
what they are for. Thats it. That includes registry references. I am 
going to stick hard to the original scope of this document.

> 
> 
> Section 3:
> 
> RFC3261: 
> 
> 	I think it would be useful to provide a reverse-lookup list of
> RFCs that formally update 3261 under the 3261 entry: RFC-3583, RFC-4320
> and RFC-4916. There is a statement under 4320 that it formally updates
> 3261, but there is no mention under 4916 that it formally updates 3261,
> it just looks like any other extension. Putting a pointer to the SIPS
> work as a TBD formal update to 3261 would also be good as well as
> collapsing the "essential corrections to SIP" under the 3261 entry so
> that people don't skip over that material would be good as well.

I disagree with this. I think the IETF's view of what is an 'update' vs. 
an 'extension' is academic for implementors. I think its worth noting so 
there is no surprise, but I don't want this long list of things which 
"are" 3261 when they each have their own RFC number.

Essential corrections is already listed in the core specifications list 
so I am not worried about it being missed.

I will mention in the sections on 3853, 4320, 4916 that they formally 
update 3261.

> 
> RFC3264:
> 
> 	Should we perhaps put a pointer here to the offer/answer draft
> for further clarification of 3264 since it seems pretty clear that the
> baseline specification did not entirely capture all of the interactions
> that arise in implementations?

That document is informational. It is meant as a clarification to 
rfc3264. The scope of the hitchhikers document doesn't include such 
documents. If you want to further expand the scope to include documents 
that are informational clarifications, please post a note to sip and 
raise this as proposed scope change for hitchhikers. As I said above 
though, I disagree with any proposed increases in scope beyond our 
original agreed set.

> 
> RFC3325:
> 
> 	May want to remove the word "secure" from the description of the
> P-Asserted-ID header description. P-Asserted-ID does not confer any
> security of the caller ID information. It's the trust domain that
> provides the security in contrast to a mechanism like RFC-4474. 

Changed to "network asserted".


> 
> RFC3581:
> 
> 	Rport is necessary to routing a response through a NAT, but does
> not solve NAT traversal for SIP signaling. Perhaps a pointer to outbound
> under this RFC would be useful to highlight what you don't get with
> rport that you need to fully address NAT traversal issues, or simply
> remove it entirely and rely on folks to go to the NAT traversal section
> to discover it there as it's not necessary at all if you have no NATs to
> traverse (ALGs and SBCs aside).

I removed and added a pointer to the section.

> 
> RFC4474:
> 
> 	I don't think it's necessary that we should highlight the
> deployment size of the various RFCs in this way, especially given that
> the RFC is much newer (and has more complicated requirements) than
> RFC3325.

Well, we'll be revising the hitchhikers guide every year or so. Should 
this statement no longer be true we can adjust it.

> 
> SIPS:
> 
> 	Should note that this will formally update RFC3261 when approved
> to highlight that newcomers should ignore what's in RFC3261.

OK.


> 
> 
> 
> Section 4:
> 
> RFC2848/3910:
> 
> 	If this has seen little deployment and is very narrowly scoped,
> then why are we including it in the guide? 

Because they are extensions and that is the scope of hitchhikers.

> 
> RFC3372:
> 
> 	Widespread implementation in a limited deployment model. It
> should be noted that it's usage is intended to be temporary as ISUP
> endpoints are obviated from the network.

OK.

> 
> RFC3960:
> 
> 	Early media is not just generated by the PSTN. We should be fair
> here and acknowledge that 3960 does not solve all of the various issues
> associated with early media (without enumerating them). We all know this
> to be the case, so just a sentence or two should suffice to warn the
> reader.

Added:

Early media
   is a complex topic, and this specification does not fully address
   the problems associated with it.


> 
> RFC3959:
> 
> 	We should highlight that this specification has not seen
> widespread deployment. As of a few IETFs ago nobody indicated that they
> had developed anything with regards to this specification when asked at
> a working group meeting. This is only important in that 3960 does not
> solve all of the early media issues.

Mentioned.

> 
> 
> Shouldn't we have an entry in this section for RFC3966 to cover tel
> URIs?
> 

No. It does not meet the defined scope:

* SIP extensions
* MIME objects just for SIP
* SDP stuff just for SIP

> 
> 
> Section 5:
> 
> RFC3262:
> 
> 	PRACK is complicated, for sure, but it's used for more than just
> PSTN interworking and is more than mildly deployed depending upon the
> environment.

Agree its not just there; the draft says that was the origin of it, and 
that it is 'most common' in PSTN interworking devices. I believe this to 
be true. I'll change "mild" to "moderate".

> 
> RFC3311:
> 
> 	..but can be used to initiate a reliable request during session
> establishment when a re-INVITE is not possible. This is key for
> conveying information to an originator that cannot be conveyed in a
> response either due to offer/answer complications or because a header is
> not allowed in a response message type. We should also point out here
> that when UPDATE is used to convey SDP, support for RFC3262 is required
> in some scenarios. I don't think this is widely recognized. Should also
> call out that it can be used to convey mid-call information as well.

changed to:

RFC 3311  defines the UPDATE method for SIP. This method is
meant as a means for updating session information prior to the
completion of the initial INVITE transaction. It can also be used to
   update other information, such as the identity of the participant
   ,
   without involving an updated offer/answer exchange. It was developed
initially to support RFC 3312  but has found
   other uses.



> 
> RFC3608:
> 
> 	You've captured the client perspective of the usage of
> service-route, but from a server perspective, it's used by proxies to
> capture the route set of a registration to know how to route future
> requests on behalf of the client. In this role it has seen greater
> deployment and applicability.

I assume you mean the 3gpp route set validation based on service route? 
Not sure what else you might mean by "capture route set of a 
registration to know how to route future requests". The route header 
field in client requests is used to route future requests.

In terms of DEPLOYMENT of this, if you mean the 3gpp stuff there is 
little deployment so far so I think my statement remains accurate.

> 
> RFC 3841:
> 
> 	Should probably call out the relationship between this RFC and
> 3840.

ok

> 
> Need to remove duplicate entry for SDP negotiation under PSTN
> interworking.

which duplicate entry?

> 
> RFC4244:
> 
> 	Should remove reference to voicemail here. It has broader scope.
> RFC4758 is intended for this purpose now (later comment).

Hmm, well I didn't think there had been WG consensus to use 4458 for 
voicemail over 4424 - thats why it got published as informational (and 
indeed it was an individual submission IIRC).

I agree it is more broad but its original target and most common usage 
AFAIK remains voicemail. Suggest:

came to be routed to a particular destination. Its primary application
was in support of voicemail services though it has more broad
   applicability. 


> 
> 
> Shouldn't we have an entry in this section for RFC3880, CPL?

No, it doesn't meet the scope of this document:

* SIP extensions
* MIME objects just for SIP
* SDP stuff just for SIP

> 
> 
> 
> Section 6:
> 
> RFC3605:
> 
> 	Should this be here and under the core specifications section? I
> don't see this attribute show up in SDP very often (pre-ICE), but it is
> necessary for some NAT traversal solutions. Perhaps only have a
> reference to it here? Outside of NAT traversal, is there a primary
> reason to have this RFC or ICE in the core specifications section?

The spec says that certain docs get listed in multiple areas for 
convenience.

It appears in the core specs because of the formal definition of core specs:


The core SIP specifications represent the set of specifications whose
functionality is broadly applicable. An extension is broadly
applicable if it fits into one of the following categories:




For specifications that impact SIP session management, the
extension would be used for almost every session initiated by a user
agent


For specifications that impact SIP registrations, the extension
would be used for almost every registration initiated by a user agent


For specifications that impact SIP subscriptions, the extension
would be used for almost every subscription initiated by a user agent




Our intention with ICE is that a client should always be using it; the 
majority of deployments involve at least one endpoint that MIGHT have a 
NAT issue, and thus ICE gets used. WHen ICE is used 3605 comes along for 
the ride.

> 
> OUTBOUND:
> 
> 	Doesn't outbound satisfy the requirements of a broadly
> applicable extension to SIP? Seems like if ICE is a core specification,
> that OUTBOUND should be considered one as well?

Yes, and it is listed there.

> 
> RFC3890:
> 
> 	It's used extensively in other SDOs, paricularly wireless.


Well, defined by an SDO is not the same as deployed. But anyway I'll 
remove the statement in this case since its a minor spec in any case.

> 
> RFC4730:
> 
> 	Should probably explain here briefly, that 2833/4733 is most
> commonly used to convey DTMF for SIP deployments, but the difference is
> that KPML does it on the signaling path as opposed to the media path.
> This is somewhat important given the low current deployment of KPML.

OK.

> 
> 
> 
> Section 13:
> 
> 	Perhaps we should add an entry here for RFC4896 or make a note
> under the entry for RFC3486 that RFC4896 updates both RFC3486 and
> RFC3485 which is the static dictionary for SIP (which provides the
> explicit coupling between SIGCOMP and SIP eluded to in the draft text).
> The important bit for an entry to RFC3485 is that there are a few bugs
> in the dictionary such that you'd need to refer to section 12 of RFC4896
> to come up with a BCP implementation.

I added 4896.
3486 doesn't meet the scope of hitchhikers:

* SIP extensions
* MIME objects just for SIP
* SDP stuff just for SIP

> 
> 
> 
> Section 14:
> 
> I think we should add an entry for RFC4758 to capture the voicemail
> service URI as another important service URI RFC.

added.

> 
> 
> Section 15:
> 
> RFC3853:
> 
> 	May want to state that RFC3853 'formally' updates RFC3261, and
> put a pointer to this from the core specifications section as a result
> since it's a correction to 3261.

Update noted.
However its not core since SMIME is not used in every call. See above 
for the definition of a core spec. Just because a document updates SIP 
does not make it a core spec.

> 
> RFC3893:
> 
> 	Should RFC3893 entry simply say something to the effect of 'use
> RFC4474', or be dropped altogether?

It basically does say that.

> 
> RFC3329:
> 
> 	There are now three possible security models now in 3GPP: HTTP
> DIGEST, AKA, and early-IMS. As early-IMS doesn't really involve much in
> the way of security mechanisms within the SIP protocol, the coexistance
> of it with digest or AKA seems to be very probable. Perhaps we should
> just remove the last sentence and leave it up to the reader to decide if
> it's needed for their purpose.

I think this is a useful piece of guidance. I know I have answered this 
question many times about whether this feature is needed.

> 
> 
> 
> Section 16:
> 
> Shouldn't we perhaps move RFC4796 from section 7 to this section?

Why?

> 
> 
> Section 17:
> 
> Providing a pointer off to ECRIT seems useful here.

That scope comment again.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 01:20:15 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsBbi-00039s-9i; Wed, 14 Nov 2007 01:20:14 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsBbg-00034J-Cg
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 01:20:12 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsBbg-00033G-0S; Wed, 14 Nov 2007 01:20:12 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IsBbf-0004UR-HU; Wed, 14 Nov 2007 01:20:11 -0500
X-IronPort-AV: E=Sophos;i="4.21,414,1188802800"; 
   d="scan'208";a="12431"
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-1.cisco.com with ESMTP; 13 Nov 2007 22:20:10 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAE6KAXv028173; 
	Tue, 13 Nov 2007 22:20:10 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lAE6K8Ye013467;
	Wed, 14 Nov 2007 06:20:08 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 13 Nov 2007 22:20:08 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 13 Nov 2007 22:20:07 -0800
Message-ID: <473A93B6.1030405@cisco.com>
Date: Wed, 14 Nov 2007 01:20:38 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Peter Saint-Andre 
Subject: Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
	<4733A781.7020906@stpeter.im>
In-Reply-To: <4733A781.7020906@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2007 06:20:07.0904 (UTC)
	FILETIME=[6734B600:01C82686]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2184; t=1195021210;
	x=1195885210; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20RAI-ART=20Review=20Comments=20for=20draft-iet
	f-sip-hitchhikers-guide |Sender:=20;
	bh=JZZouCnUBcIGZP6X1PuKHCrkm4L2I2InwQuaJRYTLJk=;
	b=dGcmISzqAFHsA8LrEBGBb2XufZh2RLoFH4JN4M8Ox9dPZfaosJermJ6cllTml92oqj9l6Igi
	e1nmTekkBCIiwOMGF8Sz6BVos4qbQDWJcnC1rz+rhGxnXTzPkwPFQPR6;
Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: sip , rai@ietf.org, Brian Stucker 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

The call flow documents do not meet the current criteria defined by 
hitchhikers for inclusion. That criteria is:

    It is very difficult to enumerate the set of SIP specifications.
    This is because there are many protocols that are intimately related
    to SIP and used by nearly all SIP implementations, but are not
    formally SIP extensions.  As such, this document formally defines a
    "SIP specification" as:

    o  Any specification that defines an extension to SIP itself, where
       an extension is a mechanism that changes or updates in some way a
       behavior specified in RFC 3261

    o  Any specification that defines an extension to SDP whose primary
       purpose is to support SIP

    o  Any specification that defines a MIME object whose primary purpose
       is to support SIP


Example call flows do not meet this criteria.

-Jonathan R.

Peter Saint-Andre wrote:
> Brian Stucker wrote:
> 
> 
> 
> Sorry to hijack this thread, but I'd like to second a comment that Mary
> Barnes made during the WGLC:
> 
> http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html
> 
> ***
> 
> It seems that all the call flow BCPs are missing and I do think those
> are really important and should be included in this document.  The only
> BCP (type (B) document) listed in this document is 3PCC.  The basic call
> flow document (RFC 3665) should be listed in section 3 (Core SIP).  The
> PSTN call flows (RFC 3666, BCP 76) should be in PSTN Interworking
> section 4. The SIPPING NAT scenarios document should be in the NAT
> section 6.  These docs are all icing on the cake IMHO and help to guide
> implementers in using all the other docs.
> 
> ***
> 
> I agree that the call flow documents are very useful and that a
> reference to them would be a good thing.
> 
> Peter

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 07:14:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsH89-0006jt-GN; Wed, 14 Nov 2007 07:14:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsH88-0006gd-9n
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 07:14:04 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsH86-0006fs-Jx
	for sip@ietf.org; Wed, 14 Nov 2007 07:14:03 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsH86-0007SL-DG
	for sip@ietf.org; Wed, 14 Nov 2007 07:14:02 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns4.neustar.com (Postfix) with ESMTP id 522E72AC69;
	Wed, 14 Nov 2007 12:13:32 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IsH7c-0002ST-3L; Wed, 14 Nov 2007 07:13:32 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: munakata.mayumi@lab.ntt.co.jp
From: IETF I-D Submission Tool 
Message-Id: 
Date: Wed, 14 Nov 2007 07:13:32 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: sip@ietf.org
Subject: [Sip] New Version Notification for draft-ietf-sip-ua-privacy-00 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-ua-privacy-00.txt has been successfuly submitted by Mayumi Munakata and posted to the IETF repository.

Filename:	 draft-ietf-sip-ua-privacy
Revision:	 00
Title:		 UA-Driven Privacy Mechanism for SIP
Creation_date:	 2007-11-12
WG ID:		 sip
Number_of_pages: 10

Abstract:
To withhold a user's identity and related information, RFC 3323
defines a Privacy mechanism for SIP, which requires the use of an
privacy service.  This document proposes a new privacy mechanism that
a user agent can facilitate to conceal privacy-sensitive information
without the need for aid from a privacy service.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 07:20:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsHDx-0004gO-Sr; Wed, 14 Nov 2007 07:20:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsHDv-0004fs-Pc
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 07:20:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsHDv-0004fc-FD; Wed, 14 Nov 2007 07:20:03 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsHDu-0007Pf-FS; Wed, 14 Nov 2007 07:20:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 57B6C26E86;
	Wed, 14 Nov 2007 12:20:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IsHDu-00037c-8d; Wed, 14 Nov 2007 07:20:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Wed, 14 Nov 2007 07:20:02 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-ua-privacy-00.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : UA-Driven Privacy Mechanism for SIP
	Author(s)       : M. Munakata, et al.
	Filename        : draft-ietf-sip-ua-privacy-00.txt
	Pages           : 10
	Date            : 2007-11-12

To withhold a user's identity and related information, RFC 3323
defines a Privacy mechanism for SIP, which requires the use of an
privacy service.  This document proposes a new privacy mechanism that
a user agent can facilitate to conceal privacy-sensitive information
without the need for aid from a privacy service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-ua-privacy-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-ua-privacy-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-14071330.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-ua-privacy-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-ua-privacy-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-14071330.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Wed Nov 14 09:51:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsJag-0005o8-EP; Wed, 14 Nov 2007 09:51:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsJaf-0005mE-6v
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 09:51:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsJae-0005lV-PU; Wed, 14 Nov 2007 09:51:40 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsJab-0000yB-GX; Wed, 14 Nov 2007 09:51:40 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lAEEpT022833; Wed, 14 Nov 2007 14:51:29 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
Date: Wed, 14 Nov 2007 08:48:42 -0600
Message-ID: 
In-Reply-To: <473A93B6.1030405@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RAI-ART Review Comments for
	draft-ietf-sip-hitchhikers-guide
Thread-Index: Acgmhm/BplAj/O+pQsaU5SDXsWEN2AAQyyYA
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
	<4733A781.7020906@stpeter.im> <473A93B6.1030405@cisco.com>
From: "Mary Barnes" 
To: "Jonathan Rosenberg" ,
	"Peter Saint-Andre" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: sip , rai@ietf.org, Brian Stucker 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Jonathan,
 =20
I honestly think that not having the call flows, which are BCPs, leaves
a huge gap in the document.  And, I think not having them is contrary to
these statements in the hitchiker's guide (from the intro):
   "It is an informational document, meant to guide newcomers,
    implementors and deployers to the SIP suite of specifications."
And  (in the paragraph following the text you extracted):=20
   "Best Current Practices are included when they normatively define
mechanisms for
   accomplishing a task."

IMHO, that is the case with all the call flow BCPs, per the basic
definition of BCP in RFC 2026:

   A BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

At a minimum,  basic call flows fits into this category because the ones
in RFC 3261 are not comprehensive.=20
If we don't tell newcomers about the call flows in this document, they
will likely miss them, since the whole point of this document is to help
them navigate the specs. It would be okay of the call flows were
referenced in the other documents, since more astute developers would
have the sense to look at referenced docs, as well, many of them are not
referenced. For example, the only document that seems to reference basic
call flows is RFC 4083 (3GPP requirements).  If the reluctance to
include the call flow BCPs is a concern that they no longer reflect
"Best" current practices, then we need to start updating those documents
or we need to obsolete them. =20

I also just noticed that one BCP that wasn't mentioned yet was RFC 4579.
It would be difficult to figure out how to put together a SIP based
conferencing implementation based only on the other docs in section 8
(conferencing) without the call flow document. =20

Regards,
Mary.=20

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
Sent: Wednesday, November 14, 2007 12:21 AM
To: Peter Saint-Andre
Cc: sip; rai@ietf.org; Stucker, Brian (RICH1:AR00)
Subject: Re: [Sip] RAI-ART Review Comments for
draft-ietf-sip-hitchhikers-guide

The call flow documents do not meet the current criteria defined by
hitchhikers for inclusion. That criteria is:

    It is very difficult to enumerate the set of SIP specifications.
    This is because there are many protocols that are intimately related
    to SIP and used by nearly all SIP implementations, but are not
    formally SIP extensions.  As such, this document formally defines a
    "SIP specification" as:

    o  Any specification that defines an extension to SIP itself, where
       an extension is a mechanism that changes or updates in some way a
       behavior specified in RFC 3261

    o  Any specification that defines an extension to SDP whose primary
       purpose is to support SIP

    o  Any specification that defines a MIME object whose primary
purpose
       is to support SIP


Example call flows do not meet this criteria.

-Jonathan R.

Peter Saint-Andre wrote:
> Brian Stucker wrote:
>=20
> 
>=20
> Sorry to hijack this thread, but I'd like to second a comment that=20
> Mary Barnes made during the WGLC:
>=20
> http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html
>=20
> ***
>=20
> It seems that all the call flow BCPs are missing and I do think those=20
> are really important and should be included in this document.  The=20
> only BCP (type (B) document) listed in this document is 3PCC.  The=20
> basic call flow document (RFC 3665) should be listed in section 3=20
> (Core SIP).  The PSTN call flows (RFC 3666, BCP 76) should be in PSTN=20
> Interworking section 4. The SIPPING NAT scenarios document should be=20
> in the NAT section 6.  These docs are all icing on the cake IMHO and=20
> help to guide implementers in using all the other docs.
>=20
> ***
>=20
> I agree that the call flow documents are very useful and that a=20
> reference to them would be a good thing.
>=20
> Peter

--=20
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 10:52:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsKX8-0000IH-PW; Wed, 14 Nov 2007 10:52:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsKX7-0000Em-8e
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:52:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsKX6-0000EE-R1; Wed, 14 Nov 2007 10:52:04 -0500
Received: from exprod6og50.obsmtp.com ([64.18.1.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsKX3-00082e-TQ; Wed, 14 Nov 2007 10:52:04 -0500
Received: from source ([192.150.20.142]) by exprod6ob50.postini.com
	([64.18.5.12]) with SMTP; Wed, 14 Nov 2007 07:51:48 PST
Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236])
	by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
	lAEFpjKn020417; Wed, 14 Nov 2007 07:51:46 -0800 (PST)
Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99])
	by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id
	lAEFpiFV013000; Wed, 14 Nov 2007 07:51:45 -0800 (PST)
Received: from namail5.corp.adobe.com ([10.8.192.88]) by
	apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Nov 2007 00:51:43 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [RAI] RE: [Sip] RAI-ART Review Comments
	fordraft-ietf-sip-hitchhikers-guide
Date: Wed, 14 Nov 2007 07:51:31 -0800
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2AA@namail5.corp.adobe.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [RAI] RE: [Sip] RAI-ART Review Comments
	fordraft-ietf-sip-hitchhikers-guide
Thread-Index: Acgmhm/BplAj/O+pQsaU5SDXsWEN2AAQyyYAAAKztXA=
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com><4733A781.7020906@stpeter.im>
	<473A93B6.1030405@cisco.com>
	
From: "Henry Sinnreich" 
To: "Mary Barnes" ,
	"Jonathan Rosenberg" ,
	"Peter Saint-Andre" 
X-OriginalArrivalTime: 14 Nov 2007 15:51:43.0505 (UTC)
	FILETIME=[40FA2010:01C826D6]
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Cc: sip , rai@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I fully agree with Mary and wish we would have similar call flow
examples for SIMPLE as well instead of a guide only.=20

The hitch-hikers guides without references to (1) call flow examples and
yes, (2) OS code seems like a band-aid instead of the real thing.

Call flow examples and OS code are IMHO the only proof the guides are
anchored in reality. Example: IETF meetings use Jabber instead of SIMPLE
and no guide will change this fact.

This makes me question the usefulness of these hitchhikers guides for
SIP and SIMPLE, unless they have references to call flow examples and OS
code or similar.=20

I suggest both guides for SIP and SIMPLE to be re-edited with such
references.

Thanks, Henry

-----Original Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]=20
Sent: Wednesday, November 14, 2007 6:49 AM
To: Jonathan Rosenberg; Peter Saint-Andre
Cc: sip; rai@ietf.org
Subject: [RAI] RE: [Sip] RAI-ART Review Comments
fordraft-ietf-sip-hitchhikers-guide

Jonathan,
 =20
I honestly think that not having the call flows, which are BCPs, leaves
a huge gap in the document.  And, I think not having them is contrary to
these statements in the hitchiker's guide (from the intro):
   "It is an informational document, meant to guide newcomers,
    implementors and deployers to the SIP suite of specifications."
And  (in the paragraph following the text you extracted):=20
   "Best Current Practices are included when they normatively define
mechanisms for
   accomplishing a task."

IMHO, that is the case with all the call flow BCPs, per the basic
definition of BCP in RFC 2026:

   A BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

At a minimum,  basic call flows fits into this category because the ones
in RFC 3261 are not comprehensive.=20
If we don't tell newcomers about the call flows in this document, they
will likely miss them, since the whole point of this document is to help
them navigate the specs. It would be okay of the call flows were
referenced in the other documents, since more astute developers would
have the sense to look at referenced docs, as well, many of them are not
referenced. For example, the only document that seems to reference basic
call flows is RFC 4083 (3GPP requirements).  If the reluctance to
include the call flow BCPs is a concern that they no longer reflect
"Best" current practices, then we need to start updating those documents
or we need to obsolete them. =20

I also just noticed that one BCP that wasn't mentioned yet was RFC 4579.
It would be difficult to figure out how to put together a SIP based
conferencing implementation based only on the other docs in section 8
(conferencing) without the call flow document. =20

Regards,
Mary.=20

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
Sent: Wednesday, November 14, 2007 12:21 AM
To: Peter Saint-Andre
Cc: sip; rai@ietf.org; Stucker, Brian (RICH1:AR00)
Subject: Re: [Sip] RAI-ART Review Comments for
draft-ietf-sip-hitchhikers-guide

The call flow documents do not meet the current criteria defined by
hitchhikers for inclusion. That criteria is:

    It is very difficult to enumerate the set of SIP specifications.
    This is because there are many protocols that are intimately related
    to SIP and used by nearly all SIP implementations, but are not
    formally SIP extensions.  As such, this document formally defines a
    "SIP specification" as:

    o  Any specification that defines an extension to SIP itself, where
       an extension is a mechanism that changes or updates in some way a
       behavior specified in RFC 3261

    o  Any specification that defines an extension to SDP whose primary
       purpose is to support SIP

    o  Any specification that defines a MIME object whose primary
purpose
       is to support SIP


Example call flows do not meet this criteria.

-Jonathan R.

Peter Saint-Andre wrote:
> Brian Stucker wrote:
>=20
> 
>=20
> Sorry to hijack this thread, but I'd like to second a comment that=20
> Mary Barnes made during the WGLC:
>=20
> http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html
>=20
> ***
>=20
> It seems that all the call flow BCPs are missing and I do think those=20
> are really important and should be included in this document.  The=20
> only BCP (type (B) document) listed in this document is 3PCC.  The=20
> basic call flow document (RFC 3665) should be listed in section 3=20
> (Core SIP).  The PSTN call flows (RFC 3666, BCP 76) should be in PSTN=20
> Interworking section 4. The SIPPING NAT scenarios document should be=20
> in the NAT section 6.  These docs are all icing on the cake IMHO and=20
> help to guide implementers in using all the other docs.
>=20
> ***
>=20
> I agree that the call flow documents are very useful and that a=20
> reference to them would be a good thing.
>=20
> Peter

--=20
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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

_______________________________________________
RAI mailing list
RAI@ietf.org
https://www1.ietf.org/mailman/listinfo/rai


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 13:31:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsN14-0007ks-4T; Wed, 14 Nov 2007 13:31:10 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsN12-0007kD-Qc
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 13:31:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsN12-0007jx-FB
	for sip@ietf.org; Wed, 14 Nov 2007 13:31:08 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsN11-00023P-A4
	for sip@ietf.org; Wed, 14 Nov 2007 13:31:08 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Wed, 14 Nov 2007 13:31:06 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Wed, 14 Nov 2007 13:31:06 -0500
From: Hadriel Kaplan 
To: "sip@ietf.org" 
Date: Wed, 14 Nov 2007 13:31:05 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt 
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt 
Thread-Index: AcgQU884Olh/7kRRT9m3/089eJov1QFRFYEQA4EaZeAAE/2noA==
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Cc: Rohan Mahy , "vkg@acm.org" ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

[note: I have not read Dale's comments yet, so there may be repeats (I star=
ted drafting this before getting his email)]

Technical:
Sec 5.2: I am really confused why this section exists.  The whole doc keeps=
 repeating how TCP or SCTP alone (sans TLS) is not an appropriate connectio=
n for connection reuse, and indeed this section ultimately means the same. =
 So why is all the mechanics of this section in the doc?  Is there somethin=
g different about TCP connection handling in this than previously?  Why is =
it even added to the alias table, when its entry cannot be used for aliasin=
g?  This is quite confusing.  I recommend removing it.

Section 5.1, p.7: "P1 determines through RFC3263 server resolution process =
that the request should be sent to P2 on port 5061 using TLS..." and same t=
hing on page 8 for P2.  Now I'm no expert, but last time I checked I though=
t SRV's allowed defining the port number, so one did NOT need to use the we=
ll-known 5061 for TLS, but could use anything.  So why is this restricting =
alias use to 5061 only?

Sec 9.3, p.15: the argument used here against TCP or SCTP connect-reuse (sa=
ns TLS) is one of malware hijacking on a multi-user computer.  I don't find=
 that argument convincing, because I think it's a red herring.  If you have=
 a malware program running on a proxy responsible for a domain, you are in =
a world of hurt regardless. (You're rearranging the deck chairs on the Tita=
nic)  What *is* convincing is that without the certificate proof of identit=
y inherent in TLS, the mechanism as defined in this draft would let a compl=
etely different machine, from a different IP, pretend to represent a legit =
domain's proxy by simply putting in the Via and alias param.  That would be=
 bad.  And due to SCTP multi-homing coming from any IP, and load-balancing =
techniques and such, just restricting the source IP to avoid that problem w=
on't work universally.  *That* should be the text in the draft for why TLS =
is required, vs. the "malware" excuse.  I am only mentioning this because n=
ot allowing TCP or SCTP alone is a major detractor for this draft, so the e=
xplanations for why not need to be strong.

Sec 8.1, p.11: Regarding TCP/SCTP connections, it says "Subsequent requests=
 that resolve to the same IP address, port, and transport tuple MUST reuse =
the same connection."  Since when is that mandatory, and why?  There is no =
connection reuse for TCP/SCTP.  If I want to open two TCP connections to a =
server, for example due to head-of-line blocking or failure of previous, wh=
y can't I?  In fact, if I want to open two separate TLS connection why can'=
t I?  This should at least only be a SHOULD strength.

Sec 8.1, p.11: Further, next sentence says "It MUST only accept responses o=
ver this connection and MUST NOT accept any requests over this connection."=
  Why is that?  The far-end chose to send a request over an open connection=
.  It's definitely not clear that the far-end should have done so (nor how =
it would have resolved to do so), but is there anything wrong from a protoc=
ol perspective with the local end accepting it?  For example if the far-end=
 is manually configured to do so.

Sec 5.1, p.8 says: "The presence of the "alias" parameter indicates that P1=
 does support aliasing.  P2 now authenticates the connection (see Section 9=
.2) and if the authentication was successful, P2 creates an alias to P1 usi=
ng the advertised address in the topmost Via."  This implies a server-side =
authentication occurs for the initial TLS connection, the request is sent f=
rom P1 to P2, P2 sees the alias, and then P2 does a TLS renegotiation to ge=
t the client side's cert?  I think it's important to spell this out in the =
draft, because I'm not sure everyone supports this after the initial TLS ha=
ndshake is over (I think most mutual-TLS happens at the beginning in the re=
al world, but I could easily be wrong - IANAE).


Editorial:
1) Sec 3, page 4: "While this is adequate for TCP, and indeed is the only w=
ay to securely do connection reuse over that transport (see Section 9.3..."=
 the words "connection reuse" should be removed since it clearly does NOT r=
euse the connection in such a case.

2) Section 5 is a bit confusing, because the diagram shows two UA's and two=
 proxies between them, then describes things in terms of "UAC" and "UAS", w=
hereas I'm fairly sure you mean the proxies instead.  For example, second p=
aragraph of sec 5.1 would imply the UAS uses P2's connection for all subseq=
uent requests going to the UAC, which is NOT true.  If it has a record-rout=
e, then for in-dialog requests yes, but it has nothing to do with subsequen=
t requests going to the UAC in general.

3) sec 5.2: "Connection reuse on the TCP transport is done differently from=
 the TLS case."  No, it's not done at all.  There is no "reused connection"=
.

4) sec 5.2 says "The presence of the "alias" parameter in the topmost Via f=
or a TCP transport is not required."  Then later in section 8.1 it says "Fo=
r TCP and SCTP transports, the client MUST NOT insert the "alias" parameter=
 in the topmost Via header.." (also note the double-period at the end of th=
at sentence)

-hadriel


> > > -----Original Message-----
> > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > > Sent: Wednesday, October 17, 2007 1:15 AM
> > > To: i-d-announce@ietf.org
> > > Cc: sip@ietf.org
> > > Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-08.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > This draft is a work item of the Session Initiation
> > Protocol Working
> > > Group of the IETF.
> > >
> > >     Title           : Connection Reuse in the Session Initiation
> > >                           Protocol (SIP)
> > >     Author(s)       : R. Mahy, et al.
> > >     Filename        : draft-ietf-sip-connect-reuse-08.txt
> > >     Pages           : 21
> > >     Date            : 2007-10-16
> > >
> > > This document enables a pair of communicating proxies to reuse a
> > >    congestion-controlled connection between themselves for sending
> > >    requests in the forward and backwards direction.  Because the
> > >    connection is essentially aliased for requests going in the
> > > backwards
> > >    direction, reuse should be predicated upon both the communicating
> > >    endpoints authenticating themselves using X.509 certificates
> > > through
> > >    TLS.  For this reason, we only consider connection reuse for TLS
> > > over
> > >    TCP and TLS over SCTP.  A single connection cannot be reused for
> > > the
> > >    TCP or SCTP transport between two peers, and this
> > document provides
> > >    insight into why this is the case.  As a remedy, it
> > suggests using
> > >    two TCP connections (or two SCTP associations), each opened pro-
> > >    actively towards the recipient by the sender.  Finally, this
> > > document
> > >    also provides guidelines on connection reuse and virtual SIP
> > > servers
> > >    and the interaction of connection reuse and DNS SRV
> > lookups in SIP.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu
> > > se-08.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a
> > message to
> > > i-d-announce-request@ietf.org with the word unsubscribe in
> > the body of
> > > the message.
> > > You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> > > username "anonymous" and a password of your e-mail address. After
> > > logging in, type "cd internet-drafts" and then "get
> > > draft-ietf-sip-connect-reuse-08.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html or
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > >     mailserv@ietf.org.
> > > In the body type:
> > >     "FILE /internet-drafts/draft-ietf-sip-connect-reuse-08.txt".
> > >
> > > NOTE:       The mail server at ietf.org can return the document in
> > >     MIME-encoded form by using the "mpack" utility.  To use this
> > >     feature, insert the command "ENCODING mime" before the "FILE"
> > >     command.  To decode the response(s), you will need "munpack" or
> > >     a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> > >     exhibit different behavior, especially when dealing with
> > >     "multipart" MIME messages (i.e. documents which have been split
> > >     up into multiple messages), so check your local documentation on
> > >     how to manipulate these messages.
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> >
> >
> > _______________________________________________
> > 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
> >
>
>
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 14:11:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsNeJ-0005Iz-Ma; Wed, 14 Nov 2007 14:11:43 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsNeH-0005E0-Sf
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 14:11:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsNeH-0005De-GJ; Wed, 14 Nov 2007 14:11:41 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsNeB-000570-8l; Wed, 14 Nov 2007 14:11:41 -0500
X-IronPort-AV: E=Sophos;i="4.21,417,1188802800"; 
   d="scan'208";a="193802"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-2.cisco.com with ESMTP; 14 Nov 2007 11:09:47 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAEJ9mMO027841; 
	Wed, 14 Nov 2007 11:09:48 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAEJ9lIw004448;
	Wed, 14 Nov 2007 19:09:47 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 11:09:47 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 11:09:47 -0800
Message-ID: <473B481A.2040802@cisco.com>
Date: Wed, 14 Nov 2007 14:10:18 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mary Barnes 
Subject: Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
	<4733A781.7020906@stpeter.im> <473A93B6.1030405@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2007 19:09:47.0340 (UTC)
	FILETIME=[EC4B70C0:01C826F1]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6242; t=1195067388;
	x=1195931388; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20RAI-ART=20Review=20Comments=20for=20draft-iet
	f-sip-hitchhikers-guide |Sender:=20;
	bh=veltQX270p/ieDcU97nJTmvkT0AuxMy7QD29qhUoFLQ=;
	b=gVHBuqiogNNnG2kxj9/M7/2TCF0Khyt/KC/RSM2bCQrHgTJquLhdXJ1ZwAsDp1T6CVjlECKp
	1hQKM+4033Er4y+0CKGw8Ry8FGhHOxyNXYbxhYv8pBIsmAMstzXFfAxt;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Cc: sip , rai@ietf.org, Brian Stucker 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Mary,

Don't get me wrong - I'm not passing judgement on the value of the call 
flow specs, or on any other spec for that matter. I'm just trying to 
keep the scope of this document to a point where there is an objective 
definition we can agree to which defines the contents of the document.

The current definition focuses squarely on protocol specs - extensions 
and object specs and the like. Those collected together define the 
functionality provided by SIP. I do agree that a BCP can, for all 
intents and purpsoes, be thought of as a protocol spec in that it 
normatively defines behavior. We have a BCP in there now (3pcc).

Whats interesting is that the call flow specs (3665, 3666) are BCP, but 
frankly I'm not sure why. RFC 3665 for example contains the definitions 
of RFC 2119 terms, but never once uses any of them. To me, a BCP is a 
BCP and not informational because it has such terms - it describes 
behavior in some way.

We could choose to expand the definition of the scope of the hitchhikers 
guide to include example call flow documents, whether they be 
informational or BCP. That would throw in a few more (torture tests for 
example). The main question I would ask is whether we view those kinds 
of informational documents as different from ones like RFC 5057 
(multiple dialog usage) which, I would argue, is closer to what  BCP 
ought to be, in terms of defining behaviors explicitly that are 
non-obvious or unspecified in the base specs.

-Jonathan R.



Mary Barnes wrote:
> Jonathan,
>   
> I honestly think that not having the call flows, which are BCPs, leaves
> a huge gap in the document.  And, I think not having them is contrary to
> these statements in the hitchiker's guide (from the intro):
>    "It is an informational document, meant to guide newcomers,
>     implementors and deployers to the SIP suite of specifications."
> And  (in the paragraph following the text you extracted): 
>    "Best Current Practices are included when they normatively define
> mechanisms for
>    accomplishing a task."
> 
> IMHO, that is the case with all the call flow BCPs, per the basic
> definition of BCP in RFC 2026:
> 
>    A BCP document is subject to the same basic set of procedures as
>    standards track documents and thus is a vehicle by which the IETF
>    community can define and ratify the community's best current thinking
>    on a statement of principle or on what is believed to be the best way
>    to perform some operations or IETF process function.
> 
> At a minimum,  basic call flows fits into this category because the ones
> in RFC 3261 are not comprehensive. 
> If we don't tell newcomers about the call flows in this document, they
> will likely miss them, since the whole point of this document is to help
> them navigate the specs. It would be okay of the call flows were
> referenced in the other documents, since more astute developers would
> have the sense to look at referenced docs, as well, many of them are not
> referenced. For example, the only document that seems to reference basic
> call flows is RFC 4083 (3GPP requirements).  If the reluctance to
> include the call flow BCPs is a concern that they no longer reflect
> "Best" current practices, then we need to start updating those documents
> or we need to obsolete them.  
> 
> I also just noticed that one BCP that wasn't mentioned yet was RFC 4579.
> It would be difficult to figure out how to put together a SIP based
> conferencing implementation based only on the other docs in section 8
> (conferencing) without the call flow document.  
> 
> Regards,
> Mary. 
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] 
> Sent: Wednesday, November 14, 2007 12:21 AM
> To: Peter Saint-Andre
> Cc: sip; rai@ietf.org; Stucker, Brian (RICH1:AR00)
> Subject: Re: [Sip] RAI-ART Review Comments for
> draft-ietf-sip-hitchhikers-guide
> 
> The call flow documents do not meet the current criteria defined by
> hitchhikers for inclusion. That criteria is:
> 
>     It is very difficult to enumerate the set of SIP specifications.
>     This is because there are many protocols that are intimately related
>     to SIP and used by nearly all SIP implementations, but are not
>     formally SIP extensions.  As such, this document formally defines a
>     "SIP specification" as:
> 
>     o  Any specification that defines an extension to SIP itself, where
>        an extension is a mechanism that changes or updates in some way a
>        behavior specified in RFC 3261
> 
>     o  Any specification that defines an extension to SDP whose primary
>        purpose is to support SIP
> 
>     o  Any specification that defines a MIME object whose primary
> purpose
>        is to support SIP
> 
> 
> Example call flows do not meet this criteria.
> 
> -Jonathan R.
> 
> Peter Saint-Andre wrote:
>> Brian Stucker wrote:
>>
>> 
>>
>> Sorry to hijack this thread, but I'd like to second a comment that 
>> Mary Barnes made during the WGLC:
>>
>> http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html
>>
>> ***
>>
>> It seems that all the call flow BCPs are missing and I do think those 
>> are really important and should be included in this document.  The 
>> only BCP (type (B) document) listed in this document is 3PCC.  The 
>> basic call flow document (RFC 3665) should be listed in section 3 
>> (Core SIP).  The PSTN call flows (RFC 3666, BCP 76) should be in PSTN 
>> Interworking section 4. The SIPPING NAT scenarios document should be 
>> in the NAT section 6.  These docs are all icing on the cake IMHO and 
>> help to guide implementers in using all the other docs.
>>
>> ***
>>
>> I agree that the call flow documents are very useful and that a 
>> reference to them would be a good thing.
>>
>> Peter
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 18:03:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsRGT-0004aA-M6; Wed, 14 Nov 2007 18:03:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsRGR-0004Zt-B5
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 18:03:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsRGQ-0004ZZ-W3; Wed, 14 Nov 2007 18:03:19 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsRGL-0003zO-2D; Wed, 14 Nov 2007 18:03:18 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 14 Nov 2007 15:03:12 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAEN3AGv032123; 
	Wed, 14 Nov 2007 15:03:10 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAEN2M8M028523;
	Wed, 14 Nov 2007 23:03:10 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 15:03:08 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 15:03:07 -0800
Message-ID: <473B7ECA.1080504@cisco.com>
Date: Wed, 14 Nov 2007 18:03:38 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Avshalom Houri 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2007 23:03:07.0732 (UTC)
	FILETIME=[852DB940:01C82712]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11678; t=1195081390;
	x=1195945390; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20RAI=20review=20of=20draft-ietf-sip-hitchhikers-guide-
	03 |Sender:=20;
	bh=jvtg/bfv05pzs+lE+EZalajgKTtKIXwl/pCVS4kYKUg=;
	b=sfKMR0QLdIcWy5mEu76km5MqLX03jVnAAn8DuI9233PPNhmJ4siNY5U4Nh/1CsPmm5nlX8OS
	RZ1KKYHskhbLSfyYxWiK5CPaCQO3pYZqssnpWY35hUyrK6rYqbs0H19I;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1
Cc: sip@ietf.org, rai@ietf.org
Subject: [Sip] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Thanks for the comments, Avshalom. Responses below:

Avshalom Houri wrote:
> 
> I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03
> from the perspective of presence and the SIMPLE group but ended up in
> commenting on the whole document at the end.
> 
> For background on RAI-ART, please see the FAQ at
> _http://www.softarmor.com/rai/art/rai-art-FAQ.html_ 
> 
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> In my opinion this draft is basically ready for publication, but has
> nits that should be fixed before publication.
> 
> Citations from the draft are marked by <<< text from draft >>>
> 
> General comments
> ----------------
> 
> By its nature there are a lot of reference to drafts in the document.
> It will take a lot of time for these documents to become and RFC.
> So how we are going to publish this as an RFC? Since when the
> referenced drafts will become an RFC, this draft would have to be
> updated with new drafts, will it be held in the
> RFC ED queue for ever?

We had a whole thread on this, so I won't address this again here, but 
rather focus on your other comments.

> 
> How do we gauge the usage of an RFC or a draft? There are many places
> here that it is said that this or that RFC/draft got widely implemented
> or not.
> How it is measured? The wide implementation test is used to decide
> whether an RFC or draft are core or not and therefore there should be
> some text explaining how the wide implementation was determined.

No. Wide usage is not used to determine core or not. There is a litmus 
test defined for inclusion as a core spec:



For specifications that impact SIP session management, the
extension would be used for almost every session initiated by a user
agent


For specifications that impact SIP registrations, the extension
would be used for almost every registration initiated by a user agent


For specifications that impact SIP subscriptions, the extension
would be used for almost every subscription initiated by a user agent




this definition is based entirely on the functionality of the spec and 
not judgement on its deployment.

The comments on deployment in the document are based on my own 
observation and awareness. Please feel free to suggest changes, that 
part of the description can only be improved with data from additional 
folks.

> 
> Better change RFC XXXX (before the reference number in []) to the name
> of the draft (with no version number), it will make the ride smoother.

OK. Changing to symrefs helps a lot.

> 
> An introduction that details the various grouping should be added. It
> should include additional text on the group and what was the criteria
> for putting an RFC/draft in the group.

OK, I added a list in the introduction along with brief classification 
description.

> 
> 2.  Scope of this Document
> --------------------------
> 
> <<<
>    o  Any specification that defines an extension to SIP itself, where
>       an extension is a mechanism that changes or updates in some way a
>       behavior specified in RFC 3261
>  >>>
> 
> "to SIP itself" sounds vague. It will be better to say:"to RFC 3261"
> instead.
> Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus
> (or the president of the galaxy) and that RFCs/drafts mentioned in this
> document are based on their relation to it.

changed this sentence to:

Any specification that defines an extension to RFC 3261,
where an extension is a mechanism that changes or updates in
some way a behavior specified there.



> 
> <<<
>    Excluded from this list are requirements, architectures, registry
>    definitions, non-normative frameworks, and processes.  Best Current
>    Practices are included when they normatively define mechanisms for
>    accomplishing a task.
>  >>>
>    
> "normatively define" not sure what is meant by normative with
> respect to BCP. Seems like a contradiction in terms.

Actually BCPs can contain normative text and are, in many ways, very 
much like a PS.

> 
> 3.  Core SIP Specifications
> ---------------------------
> 
> If we think on presence as eventually replacing registration, since it
> carries much more information about the availability of the user,
> should we consider also presence as a towel?
> 
> <<<
>    RFC 3261, The Session Initiation Protocol (S):  RFC 3261 [1] is the
>       core SIP protocol itself.  RFC 3261 is an update to RFC 2543 [9].
>       It is the president of the galaxy [42] as far as the suite of SIP
>       specifications is concerned.
>  >>>
> 
> RFC 3261 is a very big document. Should it be treated as one or it can
> be divided into parts in this document e.g. proxy, client etc.? I am not
> sure what would be better.

The purpose here is to just enumerate the specs and describe each. I 
don't think the aim is to break it up here.

> 
> 4.  Public Switched Telephone Network (PSTN) Interworking
> ---------------------------------------------------------
> 
> Regarding RFC 3578
> Ugly in one corner of the galaxy may be beautiful on the other of it :-)
> 
> 7.  Minor Extensions
> --------------------
> 
> <<<
>    RFC XXXX, Referring to Multiple Resources in SIP (S):  RFC XXXX [44]
>       allows a UA sending a REFER to ask the recipient of the REFER to
>       generate multiple SIP requests, not just one.  This is useful for
>       conferencing, where a client would like to ask a conference server
>       to eject multiple users.
>  >>>
> 
> Should not this be referred to in the conferencing section also?

ok

> 
> <<<
>    RFC 4483, A Mechanism for Content Indirection in Session Initiation
>    Protocol (SIP) Messages (S):  RFC 4483 [89] defines a mechanism for
>       content indirection.  Instead of carrying an object within a SIP
>       body, a URL reference is carried instead, and the recipient
>       dereferences the URL to obtain the object.  The specification has
>       potential applicability for sending large instant messages, but
>       has yet to find much actual use.
>  >>>
> 
> The specification has also potential for sending large presence
> documents via a URL.

sure, but I don't think it would really be classified as a 
presence-related spec.

> 
> <<<
>    RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
>    Control Protocol (BFCP) Streams (S):  RFC 4583 [91] defines a
>       mechanism in SDP to signal floor control streams that use BFCP.
>       It is used for Push-To-Talk and conference floor control.
>  >>>
> 
> Should not this be referred to in the conferencing section also?

ok

> 
> <<<
>    RFC XXXX, Connectivity Preconditions for Session Description Protocol
>    Media Streams (S):  RFC XXXX [93] defines a usage of the precondition
>       framework [59].  The connectivity precondition makes sure that the
>       session doesn't get established until actual packet connectivity
>       is checked.
>  >>>
> 
> Should not this be referred to in the QoS section also?

Well, the line is fine, but connectivity preconditions is not about QoS 
as most folks think of it (i.e., bandwidth reservation).

> 
> 8.  Conferencing
> ----------------
> 
> The Conferencing section should be before or after "Instant Messaging,
> Presence and Multimedia" as it is also an application. See the comment
> on whether presence is an application or not later.

moved.

> 
> 10.  Event Framework and Packages
> ----------------------------------
> 
> Suggest to divide this section to event framework section and to
> packages section. The event framework should include 3265, 3903, 4662
> and subnot-etags which define the event framework itself.
> The other section will the packages sections that will list the
> packages.

OK.

> 
> Alternatively, many of the packages are mentioned in their proper
> section so it may be that all the event packages can be fit into
> their relevant section and there is not a need for packages section.

I think its useful to list them.

> 
> 11.  Quality of Service
> -----------------------
> 
> <<<
>    RFC 3313, Private SIP Extensions for Media Authorization (I):  RFC
>       3313 [61] defines a P-header that provides a mechanism for passing
>       an authorization token between SIP and a network QoS reservation
>       protocol like RSVP.  Its purpose is to make sure network QoS is
>       only granted if a client has made a SIP call through the same
>       providers network.  This specification is sometimes referred to as
>       the SIP walled garden specification by the truly paranoid androids
>       in the SIP community.  This is because it requires coupling of
>       signaling and the underlying IP network.
>  >>>      
> 
> Understand that being a "truly paranoid" is a virtue? :-)
> 
> 15.  Security Mechanisms
> ------------------------
> 
> Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474
> (Identity) be mentioned here also?    

Hmm, well Brian had suggested that RFC 3325 has nothing to do with 
'secure caller ID' so that one is definitely debatable.

4474 definitely fits here. 3323 is kind of fuzzy, but I'll include.

> 
> 16.  Instant Messaging, Presence and Multimedia
> -----------------------------------------------
> 
> Maybe create an applications section and put also conferencing as a type
> of an application.

Applications is really broad. The service URI stuff could be considered 
an app too. I think its valuable to have finer granularity than that.

> 
> Including presence here with IM and multimedia seems that presence is
> regarded as an additional type of media. I am not sure that I agree with
> this. Presence is an enabler for many other applications and it deserves
> a section of its own.

Certainly its valuable, sufficiently so that simple-simple addresses it 
more completely and obviously separates IM from presence. But its not 
the emphasis of this document. If I split off presence there is only two 
docs in there (winfo and presence package), and only one in IM (3428) so 
this seems to argue for keeping them together. I did add a reference to 
simple-simple in the intro to let people know there is a more complete 
source of presence specs elsewhere.

> 
> It is very tempting to include the simple-simple content here
> (as an appendix?). If simple-simple is not to be included here, there
> should be at least a reference to simple-simple as for presence
> there are so many documents that are essential for doing presence and
> are not mentioned here (e.g. watcher format, RPID, presence rules,
> partial notify and publish and many many more).

done.

>  Roughly counting, there
> are about 20-25 RFCs/drafts that are very relevant to presence that are
> mentioned in simple-simple in addition to the ones that are mentioned here.

right, since they are not sip extensions.

> 
> The MSRP drafts seem to be forgotten?

Not a sip extension. RTP isn't listed here either.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 18:15:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsRSc-0001M9-17; Wed, 14 Nov 2007 18:15:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsRSa-0001IC-24
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 18:15:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsRSZ-0001HP-Nl; Wed, 14 Nov 2007 18:15:51 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsRSV-0004Xb-76; Wed, 14 Nov 2007 18:15:51 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-5.cisco.com with ESMTP; 14 Nov 2007 15:15:46 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAENFkkL020065; 
	Wed, 14 Nov 2007 15:15:46 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAENFdCX021348;
	Wed, 14 Nov 2007 23:15:39 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 15:15:39 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 15:15:39 -0800
Message-ID: <473B81BA.10405@cisco.com>
Date: Wed, 14 Nov 2007 18:16:10 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Joerg Ott 
References: <472878ED.9070009@netlab.hut.fi>
In-Reply-To: <472878ED.9070009@netlab.hut.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2007 23:15:39.0120 (UTC)
	FILETIME=[450A6F00:01C82714]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3088; t=1195082146;
	x=1195946146; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20RAI-ART=20review=20of=20draft-ietf-sip-hitchhikers-gu
	ide-03 |Sender:=20;
	bh=JYF085WkNTmsktJ8Bnshrrv9Bj6MBQtk9Gnad0ldeZM=;
	b=2Dthb40vYg98DmQYyQBJo9/Fg95eilwBsYWH1qdM3Tl2R8J7dWQXyDpYtDolrBHz9x+xlWUU
	/rTwpprZYJZQ0GNODsJgFq7SILYQiU9zxMaO9YGAddyo/gexSlenigB8;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: sip ietf , rai@ietf.org, drage@alcatel-lucent.com,
	Dean Willis 
Subject: [Sip] Re: RAI-ART review of draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Thanks for the review, Joerg. Responses below:

Joerg Ott wrote:
> Hi,
> 
> I am the assigned RAI-ART reviewer for draft-ietf-sip-hitchhikers-guide-03
> 
> For background on RAI-ART, please see the FAQ at 
> .
> 
> Please resolve the comments below along with any other
> Last Call comments you may receive.
> 
> It may be worthwhile to include the advice in the beginning:
> 
> "Do not print all the specs cited here at once, as they
> might share the fate of the rules of Brockian Ultracricket
> when bound together: collapse under their own gravity and
> form a black hole. [42]"

Nice! Added.

> 
> Joerg
> 
> 
> Review of draft-ietf-sip-hitchhikers-guide-03:
> 
> 
> This draft is ready for publication as an Informational RFC.
> Please consider the suggestions and nits listed below.
> 
> 
> Observations and suggestions:
> 
> Sect. 5, p10, RFC4244:
> 
>     "Its primary purpose _was_ in support of voicemail services."
> 
>     This reads like the document became obsolete already.
>     Is this intentional?  If so, would it be useful to also
>     indicate which other purposes it now serves (or none
>     at all)?

No - its broader now in fact. Brian had a similar comment. Text 
currently reads:

  defines the
History-Info header field, which indicates information on how a call
came to be routed to a particular destination. Its initial application
was in support of voicemail services, though it now has more broad
applicability. 


> 
> 
> Sect. 7, p13, RFC4583:
> 
>     This should go to the conferencing section (sect. 8).

Its been added to that section, but it has non-conferencing 
applicability too (PTT). So I think it should also remain in this section.

> 
> 
> Sect. 7, p13, RFCXXXX [59]:
> 
>     This should explicitly state that it builds upon the general
>     mechanisms of RFC 3312 (which only is described later).

[59] *is* RFC3312 so I am confused about which item you are referring to.

> 
> 
> Sect. 9, p14, RFC3515:
> 
>     It may be useful to add a warning clause concerning REFER,
>     e.g., along the following lines:
> 
>     "Beware that not all potential uses of REFER (neither for all
>      methods nor for all URI schemes) are well defined.  Be advised
>      to use only the well-defined ones and not to second guess or
>      freely assume behavior for the others to avoid unexpected
>      behavior of remote UAs, interoperability issues, and other
>      bad surprises."
> 

ok

> 
> 
> Nits:
> 
> Sect. 9, p14, RFC3515:
> 
>     2nd sentence: "Its" -> "It is"
> 

fixed.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 18:22:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsRYc-0007jD-GF; Wed, 14 Nov 2007 18:22:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsRYY-0007bm-Ha
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 18:22:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRYX-0007aa-Tr
	for sip@ietf.org; Wed, 14 Nov 2007 18:22:02 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsRYU-0004mj-5o
	for sip@ietf.org; Wed, 14 Nov 2007 18:22:01 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 14 Nov 2007 15:21:57 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAENLvOf030259; 
	Wed, 14 Nov 2007 15:21:57 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAENLhEG023915;
	Wed, 14 Nov 2007 23:21:57 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 15:21:47 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 15:21:46 -0800
Message-ID: <473B8329.2040705@cisco.com>
Date: Wed, 14 Nov 2007 18:22:17 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mary Barnes 
Subject: Re: [Sip] Some Comments: WGLC of draft-ietf-sip-hitchhikers-guide-03
References: 
	<1ECE0EB50388174790F9694F77522CCF12BCA8CD@zrc2hxm0.corp.nortel.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2007 23:21:46.0435 (UTC)
	FILETIME=[1FFA4130:01C82715]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3554; t=1195082517;
	x=1195946517; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20Some=20Comments=3A=20WGLC=20of=20draft-ietf-s
	ip-hitchhikers-guide-03 |Sender:=20;
	bh=t6O1lS7r5RrhDo9fblk3JZIG0GenZV2QDtOnFUKSq50=;
	b=L1Go1kBTQZadrOydejCDm+39P1/MOFosIxiDcELccLTOXWH5F1gwm8W0ISEd8Q8oiXSpK3Qz
	hMRoFkiPRZ6DIZiY1cP6lmk3WVxTOISglCL5CPM4L7ptzw/uBq1OH7vKn5u6kYQdO6OpoykO/f
	spMRUpEI7QkMOqPo130jWLkQw=;
Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: sip@ietf.org, Francois Audet , "DRAGE,
	Keith \(Keith\)" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

OK, I took this wording. RFC 4588 got added also per other comments, and 
appears in the service URI section.

-Jonathan R.

Mary Barnes wrote:
> I like the suggested rewording for RFC 4244 and agree that RFC 4458
> would fit well in the Service URI section.
> 
> Mary. 
> 
> -----Original Message-----
> From: Audet, Francois (SC100:3055) 
> Sent: Wednesday, October 24, 2007 6:35 PM
> To: Barnes, Mary (RICH2:AR00); Jonathan Rosenberg
> Cc: sip@ietf.org; DRAGE, Keith (Keith)
> Subject: RE: [Sip] Some Comments: WGLC of
> draft-ietf-sip-hitchhikers-guide-03
> 
> Mary has a good point, but I think an even simpler solution is the
> following:
> 
> NEW:
> 
>  RFC 4244, An Extension to SIP for Request History Information (S):
>        RFC 4244 [37] defines the History-Info header field, which
>        indicates information on how and why a call came to be routed to
> a
>        particular destination.   
> 
> As for RFC 4458, I think it belongs int the "SIP Service URIs" section
> and maybe the PSTN interop one (it's really a form of RFC 3087 service
> URI for PSTN interop).
> 
>> -----Original Message-----
>> From: Barnes, Mary (RICH2:AR00)
>> Sent: Wednesday, October 24, 2007 08:20
>> To: Jonathan Rosenberg
>> Cc: sip@ietf.org; DRAGE, Keith (Keith)
>> Subject: [Sip] Some Comments: WGLC of
>> draft-ietf-sip-hitchhikers-guide-03
>>
>>
>> Following Keith's recommendation for us to at least review the entries
> 
>> for the RFCs that we authored, I have some feedback on the entry for 
>> RFC
>> 4244 (History-Info) and a few other comments.  
>>
>> RFC 4244 comments (Section 5):
>> ------------------------------
>> The statement about the primary application being voicemail is a 
>> mis-characterization and is based on the fact that we had so, so many 
>> long, long discussions on the use of History-Info for voicemail. RFC
>> 4244 is written to provide a very general mechanism and is applicable 
>> to a variety of applications. My concern is that mis-characterization 
>> may result in folks trying to define something new when the capability
> 
>> already exists with History-Info (e.g., 3GPP p-served-user p-header).
>> So, I suggest something like the following change:
>>
>> OLD:
>> RFC 4244, An Extension to SIP for Request History Information (S):
>>       RFC 4244 [37] defines the History-Info header field, which
>>       indicates information on how a call came to be routed to a
>>       particular destination.  Its primary application was in support 
>> of
>>       voicemail services.
>>
>> NEW:
>> RFC 4244, An Extension to SIP for Request History Information (S):
>>       RFC 4244 [37] defines the History-Info header field, which
>>       indicates information on how and why a call came to be routed to
> 
>> a
>>       particular destination.  One application was in support of
>>       voicemail services, with details of such provided in RFC 4458.
>>       Other example applications include Automatic Call Distribution
>>       and Call Transfer scenarios. 
>>
>> And, this of course, adds a reference to RFC 4458. I don't have a 
>> strong opinion as to whether detail on that RFC shouldn't be included 
>> elsewhere
>> in this document.   
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 14 23:51:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsWh2-00066o-5j; Wed, 14 Nov 2007 23:51:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsWh0-00065R-9M
	for sip-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 23:51:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsWgz-00065E-3h
	for sip@ietf.org; Wed, 14 Nov 2007 23:51:05 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsWgv-0004NE-Ee
	for sip@ietf.org; Wed, 14 Nov 2007 23:51:05 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 14 Nov 2007 20:51:01 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAF4p0rG031473; 
	Wed, 14 Nov 2007 20:51:00 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAF4p0CX011066;
	Thu, 15 Nov 2007 04:51:00 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 20:51:00 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 20:51:00 -0800
Message-ID: <473BD053.6020706@cisco.com>
Date: Wed, 14 Nov 2007 23:51:31 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Elwell, John" 
Subject: Re: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-03
References: <5D1A7985295922448D5550C94DE29180017E1D88@DEEXC1U01.de.lucent.com>
	<0D5F89FAC29E2C41B98A6A762007F5D037D4FA@GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D037D4FA@GBNTHT12009MSX.gb002.siemens.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Nov 2007 04:51:00.0374 (UTC)
	FILETIME=[1E3E2360:01C82743]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14755; t=1195102260;
	x=1195966260; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20WGLC=20of=20draft-ietf-sip-hitchhikers-guide-
	03 |Sender:=20;
	bh=Rqg5ImWp8eMUEhxrJKh/y48XLBV6LrujRF7qw+1myac=;
	b=kWpYn5WIVOhIJVGkuKm83+CfqzdVqPMRgu3W70FEq/AHSX6y7uyO7D4LcKfvTTRcVfKSvbcN
	6ffBIC/D/yvGPBCH+a/B5zl0BiUf0wQcVV4VaL7FKca2hJTCFwFVUR8M;
Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 441f623df000f14368137198649cb083
Cc: IETF SIP List , "DRAGE,
	Keith \(Keith\)" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Thanks for the comments, John. Responses below:

Elwell, John wrote:
> Draft:  draft-ietf-sip-hitchhikers-guide-03
> Reviewer: John Elwell
> Review Date: 2007-10-24
> Review Deadline: 2007-10-29
> Status: WGLC
> 
> Summary: This draft is basically ready for publication, but has nits
> that should be fixed before publication.
> 
> My 42 comments below.
> 
> Minor comments:
> 1. "Any specification that defines an extension to SIP itself, where"
> Change to:
> "The basic SIP specification, RFC 3261 [ref], and any specification that
> defines an extension to SIP itself, where"

fixed by other similar comments, now reads:

Any specification that defines an extension to RFC 3261,
where an extension is a mechanism that changes or updates in
some way a behavior specified there.



> 
> 2. "Any specification that defines an extension to SDP"
> Change to
> "The basic SDP specification, RFC 4566 [ref], and any specification that
> defines an extension to SDP"

OK, but I need to add, "whose primary purpose is to support SIP" to the end.

> 
> 3. RFC 3840 has been classified as a core spec. I am not sure that it
> meets the criterion of applying to most calls. Some implementations only
> do isfocus, which hardly arises on every call. You may wish to
> reconsider this classification.

The intention of the spec is that a client is supposed to include all of 
its capabilities, including things like supported media types, etc. in 
each REGISTER. Quoting RFC 3840:

    When a UA registers, it can choose to indicate a feature set
    associated with a registered contact.  Whether or not a UA does so
    depends on what the registered URI represents.  If the registered URI
    represents a UA instance (the common case in registrations), a UA
    compliant to this specification SHOULD indicate a feature set using
    the mechanisms described here.


Based on this, each and every register ought to be utilizing this spec. 
I agree this is not very widely implemented, but the intention of the 
spec is that it is meant to be used with every REGISTER. SO it meets the 
criteria.

> 
> 4. Concerning RFC 4474: "It has seen little deployment so far,
>       but its importance as a key construct for anti-spam techniques
>       makes it a core part of the SIP specifications."
> It would be worth mentioning its use for future security mechanisms
> (e.g., DTLS-SRTP) too:
> "It has seen little deployment so far,
>       but its importance as a key construct for anti-spam techniques and
> new security mechanisms
>       makes it a core part of the SIP specifications."

ok

> 
> 5. Concerning ICE: "A SIP option tag and
>       media feature tag RFC XXXX [108] have been defined for use with
>       ICE."
> It is not clear whether [108] is also a core specification.
> 

yes. I clarified.

> 6. "RFC 4916 [81] defines an extension to SIP that allows a UAC to
>       determine the identity of the UAS.  Due to forwarding and
>       retargeting services, this may not be the same as the user that
>       the UAC was originally trying to reach.  The mechanism works in
>       tandem with the SIP identity specification [19] to provide
>       signatures over the connected party identity."
> It is confusing to talk about UAC and UAS here, because even with RFC
> 4916 it is always the UAC (for that transaction) whose identity is
> given. It might also be worth mentioning mid-call usage. Change to:
> "RFC 4916 [81] defines an extension to SIP that allows a calling UA to
>       determine the identity of the final called user (connected user).
> Due to forwarding and
>       retargeting services, this may not be the same as the user that
>       the caller was originally trying to reach.  The mechanism works in
>       tandem with the SIP identity specification [19] to provide
>       a signature over the connected party identity. It can also be used
> if a party identity changes mid call due to third party call control
> actions or PSTN behavior."

fixed


> 
> 7. "RFC 3960
>       [27] defines some guidelines for handling early media - the
>       practice of sending media from the called party towards the caller
>       - prior to acceptance of the call.  Early media is generated only
>       from the PSTN."
> This is not true - application servers can generate early media. Suggest
> deleting the last sentence and changing the previous sentence as
> follows:
> "RFC 3960
>       [27] defines some guidelines for handling early media - the
>       practice of sending media from the called party or an application
> server towards the caller
>       - prior to acceptance of the call."

changed, though I think mentioning that PSTN is a major source is a 
useful piece of guidance. Changed the second sentence to, "early media 
is often generated from the PSTN"

> 
> 8. "RFC 3204, MIME Media Types for ISUP and QSIG Objects (S):  RFC 3204
>       [84] defines MIME objects for representing SS7 signaling messages.
>       These are carried in the body of SIP messages when SIP-T is used."
> Change to:
> "RFC 3204, MIME Media Types for ISUP and QSIG Objects (S):  RFC 3204
>       [84] defines MIME objects for representing SS7 and QSIG signaling
> messages.
>       SS7 signaling messages are carried in the body of SIP messages
> when SIP-T is used. QSIG signaling messages can be carried in a similar
> way."

fixed

> 
> 9. In the PSTN section you may wish to consider adding
> "RFC 4497, Interworking between SIP and QSIG (B): RFC 4497 [ref] defines
> how to do protocol mapping from QSIG signaling to SIP."

this are out of scope based on the current definitions for included specs.

> 
> 10. Concerning RFC 3323: "Though it
>       defines numerous privacy services, the only one broadly used is
>       the one that supports privacy of the P-Asserted-ID header field
>       [15]."
> Suggest changing "numerous" to "several".

ok

> 
> 11. Concerning RFC 3311: "This method is meant as a means for
>       updating session information prior to the completion of the
>       initial INVITE transaction.  It was developed primarily to support
>       RFC 3312 [59]."
> It is not limited to use before completion of INVITE, and one use is for
> session timer refresh, another is with connected-ID. Change to:
> "This method is meant as a means for
>       updating session information prior to the completion of the
>       initial INVITE transaction.  It can also be used for updating call
> information mid-call. It was developed primarily to support
>       RFC 3312 [59], but has found other uses, including use with RFC
> 4028 [ref] for session timer refresh and with RFC 4916 [ref] for
> connected identity."

similar change already made based on other comments.

> 
> 12. Because RFC 4916, a core specification, mandates use of UPDATE, RFC
> 3311 should be considered a core specification.

Hmm, good point.

> 
> 13. Concerning RFC 4028: "Session
>       timers introduces a fair bit of complexity for relatively little
>       gain, and has thus seen little deployment."
> I am a little surprised by this statement, but if it is based on
> feedback from SIPit then I guess it is OK.

Well, sipit20 results showed a fair number of implementations. I dont 
thinka lot are used but I'm OK to temper this statement. I'll changed to 
'moderate' deployment.

> 
> 14. Section "Minor Extensions".
> Several of these are extensions to mechanisms listed later in the
> document, e.g., REFER, pre-conditions. Should the section be moved
> further back, e.g., to the end?

moved back, before security mechanisms

> 
> 15. Concerning RFC 4508: "It is useful for informing the target of the
> REFER
>       about the characteristics of the REFER target."
> Terminology is rather confusing: "target of the REFER" and "REFER
> target" are supposed to mean different things. Change to:
> "It is useful for informing the target of the REFER request
>       about the characteristics of the intended target of the referred
> request."

ok

> 
> 16. "RFC 3265 defines a basic framework for event notification in SIP.
> It
>    introduces the notion of an event package, which is a collection of
>    related state and event information.  Much of the state and events in
>    SIP systems have event packages, allowing other entities to learn
>    about changes in that state."
> Although several RFCs are repeated in different sections
> (intentionally), in this particular case the text is completely
> different from that in the core specs section. Suggest alignment one way
> or the other.

aligned this with the definition of rfc3265 from core. Indeed, rfc3265 
itself doesnt appear here, which is wrong. FIxed that too.

> 
> 17. "RFC XXXX [96] defines a SIP
>       event package that allows a proxy to notify a user agent about its
>       desire for the UA to use certain codecs or generally obey certain
>       media session policies."
> Change "proxy" to "policy server".

ok

> 
> 18. RFC 4458 is missing - any reason?

error. been added.

> 
> 19. There is mention of several SDP extensions, yet in the section
> "Security Mechanisms", there is no mention of RFCs 4567 and 4568.

wow - frankly I am not sure why I didnt put them in. Maybe its because 
they are not necessarily SIP specific (MIKEY in particular talks about 
rtsp). But that said I do think they belong. And to complete the 
triumvirate, recently added draft-ietf-sip-dtls-srtp-framework-00.txt 
probably belongs too.

I added the following to the security section:

  defines
	     extensions to SDP that allow tunneling of an key
	     management protocol, namely MIKEY
	     , through offer/answer
	     exchanges. This mechanism is one of three SRTP keying
	     techniques specified for SIP, with DTLS-SRTP
	      having
	     been selected as the final solution.



    defines extensions to SDP that allow for
   the negotiation of keying material directly through offer/answer,
   without a separate key management protocol. This mechanism,
   sometimes called sdescriptions, has the drawback that the media keys
   are available to any entity that has visibility to the SDP. It is
   one of three SRTP keying techniques specified for SIP, with
   DTLS-SRTP  having
   been selected as the final solution.



	      defines
	     the overall framework and SDP and SIP processing required
	     to perform key management for RTP using Datagram TLS
	     (DTLS)  directly between
	     endpoints, over the media path. It is
   one of three SRTP keying techniques specified for SIP, with
   DTLS-SRTP  having
   been selected as the final solution.



> 
> 20. "17.  Emergency Services
> 
>    Emergency services here covers both emergency calling (for example,
>    911 in the United States), and pre-emption services, which allow
>    authorized individuals to gain access to network resources in time of
>    emergency."
> In fact the only two RFCs listed relate to pre-emption, not emergency
> calling.

OK, changed to just pre-emption.

> 
> Editorial nits:
> 21. "and implementations
>    interested in a particular topic often implement"
> Change to:
> "and implementers
>               ^^^
>    interested in a particular topic often implement"

ok

> 
> 22. "The SIP change process [8] defines two types of extensions to SIP.
>    These are normal extensions and the so-called P-headers (where P
>    stands for "preliminary", "private", or "proprietary", and the "P-"
>    prefix is included in the header field name) are meant to be used in
>    areas of limited applicability."
> Change to:
> "The SIP change process [8] defines two types of extensions to SIP.
>    These are normal extensions and the so-called P-headers (where P
>    stands for "preliminary", "private", or "proprietary", and the "P-"
>    prefix is included in the header field name), which are meant to be
> used in
>                                                ^^^^^^^
>    areas of limited applicability."

ok

> 
> 23. "RFC 3325 [15], which defines the
>       P-Asserted-ID header field has been widely deployed."
> Add comma as follows:
> "RFC 3325 [15], which defines the
>       P-Asserted-ID header field, has been widely deployed."

ok


> 
> 24. "RFC 4320 [18] formally updates RFC 3261, and
>       modifies some of the behaviors associated with non-INVITE
>       transactions.  These address some problems found in timeout and
>       failure cases."
> It is not clear what "these" refers to. Suggest change to:
> "RFC 4320 [18] formally updates RFC 3261, and
>       modifies some of the behaviors associated with non-INVITE
>       transactions.  Modifications address some problems found in
> timeout and
>                      ^^^^^^^^^^^^^^
>       failure cases."

changed to, "this addresses"

> 
> 25. "RFC 4168 [36] defines how
>       to carry SIP messages over the Stream Control Transmission
>       Protocol (SCTP)."
> Add reference to SCTP itself.

ok

> 
> 26. "Its primary application was in support of
>       voicemail services."
> What is the reason for the past tense? Can we just change "was" to "is"?

text already adjusted basedon other comments

> 
> 27. "defines a mechanism for learning about changes in conference
>       state, including group membership."
> Change "group membership" to "conference membership". 
> This occurs twice.

done

> 
> 28. "when there are a multiplicity of
>       security mechanisms"
> Change "are" to "is".

ok

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 00:42:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsXV6-0005yQ-Nt; Thu, 15 Nov 2007 00:42:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsXV4-0005uB-28
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 00:42:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsXV3-0005tX-Mk
	for sip@ietf.org; Thu, 15 Nov 2007 00:42:49 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsXV3-0002JN-FP
	for sip@ietf.org; Thu, 15 Nov 2007 00:42:49 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns4.neustar.com (Postfix) with ESMTP id 33D202AC66;
	Thu, 15 Nov 2007 05:42:49 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IsXV2-0007hq-Vh; Thu, 15 Nov 2007 00:42:48 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: jdrosen@cisco.com
From: IETF I-D Submission Tool 
Message-Id: 
Date: Thu, 15 Nov 2007 00:42:48 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org
Subject: [Sip] New Version Notification for
	draft-ietf-sip-hitchhikers-guide-04 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


A new version of I-D, draft-ietf-sip-hitchhikers-guide-04.txt has been successfuly submitted by Jonathan Rosenberg and posted to the IETF repository.

Filename:	 draft-ietf-sip-hitchhikers-guide
Revision:	 04
Title:		 A Hitchhiker's Guide to the Session Initiation Protocol (SIP)
Creation_date:	 2007-11-15
WG ID:		 sip
Number_of_pages: 37

Abstract:
The Session Initiation Protocol (SIP) is the subject of numerous
specifications that have been produced by the IETF.  It can be
difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP.  This specification serves
as a guide to the SIP RFC series.  It lists the specifications under
the SIP umbrella, briefly summarizes each, and groups them into
categories.
                                                                                  


The IETF Secretariat.




_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 00:45:17 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsXXQ-00014j-MG; Thu, 15 Nov 2007 00:45:16 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsXXP-00013O-2U
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 00:45:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsXXO-00013G-O3
	for sip@ietf.org; Thu, 15 Nov 2007 00:45:14 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsXXO-0002Mr-C3
	for sip@ietf.org; Thu, 15 Nov 2007 00:45:14 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 14 Nov 2007 21:45:13 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAF5jDHC025717
	for ; Wed, 14 Nov 2007 21:45:13 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAF5j9EE013027
	for ; Thu, 15 Nov 2007 05:45:13 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 21:45:11 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Nov 2007 21:45:11 -0800
Message-ID: <473BDD06.30109@cisco.com>
Date: Thu, 15 Nov 2007 00:45:42 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IETF SIP List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Nov 2007 05:45:11.0473 (UTC)
	FILETIME=[B00C7A10:01C8274A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1318; t=1195105513;
	x=1195969513; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Updated=20hitchhikers=20guide |Sender:=20;
	bh=Ojjf0HGu+KnhuUE+gdPTqgt9PYbIQYKBKDPf3xGNf9I=;
	b=zl+HOYQKq2kb8k8eNH3FY+DkekJbHeWihGyYRw6+RN0Z3yFIjUgjqUUZ4qQOefmI6B2lE1Eo
	EtLvHKwjtNjJsQb5jwYTp3SQ/3J3JHsLf2bxN1YC02m/BkVeFfR8N+oW;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: [Sip] Updated hitchhikers guide
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I submitted an updated hitchhikers guide based on WGLC comments:
http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-04.txt

There is still an outstanding issue under discussion around call flows; 
the draft I posted does not include them, but incorporates the other 
comments.

Lots of changes, but the following are of note:

Spec additions and subtractions:

+ RFC 4896
+ draft-ietf-rohc-sigcomp-sip
+ RFC 4458
+ RFC 4567 (mikey)
+ RFC 4568 (sdescriptions)
+ dtls-srtp-framework

- draft-ietf-sip-hop-limit-diagnostics
- draft-ietf-sip-xcap-config

Other changes:

* removed rfc3388 from core; it was there due to ANAT but with ICE
  deprecating it, 3388 itself moved to general infrastructure
* added paragraph on the fact that internet drafts are included, the
   rationale for it, and warnings about the fact that things can change

* noted deprecation of 4091

* added rfc 3311 to core specs, due to usage with 4916

* split events section into framework and packages

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 00:50:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsXc9-0006ck-2I; Thu, 15 Nov 2007 00:50:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsXc5-0006b8-78
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 00:50:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsXc4-0006az-T2; Thu, 15 Nov 2007 00:50:04 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsXc1-0005iF-LW; Thu, 15 Nov 2007 00:50:04 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9CAAF328DA;
	Thu, 15 Nov 2007 05:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IsXc1-0001oR-Hq; Thu, 15 Nov 2007 00:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Thu, 15 Nov 2007 00:50:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-04.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : A Hitchhiker's Guide to the Session Initiation Protocol (SIP)
	Author(s)       : J. Rosenberg
	Filename        : draft-ietf-sip-hitchhikers-guide-04.txt
	Pages           : 37
	Date            : 2007-11-15

The Session Initiation Protocol (SIP) is the subject of numerous
specifications that have been produced by the IETF.  It can be
difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP.  This specification serves
as a guide to the SIP RFC series.  It lists the specifications under
the SIP umbrella, briefly summarizes each, and groups them into
categories.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-04.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-hitchhikers-guide-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-04.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-15004245.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-hitchhikers-guide-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-15004245.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Thu Nov 15 01:21:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsY6J-0002Ek-HD; Thu, 15 Nov 2007 01:21:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsY6H-0002EM-7Q
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 01:21:17 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsY6G-0002EE-LT; Thu, 15 Nov 2007 01:21:16 -0500
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IsY6E-0003bx-Pk; Thu, 15 Nov 2007 01:21:16 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lAF6L6t03761; Thu, 15 Nov 2007 06:21:06 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Nov 2007 00:20:38 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF1336266E@zrc2hxm0.corp.nortel.com>
In-Reply-To: <473A9323.3010609@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
Thread-Index: AcgmhhxjUJpKvDeuSJe5T7b9fxUlcgAwVd9Q
References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
	<473A9323.3010609@cisco.com>
From: "Brian Stucker" 
To: "Jonathan Rosenberg" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d01c7b9466fe967a5df27b46fdb03146
Cc: sip , rai@ietf.org
Subject: [Sip] RE: RAI-ART Review Comments for
	draft-ietf-sip-hitchhikers-guide
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Thanks for the updates. Replies below.

Regards,
Brian=20

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
> Sent: Wednesday, November 14, 2007 12:18 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: rai@ietf.org; sip
> Subject: Re: RAI-ART Review Comments for=20
> draft-ietf-sip-hitchhikers-guide
>=20
> Thanks for the detailed review. Responses below:
>=20
> Brian Stucker wrote:
> > Jonathan,
> >=20
> > Thanks for putting the document together. It took quite=20
> awhile to just=20
> > review it!
> >=20
> > Here are the comments that I have as part of the RAI-ART=20
> review of the=20
> > document. Apologies for the probable repeats in here from list=20
> > comments, I was not able to try to correlate my comments=20
> with others=20
> > on the various reflectors.
> >=20
> > I tried to break my comments up by section and document so=20
> hopefully=20
> > it's coherent in plain-text.
> >=20
> > Regards,
> > Brian
> >=20
> > ----
> >=20
> > Section 1:
> >=20
> >=20
> >    This document itself is not an update to RFC 3261=20
> >   or an extension to
> >    SIP.  It is an informational document, meant to guide newcomers,
> >    implementors and deployers to the SIP suite of specifications.
> >=20
> > May want to change "meant to guide newcomers, implementors and=20
> > deployers to the SIP suite of specifications" since many of the=20
> > documents are not predicated upon SIP itself. For example,=20
> RFC-4566,=20
> > 3388, 3264. Also, I don't think we want to imply that this=20
> document is=20
> > exhaustive. Perhaps "It is an information document, meant=20
> to introduce=20
> > newcomers, implementors and deployers to many of the important IETF=20
> > specifications associated with SIP. Specifications=20
> referenced by this=20
> > document were chosen based on working group consensus and the list=20
> > presented here is not intended to be exhaustive or confer=20
> any special=20
> > status over documents not included."
>=20
> Actually this is not true. The next section provides a=20
> concrete criteria for inclusion. This is a criteria that was=20
> discussed on the mailer and in meetings. The idea is NOT to=20
> have, on a doc by doc basis, discussion and consensus on=20
> whether to include it.
>=20
> I changed the wording in the last sentence to "It is an=20
> informational document, meant to guide newcomers,=20
> implementors and deployers to the many of the specifications=20
> associated with SIP."

Fair enough.

>=20
> >=20
> > Might also want to include some pointers to the relevant WG=20
> webpages=20
> > to give newcomers a place to go for further information. As well as=20
> > include some boilerplate about the dangers of implementing I-D's=20
> > before they become RFCs (I think this was already discussed=20
> somewhat=20
> > on the RAI mailing list).
>=20
> I'll add the warning per Keiths comment. I'm not sure that=20
> the web links bring any value in an era of Google.

Fair enough.

>=20
>=20
> >=20
> >=20
> >=20
> > Section 2:
> >=20
> > 	Although I agree that documents defining relevant registries
> > should be excluded, what about pointers to the registries=20
> themselves?
> > Seems like some of the interop problems we wind up with are due to
> > disregard or lack of visibility of the IANA registration process to
> > implementors.
>=20
> This document isn't meant to be the cure for the interop problems of=20
> SIP. Its scope is to help people understand what specs form "SIP" and=20
> what they are for. Thats it. That includes registry references. I am=20
> going to stick hard to the original scope of this document.

Not the cure, certainly, but if the IANA registration process for SIP
extensions is considered out of scope, then perhaps a pointer to 4485
somewhere instead? Seems mostly harmless. :)

>=20
> >=20
> >=20
> > Section 3:
> >=20
> > RFC3261:=20
> >=20
> > 	I think it would be useful to provide a reverse-lookup list of
> > RFCs that formally update 3261 under the 3261 entry:=20
> RFC-3583, RFC-4320
> > and RFC-4916. There is a statement under 4320 that it=20
> formally updates
> > 3261, but there is no mention under 4916 that it formally=20
> updates 3261,
> > it just looks like any other extension. Putting a pointer=20
> to the SIPS
> > work as a TBD formal update to 3261 would also be good as well as
> > collapsing the "essential corrections to SIP" under the=20
> 3261 entry so
> > that people don't skip over that material would be good as well.
>=20
> I disagree with this. I think the IETF's view of what is an=20
> 'update' vs.=20
> an 'extension' is academic for implementors. I think its=20
> worth noting so=20
> there is no surprise, but I don't want this long list of things which=20
> "are" 3261 when they each have their own RFC number.
>=20
> Essential corrections is already listed in the core=20
> specifications list=20
> so I am not worried about it being missed.
>=20
> I will mention in the sections on 3853, 4320, 4916 that they formally=20
> update 3261.

Thanks.

>=20
> >=20
> > RFC3264:
> >=20
> > 	Should we perhaps put a pointer here to the offer/answer draft
> > for further clarification of 3264 since it seems pretty=20
> clear that the
> > baseline specification did not entirely capture all of the=20
> interactions
> > that arise in implementations?
>=20
> That document is informational. It is meant as a clarification to=20
> rfc3264. The scope of the hitchhikers document doesn't include such=20
> documents. If you want to further expand the scope to include=20
> documents=20
> that are informational clarifications, please post a note to sip and=20
> raise this as proposed scope change for hitchhikers. As I said above=20
> though, I disagree with any proposed increases in scope beyond our=20
> original agreed set.

So you'd rather have a document that formally lists which other unclear
documents comprise the SIP specification as an aid to the implementor
for a core function of the protocol?=20

Informational or not, we have real debates at the meetings around what
is correct and what is not correct in terms of how offer/answer is used
and that is captured in the offer/answer draft.=20

I would agree that informational documents that do not clarify other
normative statements are out of scope, but that does not seem to be the
case here. The offer/answer draft isn't trying to make changes to
mechanism but to clarify unclear points of the existing normative
language so that people can implement the existing mechanisms properly.
It's informational only in that it does not need to be normative to do
the job. It is clearly not the same type of informative documents as
some others, or even, arguably, some of the BCP documents.

I'd argue that including a normative document that nobody uses is of
equal or lesser utility in this case.

Is this really then out of scope? Since this post is cross-posted to the
SIP list, please consider the note posted.

One thing I noticed while going back through the document during this
reply is that you include a reference to RFC-4091 which is obsoleted by
ICE. Don't know how you want to handle that one.

>=20
> >=20
> > RFC3325:
> >=20
> > 	May want to remove the word "secure" from the description of the
> > P-Asserted-ID header description. P-Asserted-ID does not confer any
> > security of the caller ID information. It's the trust domain that
> > provides the security in contrast to a mechanism like RFC-4474.=20
>=20
> Changed to "network asserted".

Thanks.

>=20
>=20
> >=20
> > RFC3581:
> >=20
> > 	Rport is necessary to routing a response through a NAT, but does
> > not solve NAT traversal for SIP signaling. Perhaps a=20
> pointer to outbound
> > under this RFC would be useful to highlight what you don't get with
> > rport that you need to fully address NAT traversal issues, or simply
> > remove it entirely and rely on folks to go to the NAT=20
> traversal section
> > to discover it there as it's not necessary at all if you=20
> have no NATs to
> > traverse (ALGs and SBCs aside).
>=20
> I removed and added a pointer to the section.

Thanks.

>=20
> >=20
> > RFC4474:
> >=20
> > 	I don't think it's necessary that we should highlight the
> > deployment size of the various RFCs in this way, especially=20
> given that
> > the RFC is much newer (and has more complicated requirements) than
> > RFC3325.
>=20
> Well, we'll be revising the hitchhikers guide every year or=20
> so. Should=20
> this statement no longer be true we can adjust it.

Fair enough.

>=20
> >=20
> > SIPS:
> >=20
> > 	Should note that this will formally update RFC3261 when approved
> > to highlight that newcomers should ignore what's in RFC3261.
>=20
> OK.

Thanks.

>=20
>=20
> >=20
> >=20
> >=20
> > Section 4:
> >=20
> > RFC2848/3910:
> >=20
> > 	If this has seen little deployment and is very narrowly scoped,
> > then why are we including it in the guide?=20
>=20
> Because they are extensions and that is the scope of hitchhikers.
>=20
> >=20
> > RFC3372:
> >=20
> > 	Widespread implementation in a limited deployment model. It
> > should be noted that it's usage is intended to be temporary as ISUP
> > endpoints are obviated from the network.
>=20
> OK.

Thanks.

>=20
> >=20
> > RFC3960:
> >=20
> > 	Early media is not just generated by the PSTN. We should be fair
> > here and acknowledge that 3960 does not solve all of the=20
> various issues
> > associated with early media (without enumerating them). We=20
> all know this
> > to be the case, so just a sentence or two should suffice to warn the
> > reader.
>=20
> Added:
>=20
> Early media
>    is a complex topic, and this specification does not fully address
>    the problems associated with it.

Perfect.

>=20
>=20
> >=20
> > RFC3959:
> >=20
> > 	We should highlight that this specification has not seen
> > widespread deployment. As of a few IETFs ago nobody=20
> indicated that they
> > had developed anything with regards to this specification=20
> when asked at
> > a working group meeting. This is only important in that=20
> 3960 does not
> > solve all of the early media issues.
>=20
> Mentioned.

Thanks.

>=20
> >=20
> >=20
> > Shouldn't we have an entry in this section for RFC3966 to cover tel
> > URIs?
> >=20
>=20
> No. It does not meet the defined scope:
>=20
> * SIP extensions
> * MIME objects just for SIP
> * SDP stuff just for SIP

But TEL URIs are mentioned in RFC-3261, section 19.1.6. It's not
explicitly an extension to SIP but it's used an awful lot with SIP.
Still out of scope?

>=20
> >=20
> >=20
> > Section 5:
> >=20
> > RFC3262:
> >=20
> > 	PRACK is complicated, for sure, but it's used for more than just
> > PSTN interworking and is more than mildly deployed=20
> depending upon the
> > environment.
>=20
> Agree its not just there; the draft says that was the origin=20
> of it, and=20
> that it is 'most common' in PSTN interworking devices. I=20
> believe this to=20
> be true. I'll change "mild" to "moderate".

Fine. No need to split hairs on this one, just highlighting the point.
Thanks.

>=20
> >=20
> > RFC3311:
> >=20
> > 	..but can be used to initiate a reliable request during session
> > establishment when a re-INVITE is not possible. This is key for
> > conveying information to an originator that cannot be conveyed in a
> > response either due to offer/answer complications or=20
> because a header is
> > not allowed in a response message type. We should also=20
> point out here
> > that when UPDATE is used to convey SDP, support for RFC3262=20
> is required
> > in some scenarios. I don't think this is widely recognized.=20
> Should also
> > call out that it can be used to convey mid-call information as well.
>=20
> changed to:
>=20
> RFC 3311  target=3D"RFC3311"/> defines the UPDATE method for SIP. This method is
> meant as a means for updating session information prior to the
> completion of the initial INVITE transaction. It can also be used to
>    update other information, such as the identity of the participant
>    ,
>    without involving an updated offer/answer exchange. It was=20
> developed
> initially to support RFC 3312  but has found
>    other uses.
> 

Excellent, thanks.

>=20
>=20
> >=20
> > RFC3608:
> >=20
> > 	You've captured the client perspective of the usage of
> > service-route, but from a server perspective, it's used by=20
> proxies to
> > capture the route set of a registration to know how to route future
> > requests on behalf of the client. In this role it has seen greater
> > deployment and applicability.
>=20
> I assume you mean the 3gpp route set validation based on=20
> service route?=20
> Not sure what else you might mean by "capture route set of a=20
> registration to know how to route future requests". The route header=20
> field in client requests is used to route future requests.
>=20
> In terms of DEPLOYMENT of this, if you mean the 3gpp stuff there is=20
> little deployment so far so I think my statement remains accurate.

Yes. Upon further reflection, I'll withdraw the comment.

>=20
> >=20
> > RFC 3841:
> >=20
> > 	Should probably call out the relationship between this RFC and
> > 3840.
>=20
> ok
>=20
> >=20
> > Need to remove duplicate entry for SDP negotiation under PSTN
> > interworking.
>=20
> which duplicate entry?

Sorry, you are correct. I misread reference to [105] to be duplicate to
later reference to [106]. Nevermind.

>=20
> >=20
> > RFC4244:
> >=20
> > 	Should remove reference to voicemail here. It has broader scope.
> > RFC4758 is intended for this purpose now (later comment).
>=20
> Hmm, well I didn't think there had been WG consensus to use 4458 for=20
> voicemail over 4424 - thats why it got published as=20
> informational (and=20
> indeed it was an individual submission IIRC).
>=20
> I agree it is more broad but its original target and most=20
> common usage=20
> AFAIK remains voicemail. Suggest:
>=20
> came to be routed to a particular destination. Its primary application
> was in support of voicemail services though it has more broad
>    applicability. 

Sounds fine.

>=20
>=20
> >=20
> >=20
> > Shouldn't we have an entry in this section for RFC3880, CPL?
>=20
> No, it doesn't meet the scope of this document:
>=20
> * SIP extensions
> * MIME objects just for SIP
> * SDP stuff just for SIP

Ok. Fair enough. I'm sure it'll come up in a BLISS document anyhow.

>=20
> >=20
> >=20
> >=20
> > Section 6:
> >=20
> > RFC3605:
> >=20
> > 	Should this be here and under the core specifications section? I
> > don't see this attribute show up in SDP very often=20
> (pre-ICE), but it is
> > necessary for some NAT traversal solutions. Perhaps only have a
> > reference to it here? Outside of NAT traversal, is there a primary
> > reason to have this RFC or ICE in the core specifications section?
>=20
> The spec says that certain docs get listed in multiple areas for=20
> convenience.
>=20
> It appears in the core specs because of the formal definition=20
> of core specs:
>=20
> 
> The core SIP specifications represent the set of specifications whose
> functionality is broadly applicable. An extension is broadly
> applicable if it fits into one of the following categories:
> 
>=20
> 
>=20
> For specifications that impact SIP session management, the
> extension would be used for almost every session initiated by a user
> agent
> 
>=20
> For specifications that impact SIP registrations, the extension
> would be used for almost every registration initiated by a user agent
> 
>=20
> For specifications that impact SIP subscriptions, the extension
> would be used for almost every subscription initiated by a user agent
> 
>=20
> 
>=20
> Our intention with ICE is that a client should always be=20
> using it; the=20
> majority of deployments involve at least one endpoint that=20
> MIGHT have a=20
> NAT issue, and thus ICE gets used. WHen ICE is used 3605=20
> comes along for=20
> the ride.

Fair enough.

>=20
> >=20
> > OUTBOUND:
> >=20
> > 	Doesn't outbound satisfy the requirements of a broadly
> > applicable extension to SIP? Seems like if ICE is a core=20
> specification,
> > that OUTBOUND should be considered one as well?
>=20
> Yes, and it is listed there.
>=20
> >=20
> > RFC3890:
> >=20
> > 	It's used extensively in other SDOs, paricularly wireless.
>=20
>=20
> Well, defined by an SDO is not the same as deployed. But anyway I'll=20
> remove the statement in this case since its a minor spec in any case.

The text used the term 'usage' so I didn't know precisely what you meant
(usage by other specifications vs. deployment). Just trying to capture
as much as we can, I agree it's a minor spec.

>=20
> >=20
> > RFC4730:
> >=20
> > 	Should probably explain here briefly, that 2833/4733 is most
> > commonly used to convey DTMF for SIP deployments, but the=20
> difference is
> > that KPML does it on the signaling path as opposed to the=20
> media path.
> > This is somewhat important given the low current deployment of KPML.
>=20
> OK.
>=20
> >=20
> >=20
> >=20
> > Section 13:
> >=20
> > 	Perhaps we should add an entry here for RFC4896 or make a note
> > under the entry for RFC3486 that RFC4896 updates both RFC3486 and
> > RFC3485 which is the static dictionary for SIP (which provides the
> > explicit coupling between SIGCOMP and SIP eluded to in the=20
> draft text).
> > The important bit for an entry to RFC3485 is that there are=20
> a few bugs
> > in the dictionary such that you'd need to refer to section=20
> 12 of RFC4896
> > to come up with a BCP implementation.
>=20
> I added 4896.
> 3486 doesn't meet the scope of hitchhikers:
>=20
> * SIP extensions
> * MIME objects just for SIP
> * SDP stuff just for SIP

Huh? How is 3486 not an extension to SIP? It defines a URI parameter for
the SIP/SIPS URI scheme along with other normative behavior specifically
for SIP (it's even in the title).

>=20
> >=20
> >=20
> >=20
> > Section 14:
> >=20
> > I think we should add an entry for RFC4758 to capture the voicemail
> > service URI as another important service URI RFC.
>=20
> added.
>=20
> >=20
> >=20
> > Section 15:
> >=20
> > RFC3853:
> >=20
> > 	May want to state that RFC3853 'formally' updates RFC3261, and
> > put a pointer to this from the core specifications section=20
> as a result
> > since it's a correction to 3261.
>=20
> Update noted.
> However its not core since SMIME is not used in every call. See above=20
> for the definition of a core spec. Just because a document=20
> updates SIP=20
> does not make it a core spec.

Fair enough.

>=20
> >=20
> > RFC3893:
> >=20
> > 	Should RFC3893 entry simply say something to the effect of 'use
> > RFC4474', or be dropped altogether?
>=20
> It basically does say that.

Ok. Agree.

>=20
> >=20
> > RFC3329:
> >=20
> > 	There are now three possible security models now in 3GPP: HTTP
> > DIGEST, AKA, and early-IMS. As early-IMS doesn't really=20
> involve much in
> > the way of security mechanisms within the SIP protocol, the=20
> coexistance
> > of it with digest or AKA seems to be very probable. Perhaps=20
> we should
> > just remove the last sentence and leave it up to the reader=20
> to decide if
> > it's needed for their purpose.
>=20
> I think this is a useful piece of guidance. I know I have=20
> answered this=20
> question many times about whether this feature is needed.

Ok. I hadn't even heard that question, but if it's being asked, then I'm
ok with the reader figuring it out for themselves either way.

>=20
> >=20
> >=20
> >=20
> > Section 16:
> >=20
> > Shouldn't we perhaps move RFC4796 from section 7 to this section?
>=20
> Why?

Section 16:=20

16.  Instant Messaging, Presence and Multimedia

   SIP provides extensions for instant messaging, presence, and
   multimedia.

Entry for RFC4796:

  RFC 4796, The SDP (Session Description Protocol) Content Attribute
   (S):  RFC 4796 [94] defines an SDP attribute for describing the
      purpose of a media stream. =20


Seems more related to multimedia than that it's a minor extension
although I don't feel strongly either way. If you want to leave it
alone, I'm ok with that. Was only a suggestion.

>=20
> >=20
> >=20
> > Section 17:
> >=20
> > Providing a pointer off to ECRIT seems useful here.
>=20
> That scope comment again.

Ok.

>=20
> Thanks,
> Jonathan R.
>=20
> --=20
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ=20
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 02:56:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsZaV-0003IC-9I; Thu, 15 Nov 2007 02:56:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsZaT-0003GR-QI
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 02:56:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsZaN-00039Y-Tr; Thu, 15 Nov 2007 02:56:28 -0500
Received: from mtagate2.de.ibm.com ([195.212.29.151])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IsZaL-0007G1-6E; Thu, 15 Nov 2007 02:56:27 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id lAF7uMD6030096;
	Thu, 15 Nov 2007 07:56:22 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com
	[9.149.165.229])
	by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.6) with
	ESMTP id lAF7uMrE2326754; Thu, 15 Nov 2007 08:56:22 +0100
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP
	id lAF7uLhb003061; Thu, 15 Nov 2007 08:56:22 +0100
Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com
	[9.149.167.114])
	by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP
	id lAF7uLqm003055; Thu, 15 Nov 2007 08:56:21 +0100
In-Reply-To: <473B7ECA.1080504@cisco.com>
References: 
	<473B7ECA.1080504@cisco.com>
To: Jonathan Rosenberg 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.0NP August 02, 2007
From: Avshalom Houri 
Message-ID: 
Date: Thu, 15 Nov 2007 09:56:21 +0200
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 |
	November 3, 2006) at 15/11/2007 09:56:21,
	Serialize complete at 15/11/2007 09:56:21
X-Spam-Score: 0.0 (/)
X-Scan-Signature: be1e5ad20f6e15b349a42c2dfbdd71ac
Cc: sip@ietf.org, rai@ietf.org
Subject: [Sip] Re: [RAI] Re: RAI review of
	draft-ietf-sip-hitchhikers-guide-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0050386182=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0050386182==
Content-Type: multipart/alternative;
	boundary="=_alternative 002B83F2C2257394_="

This is a multipart message in MIME format.
--=_alternative 002B83F2C2257394_=
Content-Type: text/plain; charset="US-ASCII"

Jonathan,

Agree with your all replies.

One comment only:

First paragraph in section 5:

   These extensions are general purpose enhancements to SIP, SDP and
   MIME that can serve a wide variety of uses.  However, they are not as
   widely used or as essential as the core specifications.

Maybe should be changed to put more emphasize that these RFCs are not
core specs and less on the wide deployment of them.
Current wording seems to say (at least to me) that wide deployment was the 
main
criteria.

--Avshalom








Jonathan Rosenberg  
15/11/2007 01:03

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
sip@ietf.org, rai@ietf.org
Subject
[RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03






Thanks for the comments, Avshalom. Responses below:

Avshalom Houri wrote:
> 
> I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03
> from the perspective of presence and the SIMPLE group but ended up in
> commenting on the whole document at the end.
> 
> For background on RAI-ART, please see the FAQ at
> _http://www.softarmor.com/rai/art/rai-art-FAQ.html_ 
> 
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> In my opinion this draft is basically ready for publication, but has
> nits that should be fixed before publication.
> 
> Citations from the draft are marked by <<< text from draft >>>
> 
> General comments
> ----------------
> 
> By its nature there are a lot of reference to drafts in the document.
> It will take a lot of time for these documents to become and RFC.
> So how we are going to publish this as an RFC? Since when the
> referenced drafts will become an RFC, this draft would have to be
> updated with new drafts, will it be held in the
> RFC ED queue for ever?

We had a whole thread on this, so I won't address this again here, but 
rather focus on your other comments.

> 
> How do we gauge the usage of an RFC or a draft? There are many places
> here that it is said that this or that RFC/draft got widely implemented
> or not.
> How it is measured? The wide implementation test is used to decide
> whether an RFC or draft are core or not and therefore there should be
> some text explaining how the wide implementation was determined.

No. Wide usage is not used to determine core or not. There is a litmus 
test defined for inclusion as a core spec:



For specifications that impact SIP session management, the
extension would be used for almost every session initiated by a user
agent


For specifications that impact SIP registrations, the extension
would be used for almost every registration initiated by a user agent


For specifications that impact SIP subscriptions, the extension
would be used for almost every subscription initiated by a user agent




this definition is based entirely on the functionality of the spec and 
not judgement on its deployment.

The comments on deployment in the document are based on my own 
observation and awareness. Please feel free to suggest changes, that 
part of the description can only be improved with data from additional 
folks.

> 
> Better change RFC XXXX (before the reference number in []) to the name
> of the draft (with no version number), it will make the ride smoother.

OK. Changing to symrefs helps a lot.

> 
> An introduction that details the various grouping should be added. It
> should include additional text on the group and what was the criteria
> for putting an RFC/draft in the group.

OK, I added a list in the introduction along with brief classification 
description.

> 
> 2.  Scope of this Document
> --------------------------
> 
> <<<
>    o  Any specification that defines an extension to SIP itself, where
>       an extension is a mechanism that changes or updates in some way a
>       behavior specified in RFC 3261
>  >>>
> 
> "to SIP itself" sounds vague. It will be better to say:"to RFC 3261"
> instead.
> Maybe there should be an earlier definition of RFC 3261 as the SIP 
nucleus
> (or the president of the galaxy) and that RFCs/drafts mentioned in this
> document are based on their relation to it.

changed this sentence to:

Any specification that defines an extension to RFC 3261,
where an extension is a mechanism that changes or updates in
some way a behavior specified there.



> 
> <<<
>    Excluded from this list are requirements, architectures, registry
>    definitions, non-normative frameworks, and processes.  Best Current
>    Practices are included when they normatively define mechanisms for
>    accomplishing a task.
>  >>>
> 
> "normatively define" not sure what is meant by normative with
> respect to BCP. Seems like a contradiction in terms.

Actually BCPs can contain normative text and are, in many ways, very 
much like a PS.

> 
> 3.  Core SIP Specifications
> ---------------------------
> 
> If we think on presence as eventually replacing registration, since it
> carries much more information about the availability of the user,
> should we consider also presence as a towel?
> 
> <<<
>    RFC 3261, The Session Initiation Protocol (S):  RFC 3261 [1] is the
>       core SIP protocol itself.  RFC 3261 is an update to RFC 2543 [9].
>       It is the president of the galaxy [42] as far as the suite of SIP
>       specifications is concerned.
>  >>>
> 
> RFC 3261 is a very big document. Should it be treated as one or it can
> be divided into parts in this document e.g. proxy, client etc.? I am not
> sure what would be better.

The purpose here is to just enumerate the specs and describe each. I 
don't think the aim is to break it up here.

> 
> 4.  Public Switched Telephone Network (PSTN) Interworking
> ---------------------------------------------------------
> 
> Regarding RFC 3578
> Ugly in one corner of the galaxy may be beautiful on the other of it :-)
> 
> 7.  Minor Extensions
> --------------------
> 
> <<<
>    RFC XXXX, Referring to Multiple Resources in SIP (S):  RFC XXXX [44]
>       allows a UA sending a REFER to ask the recipient of the REFER to
>       generate multiple SIP requests, not just one.  This is useful for
>       conferencing, where a client would like to ask a conference server
>       to eject multiple users.
>  >>>
> 
> Should not this be referred to in the conferencing section also?

ok

> 
> <<<
>    RFC 4483, A Mechanism for Content Indirection in Session Initiation
>    Protocol (SIP) Messages (S):  RFC 4483 [89] defines a mechanism for
>       content indirection.  Instead of carrying an object within a SIP
>       body, a URL reference is carried instead, and the recipient
>       dereferences the URL to obtain the object.  The specification has
>       potential applicability for sending large instant messages, but
>       has yet to find much actual use.
>  >>>
> 
> The specification has also potential for sending large presence
> documents via a URL.

sure, but I don't think it would really be classified as a 
presence-related spec.

> 
> <<<
>    RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
>    Control Protocol (BFCP) Streams (S):  RFC 4583 [91] defines a
>       mechanism in SDP to signal floor control streams that use BFCP.
>       It is used for Push-To-Talk and conference floor control.
>  >>>
> 
> Should not this be referred to in the conferencing section also?

ok

> 
> <<<
>    RFC XXXX, Connectivity Preconditions for Session Description Protocol
>    Media Streams (S):  RFC XXXX [93] defines a usage of the precondition
>       framework [59].  The connectivity precondition makes sure that the
>       session doesn't get established until actual packet connectivity
>       is checked.
>  >>>
> 
> Should not this be referred to in the QoS section also?

Well, the line is fine, but connectivity preconditions is not about QoS 
as most folks think of it (i.e., bandwidth reservation).

> 
> 8.  Conferencing
> ----------------
> 
> The Conferencing section should be before or after "Instant Messaging,
> Presence and Multimedia" as it is also an application. See the comment
> on whether presence is an application or not later.

moved.

> 
> 10.  Event Framework and Packages
> ----------------------------------
> 
> Suggest to divide this section to event framework section and to
> packages section. The event framework should include 3265, 3903, 4662
> and subnot-etags which define the event framework itself.
> The other section will the packages sections that will list the
> packages.

OK.

> 
> Alternatively, many of the packages are mentioned in their proper
> section so it may be that all the event packages can be fit into
> their relevant section and there is not a need for packages section.

I think its useful to list them.

> 
> 11.  Quality of Service
> -----------------------
> 
> <<<
>    RFC 3313, Private SIP Extensions for Media Authorization (I):  RFC
>       3313 [61] defines a P-header that provides a mechanism for passing
>       an authorization token between SIP and a network QoS reservation
>       protocol like RSVP.  Its purpose is to make sure network QoS is
>       only granted if a client has made a SIP call through the same
>       providers network.  This specification is sometimes referred to as
>       the SIP walled garden specification by the truly paranoid androids
>       in the SIP community.  This is because it requires coupling of
>       signaling and the underlying IP network.
>  >>> 
> 
> Understand that being a "truly paranoid" is a virtue? :-)
> 
> 15.  Security Mechanisms
> ------------------------
> 
> Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474
> (Identity) be mentioned here also? 

Hmm, well Brian had suggested that RFC 3325 has nothing to do with 
'secure caller ID' so that one is definitely debatable.

4474 definitely fits here. 3323 is kind of fuzzy, but I'll include.

> 
> 16.  Instant Messaging, Presence and Multimedia
> -----------------------------------------------
> 
> Maybe create an applications section and put also conferencing as a type
> of an application.

Applications is really broad. The service URI stuff could be considered 
an app too. I think its valuable to have finer granularity than that.

> 
> Including presence here with IM and multimedia seems that presence is
> regarded as an additional type of media. I am not sure that I agree with
> this. Presence is an enabler for many other applications and it deserves
> a section of its own.

Certainly its valuable, sufficiently so that simple-simple addresses it 
more completely and obviously separates IM from presence. But its not 
the emphasis of this document. If I split off presence there is only two 
docs in there (winfo and presence package), and only one in IM (3428) so 
this seems to argue for keeping them together. I did add a reference to 
simple-simple in the intro to let people know there is a more complete 
source of presence specs elsewhere.

> 
> It is very tempting to include the simple-simple content here
> (as an appendix?). If simple-simple is not to be included here, there
> should be at least a reference to simple-simple as for presence
> there are so many documents that are essential for doing presence and
> are not mentioned here (e.g. watcher format, RPID, presence rules,
> partial notify and publish and many many more).

done.

>  Roughly counting, there
> are about 20-25 RFCs/drafts that are very relevant to presence that are
> mentioned in simple-simple in addition to the ones that are mentioned 
here.

right, since they are not sip extensions.

> 
> The MSRP drafts seem to be forgotten?

Not a sip extension. RTP isn't listed here either.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
RAI mailing list
RAI@ietf.org
https://www1.ietf.org/mailman/listinfo/rai


--=_alternative 002B83F2C2257394_=
Content-Type: text/html; charset="US-ASCII"



Jonathan,



Agree with your all replies.



One comment only:



First paragraph in section 5:



   These extensions are general
purpose enhancements to SIP, SDP and

   MIME that can serve a
wide variety of uses.  However, they are not as

   widely used or as essential
as the core specifications.



Maybe should be changed to put more
emphasize that these RFCs are not

core specs and less on the wide deployment
of them.

Current wording seems to say (at least
to me) that wide deployment was the main

criteria.



--Avshalom




















Jonathan Rosenberg <jdrosen@cisco.com>


15/11/2007 01:03








To

Avshalom Houri/Haifa/IBM@IBMIL




cc

sip@ietf.org, rai@ietf.org




Subject

[RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03

















Thanks for the comments, Avshalom. Responses below:



Avshalom Houri wrote:

> 

> I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03

> from the perspective of presence and the SIMPLE group but ended up
in

> commenting on the whole document at the end.

> 

> For background on RAI-ART, please see the FAQ at

> _http://www.softarmor.com/rai/art/rai-art-FAQ.html_ 

> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>

> 

> Please resolve these comments along with any other Last Call comments

> you may receive.

> 

> In my opinion this draft is basically ready for publication, but has

> nits that should be fixed before publication.

> 

> Citations from the draft are marked by <<< text from draft
>>>

> 

> General comments

> ----------------

> 

> By its nature there are a lot of reference to drafts in the document.

> It will take a lot of time for these documents to become and RFC.

> So how we are going to publish this as an RFC? Since when the

> referenced drafts will become an RFC, this draft would have to be

> updated with new drafts, will it be held in the

> RFC ED queue for ever?



We had a whole thread on this, so I won't address this again here, but


rather focus on your other comments.



> 

> How do we gauge the usage of an RFC or a draft? There are many places

> here that it is said that this or that RFC/draft got widely implemented

> or not.

> How it is measured? The wide implementation test is used to decide

> whether an RFC or draft are core or not and therefore there should
be

> some text explaining how the wide implementation was determined.



No. Wide usage is not used to determine core or not. There is a litmus


test defined for inclusion as a core spec:



<list style="symbols">



<t>For specifications that impact SIP session management, the

extension would be used for almost every session initiated by a user

agent

</t>



<t>For specifications that impact SIP registrations, the extension

would be used for almost every registration initiated by a user agent

</t>



<t>For specifications that impact SIP subscriptions, the extension

would be used for almost every subscription initiated by a user agent

</t>



</list>



this definition is based entirely on the functionality of the spec and


not judgement on its deployment.



The comments on deployment in the document are based on my own 

observation and awareness. Please feel free to suggest changes, that 

part of the description can only be improved with data from additional


folks.



> 

> Better change RFC XXXX (before the reference number in []) to the
name

> of the draft (with no version number), it will make the ride smoother.



OK. Changing to symrefs helps a lot.



> 

> An introduction that details the various grouping should be added.
It

> should include additional text on the group and what was the criteria

> for putting an RFC/draft in the group.



OK, I added a list in the introduction along with brief classification


description.



> 

> 2.  Scope of this Document

> --------------------------

> 

> <<<

>    o  Any specification that defines an extension to
SIP itself, where

>       an extension is a mechanism that changes or updates
in some way a

>       behavior specified in RFC 3261

>  >>>

> 

> "to SIP itself" sounds vague. It will be better to say:"to
RFC 3261"

> instead.

> Maybe there should be an earlier definition of RFC 3261 as the SIP
nucleus

> (or the president of the galaxy) and that RFCs/drafts mentioned in
this

> document are based on their relation to it.



changed this sentence to:



<t>Any specification that defines an extension to RFC 3261,

where an extension is a mechanism that changes or updates in

some way a behavior specified there.

</t>





> 

> <<<

>    Excluded from this list are requirements, architectures,
registry

>    definitions, non-normative frameworks, and processes.
 Best Current

>    Practices are included when they normatively define mechanisms
for

>    accomplishing a task.

>  >>>

>    

> "normatively define" not sure what is meant by normative
with

> respect to BCP. Seems like a contradiction in terms.



Actually BCPs can contain normative text and are, in many ways, very 

much like a PS.



> 

> 3.  Core SIP Specifications

> ---------------------------

> 

> If we think on presence as eventually replacing registration, since
it

> carries much more information about the availability of the user,

> should we consider also presence as a towel?

> 

> <<<

>    RFC 3261, The Session Initiation Protocol (S):  RFC
3261 [1] is the

>       core SIP protocol itself.  RFC 3261 is an
update to RFC 2543 [9].

>       It is the president of the galaxy [42] as far
as the suite of SIP

>       specifications is concerned.

>  >>>

> 

> RFC 3261 is a very big document. Should it be treated as one or it
can

> be divided into parts in this document e.g. proxy, client etc.? I
am not

> sure what would be better.



The purpose here is to just enumerate the specs and describe each. I 

don't think the aim is to break it up here.



> 

> 4.  Public Switched Telephone Network (PSTN) Interworking

> ---------------------------------------------------------

> 

> Regarding RFC 3578

> Ugly in one corner of the galaxy may be beautiful on the other of
it :-)

> 

> 7.  Minor Extensions

> --------------------

> 

> <<<

>    RFC XXXX, Referring to Multiple Resources in SIP (S):
 RFC XXXX [44]

>       allows a UA sending a REFER to ask the recipient
of the REFER to

>       generate multiple SIP requests, not just one.
 This is useful for

>       conferencing, where a client would like to ask
a conference server

>       to eject multiple users.

>  >>>

> 

> Should not this be referred to in the conferencing section also?



ok



> 

> <<<

>    RFC 4483, A Mechanism for Content Indirection in Session
Initiation

>    Protocol (SIP) Messages (S):  RFC 4483 [89] defines
a mechanism for

>       content indirection.  Instead of carrying
an object within a SIP

>       body, a URL reference is carried instead, and
the recipient

>       dereferences the URL to obtain the object.  The
specification has

>       potential applicability for sending large instant
messages, but

>       has yet to find much actual use.

>  >>>

> 

> The specification has also potential for sending large presence

> documents via a URL.



sure, but I don't think it would really be classified as a 

presence-related spec.



> 

> <<<

>    RFC 4583, Session Description Protocol (SDP) Format for
Binary Floor

>    Control Protocol (BFCP) Streams (S):  RFC 4583 [91]
defines a

>       mechanism in SDP to signal floor control streams
that use BFCP.

>       It is used for Push-To-Talk and conference floor
control.

>  >>>

> 

> Should not this be referred to in the conferencing section also?



ok



> 

> <<<

>    RFC XXXX, Connectivity Preconditions for Session Description
Protocol

>    Media Streams (S):  RFC XXXX [93] defines a usage
of the precondition

>       framework [59].  The connectivity precondition
makes sure that the

>       session doesn't get established until actual
packet connectivity

>       is checked.

>  >>>

> 

> Should not this be referred to in the QoS section also?



Well, the line is fine, but connectivity preconditions is not about QoS


as most folks think of it (i.e., bandwidth reservation).



> 

> 8.  Conferencing

> ----------------

> 

> The Conferencing section should be before or after "Instant Messaging,

> Presence and Multimedia" as it is also an application. See the
comment

> on whether presence is an application or not later.



moved.



> 

> 10.  Event Framework and Packages

> ----------------------------------

> 

> Suggest to divide this section to event framework section and to

> packages section. The event framework should include 3265, 3903, 4662

> and subnot-etags which define the event framework itself.

> The other section will the packages sections that will list the

> packages.



OK.



> 

> Alternatively, many of the packages are mentioned in their proper

> section so it may be that all the event packages can be fit into

> their relevant section and there is not a need for packages section.



I think its useful to list them.



> 

> 11.  Quality of Service

> -----------------------

> 

> <<<

>    RFC 3313, Private SIP Extensions for Media Authorization
(I):  RFC

>       3313 [61] defines a P-header that provides a
mechanism for passing

>       an authorization token between SIP and a network
QoS reservation

>       protocol like RSVP.  Its purpose is to make
sure network QoS is

>       only granted if a client has made a SIP call
through the same

>       providers network.  This specification is
sometimes referred to as

>       the SIP walled garden specification by the truly
paranoid androids

>       in the SIP community.  This is because it
requires coupling of

>       signaling and the underlying IP network.

>  >>>      

> 

> Understand that being a "truly paranoid" is a virtue? :-)

> 

> 15.  Security Mechanisms

> ------------------------

> 

> Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474

> (Identity) be mentioned here also?    



Hmm, well Brian had suggested that RFC 3325 has nothing to do with 

'secure caller ID' so that one is definitely debatable.



4474 definitely fits here. 3323 is kind of fuzzy, but I'll include.



> 

> 16.  Instant Messaging, Presence and Multimedia

> -----------------------------------------------

> 

> Maybe create an applications section and put also conferencing as
a type

> of an application.



Applications is really broad. The service URI stuff could be considered


an app too. I think its valuable to have finer granularity than that.



> 

> Including presence here with IM and multimedia seems that presence
is

> regarded as an additional type of media. I am not sure that I agree
with

> this. Presence is an enabler for many other applications and it deserves

> a section of its own.



Certainly its valuable, sufficiently so that simple-simple addresses it


more completely and obviously separates IM from presence. But its not 

the emphasis of this document. If I split off presence there is only two


docs in there (winfo and presence package), and only one in IM (3428) so


this seems to argue for keeping them together. I did add a reference to


simple-simple in the intro to let people know there is a more complete


source of presence specs elsewhere.



> 

> It is very tempting to include the simple-simple content here

> (as an appendix?). If simple-simple is not to be included here, there

> should be at least a reference to simple-simple as for presence

> there are so many documents that are essential for doing presence
and

> are not mentioned here (e.g. watcher format, RPID, presence rules,

> partial notify and publish and many many more).



done.



>  Roughly counting, there

> are about 20-25 RFCs/drafts that are very relevant to presence that
are

> mentioned in simple-simple in addition to the ones that are mentioned
here.



right, since they are not sip extensions.



> 

> The MSRP drafts seem to be forgotten?



Not a sip extension. RTP isn't listed here either.



-Jonathan R.

-- 

Jonathan D. Rosenberg, Ph.D.            
      600 Lanidex Plaza

Cisco Fellow                  
                Parsippany, NJ
07054-2711

Cisco Systems

jdrosen@cisco.com                
             FAX:   (973) 952-5050

http://www.jdrosen.net
                     
  PHONE: (973) 952-5000

http://www.cisco.com



_______________________________________________

RAI mailing list

RAI@ietf.org

https://www1.ietf.org/mailman/listinfo/rai




--=_alternative 002B83F2C2257394_=--



--===============0050386182==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0050386182==--





From sip-bounces@ietf.org Thu Nov 15 03:47:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsaNe-0005FL-8U; Thu, 15 Nov 2007 03:47:22 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsaNb-00059n-Qp
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 03:47:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsaNb-00058j-GH for sip@ietf.org; Thu, 15 Nov 2007 03:47:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZl7-0000CM-RV
	for sip@ietf.org; Thu, 15 Nov 2007 03:07:33 -0500
Received: from gws04.hcl.in ([203.105.186.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsZl1-0001HW-GR
	for sip@ietf.org; Thu, 15 Nov 2007 03:07:33 -0500
Received: from gws04.hcl.in (gws04 [10.249.64.135])
	by localhost.hcl.in (Postfix) with ESMTP
	id AF185364090; Thu, 15 Nov 2007 13:37:24 +0530 (IST)
Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by 
	gws04.hcl.in (Postfix) with ESMTPid 9F4F2364084;
	Thu, 15 Nov 2007 13:37:24 +0530 (IST)
Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by 
	chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830);
	Thu, 15 Nov 2007 13:37:23 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Nov 2007 13:36:20 +0530
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Can a transaction stateless proxy support Outbound draft? If 
	yes, how will the response be sent back the UA behind NAT
Thread-Index: AcgnWKQSGvsSaIAoQDqcqxIc6t0t5AABMJJA
From: "Karthikeyan Gopal , TLS-Chennai" 
To: 
X-OriginalArrivalTime: 15 Nov 2007 08:07:24.0195 (UTC) 
	FILETIME=[8DF28730:01C8275E]
X-imss-version: 2.049
X-imss-result: Passed
X-imss-scanInfo: M:T L:E SM:1
X-imss-tmaseResult: TT:1 TS:-0.3538 TC:1F TRN:10 TV:5.0.1023(15546.003)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
X-TMDA-Confirmed: Thu, 15 Nov 2007 03:47:19 -0500
Cc: dean.willis@softarmor.com
Subject: [Sip] Can a transaction stateless proxy support Outbound draft? If
	yes, how will the response be sent back the UA behind NAT
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Hi All,
    Can a transaction stateless proxy support Outbound draft? If yes,
how will the response be sent back the UA behind NAT?
Thanks & Regards,
Karthikeyan=2EG



DISCLAIMER:
---------------------------------------------------------------------------=
--------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and=
 intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its=
 affiliates=2E Any views or opinions presented in=20
this email are solely those of the author and may not necessarily reflect=
 the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,=
 distribution and / or publication of=20
this message without the prior written consent of the author of this e-mail=
 is strictly prohibited=2E If you have=20
received this email in error please delete it and notify the sender=
 immediately=2E Before opening any mail and=20
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------=
--------------------------------------------



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 09:04:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsfKY-0006LO-ME; Thu, 15 Nov 2007 09:04:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsfKW-0006Jl-Ga
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 09:04:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsfKW-0006JD-2v
	for sip@ietf.org; Thu, 15 Nov 2007 09:04:28 -0500
Received: from smtp-1.hut.fi ([130.233.228.91])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsfKV-0005X8-Bn
	for sip@ietf.org; Thu, 15 Nov 2007 09:04:27 -0500
Received: from localhost (katosiko.hut.fi [130.233.228.115])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAFE4PaA023409
	for ; Thu, 15 Nov 2007 16:04:25 +0200
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new,
	port 10024) with LMTP id 11873-17-9 for ;
	Thu, 15 Nov 2007 16:04:25 +0200 (EET)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAFE2QnI022391
	for ; Thu, 15 Nov 2007 16:02:27 +0200
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id AA8D63A2CD8
	for ; Thu, 15 Nov 2007 16:02:26 +0200 (EET)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 00506-08 for ;
	Thu, 15 Nov 2007 16:02:25 +0200 (EET)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id 9633E3A2CCC
	for ; Thu, 15 Nov 2007 16:02:25 +0200 (EET)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Thu, 15 Nov 2007 16:02:25 +0200
Message-ID: <20071115160225.rxh3b27bsccwook0@horde-intra.tml.hut.fi>
Date: Thu, 15 Nov 2007 16:02:25 +0200
From: sergiole@tml.hut.fi
To: sip@ietf.org
Subject: Re: [Sip] Can a transaction stateless proxy support Outbound
	draft? If yes, how will the response be sent back the UA behind NAT
References: 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Hi,


  Suppose that the proxy is stateless. Could you clarify the reasoning =20
behind your question: "how will the response be sent back the UA =20
behind NAT?"

  We are asking a similar question from time ago but I don't know if =20
the problem you are targeting is the same as our.

Regards

Sergio


Quoting "Karthikeyan Gopal , TLS-Chennai" :

>
>
> Hi All,
>     Can a transaction stateless proxy support Outbound draft? If yes,
> how will the response be sent back the UA behind NAT?
> Thanks & Regards,
> Karthikeyan.G
>
>
>
> DISCLAIMER:
> --------------------------------------------------------------------------=
---------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential  =20
> and intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its  =20
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily  =20
> reflect the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,  =20
> modification, distribution and / or publication of
> this message without the prior written consent of the author of this =20
>  e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender  =20
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> --------------------------------------------------------------------------=
---------------------------------------------
>
>
>
> _______________________________________________
> 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
>





_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 09:53:15 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Isg5g-0000v2-Jj; Thu, 15 Nov 2007 09:53:12 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Isg5f-0000sf-Ew
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 09:53:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg5e-0000qw-Jk
	for sip@ietf.org; Thu, 15 Nov 2007 09:53:10 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isg5Z-0007Yn-KO
	for sip@ietf.org; Thu, 15 Nov 2007 09:53:10 -0500
Received: from rly05f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly05f.srv.mailcontrol.com (MailControl) with ESMTP id
	lAFEqsP6014917 for ; Thu, 15 Nov 2007 14:52:54 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly05f.srv.mailcontrol.com (MailControl) id lAFEq4hZ012602
	for sip@ietf.org; Thu, 15 Nov 2007 14:52:04 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly05f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lAFEoakx005446; Thu, 15 Nov 2007 14:52:04 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Nov 2007 14:51:40 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Can a transaction stateless proxy support Outbound draft?
	Ifyes, how will the response be sent back the UA behind NAT
Date: Thu, 15 Nov 2007 14:51:01 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60A02868@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can a transaction stateless proxy support Outbound draft?
	Ifyes, how will the response be sent back the UA behind NAT
Thread-Index: AcgnWKQSGvsSaIAoQDqcqxIc6t0t5AABMJJAAA4bw0A=
From: "Attila Sipos" 
To: "Karthikeyan Gopal , TLS-Chennai" , 
X-OriginalArrivalTime: 15 Nov 2007 14:51:40.0249 (UTC)
	FILETIME=[07AEA490:01C82797]
X-Scanned-By: MailControl A-08-00-01 (www.mailcontrol.com) on 10.70.1.115
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: dean.willis@softarmor.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


I think a stateless proxy CAN support outbound.

As long as the stateless proxy can store registrations (well, what's the
point if it can't) then it can keep up a flow back to any registering
UA.

When it comes to routing a request to a registered UA, it will route it
using the establiashed flow.  For requests from the registered UA, the
responses will be routed back to the UA using the established flow.

Can you see a problem with this?  It seems like it should work to me.

Regards,
Attila


=20

-----Original Message-----
From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]=20
Sent: 15 November 2007 08:06
To: sip@ietf.org
Cc: dean.willis@softarmor.com
Subject: [Sip] Can a transaction stateless proxy support Outbound draft?
Ifyes, how will the response be sent back the UA behind NAT



Hi All,
    Can a transaction stateless proxy support Outbound draft? If yes,
how will the response be sent back the UA behind NAT?
Thanks & Regards,
Karthikeyan.G



DISCLAIMER:
------------------------------------------------------------------------
-----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its
affiliates. Any views or opinions presented in this email are solely
those of the author and may not necessarily reflect the opinions of HCL
or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without
the prior written consent of the author of this e-mail is strictly
prohibited. If you have received this email in error please delete it
and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

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



_______________________________________________
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


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 10:15:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsgRI-0004Gh-4U; Thu, 15 Nov 2007 10:15:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsgRG-0004DT-Nr
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 10:15:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgRG-0004Br-D6
	for sip@ietf.org; Thu, 15 Nov 2007 10:15:30 -0500
Received: from smtp-1.hut.fi ([130.233.228.91])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsgRA-0008Eo-DM
	for sip@ietf.org; Thu, 15 Nov 2007 10:15:30 -0500
Received: from localhost (katosiko.hut.fi [130.233.228.115])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAFFFHJC004771;
	Thu, 15 Nov 2007 17:15:17 +0200
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new,
	port 10024)
	with LMTP id 21517-28-3; Thu, 15 Nov 2007 17:15:15 +0200 (EET)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAFFDoxW003814;
	Thu, 15 Nov 2007 17:13:50 +0200
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 59EEE3A2CD9;
	Thu, 15 Nov 2007 17:13:50 +0200 (EET)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 26687-05; Thu, 15 Nov 2007 17:13:48 +0200 (EET)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id A68643A2CCC;
	Thu, 15 Nov 2007 17:13:48 +0200 (EET)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Thu, 15 Nov 2007 17:13:48 +0200
Message-ID: <20071115171348.oypdq3y01wocw48o@horde-intra.tml.hut.fi>
Date: Thu, 15 Nov 2007 17:13:48 +0200
From: sergiole@tml.hut.fi
To: sip@ietf.org
Subject: RE: [Sip] Can a transaction stateless proxy support Outbound
	draft? Ifyes, how will the response be sent back the UA behind NAT
References: <680808427CF931459462C3D78CB5EC60A02868@EXVS02.nasstar-t1.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC60A02868@EXVS02.nasstar-t1.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: Attila Sipos 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> For requests from the registered UA, the
> responses will be routed back to the UA using the established flow.

  That is not possible if we limit to the draft.
  Normal responses use the information in the Via header, and to use =20
the flow we need a flow token (that is not available in the Via)...


Sergio


Quoting Attila Sipos :

>
> I think a stateless proxy CAN support outbound.
>
> As long as the stateless proxy can store registrations (well, what's the
> point if it can't) then it can keep up a flow back to any registering
> UA.
>
> When it comes to routing a request to a registered UA, it will route it
> using the establiashed flow.  For requests from the registered UA, the
> responses will be routed back to the UA using the established flow.
>
> Can you see a problem with this?  It seems like it should work to me.
>
> Regards,
> Attila
>
>
>
>
> -----Original Message-----
> From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]
> Sent: 15 November 2007 08:06
> To: sip@ietf.org
> Cc: dean.willis@softarmor.com
> Subject: [Sip] Can a transaction stateless proxy support Outbound draft?
> Ifyes, how will the response be sent back the UA behind NAT
>
>
>
> Hi All,
>     Can a transaction stateless proxy support Outbound draft? If yes,
> how will the response be sent back the UA behind NAT?
> Thanks & Regards,
> Karthikeyan.G
>
>
>
> DISCLAIMER:
> ------------------------------------------------------------------------
> -----------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its
> affiliates. Any views or opinions presented in this email are solely
> those of the author and may not necessarily reflect the opinions of HCL
> or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of this message without
> the prior written consent of the author of this e-mail is strictly
> prohibited. If you have received this email in error please delete it
> and notify the sender immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> ------------------------------------------------------------------------
> -----------------------------------------------
>
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
>





_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 10:56:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ish4s-0002IM-4E; Thu, 15 Nov 2007 10:56:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ish4q-0002H3-Ue
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 10:56:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ish4q-0002Gt-Ks
	for sip@ietf.org; Thu, 15 Nov 2007 10:56:24 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ish4l-0001f4-9X
	for sip@ietf.org; Thu, 15 Nov 2007 10:56:24 -0500
Received: from rly24f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly24f.srv.mailcontrol.com (MailControl) with ESMTP id
	lAFFu1sk012616 for ; Thu, 15 Nov 2007 15:56:18 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly24f.srv.mailcontrol.com (MailControl) id lAFFtwM4012574
	for sip@ietf.org; Thu, 15 Nov 2007 15:55:58 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly24f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lAFFtU2F010118; Thu, 15 Nov 2007 15:55:58 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Nov 2007 15:56:09 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Can a transaction stateless proxy support Outbounddraft?
	Ifyes, how will the response be sent back the UA behind NAT
Date: Thu, 15 Nov 2007 15:55:30 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60A02910@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can a transaction stateless proxy support Outbounddraft?
	Ifyes, how will the response be sent back the UA behind NAT
Thread-Index: Acgnmo4pqPElCUWlS0ObfI9lwRVGzQAAnNdQ
From: "Attila Sipos" 
To: , 
X-OriginalArrivalTime: 15 Nov 2007 15:56:09.0159 (UTC)
	FILETIME=[09BB7570:01C827A0]
X-Scanned-By: MailControl A-08-00-02 (www.mailcontrol.com) on 10.70.1.134
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.0 (-)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

>>  That is not possible if we limit to the draft.
>>  Normal responses use the information in the Via header, and to
>>use the flow we need a flow token (that is not available in the
Via)...

But couldn't you encode the flow token into the Via's branch parameter?
You'd have to make sure you didn't break SIP grammar rules
(but a variation of base 64 would solve that).

Would there be a problem with that?

Regards,
Attila



-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: 15 November 2007 15:14
To: sip@ietf.org
Cc: Attila Sipos
Subject: RE: [Sip] Can a transaction stateless proxy support
Outbounddraft? Ifyes, how will the response be sent back the UA behind
NAT



> For requests from the registered UA, the responses will be routed back

> to the UA using the established flow.

  That is not possible if we limit to the draft.
  Normal responses use the information in the Via header, and to use the
flow we need a flow token (that is not available in the Via)...


Sergio


Quoting Attila Sipos :

>
> I think a stateless proxy CAN support outbound.
>
> As long as the stateless proxy can store registrations (well, what's=20
> the point if it can't) then it can keep up a flow back to any=20
> registering UA.
>
> When it comes to routing a request to a registered UA, it will route=20
> it using the establiashed flow.  For requests from the registered UA,=20
> the responses will be routed back to the UA using the established
flow.
>
> Can you see a problem with this?  It seems like it should work to me.
>
> Regards,
> Attila
>
>
>
>
> -----Original Message-----
> From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]
> Sent: 15 November 2007 08:06
> To: sip@ietf.org
> Cc: dean.willis@softarmor.com
> Subject: [Sip] Can a transaction stateless proxy support Outbound
draft?
> Ifyes, how will the response be sent back the UA behind NAT
>
>
>
> Hi All,
>     Can a transaction stateless proxy support Outbound draft? If yes,=20
> how will the response be sent back the UA behind NAT?
> Thanks & Regards,
> Karthikeyan.G
>
>
>
> DISCLAIMER:
> ----------------------------------------------------------------------
> --
> -----------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and

> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its=20
> affiliates. Any views or opinions presented in this email are solely=20
> those of the author and may not necessarily reflect the opinions of=20
> HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,=20
> modification, distribution and / or publication of this message=20
> without the prior written consent of the author of this e-mail is=20
> strictly prohibited. If you have received this email in error please=20
> delete it and notify the sender immediately. Before opening any mail=20
> and attachments please check them for viruses and defect.
>
> ----------------------------------------------------------------------
> --
> -----------------------------------------------
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip
>





_______________________________________________
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


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 11:20:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IshRv-00029V-DT; Thu, 15 Nov 2007 11:20:15 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IshRl-0001oM-0G
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:20:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IshRk-0001nD-8q
	for sip@ietf.org; Thu, 15 Nov 2007 11:20:04 -0500
Received: from smtp-1.hut.fi ([130.233.228.91])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IshRj-0003mt-9f
	for sip@ietf.org; Thu, 15 Nov 2007 11:20:04 -0500
Received: from localhost (putosiko.hut.fi [130.233.228.114])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAFGK1Fo008582;
	Thu, 15 Nov 2007 18:20:01 +0200
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new,
	port 10024)
	with LMTP id 25709-02-5; Thu, 15 Nov 2007 18:20:01 +0200 (EET)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAFGIRqo007613;
	Thu, 15 Nov 2007 18:18:28 +0200
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 629B03A2CD8;
	Thu, 15 Nov 2007 18:18:27 +0200 (EET)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 28246-08; Thu, 15 Nov 2007 18:18:25 +0200 (EET)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id 89B883A2CCC;
	Thu, 15 Nov 2007 18:18:25 +0200 (EET)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Thu, 15 Nov 2007 18:18:25 +0200
Message-ID: <20071115181825.kmch1915skk8sc8s@horde-intra.tml.hut.fi>
Date: Thu, 15 Nov 2007 18:18:25 +0200
From: sergiole@tml.hut.fi
To: sip@ietf.org
Subject: RE: [Sip] Can a transaction stateless proxy support Outbounddraft?
	Ifyes, how will the response be sent back the UA behind NAT
References: <680808427CF931459462C3D78CB5EC60A02910@EXVS02.nasstar-t1.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC60A02910@EXVS02.nasstar-t1.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Cc: Attila Sipos 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


> But couldn't you encode the flow token into the Via's branch parameter?

  Yes, it is possible, but the draft does not tell anything about responses.
  To put the flow token in the Via I see 2 options : 1) ensure that =20
the UA stores the flow token and sends it in the body of every =20
request. 2) generate again the flow token for every request (very bad =20
from security point of views) and destroys the consistency of the =20
system since you can send requests for non existing flows. Note that =20
the draft mentions that the flow and the flow token is only created =20
with REGISTERs.

  I guess that the authors did not consider this issue because the UA =20
can go through the NAT, so it can always send requests and receive =20
responses normally out of the flow.

Sergio

Quoting Attila Sipos :

>>>  That is not possible if we limit to the draft.
>>>  Normal responses use the information in the Via header, and to
>>> use the flow we need a flow token (that is not available in the
> Via)...
>
> But couldn't you encode the flow token into the Via's branch parameter?
> You'd have to make sure you didn't break SIP grammar rules
> (but a variation of base 64 would solve that).
>
> Would there be a problem with that?
>
> Regards,
> Attila
>
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 15 November 2007 15:14
> To: sip@ietf.org
> Cc: Attila Sipos
> Subject: RE: [Sip] Can a transaction stateless proxy support
> Outbounddraft? Ifyes, how will the response be sent back the UA behind
> NAT
>
>
>
>> For requests from the registered UA, the responses will be routed back
>
>> to the UA using the established flow.
>
>   That is not possible if we limit to the draft.
>   Normal responses use the information in the Via header, and to use the
> flow we need a flow token (that is not available in the Via)...
>
>
> Sergio
>
>
> Quoting Attila Sipos :
>
>>
>> I think a stateless proxy CAN support outbound.
>>
>> As long as the stateless proxy can store registrations (well, what's
>> the point if it can't) then it can keep up a flow back to any
>> registering UA.
>>
>> When it comes to routing a request to a registered UA, it will route
>> it using the establiashed flow.  For requests from the registered UA,
>> the responses will be routed back to the UA using the established
> flow.
>>
>> Can you see a problem with this?  It seems like it should work to me.
>>
>> Regards,
>> Attila
>>
>>
>>
>>
>> -----Original Message-----
>> From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]
>> Sent: 15 November 2007 08:06
>> To: sip@ietf.org
>> Cc: dean.willis@softarmor.com
>> Subject: [Sip] Can a transaction stateless proxy support Outbound
> draft?
>> Ifyes, how will the response be sent back the UA behind NAT
>>
>>
>>
>> Hi All,
>>     Can a transaction stateless proxy support Outbound draft? If yes,
>> how will the response be sent back the UA behind NAT?
>> Thanks & Regards,
>> Karthikeyan.G
>>
>>
>>
>> DISCLAIMER:
>> ----------------------------------------------------------------------
>> --
>> -----------------------------------------------
>>
>> The contents of this e-mail and any attachment(s) are confidential and
>
>> intended for the named recipient(s) only.
>> It shall not attach any liability on the originator or HCL or its
>> affiliates. Any views or opinions presented in this email are solely
>> those of the author and may not necessarily reflect the opinions of
>> HCL or its affiliates.
>> Any form of reproduction, dissemination, copying, disclosure,
>> modification, distribution and / or publication of this message
>> without the prior written consent of the author of this e-mail is
>> strictly prohibited. If you have received this email in error please
>> delete it and notify the sender immediately. Before opening any mail
>> and attachments please check them for viruses and defect.
>>
>> ----------------------------------------------------------------------
>> --
>> -----------------------------------------------
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
>
>
> _______________________________________________
> 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
>





_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 11:37:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IshiW-0004s2-Bv; Thu, 15 Nov 2007 11:37:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IshiU-0004rb-NP
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:37:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IshiU-0004rL-D4
	for sip@ietf.org; Thu, 15 Nov 2007 11:37:22 -0500
Received: from david.siemens.gr ([212.251.43.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshiQ-0004M2-Gr
	for sip@ietf.org; Thu, 15 Nov 2007 11:37:22 -0500
Received: from mail.siemens.gr (localhost [127.0.0.1])
	by david.siemens.gr (8.12.6/8.12.6) with ESMTP id lAFGbG0v028632
	for ; Thu, 15 Nov 2007 17:37:16 +0100
Received: from atha112a.gr001.siemens.net ([141.29.38.98])
	by mail.siemens.gr (8.12.6/8.12.6) with ESMTP id lAFGb6Y7030566
	for ; Thu, 15 Nov 2007 17:37:16 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 15 Nov 2007 18:37:04 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Dialog state
Thread-Index: AcgnpcFUz/+3djAQS7uAGhXbcrOfeQ==
From: "Papapanagiotou, Serafim" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Subject: [Sip] Dialog state
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0590590328=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0590590328==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C827A5.C2117256"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C827A5.C2117256
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
I have a question concerning new requests within a Dialog (according to
RFC 3261).
In 12.1.1 is described the role for UAS in order to build the "state of
the Dialog" and 12.1.2 the role of UAC to build the "state of the
Dialog".
Up to here it is ok. The two Dialog states have been created !
The problem now is that in 12.2.1 is described how to send new requests
within a Dialog and the role of the UAC once again.
Hence as it is written " The URI in the To field of the request MUST be
set to the remote URI from the dialog state. ...etc"
Which of the two dialog states are chosen? (the one that was created as
a UAS ?) Of course this is the answer but you can see this only from
tracers and message flows.
Somehow the 12.2 is mixing the roles of UAs. So we have UAC/UAS for the
transaction and these roles can be interchanged according to who is
originating the Request during the Dialog life.
In terms of Dialog though the role of UAC seems to be always the same
(the one who sent the initial INVITE/ created the Dialog) and the UAS
(the one who received the initial INVITE)
Is it somewhere that I do not see that this is explicitly written or did
I misunderstand something? Especially for the way of choosing which of
the two Dialog states to select ?  =20
=20
=20
Thanx,

------_=_NextPart_001_01C827A5.C2117256
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Hello,


 


I have =
a question=20
concerning new requests within a Dialog (according to RFC=20
3261).


In =
12.1.1 is=20
described the role for UAS in order to build the "state of the Dialog" =
and=20
12.1.2 the role of UAC to build the "state of the =
Dialog".


Up to here it=20
is ok. The two Dialog states have been=20
created !


The =
problem now is=20
that in 12.2.1 is described how to send new requests within a Dialog and =
the=20
role of the UAC once again.


Hence =
as it is=20
written " The URI in the To field of the request MUST be set to the =
remote=20
URI from the dialog state. ...etc"


Which =
of the two=20
dialog states are chosen? (the one =

that was created as a UAS ?) Of course this is the answer =
but you=20
can see this only from tracers and message flows.


Somehow the 12.2 is=20
mixing the roles of UAs. So we have UAC/UAS for the transaction =
and these=20
roles can be interchanged according to who is originating the Request =
during the=20
Dialog life.


In =
terms of Dialog=20
though the role of UAC seems to be always the same (the one who sent the =
initial=20
INVITE/ created the Dialog) and =
the UAS=20
(the one who received the initial INVITE)


Is it=20
somewhere that I do not see that this is explicitly written or did =
I=20
misunderstand something? Especially for =
the way=20
of choosing which of the two Dialog states to select =
?   


 


 


Thanx,


------_=_NextPart_001_01C827A5.C2117256--



--===============0590590328==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0590590328==--





From sip-bounces@ietf.org Thu Nov 15 12:15:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsiJ8-0005Dl-TC; Thu, 15 Nov 2007 12:15:14 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsiJ1-0004t0-3o
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 12:15:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiIz-0004pq-8T
	for sip@ietf.org; Thu, 15 Nov 2007 12:15:06 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsiIu-0006Oc-38
	for sip@ietf.org; Thu, 15 Nov 2007 12:15:05 -0500
Received: from rly22f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly22f.srv.mailcontrol.com (MailControl) with ESMTP id
	lAFHEoti016776 for ; Thu, 15 Nov 2007 17:14:56 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly22f.srv.mailcontrol.com (MailControl) id lAFHDoSU011933
	for sip@ietf.org; Thu, 15 Nov 2007 17:13:50 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly22f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lAFHCaoW007058; Thu, 15 Nov 2007 17:13:50 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Nov 2007 17:13:49 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Can a transaction stateless proxy support
	Outbounddraft?Ifyes,
	how will the response be sent back the UA behind NAT
Date: Thu, 15 Nov 2007 17:13:09 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60A029C5@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can a transaction stateless proxy support
	Outbounddraft?Ifyes,
	how will the response be sent back the UA behind NAT
Thread-Index: Acgno45AXfwjnXgiQ6+iG0THvzLcVQABJ5kA
From: "Attila Sipos" 
To: , 
X-OriginalArrivalTime: 15 Nov 2007 17:13:49.0812 (UTC)
	FILETIME=[E3B2AB40:01C827AA]
X-Scanned-By: MailControl A-08-00-02 (www.mailcontrol.com) on 10.70.1.132
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.0 (-)
X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


I was talking about the stateless proxy putting the flow token into the
Via.
I don't understand why you mentioned UA's.

re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
Let's say we use the "Example Message Flow".  To forward the INVITE
in message 7, we use the existing flow created by the REGISTRATION.
The response of message 9 gets forwarded in the normal way and as
defined in the outbound draft (i.e. it adds the flow token into the
Record-Route).

Now let's say the callee sends BYE (not the caller).

So my idea is that the proxy gets this and forwards it in the normal
way and inserts a Via header. In the Via header's branch parameter, it
would encode the required flow token.  Then when the 200 response
arrives,
it looks at the top Via and decodes the branch parameter.  From this it
knows which flow to use to forward the response.

Is this wrong?

	Attila




-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: 15 November 2007 16:18
To: sip@ietf.org
Cc: Attila Sipos
Subject: RE: [Sip] Can a transaction stateless proxy support
Outbounddraft?Ifyes, how will the response be sent back the UA behind
NAT


> But couldn't you encode the flow token into the Via's branch
parameter?

  Yes, it is possible, but the draft does not tell anything about
responses.
  To put the flow token in the Via I see 2 options : 1) ensure that the
UA stores the flow token and sends it in the body of every request. 2)
generate again the flow token for every request (very bad from security
point of views) and destroys the consistency of the system since you can
send requests for non existing flows. Note that the draft mentions that
the flow and the flow token is only created with REGISTERs.

  I guess that the authors did not consider this issue because the UA
can go through the NAT, so it can always send requests and receive
responses normally out of the flow.

Sergio

Quoting Attila Sipos :

>>>  That is not possible if we limit to the draft.
>>>  Normal responses use the information in the Via header, and to use=20
>>> the flow we need a flow token (that is not available in the
> Via)...
>
> But couldn't you encode the flow token into the Via's branch
parameter?
> You'd have to make sure you didn't break SIP grammar rules (but a=20
> variation of base 64 would solve that).
>
> Would there be a problem with that?
>
> Regards,
> Attila
>
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 15 November 2007 15:14
> To: sip@ietf.org
> Cc: Attila Sipos
> Subject: RE: [Sip] Can a transaction stateless proxy support=20
> Outbounddraft? Ifyes, how will the response be sent back the UA behind

> NAT
>
>
>
>> For requests from the registered UA, the responses will be routed=20
>> back
>
>> to the UA using the established flow.
>
>   That is not possible if we limit to the draft.
>   Normal responses use the information in the Via header, and to use=20
> the flow we need a flow token (that is not available in the Via)...
>
>
> Sergio
>
>
> Quoting Attila Sipos :
>
>>
>> I think a stateless proxy CAN support outbound.
>>
>> As long as the stateless proxy can store registrations (well, what's=20
>> the point if it can't) then it can keep up a flow back to any=20
>> registering UA.
>>
>> When it comes to routing a request to a registered UA, it will route=20
>> it using the establiashed flow.  For requests from the registered UA,

>> the responses will be routed back to the UA using the established
> flow.
>>
>> Can you see a problem with this?  It seems like it should work to me.
>>
>> Regards,
>> Attila
>>
>>
>>
>>
>> -----Original Message-----
>> From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]
>> Sent: 15 November 2007 08:06
>> To: sip@ietf.org
>> Cc: dean.willis@softarmor.com
>> Subject: [Sip] Can a transaction stateless proxy support Outbound
> draft?
>> Ifyes, how will the response be sent back the UA behind NAT
>>
>>
>>
>> Hi All,
>>     Can a transaction stateless proxy support Outbound draft? If yes,

>> how will the response be sent back the UA behind NAT?
>> Thanks & Regards,
>> Karthikeyan.G
>>
>>
>>
>> DISCLAIMER:
>> ---------------------------------------------------------------------
>> -
>> --
>> -----------------------------------------------
>>
>> The contents of this e-mail and any attachment(s) are confidential=20
>> and
>
>> intended for the named recipient(s) only.
>> It shall not attach any liability on the originator or HCL or its=20
>> affiliates. Any views or opinions presented in this email are solely=20
>> those of the author and may not necessarily reflect the opinions of=20
>> HCL or its affiliates.
>> Any form of reproduction, dissemination, copying, disclosure,=20
>> modification, distribution and / or publication of this message=20
>> without the prior written consent of the author of this e-mail is=20
>> strictly prohibited. If you have received this email in error please=20
>> delete it and notify the sender immediately. Before opening any mail=20
>> and attachments please check them for viruses and defect.
>>
>> ---------------------------------------------------------------------
>> -
>> --
>> -----------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>
>
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip
>





_______________________________________________
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


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 12:46:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsinH-0001yf-4B; Thu, 15 Nov 2007 12:46:23 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsinF-0001xt-M8
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 12:46:21 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsinF-0001xg-AT
	for sip@ietf.org; Thu, 15 Nov 2007 12:46:21 -0500
Received: from smtp-2.hut.fi ([130.233.228.92])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsinD-0000Qv-Su
	for sip@ietf.org; Thu, 15 Nov 2007 12:46:21 -0500
Received: from localhost (katosiko.hut.fi [130.233.228.115])
	by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id lAFHkI8H018086;
	Thu, 15 Nov 2007 19:46:18 +0200
Received: from smtp-2.hut.fi ([130.233.228.92])
	by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new,
	port 10024)
	with LMTP id 31562-04-4; Thu, 15 Nov 2007 19:46:17 +0200 (EET)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id lAFHjXCw017832;
	Thu, 15 Nov 2007 19:45:33 +0200
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 1AC883A2CD9;
	Thu, 15 Nov 2007 19:45:33 +0200 (EET)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 22432-02; Thu, 15 Nov 2007 19:45:26 +0200 (EET)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id 7F2933A2CCC;
	Thu, 15 Nov 2007 19:45:26 +0200 (EET)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Thu, 15 Nov 2007 19:45:26 +0200
Message-ID: <20071115194526.1b7gbixnnk04c88k@horde-intra.tml.hut.fi>
Date: Thu, 15 Nov 2007 19:45:26 +0200
From: sergiole@tml.hut.fi
To: sip@ietf.org
Subject: RE: [Sip] Can a transaction stateless proxy support
	Outbounddraft?Ifyes,
	how will the response be sent back the UA behind NAT
References: <680808427CF931459462C3D78CB5EC60A029C5@EXVS02.nasstar-t1.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC60A029C5@EXVS02.nasstar-t1.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 40161b1d86420e0807d771943d981d25
Cc: Attila Sipos 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


> I was talking about the stateless proxy putting the flow token into the
> Via.
> I don't understand why you mentioned UA's.

  Yes, me too. I mentioned the UA because is a possible solution to =20
pass the flow token to the edge proxy when it handles non-register =20
requests.

> re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
> Let's say we use the "Example Message Flow".  To forward the INVITE
> in message 7, we use the existing flow created by the REGISTRATION.
> The response of message 9 gets forwarded in the normal way and as
> defined in the outbound draft (i.e. it adds the flow token into the
> Record-Route).

  Yes, I agree.


1.
> Now let's say the callee sends BYE (not the caller).

Ok, here I see 2 options.
1) The BYE is sent over the flow
2) The BYE is sent in a traditional way (non-outbound case)

I assume that you are talking of option 1) above.

2.
> So my idea is that the proxy gets this and forwards it in the normal
> way and inserts a Via header.

I agree.

3.
> In the Via header's branch parameter, it
> would encode the required flow token.

Here is the issue : From were you get the flow token?
(In my previous email I mentioned 2 options... )

4.
> Then when the 200 response
> arrives,
> it looks at the top Via and decodes the branch parameter.  From this it
> knows which flow to use to forward the response.

  If you managed to add the flow token in the step above it is OK


  In my opinion there is a problem in step 3. In my previous email I =20
mentioned this case, I copy the text below :

>   To put the flow token in the Via I see 2 options : 1) ensure that the
> UA stores the flow token and sends it in the body of every request. 2)
> generate again the flow token for every request (very bad from security
> point of views) and destroys the consistency of the system since you can
> send requests for non existing flows. Note that the draft mentions that
> the flow and the flow token is only created with REGISTERs.

  Any ideas or comments are welcome. I was dealing with this issue for =20
months...


Regards,

Sergio


Quoting Attila Sipos :

>
> I was talking about the stateless proxy putting the flow token into the
> Via.
> I don't understand why you mentioned UA's.
>
> re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
> Let's say we use the "Example Message Flow".  To forward the INVITE
> in message 7, we use the existing flow created by the REGISTRATION.
> The response of message 9 gets forwarded in the normal way and as
> defined in the outbound draft (i.e. it adds the flow token into the
> Record-Route).
>
> Now let's say the callee sends BYE (not the caller).
>
> So my idea is that the proxy gets this and forwards it in the normal
> way and inserts a Via header. In the Via header's branch parameter, it
> would encode the required flow token.  Then when the 200 response
> arrives,
> it looks at the top Via and decodes the branch parameter.  From this it
> knows which flow to use to forward the response.
>
> Is this wrong?
>
> =09Attila
>
>
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 15 November 2007 16:18
> To: sip@ietf.org
> Cc: Attila Sipos
> Subject: RE: [Sip] Can a transaction stateless proxy support
> Outbounddraft?Ifyes, how will the response be sent back the UA behind
> NAT
>
>
>> But couldn't you encode the flow token into the Via's branch
> parameter?
>
>   Yes, it is possible, but the draft does not tell anything about
> responses.
>   To put the flow token in the Via I see 2 options : 1) ensure that the
> UA stores the flow token and sends it in the body of every request. 2)
> generate again the flow token for every request (very bad from security
> point of views) and destroys the consistency of the system since you can
> send requests for non existing flows. Note that the draft mentions that
> the flow and the flow token is only created with REGISTERs.
>
>   I guess that the authors did not consider this issue because the UA
> can go through the NAT, so it can always send requests and receive
> responses normally out of the flow.
>
> Sergio
>
> Quoting Attila Sipos :
>
>>>>  That is not possible if we limit to the draft.
>>>>  Normal responses use the information in the Via header, and to use
>>>> the flow we need a flow token (that is not available in the
>> Via)...
>>
>> But couldn't you encode the flow token into the Via's branch
> parameter?
>> You'd have to make sure you didn't break SIP grammar rules (but a
>> variation of base 64 would solve that).
>>
>> Would there be a problem with that?
>>
>> Regards,
>> Attila
>>
>>
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: 15 November 2007 15:14
>> To: sip@ietf.org
>> Cc: Attila Sipos
>> Subject: RE: [Sip] Can a transaction stateless proxy support
>> Outbounddraft? Ifyes, how will the response be sent back the UA behind
>
>> NAT
>>
>>
>>
>>> For requests from the registered UA, the responses will be routed
>>> back
>>
>>> to the UA using the established flow.
>>
>>   That is not possible if we limit to the draft.
>>   Normal responses use the information in the Via header, and to use
>> the flow we need a flow token (that is not available in the Via)...
>>
>>
>> Sergio
>>
>>
>> Quoting Attila Sipos :
>>
>>>
>>> I think a stateless proxy CAN support outbound.
>>>
>>> As long as the stateless proxy can store registrations (well, what's
>>> the point if it can't) then it can keep up a flow back to any
>>> registering UA.
>>>
>>> When it comes to routing a request to a registered UA, it will route
>>> it using the establiashed flow.  For requests from the registered UA,
>
>>> the responses will be routed back to the UA using the established
>> flow.
>>>
>>> Can you see a problem with this?  It seems like it should work to me.
>>>
>>> Regards,
>>> Attila
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]
>>> Sent: 15 November 2007 08:06
>>> To: sip@ietf.org
>>> Cc: dean.willis@softarmor.com
>>> Subject: [Sip] Can a transaction stateless proxy support Outbound
>> draft?
>>> Ifyes, how will the response be sent back the UA behind NAT
>>>
>>>
>>>
>>> Hi All,
>>>     Can a transaction stateless proxy support Outbound draft? If yes,
>
>>> how will the response be sent back the UA behind NAT?
>>> Thanks & Regards,
>>> Karthikeyan.G
>>>
>>>
>>>
>>> DISCLAIMER:
>>> ---------------------------------------------------------------------
>>> -
>>> --
>>> -----------------------------------------------
>>>
>>> The contents of this e-mail and any attachment(s) are confidential
>>> and
>>
>>> intended for the named recipient(s) only.
>>> It shall not attach any liability on the originator or HCL or its
>>> affiliates. Any views or opinions presented in this email are solely
>>> those of the author and may not necessarily reflect the opinions of
>>> HCL or its affiliates.
>>> Any form of reproduction, dissemination, copying, disclosure,
>>> modification, distribution and / or publication of this message
>>> without the prior written consent of the author of this e-mail is
>>> strictly prohibited. If you have received this email in error please
>>> delete it and notify the sender immediately. Before opening any mail
>>> and attachments please check them for viruses and defect.
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --
>>> -----------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
>
>
> _______________________________________________
> 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
>





_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 13:23:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsjND-0001k4-2v; Thu, 15 Nov 2007 13:23:31 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IsjNB-0001j8-GS
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 13:23:29 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IsjNB-0001io-4A
	for sip@ietf.org; Thu, 15 Nov 2007 13:23:29 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsjN9-0002EJ-IP
	for sip@ietf.org; Thu, 15 Nov 2007 13:23:29 -0500
Received: from rly07f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly07f.srv.mailcontrol.com (MailControl) with ESMTP id
	lAFIMvSm030669 for ; Thu, 15 Nov 2007 18:23:24 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly07f.srv.mailcontrol.com (MailControl) id lAFIM5Si025030
	for sip@ietf.org; Thu, 15 Nov 2007 18:22:05 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly07f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lAFILhDi022771; Thu, 15 Nov 2007 18:22:05 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Nov 2007 18:22:14 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Can a transaction stateless proxy
	supportOutbounddraft?Ifyes,
	how will the response be sent back the UA behind NAT
Date: Thu, 15 Nov 2007 18:21:34 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60A02A24@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can a transaction stateless proxy
	supportOutbounddraft?Ifyes,
	how will the response be sent back the UA behind NAT
Thread-Index: Acgnr41DEcmZYYA1Rdq6YfGUzgyVtAAAO8fA
From: "Attila Sipos" 
To: , 
X-OriginalArrivalTime: 15 Nov 2007 18:22:14.0837 (UTC)
	FILETIME=[727BC650:01C827B4]
X-Scanned-By: MailControl A-08-00-02 (www.mailcontrol.com) on 10.70.1.117
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e06437eb72f6703f11713d345be8298a
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

>>1.
>>> Now let's say the callee sends BYE (not the caller).
>>
>>Ok, here I see 2 options.
>>1) The BYE is sent over the flow
>>2) The BYE is sent in a traditional way (non-outbound case)
>>
>>I assume that you are talking of option 1) above.

yes.  I would have thought that it must be sent using the flow.


>>2.
>>> So my idea is that the proxy gets this and forwards it in the normal

>>> way and inserts a Via header.
>>
>>I agree.
>>
>>3.
>>> In the Via header's branch parameter, it would encode the required=20
>>> flow token.
>>
>>Here is the issue : From were you get the flow token?
>>(In my previous email I mentioned 2 options... )
>>

OK I'm starting to see your problem.

The registration record stores the flow token (obviously)
And the socket id for the flow would be stored as well (for
connection-oriented
protocols). So if you received a request on that socket, you could match
that
up to one of the registration records and hence, one of the flow tokens.

(I think I am starting to see some difficulties with this)


>>4.
>>>> Then when the 200 response arrives,
>>>>> it looks at the top Via and decodes the branch parameter.  From
this=20
>>>>> it knows which flow to use to forward the response.
>>
>>If you managed to add the flow token in the step above it is OK


I hope I have explained how the flow token might be mapped to the
socket.
I can now see that my idea wouldn't work for UDP.

But what if you used the gruu in the contact to match up with
the gruu of a registration?  Then the registration record tells
tells you about the flow token.  That would work wouldn't it?

Regards,
	Attila

=20

-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: 15 November 2007 17:45
To: sip@ietf.org
Cc: Attila Sipos
Subject: RE: [Sip] Can a transaction stateless proxy
supportOutbounddraft?Ifyes, how will the response be sent back the UA
behind NAT


> I was talking about the stateless proxy putting the flow token into=20
> the Via.
> I don't understand why you mentioned UA's.

  Yes, me too. I mentioned the UA because is a possible solution to pass
the flow token to the edge proxy when it handles non-register requests.

> re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
> Let's say we use the "Example Message Flow".  To forward the INVITE in

> message 7, we use the existing flow created by the REGISTRATION.
> The response of message 9 gets forwarded in the normal way and as=20
> defined in the outbound draft (i.e. it adds the flow token into the=20
> Record-Route).

  Yes, I agree.


1.
> Now let's say the callee sends BYE (not the caller).

Ok, here I see 2 options.
1) The BYE is sent over the flow
2) The BYE is sent in a traditional way (non-outbound case)

I assume that you are talking of option 1) above.

2.
> So my idea is that the proxy gets this and forwards it in the normal=20
> way and inserts a Via header.

I agree.

3.
> In the Via header's branch parameter, it would encode the required=20
> flow token.

Here is the issue : From were you get the flow token?
(In my previous email I mentioned 2 options... )

4.
> Then when the 200 response
> arrives,
> it looks at the top Via and decodes the branch parameter.  From this=20
> it knows which flow to use to forward the response.

  If you managed to add the flow token in the step above it is OK


  In my opinion there is a problem in step 3. In my previous email I
mentioned this case, I copy the text below :

>   To put the flow token in the Via I see 2 options : 1) ensure that=20
> the UA stores the flow token and sends it in the body of every=20
> request. 2) generate again the flow token for every request (very bad=20
> from security point of views) and destroys the consistency of the=20
> system since you can send requests for non existing flows. Note that=20
> the draft mentions that the flow and the flow token is only created
with REGISTERs.

  Any ideas or comments are welcome. I was dealing with this issue for
months...


Regards,

Sergio


Quoting Attila Sipos :

>
> I was talking about the stateless proxy putting the flow token into=20
> the Via.
> I don't understand why you mentioned UA's.
>
> re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
> Let's say we use the "Example Message Flow".  To forward the INVITE in

> message 7, we use the existing flow created by the REGISTRATION.
> The response of message 9 gets forwarded in the normal way and as=20
> defined in the outbound draft (i.e. it adds the flow token into the=20
> Record-Route).
>
> Now let's say the callee sends BYE (not the caller).
>
> So my idea is that the proxy gets this and forwards it in the normal=20
> way and inserts a Via header. In the Via header's branch parameter, it

> would encode the required flow token.  Then when the 200 response=20
> arrives, it looks at the top Via and decodes the branch parameter. =20
> From this it knows which flow to use to forward the response.
>
> Is this wrong?
>
> 	Attila
>
>
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 15 November 2007 16:18
> To: sip@ietf.org
> Cc: Attila Sipos
> Subject: RE: [Sip] Can a transaction stateless proxy support=20
> Outbounddraft?Ifyes, how will the response be sent back the UA behind=20
> NAT
>
>
>> But couldn't you encode the flow token into the Via's branch
> parameter?
>
>   Yes, it is possible, but the draft does not tell anything about=20
> responses.
>   To put the flow token in the Via I see 2 options : 1) ensure that=20
> the UA stores the flow token and sends it in the body of every=20
> request. 2) generate again the flow token for every request (very bad=20
> from security point of views) and destroys the consistency of the=20
> system since you can send requests for non existing flows. Note that=20
> the draft mentions that the flow and the flow token is only created
with REGISTERs.
>
>   I guess that the authors did not consider this issue because the UA=20
> can go through the NAT, so it can always send requests and receive=20
> responses normally out of the flow.
>
> Sergio
>
> Quoting Attila Sipos :
>
>>>>  That is not possible if we limit to the draft.
>>>>  Normal responses use the information in the Via header, and to use

>>>> the flow we need a flow token (that is not available in the
>> Via)...
>>
>> But couldn't you encode the flow token into the Via's branch
> parameter?
>> You'd have to make sure you didn't break SIP grammar rules (but a=20
>> variation of base 64 would solve that).
>>
>> Would there be a problem with that?
>>
>> Regards,
>> Attila
>>
>>
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: 15 November 2007 15:14
>> To: sip@ietf.org
>> Cc: Attila Sipos
>> Subject: RE: [Sip] Can a transaction stateless proxy support=20
>> Outbounddraft? Ifyes, how will the response be sent back the UA=20
>> behind
>
>> NAT
>>
>>
>>
>>> For requests from the registered UA, the responses will be routed=20
>>> back
>>
>>> to the UA using the established flow.
>>
>>   That is not possible if we limit to the draft.
>>   Normal responses use the information in the Via header, and to use=20
>> the flow we need a flow token (that is not available in the Via)...
>>
>>
>> Sergio
>>
>>
>> Quoting Attila Sipos :
>>
>>>
>>> I think a stateless proxy CAN support outbound.
>>>
>>> As long as the stateless proxy can store registrations (well, what's

>>> the point if it can't) then it can keep up a flow back to any=20
>>> registering UA.
>>>
>>> When it comes to routing a request to a registered UA, it will route

>>> it using the establiashed flow.  For requests from the registered=20
>>> UA,
>
>>> the responses will be routed back to the UA using the established
>> flow.
>>>
>>> Can you see a problem with this?  It seems like it should work to
me.
>>>
>>> Regards,
>>> Attila
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]
>>> Sent: 15 November 2007 08:06
>>> To: sip@ietf.org
>>> Cc: dean.willis@softarmor.com
>>> Subject: [Sip] Can a transaction stateless proxy support Outbound
>> draft?
>>> Ifyes, how will the response be sent back the UA behind NAT
>>>
>>>
>>>
>>> Hi All,
>>>     Can a transaction stateless proxy support Outbound draft? If=20
>>> yes,
>
>>> how will the response be sent back the UA behind NAT?
>>> Thanks & Regards,
>>> Karthikeyan.G
>>>
>>>
>>>
>>> DISCLAIMER:
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --
>>> -----------------------------------------------
>>>
>>> The contents of this e-mail and any attachment(s) are confidential=20
>>> and
>>
>>> intended for the named recipient(s) only.
>>> It shall not attach any liability on the originator or HCL or its=20
>>> affiliates. Any views or opinions presented in this email are solely

>>> those of the author and may not necessarily reflect the opinions of=20
>>> HCL or its affiliates.
>>> Any form of reproduction, dissemination, copying, disclosure,=20
>>> modification, distribution and / or publication of this message=20
>>> without the prior written consent of the author of this e-mail is=20
>>> strictly prohibited. If you have received this email in error please

>>> delete it and notify the sender immediately. Before opening any mail

>>> and attachments please check them for viruses and defect.
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --
>>> -----------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use=20
>>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>>> sipping@ietf.org for new developments on the application of sip
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use=20
>>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>>> sipping@ietf.org for new developments on the application of sip
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>
>
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip
>





_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 14:49:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iskhy-0007IH-9N; Thu, 15 Nov 2007 14:49:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iskhx-0007Ge-AU
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 14:49:01 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iskhw-0007FQ-VG
	for sip@ietf.org; Thu, 15 Nov 2007 14:49:01 -0500
Received: from qmta08.westchester.pa.mail.comcast.net ([76.96.62.80])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iskhw-0005OE-GJ
	for sip@ietf.org; Thu, 15 Nov 2007 14:49:00 -0500
Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12])
	by QMTA08.westchester.pa.mail.comcast.net with comcast
	id D6so1Y00K0Fqzac0505700; Thu, 15 Nov 2007 19:48:59 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA08.westchester.pa.mail.comcast.net with comcast
	id D7oz1Y00J0umElk0300000; Thu, 15 Nov 2007 19:48:59 +0000
X-Authority-Analysis: v=1.0 c=1 a=BHMUCbc_wSm1Ccmuy4sA:9
	a=-iBzxRlgi2lnUy1JgIwA:7 a=DPKIuT4J9_3ByUPOz9txXZkE7_AA:4
	a=zwC7bnKO5xoA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAFJmxSV006001
	for ; Thu, 15 Nov 2007 14:48:59 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAFJmxK9005997;
	Thu, 15 Nov 2007 14:48:59 -0500
Date: Thu, 15 Nov 2007 14:48:59 -0500
Message-Id: <200711151948.lAFJmxK9005997@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: 
	(serafim.papapanagiotou@nsn.com)
Subject: Re: [Sip] Dialog state
References: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Papapanagiotou, Serafim" 

   I have a question concerning new requests within a Dialog (according to
   RFC 3261).
   In 12.1.1 is described the role for UAS in order to build the "state of
   the Dialog" and 12.1.2 the role of UAC to build the "state of the
   Dialog".
   Up to here it is ok. The two Dialog states have been created !

Yes, the UA at each end of the connection must of necessity maintain
its own dialog state.  Any time the dialog is quiescent (all
outstanding messages are processed), the two states will be the same.
But of course, in the middle of a transaction, the two states may not
be the same.

   The problem now is that in 12.2.1 is described how to send new requests
   within a Dialog and the role of the UAC once again.
   Hence as it is written " The URI in the To field of the request MUST be
   set to the remote URI from the dialog state. ...etc"
   Which of the two dialog states are chosen?

The dialog state maintained by the UA which is composing the message.
(It has no access to the dialog state of the other UA.)

   Somehow the 12.2 is mixing the roles of UAs. So we have UAC/UAS for the
   transaction and these roles can be interchanged according to who is
   originating the Request during the Dialog life.

That is correct -- the roles of UAC and UAS are only defined with
respect to a single transaction, that is, a request and its response.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 15 19:03:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Isog2-0006Jj-3w; Thu, 15 Nov 2007 19:03:18 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Isog0-0006GJ-P4
	for sip-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 19:03:16 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Isog0-0006Fv-Dg
	for sip@ietf.org; Thu, 15 Nov 2007 19:03:16 -0500
Received: from qmta07.emeryville.ca.mail.comcast.net ([76.96.30.64])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isofz-0000Ok-Rl
	for sip@ietf.org; Thu, 15 Nov 2007 19:03:16 -0500
Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28])
	by QMTA07.emeryville.ca.mail.comcast.net with comcast
	id DBX41Y0040cQ2SL0A05S00; Fri, 16 Nov 2007 00:03:17 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA10.emeryville.ca.mail.comcast.net with comcast
	id DC3F1Y00J0umElk0800000; Fri, 16 Nov 2007 00:03:17 +0000
X-Authority-Analysis: v=1.0 c=1 a=3JbEUAmoh2BFdL-C6qsA:9
	a=_bu-7kSuBKoMRX5A8kzvt4IJt78A:4 a=VRKwbjqsiJ4A:10
	a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAG03CSV024544
	for ; Thu, 15 Nov 2007 19:03:12 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAG03Cci024540;
	Thu, 15 Nov 2007 19:03:12 -0500
Date: Thu, 15 Nov 2007 19:03:12 -0500
Message-Id: <200711160003.lAG03Cci024540@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: 
	(b.swamy@aricent.com)
Subject: Re: [Sip] Early Dialogue Handling
References: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "B Venkat S.R Swamy" 

   I am sorry for that confusing statements, let me correct and clarify it as 
   follows:

   1> Invite sent to the network
   2> 1xx response to Invite received from network without any Contact 
   header. Dialogue gets established.

Such a 1xx response is incorrect.

>From a practical point of view, it is incorrect because it would cause
the creation of an early dialog, but the UAC would not know the
contact address of the UAS.  This results in the difficulties you have
enumerated.

>From a standards point of view, see these sections of RFC 3261:

   13.3.1.1 Progress

   If the UAS is not able to answer the invitation immediately, it can
   choose to indicate some kind of progress to the UAC (for example, an
   indication that a phone is ringing).  This is accomplished with a
   provisional response between 101 and 199.  These provisional
   responses establish early dialogs and therefore follow the procedures
   of Section 12.1.1 in addition to those of Section 8.2.6.

   12.1.1 UAS behavior

   When a UAS responds to a request with a response that establishes a
   dialog (such as a 2xx to INVITE), the UAS MUST [...].  The UAS MUST
   add a Contact header field to the response.  The Contact header
   field contains an address where the UAS would like to be contacted
   for subsequent requests in the dialog [...].

Dale


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 02:43:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Isvr6-0002xh-4R; Fri, 16 Nov 2007 02:43:12 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Isvr4-0002wn-FW
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 02:43:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Isvr4-0002we-3P
	for sip@ietf.org; Fri, 16 Nov 2007 02:43:10 -0500
Received: from mail128.messagelabs.com ([216.82.250.131])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Isvqz-0008MU-Sy
	for sip@ietf.org; Fri, 16 Nov 2007 02:43:10 -0500
X-VirusChecked: Checked
X-Env-Sender: vineet.gupta@motorola.com
X-Msg-Ref: server-12.tower-128.messagelabs.com!1195198984!16733500!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 24736 invoked from network); 16 Nov 2007 07:43:04 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-12.tower-128.messagelabs.com with SMTP;
	16 Nov 2007 07:43:04 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAG7h1DC007470
	for ; Fri, 16 Nov 2007 00:43:04 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143])
	by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lAG7h0ws014476
	for ; Fri, 16 Nov 2007 01:43:00 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAG7gxaH014457
	for ; Fri, 16 Nov 2007 01:42:59 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 16 Nov 2007 15:40:03 +0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Status of require headers in the re-INVITE request.
thread-index: AcgoI+as36BY5XJ9RX+hhlORYb8N8Q==
From: "Gupta Vineet-A18467" 
To: 
X-CFilter-Loop: Reflected
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Subject: [Sip] Status of require headers in the re-INVITE request.
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0125653955=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0125653955==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82824.4E948D62"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82824.4E948D62
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I have a doubt related to using Require:100rel in re-INVITE requests.
=20
If a Require header was used in the INVITE request establishing the
dialog, is it mandatory to include the same Require header in subsequent
re-INVITE requests within the dialog?
To be specific, if INVITE request contained Require:100rel, then
inclusion of Require:100rel in re-INVITE would require the originator to
handle Reliable provisional responses and respond accordingly. So, it
would also imply that re-INVITE also takes same call establishment time
(owing to multiple messages like 183 session in Progress, PRACK, 180
ringing, PRACK etc.).=20
=20
I agree, that such delay in re-INVITE might be acceptable given that
re-INVITE requires the user-intervention, but it complicates makes the
re-INVITE handling as complicated as the INVITE handling. Also, if the
initial INVITE involved procedures such as QoS negotiation the re-INVITE
state-machine complicates even further.
=20
Regards,
Vineet.
=20
"You're only given a little spark of madness. You mustn't lose it."
=20

------_=_NextPart_001_01C82824.4E948D62
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi,


 


I have =
a doubt=20
related to using Require:100rel in re-INVITE =
requests.


 


If a Require=20
header was used in the INVITE request establishing the dialog, is it =
mandatory=20
to include the same Require header in subsequent re-INVITE requests =
within the=20
dialog?


To be =
specific, if=20
INVITE request contained Require:100rel, then inclusion of =
Require:100rel in=20
re-INVITE would require the originator to handle Reliable provisional =
responses=20
and respond accordingly. So, it would also imply that re-INVITE also =
takes same=20
call establishment time (owing to multiple messages like 183 session in=20
Progress, PRACK, 180 ringing, PRACK etc.). 


 


I =
agree, that such=20
delay in re-INVITE might be acceptable given that re-INVITE requires the =

user-intervention, but it complicates makes the re-INVITE handling as=20
complicated as the INVITE handling. Also, if the initial INVITE involved =

procedures such as QoS negotiation the re-INVITE state-machine =
complicates even=20
further.


 


Regards,




Vineet.


 


“You're only given a=20
little spark of madness. You mustn't lose =
it.”


 


------_=_NextPart_001_01C82824.4E948D62--



--===============0125653955==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0125653955==--





From sip-bounces@ietf.org Fri Nov 16 03:03:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IswAe-0008L6-Ec; Fri, 16 Nov 2007 03:03:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IswAc-0008Jj-A1
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 03:03:22 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IswAb-0008JG-UQ
	for sip@ietf.org; Fri, 16 Nov 2007 03:03:22 -0500
Received: from wip-cdc-wd.wipro.com ([203.91.201.26])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IswAa-0004u5-Sd
	for sip@ietf.org; Fri, 16 Nov 2007 03:03:21 -0500
Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1])
	by localhost (Postfix) with ESMTP id D991C1805B
	for ; Fri, 16 Nov 2007 13:33:18 +0530 (IST)
Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91])
	by wip-cdc-wd.wipro.com (Postfix) with ESMTP id C84BD18056
	for ; Fri, 16 Nov 2007 13:33:18 +0530 (IST)
Received: from BLR-EC-MBX02.wipro.com ([10.201.50.161]) by
	blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Fri, 16 Nov 2007 13:33:18 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Status of require headers in the re-INVITE request.
Date: Fri, 16 Nov 2007 13:32:06 +0530
Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE05B3C396@BLR-EC-MBX02.wipro.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Status of require headers in the re-INVITE request.
Thread-Index: AcgoI+as36BY5XJ9RX+hhlORYb8N8QAAUx2w
From: 
To: ,
	
X-OriginalArrivalTime: 16 Nov 2007 08:03:18.0934 (UTC)
	FILETIME=[262C6B60:01C82827]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0560140244=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0560140244==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82827.244EF3AD"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82827.244EF3AD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Comments inline...

Regards,=20
Nataraju A B=20

________________________________

From: Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]=20
Sent: Friday, November 16, 2007 1:10 PM
To: sip@ietf.org
Subject: [Sip] Status of require headers in the re-INVITE request.



	Hi,
	=20
	I have a doubt related to using Require:100rel in re-INVITE
requests.
	=20
	If a Require header was used in the INVITE request establishing
the dialog, is it mandatory to include the same Require header in
subsequent re-INVITE requests within the dialog?
	[ABN] yes, its necessary that re-INVITE carry the same set of
Require header values that of INVITE.
	=20
	To be specific, if INVITE request contained Require:100rel, then
inclusion of Require:100rel in re-INVITE would require the originator to
handle Reliable provisional responses and respond accordingly. So, it
would also imply that re-INVITE also takes same call establishment time
(owing to multiple messages like 183 session in Progress, PRACK, 180
ringing, PRACK etc.).=20
	[ABN] Yes, UA's should be ready to handle PRACK txn triggered by
re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS has to
generate 1xx. if UAS generates 1xx responses for re-INVITE, then yes, it
lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it is not mandatory to
send  1xx for re-INVITE, hence even if Require:100rel is in re-INVITE,
re-INVITE txn could be completed with out PRACK transaction.
	=20
	I agree, that such delay in re-INVITE might be acceptable given
that re-INVITE requires the user-intervention, but it complicates makes
the re-INVITE handling as complicated as the INVITE handling. Also, if
the initial INVITE involved procedures such as QoS negotiation the
re-INVITE state-machine complicates even further.
	=20
	[ABN] In most of the cases, re-INVITE is not expected to undergo
user-intervention. hence in most of the cases it would end up with
re-INV, 200, ACK only...=20
	=20
	In general, re-INVITE is expected to perform subset of what
happened in INVITE transaction. it should not create any issues to
handle 1xx responses reliably.
	=20
	Hope this answers all your questions...=20
	=20
	Regards,
	Vineet.
	=20
	"You're only given a little spark of madness. You mustn't lose
it."
	=20


------_=_NextPart_001_01C82827.244EF3AD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Comments inline...


Regards, 
Nataraju A =
B 





From: Gupta Vineet-A18467=20
[mailto:vineet.gupta@motorola.com] 
Sent: Friday, November 16, =
2007=20
1:10 PM
To: sip@ietf.org
Subject: [Sip] Status of =
require=20
headers in the re-INVITE request.




  

  
Hi,

  
 

  
I =
have a doubt=20
  related to using Require:100rel in re-INVITE =
requests.

  
 

  
If a=20
  Require header was used in the INVITE request establishing the dialog, =
is it=20
  mandatory to include the same Require header in subsequent re-INVITE =
requests=20
  within the dialog?
[ABN] yes, its necessary =
that re-INVITE=20
  carry the same set of Require header values that of=20
  INVITE.

  
 

  
To be=20
  specific, if INVITE request contained Require:100rel, then inclusion =
of=20
  Require:100rel in re-INVITE would require the originator to handle =
Reliable=20
  provisional responses and respond accordingly. So, it would also imply =
that=20
  re-INVITE also takes same call establishment time (owing to multiple =
messages=20
  like 183 session in Progress, PRACK, 180 ringing, PRACK etc.). =

[ABN] Yes, UA's should be ready to handle PRACK =
txn=20
  triggered by re-INVITE txn. Also sending 100rel in re-INVITE does =
not=20
  mean UAS has to generate 1xx. if UAS generates 1xx responses for=20
  re-INVITE, then yes, it lead to re-INV , 1xx(100rel), PRACK, =
200-PRK,=20
  ... it is not mandatory to send  1xx for =
re-INVITE,=20
  hence even if Require:100rel is in re-INVITE, re-INVITE txn could be =
completed=20
  with out PRACK transaction.

  
 

  
I =
agree, that such=20
  delay in re-INVITE might be acceptable given that re-INVITE requires =
the=20
  user-intervention, but it complicates makes the re-INVITE handling as=20
  complicated as the INVITE handling. Also, if the initial INVITE =
involved=20
  procedures such as QoS negotiation the re-INVITE state-machine =
complicates=20
  even further.

  
 

  
[ABN] In most of the cases, re-INVITE is not =
expected to=20
  undergo user-intervention. hence in most of the cases it would end up =
with=20
  re-INV, 200, ACK only... 

  
 

  
In general, re-INVITE is expected to perform =
subset of what=20
  happened in INVITE transaction. it should not create any issues to =
handle 1xx=20
  responses reliably.

  
 

  
Hope this answers all your questions...=20
  

  
 

  
Regards,

  

  
Vineet.

  
 

  
“You're only given a=20
  little spark of madness. You mustn't lose =
it.”

  
 


------_=_NextPart_001_01C82827.244EF3AD--



--===============0560140244==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0560140244==--





From sip-bounces@ietf.org Fri Nov 16 07:56:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It0kF-0003Vr-QV; Fri, 16 Nov 2007 07:56:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It0kD-0003UV-G2
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 07:56:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It0kD-0003TZ-4y
	for sip@ietf.org; Fri, 16 Nov 2007 07:56:25 -0500
Received: from smtp-1.hut.fi ([130.233.228.91])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It0k7-0000Rj-54
	for sip@ietf.org; Fri, 16 Nov 2007 07:56:25 -0500
Received: from localhost (putosiko.hut.fi [130.233.228.114])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAGCuH5v018187;
	Fri, 16 Nov 2007 14:56:17 +0200
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new,
	port 10024)
	with LMTP id 01470-11-6; Fri, 16 Nov 2007 14:56:15 +0200 (EET)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAGCsL11016988;
	Fri, 16 Nov 2007 14:54:21 +0200
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 57A5E3A2CDE;
	Fri, 16 Nov 2007 14:54:21 +0200 (EET)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 18637-07; Fri, 16 Nov 2007 14:54:18 +0200 (EET)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id C4A993A2CD8;
	Fri, 16 Nov 2007 14:54:18 +0200 (EET)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Fri, 16 Nov 2007 14:54:18 +0200
Message-ID: <20071116145418.v74lilwdno0owsks@horde-intra.tml.hut.fi>
Date: Fri, 16 Nov 2007 14:54:18 +0200
From: sergiole@tml.hut.fi
To: Attila Sipos 
Subject: RE: [Sip] Can a transaction stateless proxy
	supportOutbounddraft?Ifyes, how will the response be sent back the UA
	behind NAT
References: <680808427CF931459462C3D78CB5EC60A02A24@EXVS02.nasstar-t1.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC60A02A24@EXVS02.nasstar-t1.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

>>> 3.
>>>> In the Via header's branch parameter, it would encode the required
>>>> flow token.
>>>
>>> Here is the issue : From were you get the flow token?
>>> (In my previous email I mentioned 2 options... )
>>>
>
> OK I'm starting to see your problem.
>
> The registration record stores the flow token (obviously)


  It seems that you are integrating the edge proxy and registrar in =20
the same code, right?


> And the socket id for the flow would be stored as well (for


  Can you confirm that you call socket id to the socket/file =20
descriptor of the connection?


> connection-oriented
> protocols). So if you received a request on that socket, you could match
> that
> up to one of the registration records and hence, one of the flow tokens.
>

  Good approach. I assume that you have available the socket =20
descriptor in the registrar, so basically you consider storing the =20
socket descriptor (number) in the registrar tables. Then perhaps using =20
a flow token it is not necessary since you have available in the =20
socket descriptor all the information that describes a flow (TCP case).

> I hope I have explained how the flow token might be mapped to the
> socket.

  Yes if my comments above make sense..

> I can now see that my idea wouldn't work for UDP.

  Now for UDP perhaps you can consider storing the socket descriptor =20
for UDP and the IP and port for the flow from the NAT.


  My point of view is that integrating the edge proxy with the =20
registrar can be good as a proof of concept but not suitable for a =20
production system.
  I think that this approach is not flexible in terms of scalability =20
for the number of edge proxies.

  My situation is different. I considered scalability and wanted =20
modularity. Then I considered an isolated edge proxy (no registrar). =20
Then following the ethic of the authors I try to avoid any state as =20
mentioned on section "5.2.  Generating Flow Tokens" and I can not rely =20
in any storage (like the registrar bindings in your case).

  Furthermore my registrar should not store socket descriptors due =20
that if the edge proxy crashes, the registrar could have a number of =20
descriptor that after the crash belong to other flows.

  I generate the flow token with REGISTER and send it to the registrar =20
(other node). The approach works as the draft says for incoming =20
requests (to the Calle). Now when the Callee  sends requests, and the =20
requests are sent over the flow, the responses of that request reach =20
first the edge proxy and it can not forward them to the Callee over =20
the flow, because these responses don't have the flow token (and the =20
flow token is not stored in the edge proxy)...

> But what if you used the gruu in the contact to match up with
> the gruu of a registration?  Then the registration record tells
> tells you about the flow token.  That would work wouldn't it?

  I have not background with gruu. Could you recommend what could I =20
read about it?

BR
Sergio


Quoting Attila Sipos :

>>> 1.
>>>> Now let's say the callee sends BYE (not the caller).
>>>
>>> Ok, here I see 2 options.
>>> 1) The BYE is sent over the flow
>>> 2) The BYE is sent in a traditional way (non-outbound case)
>>>
>>> I assume that you are talking of option 1) above.
>
> yes.  I would have thought that it must be sent using the flow.
>
>
>>> 2.
>>>> So my idea is that the proxy gets this and forwards it in the normal
>
>>>> way and inserts a Via header.
>>>
>>> I agree.
>>>
>>> 3.
>>>> In the Via header's branch parameter, it would encode the required
>>>> flow token.
>>>
>>> Here is the issue : From were you get the flow token?
>>> (In my previous email I mentioned 2 options... )
>>>
>
> OK I'm starting to see your problem.
>
> The registration record stores the flow token (obviously)
> And the socket id for the flow would be stored as well (for
> connection-oriented
> protocols). So if you received a request on that socket, you could match
> that
> up to one of the registration records and hence, one of the flow tokens.
>
> (I think I am starting to see some difficulties with this)
>
>
>>> 4.
>>>>> Then when the 200 response arrives,
>>>>>> it looks at the top Via and decodes the branch parameter.  From
> this
>>>>>> it knows which flow to use to forward the response.
>>>
>>> If you managed to add the flow token in the step above it is OK
>
>
> I hope I have explained how the flow token might be mapped to the
> socket.
> I can now see that my idea wouldn't work for UDP.
>
> But what if you used the gruu in the contact to match up with
> the gruu of a registration?  Then the registration record tells
> tells you about the flow token.  That would work wouldn't it?
>
> Regards,
> =09Attila
>
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 15 November 2007 17:45
> To: sip@ietf.org
> Cc: Attila Sipos
> Subject: RE: [Sip] Can a transaction stateless proxy
> supportOutbounddraft?Ifyes, how will the response be sent back the UA
> behind NAT
>
>
>> I was talking about the stateless proxy putting the flow token into
>> the Via.
>> I don't understand why you mentioned UA's.
>
>   Yes, me too. I mentioned the UA because is a possible solution to pass
> the flow token to the edge proxy when it handles non-register requests.
>
>> re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
>> Let's say we use the "Example Message Flow".  To forward the INVITE in
>
>> message 7, we use the existing flow created by the REGISTRATION.
>> The response of message 9 gets forwarded in the normal way and as
>> defined in the outbound draft (i.e. it adds the flow token into the
>> Record-Route).
>
>   Yes, I agree.
>
>
> 1.
>> Now let's say the callee sends BYE (not the caller).
>
> Ok, here I see 2 options.
> 1) The BYE is sent over the flow
> 2) The BYE is sent in a traditional way (non-outbound case)
>
> I assume that you are talking of option 1) above.
>
> 2.
>> So my idea is that the proxy gets this and forwards it in the normal
>> way and inserts a Via header.
>
> I agree.
>
> 3.
>> In the Via header's branch parameter, it would encode the required
>> flow token.
>
> Here is the issue : From were you get the flow token?
> (In my previous email I mentioned 2 options... )
>
> 4.
>> Then when the 200 response
>> arrives,
>> it looks at the top Via and decodes the branch parameter.  From this
>> it knows which flow to use to forward the response.
>
>   If you managed to add the flow token in the step above it is OK
>
>
>   In my opinion there is a problem in step 3. In my previous email I
> mentioned this case, I copy the text below :
>
>>   To put the flow token in the Via I see 2 options : 1) ensure that
>> the UA stores the flow token and sends it in the body of every
>> request. 2) generate again the flow token for every request (very bad
>> from security point of views) and destroys the consistency of the
>> system since you can send requests for non existing flows. Note that
>> the draft mentions that the flow and the flow token is only created
> with REGISTERs.
>
>   Any ideas or comments are welcome. I was dealing with this issue for
> months...
>
>
> Regards,
>
> Sergio
>
>
> Quoting Attila Sipos :
>
>>
>> I was talking about the stateless proxy putting the flow token into
>> the Via.
>> I don't understand why you mentioned UA's.
>>
>> re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
>> Let's say we use the "Example Message Flow".  To forward the INVITE in
>
>> message 7, we use the existing flow created by the REGISTRATION.
>> The response of message 9 gets forwarded in the normal way and as
>> defined in the outbound draft (i.e. it adds the flow token into the
>> Record-Route).
>>
>> Now let's say the callee sends BYE (not the caller).
>>
>> So my idea is that the proxy gets this and forwards it in the normal
>> way and inserts a Via header. In the Via header's branch parameter, it
>
>> would encode the required flow token.  Then when the 200 response
>> arrives, it looks at the top Via and decodes the branch parameter.
>> From this it knows which flow to use to forward the response.
>>
>> Is this wrong?
>>
>> =09Attila
>>
>>
>>
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: 15 November 2007 16:18
>> To: sip@ietf.org
>> Cc: Attila Sipos
>> Subject: RE: [Sip] Can a transaction stateless proxy support
>> Outbounddraft?Ifyes, how will the response be sent back the UA behind
>> NAT
>>
>>
>>> But couldn't you encode the flow token into the Via's branch
>> parameter?
>>
>>   Yes, it is possible, but the draft does not tell anything about
>> responses.
>>   To put the flow token in the Via I see 2 options : 1) ensure that
>> the UA stores the flow token and sends it in the body of every
>> request. 2) generate again the flow token for every request (very bad
>> from security point of views) and destroys the consistency of the
>> system since you can send requests for non existing flows. Note that
>> the draft mentions that the flow and the flow token is only created
> with REGISTERs.
>>
>>   I guess that the authors did not consider this issue because the UA
>> can go through the NAT, so it can always send requests and receive
>> responses normally out of the flow.
>>
>> Sergio
>>
>> Quoting Attila Sipos :
>>
>>>>>  That is not possible if we limit to the draft.
>>>>>  Normal responses use the information in the Via header, and to use
>
>>>>> the flow we need a flow token (that is not available in the
>>> Via)...
>>>
>>> But couldn't you encode the flow token into the Via's branch
>> parameter?
>>> You'd have to make sure you didn't break SIP grammar rules (but a
>>> variation of base 64 would solve that).
>>>
>>> Would there be a problem with that?
>>>
>>> Regards,
>>> Attila
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>>> Sent: 15 November 2007 15:14
>>> To: sip@ietf.org
>>> Cc: Attila Sipos
>>> Subject: RE: [Sip] Can a transaction stateless proxy support
>>> Outbounddraft? Ifyes, how will the response be sent back the UA
>>> behind
>>
>>> NAT
>>>
>>>
>>>
>>>> For requests from the registered UA, the responses will be routed
>>>> back
>>>
>>>> to the UA using the established flow.
>>>
>>>   That is not possible if we limit to the draft.
>>>   Normal responses use the information in the Via header, and to use
>>> the flow we need a flow token (that is not available in the Via)...
>>>
>>>
>>> Sergio
>>>
>>>
>>> Quoting Attila Sipos :
>>>
>>>>
>>>> I think a stateless proxy CAN support outbound.
>>>>
>>>> As long as the stateless proxy can store registrations (well, what's
>
>>>> the point if it can't) then it can keep up a flow back to any
>>>> registering UA.
>>>>
>>>> When it comes to routing a request to a registered UA, it will route
>
>>>> it using the establiashed flow.  For requests from the registered
>>>> UA,
>>
>>>> the responses will be routed back to the UA using the established
>>> flow.
>>>>
>>>> Can you see a problem with this?  It seems like it should work to
> me.
>>>>
>>>> Regards,
>>>> Attila
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]
>>>> Sent: 15 November 2007 08:06
>>>> To: sip@ietf.org
>>>> Cc: dean.willis@softarmor.com
>>>> Subject: [Sip] Can a transaction stateless proxy support Outbound
>>> draft?
>>>> Ifyes, how will the response be sent back the UA behind NAT
>>>>
>>>>
>>>>
>>>> Hi All,
>>>>     Can a transaction stateless proxy support Outbound draft? If
>>>> yes,
>>
>>>> how will the response be sent back the UA behind NAT?
>>>> Thanks & Regards,
>>>> Karthikeyan.G
>>>>
>>>>
>>>>
>>>> DISCLAIMER:
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> --
>>>> -----------------------------------------------
>>>>
>>>> The contents of this e-mail and any attachment(s) are confidential
>>>> and
>>>
>>>> intended for the named recipient(s) only.
>>>> It shall not attach any liability on the originator or HCL or its
>>>> affiliates. Any views or opinions presented in this email are solely
>
>>>> those of the author and may not necessarily reflect the opinions of
>>>> HCL or its affiliates.
>>>> Any form of reproduction, dissemination, copying, disclosure,
>>>> modification, distribution and / or publication of this message
>>>> without the prior written consent of the author of this e-mail is
>>>> strictly prohibited. If you have received this email in error please
>
>>>> delete it and notify the sender immediately. Before opening any mail
>
>>>> and attachments please check them for viruses and defect.
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> --
>>>> -----------------------------------------------
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
>





_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 08:04:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It0rh-00045R-RD; Fri, 16 Nov 2007 08:04:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It0rg-00044J-Hb
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 08:04:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It0rg-00043L-63
	for sip@ietf.org; Fri, 16 Nov 2007 08:04:08 -0500
Received: from mail128.messagelabs.com ([216.82.250.131])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1It0rf-0006Pb-PG
	for sip@ietf.org; Fri, 16 Nov 2007 08:04:08 -0500
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-7.tower-128.messagelabs.com!1195218245!2944656!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 18036 invoked from network); 16 Nov 2007 13:04:05 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102)
	by server-7.tower-128.messagelabs.com with SMTP;
	16 Nov 2007 13:04:05 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233])
	by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAGD45kV025866
	for ; Fri, 16 Nov 2007 06:04:05 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242])
	by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAGD44Vo021815
	for ; Fri, 16 Nov 2007 07:04:05 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAGD42OC021792
	for ; Fri, 16 Nov 2007 07:04:03 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Status of require headers in the re-INVITE request.
Date: Fri, 16 Nov 2007 21:04:01 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0516D496@ZMY16EXM66.ds.mot.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Status of require headers in the re-INVITE request.
thread-index: AcgoI+as36BY5XJ9RX+hhlORYb8N8QALPw/Q
References: 
From: "Avasarala Ranjit-A20990" 
To: "Gupta Vineet-A18467" , 
X-CFilter-Loop: Reflected
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0994559544=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0994559544==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82851.28B2AED0"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82851.28B2AED0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Vineet
=20
It also depends on the purpose of reinvite. like if the re-invite is for
a call hold / resume, then there is no use of a Require:100rel header
there. =20
=20

Regards=20
Ranjit=20

=20

________________________________

From: Gupta Vineet-A18467=20
Sent: Friday, November 16, 2007 1:10 PM
To: sip@ietf.org
Subject: [Sip] Status of require headers in the re-INVITE request.


Hi,
=20
I have a doubt related to using Require:100rel in re-INVITE requests.
=20
If a Require header was used in the INVITE request establishing the
dialog, is it mandatory to include the same Require header in subsequent
re-INVITE requests within the dialog?
To be specific, if INVITE request contained Require:100rel, then
inclusion of Require:100rel in re-INVITE would require the originator to
handle Reliable provisional responses and respond accordingly. So, it
would also imply that re-INVITE also takes same call establishment time
(owing to multiple messages like 183 session in Progress, PRACK, 180
ringing, PRACK etc.).=20
=20
I agree, that such delay in re-INVITE might be acceptable given that
re-INVITE requires the user-intervention, but it complicates makes the
re-INVITE handling as complicated as the INVITE handling. Also, if the
initial INVITE involved procedures such as QoS negotiation the re-INVITE
state-machine complicates even further.
=20
Regards,
Vineet.
=20
"You're only given a little spark of madness. You mustn't lose it."
=20

------_=_NextPart_001_01C82851.28B2AED0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi Vineet


 


It also depends on the purpose of reinvite. =
like if the=20
re-invite is for a call hold / resume, then there is no use of a =
Require:100rel=20
header there.  


 


Regards 
Ranjit 


 






From: Gupta Vineet-A18467 =

Sent:=20
Friday, November 16, 2007 1:10 PM
To: =
sip@ietf.org
Subject:=20
[Sip] Status of require headers in the re-INVITE =
request.





Hi,


 


I have =
a doubt=20
related to using Require:100rel in re-INVITE =
requests.


 


If a Require=20
header was used in the INVITE request establishing the dialog, is it =
mandatory=20
to include the same Require header in subsequent re-INVITE requests =
within the=20
dialog?


To be =
specific, if=20
INVITE request contained Require:100rel, then inclusion of =
Require:100rel in=20
re-INVITE would require the originator to handle Reliable provisional =
responses=20
and respond accordingly. So, it would also imply that re-INVITE also =
takes same=20
call establishment time (owing to multiple messages like 183 session in=20
Progress, PRACK, 180 ringing, PRACK etc.). 


 


I =
agree, that such=20
delay in re-INVITE might be acceptable given that re-INVITE requires the =

user-intervention, but it complicates makes the re-INVITE handling as=20
complicated as the INVITE handling. Also, if the initial INVITE involved =

procedures such as QoS negotiation the re-INVITE state-machine =
complicates even=20
further.


 


Regards,




Vineet.


 


“You're only given a=20
little spark of madness. You mustn't lose =
it.”


 


------_=_NextPart_001_01C82851.28B2AED0--



--===============0994559544==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0994559544==--





From sip-bounces@ietf.org Fri Nov 16 08:10:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It0xN-0004HR-77; Fri, 16 Nov 2007 08:10:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It0xL-00049F-CN
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 08:09:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It0xL-000495-0u
	for sip@ietf.org; Fri, 16 Nov 2007 08:09:59 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It0xK-0006eG-DB
	for sip@ietf.org; Fri, 16 Nov 2007 08:09:58 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 16 Nov 2007 08:09:58 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAGD9wgC005559; 
	Fri, 16 Nov 2007 08:09:58 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAGD9iNZ019658; 
	Fri, 16 Nov 2007 13:09:49 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 08:09:44 -0500
Received: from [10.86.242.63] ([10.86.242.63]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 08:09:43 -0500
Message-ID: <473D9696.8050105@cisco.com>
Date: Fri, 16 Nov 2007 08:09:42 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: nataraju.basavaraju@wipro.com
Subject: Re: [Sip] Status of require headers in the re-INVITE request.
References: <01949ABCDD38EF4A95B8C347C399D1CE05B3C396@BLR-EC-MBX02.wipro.com>
In-Reply-To: <01949ABCDD38EF4A95B8C347C399D1CE05B3C396@BLR-EC-MBX02.wipro.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 16 Nov 2007 13:09:43.0735 (UTC)
	FILETIME=[F45E6C70:01C82851]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15548.002
X-TM-AS-Result: No--21.549400-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3999; t=1195218598;
	x=1196082598; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20Status=20of=20require=20headers=20in=20the=20
	re-INVITE=20request. |Sender:=20
	|To:=20nataraju.basavaraju@wipro.com;
	bh=5ZSNyspfCJWa679rjFRJxkWXDGgmlaS4/oiiDwZMtAs=;
	b=Ms86pzkPQKkHsR/oih/rbQB/XS53u5oDxE1W3gRCLyy3YvZU2otYZt+ztYhyH9WtkBsHyUsF
	pBBIlq+0BtXD9tvj7aXo/3CuFMFisyAfymmyIACpNJGSXCczDhTB2iTh;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Nataraju,

Why do you think this behavior is required?

The scope of applicability of Supported, Require, etc. is not well 
defined. If you want to be certain, then you should repeat these in 
every request. But if you *don't* include them in every request it is 
still likely that some peers will remember a value you sent earlier and 
assume it still applies.

This is a potential interoperability issue and should be fixed, but I 
think it will be difficult. To be useful these options generally need to 
have a scope longer than a single transaction, yet if you assume they 
should have longer scope then it becomes difficult to define when that 
scope ends.

In your particular case, if you want to use PRACK for the initial INVITE 
but you don't want to use it for reINVITE, I guess you can try omitting 
the Require:100rel in the reINVITE and hope for the best. But don't get 
upset if somebody still sends you PRACKs.

	Thanks,
	Paul

nataraju.basavaraju@wipro.com wrote:
> Comments inline...
> 
> *Regards,*
> *Nataraju A B*
> 
> ------------------------------------------------------------------------
> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
> *Sent:* Friday, November 16, 2007 1:10 PM
> *To:* sip@ietf.org
> *Subject:* [Sip] Status of require headers in the re-INVITE request.
> 
>     Hi,
>      
>     I have a doubt related to using Require:100rel in re-INVITE requests.
>      
>     *If a Require header was used in the INVITE request establishing the
>     dialog, is it mandatory to include the same Require header in
>     subsequent re-INVITE requests within the dialog?
>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>     Require header values that of INVITE.
>      
>     To be specific, if INVITE request contained Require:100rel, then
>     inclusion of Require:100rel in re-INVITE would require the
>     originator to handle Reliable provisional responses and respond
>     accordingly. So, it would also imply that re-INVITE also takes same
>     call establishment time (owing to multiple messages like 183 session
>     in Progress, PRACK, 180 ringing, PRACK etc.).
>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>     has to generate 1xx. if UAS generates 1xx responses for re-INVITE,
>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it is
>     not mandatory to send  1xx for re-INVITE, hence even if
>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>     with out PRACK transaction.
>      
>     I agree, that such delay in re-INVITE might be acceptable given that
>     re-INVITE requires the user-intervention, but it complicates makes
>     the re-INVITE handling as complicated as the INVITE handling. Also,
>     if the initial INVITE involved procedures such as QoS negotiation
>     the re-INVITE state-machine complicates even further.
>      
>     [ABN] In most of the cases, re-INVITE is not expected to undergo
>     user-intervention. hence in most of the cases it would end up with
>     re-INV, 200, ACK only...
>      
>     In general, re-INVITE is expected to perform subset of what happened
>     in INVITE transaction. it should not create any issues to handle 1xx
>     responses reliably.
>      
>     Hope this answers all your questions...
>      
>     Regards,
>     Vineet.
>      
>     /“You're only given a little spark of madness. You mustn't lose it.”/
>      
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 08:51:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It1aw-0008Ao-7t; Fri, 16 Nov 2007 08:50:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It1au-0008A9-EK
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 08:50:52 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It1au-00089c-2F
	for sip@ietf.org; Fri, 16 Nov 2007 08:50:52 -0500
Received: from mail119.messagelabs.com ([216.82.241.179])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1It1at-0000lB-Cg
	for sip@ietf.org; Fri, 16 Nov 2007 08:50:51 -0500
X-VirusChecked: Checked
X-Env-Sender: vineet.gupta@motorola.com
X-Msg-Ref: server-12.tower-119.messagelabs.com!1195221046!33605420!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.101]
Received: (qmail 16043 invoked from network); 16 Nov 2007 13:50:46 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101)
	by server-12.tower-119.messagelabs.com with SMTP;
	16 Nov 2007 13:50:46 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232])
	by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAGDojvp008321
	for ; Fri, 16 Nov 2007 06:50:45 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242])
	by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAGDoipl015044
	for ; Fri, 16 Nov 2007 07:50:44 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAGDogm9015014
	for ; Fri, 16 Nov 2007 07:50:43 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Status of require headers in the re-INVITE request.
Date: Fri, 16 Nov 2007 21:50:41 +0800
Message-ID: 
In-Reply-To: <473D9696.8050105@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Status of require headers in the re-INVITE request.
thread-index: AcgoUgLsZVSfK9oWQpC0J3StVCUZXQAA11TQ
From: "Gupta Vineet-A18467" 
To: "Paul Kyzivat" , ,
	"Avasarala Ranjit-A20990" 
X-CFilter-Loop: Reflected
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,

Natraju, I will be glad if you can point out sections in RFC/drafts
which suggest the same. Also, I believe if the user intervention is not
required for session modification, the UA	 would use UPDATE rather
than re-INVITE.

I agree with Paul in that there is well defined scope of the
applicability of Supported/Require headers to a dialog.

Logically, I assume an highly interoperable implementation should use
same value of Supported/Require headers of all the requests within the
dialog, but  I want to explore the oppurtunity for an extended
implementation for use-case such as 100rel, where the implementor might
chose to include the same in INVITE request and omit the same in
re-INVITE request.=20

This is because, even though re-INVITE requires user intervetion it
might not require the same set of Offer-Answer negotiations and resource
reservation negotiations that was there in session establishement.

Also, would be interopable implementation to use UPDATE method for
session modifications which don't require user intervention, and
re-INVITE for session modifications which require user intervention?

Regards,
Vineet.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Friday, November 16, 2007 6:40 PM
To: nataraju.basavaraju@wipro.com
Cc: Gupta Vineet-A18467; sip@ietf.org
Subject: Re: [Sip] Status of require headers in the re-INVITE request.

Nataraju,

Why do you think this behavior is required?

The scope of applicability of Supported, Require, etc. is not well
defined. If you want to be certain, then you should repeat these in
every request. But if you *don't* include them in every request it is
still likely that some peers will remember a value you sent earlier and
assume it still applies.

This is a potential interoperability issue and should be fixed, but I
think it will be difficult. To be useful these options generally need to
have a scope longer than a single transaction, yet if you assume they
should have longer scope then it becomes difficult to define when that
scope ends.

In your particular case, if you want to use PRACK for the initial INVITE
but you don't want to use it for reINVITE, I guess you can try omitting
the Require:100rel in the reINVITE and hope for the best. But don't get
upset if somebody still sends you PRACKs.

	Thanks,
	Paul

nataraju.basavaraju@wipro.com wrote:
> Comments inline...
>=20
> *Regards,*
> *Nataraju A B*
>=20
> ----------------------------------------------------------------------
> --
> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
> *Sent:* Friday, November 16, 2007 1:10 PM
> *To:* sip@ietf.org
> *Subject:* [Sip] Status of require headers in the re-INVITE request.
>=20
>     Hi,
>     =20
>     I have a doubt related to using Require:100rel in re-INVITE
requests.
>     =20
>     *If a Require header was used in the INVITE request establishing
the
>     dialog, is it mandatory to include the same Require header in
>     subsequent re-INVITE requests within the dialog?
>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>     Require header values that of INVITE.
>     =20
>     To be specific, if INVITE request contained Require:100rel, then
>     inclusion of Require:100rel in re-INVITE would require the
>     originator to handle Reliable provisional responses and respond
>     accordingly. So, it would also imply that re-INVITE also takes
same
>     call establishment time (owing to multiple messages like 183
session
>     in Progress, PRACK, 180 ringing, PRACK etc.).
>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>     has to generate 1xx. if UAS generates 1xx responses for re-INVITE,
>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it
is
>     not mandatory to send  1xx for re-INVITE, hence even if
>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>     with out PRACK transaction.
>     =20
>     I agree, that such delay in re-INVITE might be acceptable given
that
>     re-INVITE requires the user-intervention, but it complicates makes
>     the re-INVITE handling as complicated as the INVITE handling.
Also,
>     if the initial INVITE involved procedures such as QoS negotiation
>     the re-INVITE state-machine complicates even further.
>     =20
>     [ABN] In most of the cases, re-INVITE is not expected to undergo
>     user-intervention. hence in most of the cases it would end up with
>     re-INV, 200, ACK only...
>     =20
>     In general, re-INVITE is expected to perform subset of what
happened
>     in INVITE transaction. it should not create any issues to handle
1xx
>     responses reliably.
>     =20
>     Hope this answers all your questions...
>     =20
>     Regards,
>     Vineet.
>     =20
>     /"You're only given a little spark of madness. You mustn't lose=20
> it."/
>     =20
>=20
>=20
> ----------------------------------------------------------------------
> --
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 09:22:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It25r-0002qh-9s; Fri, 16 Nov 2007 09:22:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It25p-0002oj-NG
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:22:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It25p-0002na-Ap
	for sip@ietf.org; Fri, 16 Nov 2007 09:22:49 -0500
Received: from wip-cdc-wd.wipro.com ([203.91.201.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It25j-0005wP-Ur
	for sip@ietf.org; Fri, 16 Nov 2007 09:22:49 -0500
Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1])
	by localhost (Postfix) with ESMTP id D06F818071
	for ; Fri, 16 Nov 2007 19:52:41 +0530 (IST)
Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91])
	by wip-cdc-wd.wipro.com (Postfix) with ESMTP id BDF2F18051
	for ; Fri, 16 Nov 2007 19:52:41 +0530 (IST)
Received: from BLR-EC-MBX02.wipro.com ([10.201.50.161]) by
	blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Fri, 16 Nov 2007 19:52:42 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Status of require headers in the re-INVITE request.
Date: Fri, 16 Nov 2007 19:51:32 +0530
Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>
In-Reply-To: <473D9696.8050105@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Status of require headers in the re-INVITE request.
Thread-Index: AcgoUgCzfjJ4+sXATLqQ2hM7yoDlJQAAFOvw
From: 
To: 
X-OriginalArrivalTime: 16 Nov 2007 14:22:42.0065 (UTC)
	FILETIME=[260E9010:01C8285C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Paul,=20

You are right, its not a mandatory that re-INVITE carry the same set of
options which INVITE carried. It would vary from application to
application.

To make the implementation simpler UAs might decide to send the same set
of options negotiated during initial INVITE transaction. At least its
not acceptable to add more options in re-INVITE, which were not
negotiated during INTITE transaction. If so it might end up with a an
issue with refresh (if remote guy does not support the new option). As
you said it has interoperability issue, because different people
implement in different manner.=20

Regards,
Nataraju A B

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Friday, November 16, 2007 6:40 PM
To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
Infrastructure)
Cc: vineet.gupta@motorola.com; sip@ietf.org
Subject: Re: [Sip] Status of require headers in the re-INVITE request.

Nataraju,

Why do you think this behavior is required?

The scope of applicability of Supported, Require, etc. is not well
defined. If you want to be certain, then you should repeat these in
every request. But if you *don't* include them in every request it is
still likely that some peers will remember a value you sent earlier and
assume it still applies.

This is a potential interoperability issue and should be fixed, but I
think it will be difficult. To be useful these options generally need to
have a scope longer than a single transaction, yet if you assume they
should have longer scope then it becomes difficult to define when that
scope ends.

In your particular case, if you want to use PRACK for the initial INVITE
but you don't want to use it for reINVITE, I guess you can try omitting
the Require:100rel in the reINVITE and hope for the best. But don't get
upset if somebody still sends you PRACKs.

	Thanks,
	Paul

nataraju.basavaraju@wipro.com wrote:
> Comments inline...
>=20
> *Regards,*
> *Nataraju A B*
>=20
> ----------------------------------------------------------------------
> --
> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
> *Sent:* Friday, November 16, 2007 1:10 PM
> *To:* sip@ietf.org
> *Subject:* [Sip] Status of require headers in the re-INVITE request.
>=20
>     Hi,
>     =20
>     I have a doubt related to using Require:100rel in re-INVITE
requests.
>     =20
>     *If a Require header was used in the INVITE request establishing
the
>     dialog, is it mandatory to include the same Require header in
>     subsequent re-INVITE requests within the dialog?
>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>     Require header values that of INVITE.
>     =20
>     To be specific, if INVITE request contained Require:100rel, then
>     inclusion of Require:100rel in re-INVITE would require the
>     originator to handle Reliable provisional responses and respond
>     accordingly. So, it would also imply that re-INVITE also takes
same
>     call establishment time (owing to multiple messages like 183
session
>     in Progress, PRACK, 180 ringing, PRACK etc.).
>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>     has to generate 1xx. if UAS generates 1xx responses for re-INVITE,
>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it
is
>     not mandatory to send  1xx for re-INVITE, hence even if
>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>     with out PRACK transaction.
>     =20
>     I agree, that such delay in re-INVITE might be acceptable given
that
>     re-INVITE requires the user-intervention, but it complicates makes
>     the re-INVITE handling as complicated as the INVITE handling.
Also,
>     if the initial INVITE involved procedures such as QoS negotiation
>     the re-INVITE state-machine complicates even further.
>     =20
>     [ABN] In most of the cases, re-INVITE is not expected to undergo
>     user-intervention. hence in most of the cases it would end up with
>     re-INV, 200, ACK only...
>     =20
>     In general, re-INVITE is expected to perform subset of what
happened
>     in INVITE transaction. it should not create any issues to handle
1xx
>     responses reliably.
>     =20
>     Hope this answers all your questions...
>     =20
>     Regards,
>     Vineet.
>     =20
>     /"You're only given a little spark of madness. You mustn't lose=20
> it."/
>     =20
>=20
>=20
> ----------------------------------------------------------------------
> --
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 09:28:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It2Az-0000Cm-VH; Fri, 16 Nov 2007 09:28:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It2Ay-0000A4-Cn
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:28:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It2Ay-00009u-0a
	for sip@ietf.org; Fri, 16 Nov 2007 09:28:08 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It2Aw-0003eV-4d
	for sip@ietf.org; Fri, 16 Nov 2007 09:28:07 -0500
Received: from rly30f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly30f.srv.mailcontrol.com (MailControl) with ESMTP id
	lAGERurw003212 for ; Fri, 16 Nov 2007 14:28:04 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly30f.srv.mailcontrol.com (MailControl) id lAGERVhC032528
	for sip@ietf.org; Fri, 16 Nov 2007 14:27:31 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly30f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lAGEQvCR028287; Fri, 16 Nov 2007 14:27:31 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 14:28:06 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Can a transaction stateless proxysupportOutbounddraft?Ifyes,
	how will the response be sent back the UAbehind NAT
Date: Fri, 16 Nov 2007 14:27:26 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60A02DCD@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can a transaction stateless
	proxysupportOutbounddraft?Ifyes,
	how will the response be sent back the UAbehind NAT
Thread-Index: AcgoUD6VDLAJs8hRSF6Zu1JzEHPSPgAB8DNQ
From: "Attila Sipos" 
To: 
X-OriginalArrivalTime: 16 Nov 2007 14:28:06.0892 (UTC)
	FILETIME=[E7AB3AC0:01C8285C]
X-Scanned-By: MailControl A-08-00-02 (www.mailcontrol.com) on 10.70.1.140
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e52c6009a9b39871b75233310d7f3490
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20

>>>>> 3.
>>>>>> In the Via header's branch parameter, it would encode the
required=20
>>>>>> flow token.
>>>>>
>>>>> Here is the issue : From were you get the flow token?
>>>>> (In my previous email I mentioned 2 options... )
>>>>>
>>>
>>> OK I'm starting to see your problem.
>>>
>>> The registration record stores the flow token (obviously)
>>
>>It seems that you are integrating the edge proxy and registrar in the
same code, right?

yes, that's it.


>>> And the socket id for the flow would be stored as well (for
>>
>>Can you confirm that you call socket id to the socket/file descriptor
of the connection?

yes.

>>> connection-oriented
>>> protocols). So if you received a request on that socket, you could=20
>>> match that up to one of the registration records and hence, one of
the=20
>>> flow tokens.
>>>
>>
>>  Good approach. I assume that you have available the socket
descriptor
>>in the registrar, so basically you consider storing the socket
descriptor
>>(number) in the registrar tables. Then perhaps using a flow token it
is not
>>necessary since you have available in the socket descriptor all the
information
>>that describes a flow (TCP case).

That's true.  I might not need the flow tokens.


>>> I hope I have explained how the flow token might be mapped to the=20
>>> socket.
>>
>>  Yes if my comments above make sense..
>>
>>> I can now see that my idea wouldn't work for UDP.
>>
>>  Now for UDP perhaps you can consider storing the socket descriptor
for
>>UDP and the IP and port for the flow from the NAT.

yes, that would work I think.


>>  Furthermore my registrar should not store socket descriptors due
that
>>if the edge proxy crashes, the registrar could have a number of
descriptor
>>that after the crash belong to other flows.
>>
>>  I generate the flow token with REGISTER and send it to the registrar
>>(other node). The approach works as the draft says for incoming
requests
>>(to the Calle). Now when the Callee  sends requests, and the requests
are
>>sent over the flow, the responses of that request reach first the edge
proxy
>>and it can not forward them to the Callee over the flow, because these
>>responses don't have the flow token (and the flow token is not stored
in
>>the edge proxy)...

I am starting to see the problems.

If I understand correctly, your scenario is this...

REGISTRAR--------PROXY----------NAT---------SIP UA

Can you confirm?

And, since you were talking about scalability, you might also have
REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA

is this right?


>>> But what if you used the gruu in the contact to match up with the
gruu=20
>>> of a registration?  Then the registration record tells tells you
about=20
>>> the flow token.  That would work wouldn't it?
>>
>>  I have not background with gruu. Could you recommend what could I
read about it?

Sorry, I didn't mean gruu, I was mixing up my drafts!
I was just looking for a unique identifier for the UA
which is the sip.instance from the outbound draft (not gruu).


Regards,
Attila



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Quoting Attila Sipos :

>>> 1.
>>>> Now let's say the callee sends BYE (not the caller).
>>>
>>> Ok, here I see 2 options.
>>> 1) The BYE is sent over the flow
>>> 2) The BYE is sent in a traditional way (non-outbound case)
>>>
>>> I assume that you are talking of option 1) above.
>
> yes.  I would have thought that it must be sent using the flow.
>
>
>>> 2.
>>>> So my idea is that the proxy gets this and forwards it in the=20
>>>> normal
>
>>>> way and inserts a Via header.
>>>
>>> I agree.
>>>
>>> 3.
>>>> In the Via header's branch parameter, it would encode the required=20
>>>> flow token.
>>>
>>> Here is the issue : From were you get the flow token?
>>> (In my previous email I mentioned 2 options... )
>>>
>
> OK I'm starting to see your problem.
>
> The registration record stores the flow token (obviously) And the=20
> socket id for the flow would be stored as well (for=20
> connection-oriented protocols). So if you received a request on that=20
> socket, you could match that up to one of the registration records and

> hence, one of the flow tokens.
>
> (I think I am starting to see some difficulties with this)
>
>
>>> 4.
>>>>> Then when the 200 response arrives,
>>>>>> it looks at the top Via and decodes the branch parameter.  From
> this
>>>>>> it knows which flow to use to forward the response.
>>>
>>> If you managed to add the flow token in the step above it is OK
>
>
> I hope I have explained how the flow token might be mapped to the=20
> socket.
> I can now see that my idea wouldn't work for UDP.
>
> But what if you used the gruu in the contact to match up with the gruu

> of a registration?  Then the registration record tells tells you about

> the flow token.  That would work wouldn't it?
>
> Regards,
> 	Attila
>
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 15 November 2007 17:45
> To: sip@ietf.org
> Cc: Attila Sipos
> Subject: RE: [Sip] Can a transaction stateless proxy=20
> supportOutbounddraft?Ifyes, how will the response be sent back the UA=20
> behind NAT
>
>
>> I was talking about the stateless proxy putting the flow token into=20
>> the Via.
>> I don't understand why you mentioned UA's.
>
>   Yes, me too. I mentioned the UA because is a possible solution to=20
> pass the flow token to the edge proxy when it handles non-register
requests.
>
>> re:=20
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
>> Let's say we use the "Example Message Flow".  To forward the INVITE=20
>> in
>
>> message 7, we use the existing flow created by the REGISTRATION.
>> The response of message 9 gets forwarded in the normal way and as=20
>> defined in the outbound draft (i.e. it adds the flow token into the=20
>> Record-Route).
>
>   Yes, I agree.
>
>
> 1.
>> Now let's say the callee sends BYE (not the caller).
>
> Ok, here I see 2 options.
> 1) The BYE is sent over the flow
> 2) The BYE is sent in a traditional way (non-outbound case)
>
> I assume that you are talking of option 1) above.
>
> 2.
>> So my idea is that the proxy gets this and forwards it in the normal=20
>> way and inserts a Via header.
>
> I agree.
>
> 3.
>> In the Via header's branch parameter, it would encode the required=20
>> flow token.
>
> Here is the issue : From were you get the flow token?
> (In my previous email I mentioned 2 options... )
>
> 4.
>> Then when the 200 response
>> arrives,
>> it looks at the top Via and decodes the branch parameter.  From this=20
>> it knows which flow to use to forward the response.
>
>   If you managed to add the flow token in the step above it is OK
>
>
>   In my opinion there is a problem in step 3. In my previous email I=20
> mentioned this case, I copy the text below :
>
>>   To put the flow token in the Via I see 2 options : 1) ensure that=20
>> the UA stores the flow token and sends it in the body of every=20
>> request. 2) generate again the flow token for every request (very bad

>> from security point of views) and destroys the consistency of the=20
>> system since you can send requests for non existing flows. Note that=20
>> the draft mentions that the flow and the flow token is only created
> with REGISTERs.
>
>   Any ideas or comments are welcome. I was dealing with this issue for

> months...
>
>
> Regards,
>
> Sergio
>
>
> Quoting Attila Sipos :
>
>>
>> I was talking about the stateless proxy putting the flow token into=20
>> the Via.
>> I don't understand why you mentioned UA's.
>>
>> re:=20
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
>> Let's say we use the "Example Message Flow".  To forward the INVITE=20
>> in
>
>> message 7, we use the existing flow created by the REGISTRATION.
>> The response of message 9 gets forwarded in the normal way and as=20
>> defined in the outbound draft (i.e. it adds the flow token into the=20
>> Record-Route).
>>
>> Now let's say the callee sends BYE (not the caller).
>>
>> So my idea is that the proxy gets this and forwards it in the normal=20
>> way and inserts a Via header. In the Via header's branch parameter,=20
>> it
>
>> would encode the required flow token.  Then when the 200 response=20
>> arrives, it looks at the top Via and decodes the branch parameter.
>> From this it knows which flow to use to forward the response.
>>
>> Is this wrong?
>>
>> 	Attila
>>
>>
>>
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: 15 November 2007 16:18
>> To: sip@ietf.org
>> Cc: Attila Sipos
>> Subject: RE: [Sip] Can a transaction stateless proxy support=20
>> Outbounddraft?Ifyes, how will the response be sent back the UA behind

>> NAT
>>
>>
>>> But couldn't you encode the flow token into the Via's branch
>> parameter?
>>
>>   Yes, it is possible, but the draft does not tell anything about=20
>> responses.
>>   To put the flow token in the Via I see 2 options : 1) ensure that=20
>> the UA stores the flow token and sends it in the body of every=20
>> request. 2) generate again the flow token for every request (very bad

>> from security point of views) and destroys the consistency of the=20
>> system since you can send requests for non existing flows. Note that=20
>> the draft mentions that the flow and the flow token is only created
> with REGISTERs.
>>
>>   I guess that the authors did not consider this issue because the UA

>> can go through the NAT, so it can always send requests and receive=20
>> responses normally out of the flow.
>>
>> Sergio
>>
>> Quoting Attila Sipos :
>>
>>>>>  That is not possible if we limit to the draft.
>>>>>  Normal responses use the information in the Via header, and to=20
>>>>> use
>
>>>>> the flow we need a flow token (that is not available in the
>>> Via)...
>>>
>>> But couldn't you encode the flow token into the Via's branch
>> parameter?
>>> You'd have to make sure you didn't break SIP grammar rules (but a=20
>>> variation of base 64 would solve that).
>>>
>>> Would there be a problem with that?
>>>
>>> Regards,
>>> Attila
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>>> Sent: 15 November 2007 15:14
>>> To: sip@ietf.org
>>> Cc: Attila Sipos
>>> Subject: RE: [Sip] Can a transaction stateless proxy support=20
>>> Outbounddraft? Ifyes, how will the response be sent back the UA=20
>>> behind
>>
>>> NAT
>>>
>>>
>>>
>>>> For requests from the registered UA, the responses will be routed=20
>>>> back
>>>
>>>> to the UA using the established flow.
>>>
>>>   That is not possible if we limit to the draft.
>>>   Normal responses use the information in the Via header, and to use

>>> the flow we need a flow token (that is not available in the Via)...
>>>
>>>
>>> Sergio
>>>
>>>
>>> Quoting Attila Sipos :
>>>
>>>>
>>>> I think a stateless proxy CAN support outbound.
>>>>
>>>> As long as the stateless proxy can store registrations (well,=20
>>>> what's
>
>>>> the point if it can't) then it can keep up a flow back to any=20
>>>> registering UA.
>>>>
>>>> When it comes to routing a request to a registered UA, it will=20
>>>> route
>
>>>> it using the establiashed flow.  For requests from the registered=20
>>>> UA,
>>
>>>> the responses will be routed back to the UA using the established
>>> flow.
>>>>
>>>> Can you see a problem with this?  It seems like it should work to
> me.
>>>>
>>>> Regards,
>>>> Attila
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Karthikeyan Gopal , TLS-Chennai [mailto:g_karthikeyan@hcl.in]
>>>> Sent: 15 November 2007 08:06
>>>> To: sip@ietf.org
>>>> Cc: dean.willis@softarmor.com
>>>> Subject: [Sip] Can a transaction stateless proxy support Outbound
>>> draft?
>>>> Ifyes, how will the response be sent back the UA behind NAT
>>>>
>>>>
>>>>
>>>> Hi All,
>>>>     Can a transaction stateless proxy support Outbound draft? If=20
>>>> yes,
>>
>>>> how will the response be sent back the UA behind NAT?
>>>> Thanks & Regards,
>>>> Karthikeyan.G
>>>>
>>>>
>>>>
>>>> DISCLAIMER:
>>>> -------------------------------------------------------------------
>>>> -
>>>> -
>>>> -
>>>> --
>>>> -----------------------------------------------
>>>>
>>>> The contents of this e-mail and any attachment(s) are confidential=20
>>>> and
>>>
>>>> intended for the named recipient(s) only.
>>>> It shall not attach any liability on the originator or HCL or its=20
>>>> affiliates. Any views or opinions presented in this email are=20
>>>> solely
>
>>>> those of the author and may not necessarily reflect the opinions of

>>>> HCL or its affiliates.
>>>> Any form of reproduction, dissemination, copying, disclosure,=20
>>>> modification, distribution and / or publication of this message=20
>>>> without the prior written consent of the author of this e-mail is=20
>>>> strictly prohibited. If you have received this email in error=20
>>>> please
>
>>>> delete it and notify the sender immediately. Before opening any=20
>>>> mail
>
>>>> and attachments please check them for viruses and defect.
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> -
>>>> -
>>>> --
>>>> -----------------------------------------------
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the core SIP Protocol Use=20
>>>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>>>> sipping@ietf.org for new developments on the application of sip
>>>>
>>>>
>>>> _______________________________________________
>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the core SIP Protocol Use=20
>>>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>>>> sipping@ietf.org for new developments on the application of sip
>>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use=20
>>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>>> sipping@ietf.org for new developments on the application of sip
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>
>
>
>
>





_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 09:29:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It2Cl-00034s-8X; Fri, 16 Nov 2007 09:29:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It2Ck-00032T-BW
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:29:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It2Cj-00031V-Va
	for sip@ietf.org; Fri, 16 Nov 2007 09:29:58 -0500
Received: from wip-cdc-wd.wipro.com ([203.91.201.26])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It2Ci-0003mh-Om
	for sip@ietf.org; Fri, 16 Nov 2007 09:29:57 -0500
Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1])
	by localhost (Postfix) with ESMTP id 891BA18075
	for ; Fri, 16 Nov 2007 19:59:54 +0530 (IST)
Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91])
	by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 778E718051
	for ; Fri, 16 Nov 2007 19:59:54 +0530 (IST)
Received: from BLR-EC-MBX02.wipro.com ([10.201.50.161]) by
	blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Fri, 16 Nov 2007 19:59:54 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Status of require headers in the re-INVITE request.
Date: Fri, 16 Nov 2007 19:58:45 +0530
Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE05B7EBA3@BLR-EC-MBX02.wipro.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Status of require headers in the re-INVITE request.
Thread-Index: AcgoUgLsZVSfK9oWQpC0J3StVCUZXQAA11TQAAG8RjA=
From: 
To: , , 
X-OriginalArrivalTime: 16 Nov 2007 14:29:54.0770 (UTC)
	FILETIME=[27F81B20:01C8285D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Inline...

Regards,
Nataraju A B

-----Original Message-----
From: Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]=20
Sent: Friday, November 16, 2007 7:21 PM
To: Paul Kyzivat; Nataraju Alilughatta basavaraju (WT01 - TES-Mobility &
Carrier Infrastructure); Avasarala Ranjit-A20990
Cc: sip@ietf.org
Subject: RE: [Sip] Status of require headers in the re-INVITE request.

Hi,

Natraju, I will be glad if you can point out sections in RFC/drafts
which suggest the same. Also, I believe if the user intervention is not
required for session modification, the UA	 would use UPDATE rather
than re-INVITE.

[ABN] its based on my insight and understanding. By doing so, you might
avoid some unwanted issues.

I agree with Paul in that there is well defined scope of the
applicability of Supported/Require headers to a dialog.

Logically, I assume an highly interoperable implementation should use
same value of Supported/Require headers of all the requests within the
dialog, but  I want to explore the oppurtunity for an extended
implementation for use-case such as 100rel, where the implementor might
chose to include the same in INVITE request and omit the same in
re-INVITE request.=20

This is because, even though re-INVITE requires user intervetion it
might not require the same set of Offer-Answer negotiations and resource
reservation negotiations that was there in session establishement.

Also, would be interopable implementation to use UPDATE method for
session modifications which don't require user intervention, and
re-INVITE for session modifications which require user intervention?

[ABN] its my understanding and information about most implementation
only. I have not read any where it has to be same or not. Probably if
you can validate the alternatives for different features you can infer
which is better over others...=20

Regards,
Vineet.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Friday, November 16, 2007 6:40 PM
To: nataraju.basavaraju@wipro.com
Cc: Gupta Vineet-A18467; sip@ietf.org
Subject: Re: [Sip] Status of require headers in the re-INVITE request.

Nataraju,

Why do you think this behavior is required?

The scope of applicability of Supported, Require, etc. is not well
defined. If you want to be certain, then you should repeat these in
every request. But if you *don't* include them in every request it is
still likely that some peers will remember a value you sent earlier and
assume it still applies.

This is a potential interoperability issue and should be fixed, but I
think it will be difficult. To be useful these options generally need to
have a scope longer than a single transaction, yet if you assume they
should have longer scope then it becomes difficult to define when that
scope ends.

In your particular case, if you want to use PRACK for the initial INVITE
but you don't want to use it for reINVITE, I guess you can try omitting
the Require:100rel in the reINVITE and hope for the best. But don't get
upset if somebody still sends you PRACKs.

	Thanks,
	Paul

nataraju.basavaraju@wipro.com wrote:
> Comments inline...
>=20
> *Regards,*
> *Nataraju A B*
>=20
> ----------------------------------------------------------------------
> --
> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
> *Sent:* Friday, November 16, 2007 1:10 PM
> *To:* sip@ietf.org
> *Subject:* [Sip] Status of require headers in the re-INVITE request.
>=20
>     Hi,
>     =20
>     I have a doubt related to using Require:100rel in re-INVITE
requests.
>     =20
>     *If a Require header was used in the INVITE request establishing
the
>     dialog, is it mandatory to include the same Require header in
>     subsequent re-INVITE requests within the dialog?
>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>     Require header values that of INVITE.
>     =20
>     To be specific, if INVITE request contained Require:100rel, then
>     inclusion of Require:100rel in re-INVITE would require the
>     originator to handle Reliable provisional responses and respond
>     accordingly. So, it would also imply that re-INVITE also takes
same
>     call establishment time (owing to multiple messages like 183
session
>     in Progress, PRACK, 180 ringing, PRACK etc.).
>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>     has to generate 1xx. if UAS generates 1xx responses for re-INVITE,
>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it
is
>     not mandatory to send  1xx for re-INVITE, hence even if
>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>     with out PRACK transaction.
>     =20
>     I agree, that such delay in re-INVITE might be acceptable given
that
>     re-INVITE requires the user-intervention, but it complicates makes
>     the re-INVITE handling as complicated as the INVITE handling.
Also,
>     if the initial INVITE involved procedures such as QoS negotiation
>     the re-INVITE state-machine complicates even further.
>     =20
>     [ABN] In most of the cases, re-INVITE is not expected to undergo
>     user-intervention. hence in most of the cases it would end up with
>     re-INV, 200, ACK only...
>     =20
>     In general, re-INVITE is expected to perform subset of what
happened
>     in INVITE transaction. it should not create any issues to handle
1xx
>     responses reliably.
>     =20
>     Hope this answers all your questions...
>     =20
>     Regards,
>     Vineet.
>     =20
>     /"You're only given a little spark of madness. You mustn't lose=20
> it."/
>     =20
>=20
>=20
> ----------------------------------------------------------------------
> --
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 10:56:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It3Yg-0006oy-J9; Fri, 16 Nov 2007 10:56:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It3Yf-0006kZ-7W
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:56:41 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It3Ye-0006gu-Nq
	for sip@ietf.org; Fri, 16 Nov 2007 10:56:40 -0500
Received: from smtp-2.hut.fi ([130.233.228.92])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3Yd-0004Q3-Oh
	for sip@ietf.org; Fri, 16 Nov 2007 10:56:40 -0500
Received: from localhost (putosiko.hut.fi [130.233.228.114])
	by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id lAGFucO2014724
	for ; Fri, 16 Nov 2007 17:56:38 +0200
Received: from smtp-2.hut.fi ([130.233.228.92])
	by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new,
	port 10024) with LMTP id 04344-21-2 for ;
	Fri, 16 Nov 2007 17:56:37 +0200 (EET)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id lAGFtJ2W014268
	for ; Fri, 16 Nov 2007 17:55:19 +0200
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 87BBE3A2CDE
	for ; Fri, 16 Nov 2007 17:55:19 +0200 (EET)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 12804-08 for ;
	Fri, 16 Nov 2007 17:55:17 +0200 (EET)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id BD0343A2CD8
	for ; Fri, 16 Nov 2007 17:55:17 +0200 (EET)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Fri, 16 Nov 2007 17:55:17 +0200
Message-ID: <20071116175517.3qiis41ajo84kgg8@horde-intra.tml.hut.fi>
Date: Fri, 16 Nov 2007 17:55:17 +0200
From: sergiole@tml.hut.fi
To: sip@ietf.org
Subject: RE: [Sip] Can a transaction stateless
	proxysupportOutbounddraft?Ifyes, how will the response be sent back the
	UAbehind NAT
References: <680808427CF931459462C3D78CB5EC60A02DCD@EXVS02.nasstar-t1.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC60A02DCD@EXVS02.nasstar-t1.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> I am starting to see the problems.
>
> If I understand correctly, your scenario is this...
>
> REGISTRAR--------PROXY----------NAT---------SIP UA
>
> Can you confirm?

more specifically my scenario is

REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA


where PROXY is a traditional SIP proxy


> And, since you were talking about scalability, you might also have
> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>
> is this right?


   About scalability I was thinking about


                         /EDGEPROXY1\
REGISTRAR/PROXY--------            ----------NAT---------SIP UA
                         \EDGEPROXY2/


   So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.


   I have no experience with registrars, I guess that in your case you
have a REGISTRAR/EDGEPROXY in the same process (or group of processes)
and not
REGISTRAR--------EDGEPROXY (linked by other means).

   The problem with the above (separated elements) is that there is not
synchronization about the state of the socket descriptors. As
mentioned before, if the edge proxy crashes the socket descriptors
used immediately after reboot could result in delivering messages to
different flows.

   In my opinion the randomness included in the flow token avoids that
to happen, since after reboot the flowtoken can not be decoded and/or
find an existing flow and that cause the return a error response.
   Then another entry in the registrar binding will be used, i.e. other
flow token. If you have a second edge proxy (that does not crashed at
the same time that the first one :) and the flow token belongs to the
second edge proxy, the message will reach the UA over a flow
previously established to the second edge proxy.



BR

Sergio


Quoting Attila Sipos :

>
>
>>>>>> 3.
>>>>>>> In the Via header's branch parameter, it would encode the
> required
>>>>>>> flow token.
>>>>>>
>>>>>> Here is the issue : From were you get the flow token?
>>>>>> (In my previous email I mentioned 2 options... )
>>>>>>
>>>>
>>>> OK I'm starting to see your problem.
>>>>
>>>> The registration record stores the flow token (obviously)
>>>
>>> It seems that you are integrating the edge proxy and registrar in the
> same code, right?
>
> yes, that's it.
>
>
>>>> And the socket id for the flow would be stored as well (for
>>>
>>> Can you confirm that you call socket id to the socket/file descriptor
> of the connection?
>
> yes.
>
>>>> connection-oriented
>>>> protocols). So if you received a request on that socket, you could
>>>> match that up to one of the registration records and hence, one of
> the
>>>> flow tokens.
>>>>
>>>
>>>  Good approach. I assume that you have available the socket
> descriptor
>>> in the registrar, so basically you consider storing the socket
> descriptor
>>> (number) in the registrar tables. Then perhaps using a flow token it
> is not
>>> necessary since you have available in the socket descriptor all the
> information
>>> that describes a flow (TCP case).
>
> That's true.  I might not need the flow tokens.
>
>
>>>> I hope I have explained how the flow token might be mapped to the
>>>> socket.
>>>
>>>  Yes if my comments above make sense..
>>>
>>>> I can now see that my idea wouldn't work for UDP.
>>>
>>>  Now for UDP perhaps you can consider storing the socket descriptor
> for
>>> UDP and the IP and port for the flow from the NAT.
>
> yes, that would work I think.
>
>
>>>  Furthermore my registrar should not store socket descriptors due
> that
>>> if the edge proxy crashes, the registrar could have a number of
> descriptor
>>> that after the crash belong to other flows.
>>>
>>>  I generate the flow token with REGISTER and send it to the registrar
>>> (other node). The approach works as the draft says for incoming
> requests
>>> (to the Calle). Now when the Callee  sends requests, and the requests
> are
>>> sent over the flow, the responses of that request reach first the edge
> proxy
>>> and it can not forward them to the Callee over the flow, because these
>>> responses don't have the flow token (and the flow token is not stored
> in
>>> the edge proxy)...
>
> I am starting to see the problems.
>
> If I understand correctly, your scenario is this...
>
> REGISTRAR--------PROXY----------NAT---------SIP UA
>
> Can you confirm?
>
> And, since you were talking about scalability, you might also have
> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>
> is this right?
>
>
>>>> But what if you used the gruu in the contact to match up with the
> gruu
>>>> of a registration?  Then the registration record tells tells you
> about
>>>> the flow token.  That would work wouldn't it?
>>>
>>>  I have not background with gruu. Could you recommend what could I
> read about it?
>
> Sorry, I didn't mean gruu, I was mixing up my drafts!
> I was just looking for a unique identifier for the UA
> which is the sip.instance from the outbound draft (not gruu).
>
>
> Regards,
> Attila
>





_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 12:07:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It4fB-0005up-L1; Fri, 16 Nov 2007 12:07:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It4f7-0005u9-F0
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 12:07:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It4f6-0005tU-Vy
	for sip@ietf.org; Fri, 16 Nov 2007 12:07:25 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It4f6-000410-2J
	for sip@ietf.org; Fri, 16 Nov 2007 12:07:24 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lAGH76ik012716; 
	Fri, 16 Nov 2007 11:07:10 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAGH73j21599; Fri, 16 Nov 2007 11:07:03 -0600 (CST)
Message-ID: <473DCE36.8070105@lucent.com>
Date: Fri, 16 Nov 2007 11:07:02 -0600
From: "Vijay K. Gurbani" 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	<200711112208.lABM8xh5016388@dragon.ariadne.com>
In-Reply-To: <200711112208.lABM8xh5016388@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dale.Worley@comcast.net wrote:
> Comments on draft-ietf-sip-connect-reuse-08.
> 
> Overall:
> 
> The mechanism defined in this I-D is sensible and useful.  The
> writing could be improved significantly.

Dale: Thank you for your in-depth review and feedback.  More inline.

> Major technical:
> 
> Section 10, "Support for Virtual Servers" explains the necessity of 
> certain elements of the connection-reuse mechanism.  But as far as I 
> can tell, this explanation is incorrect (although the problem is 
> real).

I suspect we are not that far apart in the understanding of the problem.
In other words, the problem is indeed, as you write:

> However, the virtual server problem is quite real.  The fundamental 
> problem is that making a TLS connection to a destination involves two
> distinct steps -- first, using RFC 3263 to find the address of the 
> destination, then second, using TLS to establish *and authenticate* a
> connection.  Only if both steps succeed is the connection available 
> for sending the message.  As such, the "alias table" must cache not 
> only which connections go to which destination addresses, but which 
> connections have authenticated themselves as responsible for which
> SIP domains.  If a message is to a *new* SIP domain that resolves to
> an address with a cached connection, the cached connection cannot be 
> used, because the connection is not authenticated for the new domain.

That is precisely why the alias table supports the "Destination
Identity" column.

I take it that the text describing the virtual server problem needs
to be made much more clear.  I will do so in the next revision,
using your comments as a guideline.

> Editorial:
> 
> Overall
> 
> Excessive text is spent on the cases of TCP and SCTP without TLS.  As
>  far as I can see, they are to be handled exactly as previously.  It
> is useful to explain why this must be so, and section 9.3 does so,
> but I don't see the need for the page-long section 5.2 and 5.3.

By "exactly as previously", do you mean handled as TLS?  If so,
then I would disagree since for the TLS case, you can indeed only
use one connection, but for TCP and SCTP without TLS you will
need two connections.  S5.2 disambiguates TCP connection reuse
from TLS reuse, thus I believe it is relevant (S5.3 is basically
a short two-paragraph section discussing SCTP for completeness.)

> The description focuses on the "alias table", making that particular 
> implementation quasi-standard.  But I don't see the mechanism as
> being complex enough to require describing that specific
> implementation in order to make the mechanism clear.

The intent is not to make the alias table quasi-standard.  Rather,
it is easier to follow the subsequent discussion based on the
information presented in tabular format.  In reality, many robust
SIP implementations probably already include such a table anyway.  So
I do not see the harm in the continued use of the metaphor.

> A few definitions are given, but various terms that are used with new
> meanings are not defined.  E.g., "establish an alias" meaning "the 
> destination of a connection deciding that the connection can be used 
> in the reverse direction, that is, for sending requests".

OK; I will go through and attempt to catch some of the undefined
terms.

> Examples tend to discuss multiple user agents and proxies, when the 
> entirety of the mechanism can be described by considering only the
> two SIP agents at the ends of the connection.  I think the intention
> is to make the examples more realistic, but instead the examples get
> more complex and hard to follow -- especially because the discussions
> often aren't meticulous about specifying which agent sends which
> message to which agent.  (Not to mention that the discussion suggests
> that user agents and proxies might participate in this mechanism in
> different ways, whereas connection-reuse treats user agents and
> proxies identically.)

Correct; any remaining ambiguity you see is my failure at
delineating what belongs to outbound and what should remain in
connect-reuse.  I will be more diligent about this in the next
revision.

> The use of "alias descriptor" is unfortunate.  To start with, it is 
> confusing -- initially I mistook it for some sort of identification
> of the row of the alias table.  But the concept of "descriptor" as
> being a small integer identifying a network connection, as well as
> the very term "descriptor", are Unix-specific.

Anything wrong with that :-) ?

> Much better would be to use a neutral term like "internal connection
> identifier" and to represent the value by something like "XXXX".

As a programmer, I find it convenient to refer to the connection
identifier as a descriptor.  With your permission, I would like to
continue using that analogy.

> There is an overall conflating of two concepts as "connection reuse".
> One is using one connection to send more than one request from one 
> sender to one recipient.  The second is using one connection to send 
> requests in both directions.  The first concept is already supported 
> by RFC 3261; the second is what is being enabled by this I-D.  But
> the I-D implements both actions using one alias table, obfuscating
> the distinction and so obfuscating the changes that the I-D is 
> introducing.

So this is an interesting and very relevant comment.  You are
absolutely right that there are indeed two concepts of connection
reuse.  However, I do not believe that the draft conflates them.

What you term as the "first concept" is indeed mentioned in rfc3261,
but not in the form that connect-reuse is exalting.  More specifically,
S18 of rfc3261 talks about persistent connections, and how an
implementation should keep connections open to send subsequent
requests over the same connection.  However, rfc3261 also mentions
that the duration a connection stays open should be at least as
long as 64*T1 seconds.  Thus, I have observed implementations that
keep a connection open as long as 64*T1 seconds and no more, and
some even less than that.

As a result of that observation, the text in connect-reuse exhorts
implementations to keep the connection open for as long as they can
(i.e., close it when resources need to be reclaimed using some
strategy like closing the least actively used connection, or the
connection that has been open for the longest time, etc.)

> Details
[...]

All of the details you point here are excellent, and will be
included in the next revision of the draft.

Thanks for the WGLC review, Dale.

Regards,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 13:03:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It5Xi-00047t-KC; Fri, 16 Nov 2007 13:03:50 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It5Xi-000473-2m
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:03:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It5Xh-00046G-MG
	for sip@ietf.org; Fri, 16 Nov 2007 13:03:49 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It5Xg-0002gy-5w
	for sip@ietf.org; Fri, 16 Nov 2007 13:03:49 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 16 Nov 2007 13:03:48 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAGI3l1W016819; 
	Fri, 16 Nov 2007 13:03:47 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAGI3hEW009850; 
	Fri, 16 Nov 2007 18:03:47 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 13:03:43 -0500
Received: from [161.44.174.244] ([161.44.174.244]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 13:03:43 -0500
Message-ID: <473DDB80.8060507@cisco.com>
Date: Fri, 16 Nov 2007 13:03:44 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: nataraju.basavaraju@wipro.com
Subject: Re: [Sip] Status of require headers in the re-INVITE request.
References: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>
In-Reply-To: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Nov 2007 18:03:43.0615 (UTC)
	FILETIME=[068E80F0:01C8287B]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15548.002
X-TM-AS-Result: No--29.519800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7574; t=1195236227;
	x=1196100227; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20Status=20of=20require=20headers=20in=20the=20
	re-INVITE=20request. |Sender:=20
	|To:=20nataraju.basavaraju@wipro.com;
	bh=JqDj3oNHJ8Gy7rYamFBDrkTO0LN7CVx/WgdlAnSVgiY=;
	b=fLHLIUkvgMl+CTI0BqieSJom+KkNuxNpLSYLxv0OQsywcqxTTYw4hXz7B5Re19CFbxqjqAhA
	upXhnSAIFZ14xoVWs4XjgVCBl5u8g0RfDwxOXvAvijUjIg1rf6oJhxwe;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



nataraju.basavaraju@wipro.com wrote:
> Paul, 
> 
> You are right, its not a mandatory that re-INVITE carry the same set of
> options which INVITE carried. It would vary from application to
> application.

And the meaning when it changes may also vary from implementation to 
implementation because it is not standardized.

> To make the implementation simpler UAs might decide to send the same set
> of options negotiated during initial INVITE transaction.

That would be a safe thing to do, but may not always be possible.

> At least its
> not acceptable to add more options in re-INVITE, which were not
> negotiated during INTITE transaction.

I would say that it might not be wise, or might be asking for trouble, 
but its not banned by the specs. Whether it is acceptable or not is 
something that will be judged by the recipient.

> If so it might end up with a an
> issue with refresh (if remote guy does not support the new option).

Yes you might. So if you do it you had better be prepared to get a 420 
error and recover.

More difficult that adding options is taking them away, which is what 
the original poster wanted to do. There is no Unrequire header, and 
while there is an Unsupported header it may only be used in a 420 response.

Suppose Alice originally called Bob, specifying Supported:100rel, and 
Bob answered with Require:100rel and used reliable provisionals. Then 
Alice wants to send a reinvite but doesn't want to use 100rel any 
longer. She can omit Supported:100rel from the reinvite, but there is no 
guarantee that Bob won't remember it and again put Require:100rel in the 
response and use reliable provisionals. (If any provisionals are used at 
all.) The best Alice can do is hope. If she gets a 1xx with 
Require:100rel she has no real option except to send a PRACK.

Note that Supported and Require are among the things that are supposed 
to be included in an OPTIONS response. OPTIONS is typically used outside 
a dialog. For the Supported and Require values in the OPTIONS response 
to have any utility they must remain valid beyond the transaction. One 
would expect that they are valid until further notice I suppose.

Basically this is a mess.

	Paul

> As
> you said it has interoperability issue, because different people
> implement in different manner. 

Yes.

> Regards,
> Nataraju A B
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: Friday, November 16, 2007 6:40 PM
> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
> Infrastructure)
> Cc: vineet.gupta@motorola.com; sip@ietf.org
> Subject: Re: [Sip] Status of require headers in the re-INVITE request.
> 
> Nataraju,
> 
> Why do you think this behavior is required?
> 
> The scope of applicability of Supported, Require, etc. is not well
> defined. If you want to be certain, then you should repeat these in
> every request. But if you *don't* include them in every request it is
> still likely that some peers will remember a value you sent earlier and
> assume it still applies.
> 
> This is a potential interoperability issue and should be fixed, but I
> think it will be difficult. To be useful these options generally need to
> have a scope longer than a single transaction, yet if you assume they
> should have longer scope then it becomes difficult to define when that
> scope ends.
> 
> In your particular case, if you want to use PRACK for the initial INVITE
> but you don't want to use it for reINVITE, I guess you can try omitting
> the Require:100rel in the reINVITE and hope for the best. But don't get
> upset if somebody still sends you PRACKs.
> 
> 	Thanks,
> 	Paul
> 
> nataraju.basavaraju@wipro.com wrote:
>> Comments inline...
>>
>> *Regards,*
>> *Nataraju A B*
>>
>> ----------------------------------------------------------------------
>> --
>> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
>> *Sent:* Friday, November 16, 2007 1:10 PM
>> *To:* sip@ietf.org
>> *Subject:* [Sip] Status of require headers in the re-INVITE request.
>>
>>     Hi,
>>      
>>     I have a doubt related to using Require:100rel in re-INVITE
> requests.
>>      
>>     *If a Require header was used in the INVITE request establishing
> the
>>     dialog, is it mandatory to include the same Require header in
>>     subsequent re-INVITE requests within the dialog?
>>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>>     Require header values that of INVITE.
>>      
>>     To be specific, if INVITE request contained Require:100rel, then
>>     inclusion of Require:100rel in re-INVITE would require the
>>     originator to handle Reliable provisional responses and respond
>>     accordingly. So, it would also imply that re-INVITE also takes
> same
>>     call establishment time (owing to multiple messages like 183
> session
>>     in Progress, PRACK, 180 ringing, PRACK etc.).
>>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>>     has to generate 1xx. if UAS generates 1xx responses for re-INVITE,
>>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it
> is
>>     not mandatory to send  1xx for re-INVITE, hence even if
>>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>>     with out PRACK transaction.
>>      
>>     I agree, that such delay in re-INVITE might be acceptable given
> that
>>     re-INVITE requires the user-intervention, but it complicates makes
>>     the re-INVITE handling as complicated as the INVITE handling.
> Also,
>>     if the initial INVITE involved procedures such as QoS negotiation
>>     the re-INVITE state-machine complicates even further.
>>      
>>     [ABN] In most of the cases, re-INVITE is not expected to undergo
>>     user-intervention. hence in most of the cases it would end up with
>>     re-INV, 200, ACK only...
>>      
>>     In general, re-INVITE is expected to perform subset of what
> happened
>>     in INVITE transaction. it should not create any issues to handle
> 1xx
>>     responses reliably.
>>      
>>     Hope this answers all your questions...
>>      
>>     Regards,
>>     Vineet.
>>      
>>     /"You're only given a little spark of madness. You mustn't lose 
>> it."/
>>      
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> 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
> 
> 
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
>  
> www.wipro.com
> 


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 13:11:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It5ep-0003YC-36; Fri, 16 Nov 2007 13:11:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It5em-0003Wy-PK
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:11:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It5em-0003Wl-BX
	for sip@ietf.org; Fri, 16 Nov 2007 13:11:08 -0500
Received: from qmta09.westchester.pa.mail.comcast.net ([76.96.62.96])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It5el-00037X-O8
	for sip@ietf.org; Fri, 16 Nov 2007 13:11:08 -0500
Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44])
	by QMTA09.westchester.pa.mail.comcast.net with comcast
	id DW6k1Y0090xGWP80501N00; Fri, 16 Nov 2007 18:11:07 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA12.westchester.pa.mail.comcast.net with comcast
	id DWB61Y00P0umElk0300000; Fri, 16 Nov 2007 18:11:07 +0000
X-Authority-Analysis: v=1.0 c=1 a=JKDMKUbTKJOaQ04ZPVAA:9
	a=364OcsJLwjViZiHQNlwA:7 a=-UxATc6gyHHPDTCmcMwq8F1MKEEA:4
	a=3FZX-ydVlcEA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAGIB6SV007095
	for ; Fri, 16 Nov 2007 13:11:06 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAGIB6FL007091;
	Fri, 16 Nov 2007 13:11:06 -0500
Date: Fri, 16 Nov 2007 13:11:06 -0500
Message-Id: <200711161811.lAGIB6FL007091@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <473DCE36.8070105@lucent.com> (vkg@alcatel-lucent.com)
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	<200711112208.lABM8xh5016388@dragon.ariadne.com>
	<473DCE36.8070105@lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Vijay K. Gurbani" 

   > Excessive text is spent on the cases of TCP and SCTP without TLS.  As
   >  far as I can see, they are to be handled exactly as previously.  It
   > is useful to explain why this must be so, and section 9.3 does so,
   > but I don't see the need for the page-long section 5.2 and 5.3.

   By "exactly as previously", do you mean handled as TLS?

No, as described in RFC 3261.

   > The description focuses on the "alias table", making that particular 
   > implementation quasi-standard.  But I don't see the mechanism as
   > being complex enough to require describing that specific
   > implementation in order to make the mechanism clear.

   The intent is not to make the alias table quasi-standard.  Rather,
   it is easier to follow the subsequent discussion based on the
   information presented in tabular format.  In reality, many robust
   SIP implementations probably already include such a table anyway.  So
   I do not see the harm in the continued use of the metaphor.

The problem I see is that the table is not labeled as a mataphor; it
is described as if its existence is mandatory.  But what the standard
will actually prescribe is the *behavior* that is carried out by the
example mechanism you are describing; if it is possible to do so
without confusion, it is better to explicitly describe the behavior
(and especially making clear the allowed variations) than to describe
a mechanism and then imply (but not state) "you have to make it act
like this".

Not specifying behavior explicitly leads to versions of the "implement
to example" problem that has plagued SIP since the early days.

   > The use of "alias descriptor" is unfortunate.  To start with, it is 
   > confusing -- initially I mistook it for some sort of identification
   > of the row of the alias table.  But the concept of "descriptor" as
   > being a small integer identifying a network connection, as well as
   > the very term "descriptor", are Unix-specific.

   Anything wrong with that :-) ?

In a standard?

   > Much better would be to use a neutral term like "internal connection
   > identifier" and to represent the value by something like "XXXX".

   As a programmer, I find it convenient to refer to the connection
   identifier as a descriptor.  With your permission, I would like to
   continue using that analogy.

As a standards weenie, I would say that the less we incorporate of
specific implementations, the better.  We are already plagued by
programmers who cannot analyze something without visualizing one,
specific, concrete example, and as a consequence they do not envision
the range of possibilities that the standard admits, leading to all
sorts of errors.  We should not encourage that.

   > There is an overall conflating of two concepts as "connection reuse".
   > One is using one connection to send more than one request from one 
   > sender to one recipient.  The second is using one connection to send 
   > requests in both directions.  The first concept is already supported 
   > by RFC 3261; the second is what is being enabled by this I-D.  But
   > the I-D implements both actions using one alias table, obfuscating
   > the distinction and so obfuscating the changes that the I-D is 
   > introducing.

   So this is an interesting and very relevant comment.  You are
   absolutely right that there are indeed two concepts of connection
   reuse.  However, I do not believe that the draft conflates them.

It's using the same word for both, which requires very close reading
to figure out which concept is being talked about at which time.  (I'm
not claiming that *you* don't keep the two ideas straight, but I'm
worried about the next 200 readers.)

Dale


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 13:54:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It6L5-0001gh-RZ; Fri, 16 Nov 2007 13:54:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It6L3-0001WK-OX
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:54:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It6L2-0001RN-T8
	for sip@ietf.org; Fri, 16 Nov 2007 13:54:49 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It6L1-0000HZ-M4
	for sip@ietf.org; Fri, 16 Nov 2007 13:54:48 -0500
Received: from rly09f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly09f.srv.mailcontrol.com (MailControl) with ESMTP id
	lAGIse0T013136 for ; Fri, 16 Nov 2007 18:54:41 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly09f.srv.mailcontrol.com (MailControl) id lAGIs9vL009959
	for sip@ietf.org; Fri, 16 Nov 2007 18:54:09 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly09f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lAGIrxPL008723; Fri, 16 Nov 2007 18:54:09 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 18:53:03 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Can a transaction statelessproxysupportOutbounddraft?Ifyes,
	how will the response be sent back theUAbehind NAT
Date: Fri, 16 Nov 2007 18:52:26 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60A03029@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can a transaction statelessproxysupportOutbounddraft?Ifyes,
	how will the response be sent back theUAbehind NAT
Thread-Index: AcgoaSxHUIkPyOoKSkS5DHEtZ3rQTgAE4QJg
From: "Attila Sipos" 
To: , 
X-OriginalArrivalTime: 16 Nov 2007 18:53:03.0169 (UTC)
	FILETIME=[EA969B10:01C82881]
X-Scanned-By: MailControl A-08-00-02 (www.mailcontrol.com) on 10.70.1.119
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20
>>  The problem with the above (separated elements) is that there is not
>>synchronization about the state of the socket descriptors. As
mentioned
>>before, if the edge proxy crashes the socket descriptors used
immediately
>>after reboot could result in delivering messages to different flows.
>>
>>  In my opinion the randomness included in the flow token avoids that
to
>>happen, since after reboot the flowtoken can not be decoded and/or
find an
>>existing flow and that cause the return a error response.


Yes, absolutely.  And this is a problem with stateful proxies too.

I have agreed with everything you've said.
However, I still think there is a way to do an outbound-compatible
edge proxy with a transaction-stateless/call-stateless proxy.

So I now go back to say something similar to what I said before.
But first, I will refer to something you said in an earlier mail:

>>  Furthermore my registrar should not store socket descriptors
>>due that if the edge proxy crashes, the registrar could have a
>>number of descriptor that after the crash belong to other flows.

I feel this would not be a problem for a stateless proxy providing that
it is not just a raw socket descriptor id that is passed to
the registrar.  The branch parameter in the Via would need
some kind of hashed/encrypted "reboot count" parameter as well
as the socket id.  Then if the edge-proxy rebooted, it would know that
the response coming back is stale.  There are many ways to do the
hashing/encryption - you could use a method similar to that used
in the gruu draft Appendix A.2.
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-15
.txt

So the Via header's branch parameter would contain encoded
information about:
1. the flow back to the UA (socket id, IP, port)
2. the reboot count

So now I go back to something else you said:
>> 2) generate again the flow token for every request (very bad from
>>security point of views) and destroys the consistency of the system
>>since you can send requests for non existing flows. Note that the
>>draft mentions that the flow and the flow token is only created with
REGISTERs.

So my proposal is generating some kind of flow token (but not THE same
"flow token"
as used in the REGISTER).  So there is the "flow token" as described in
the
outbound draft and now there is also a "branch flow token" that I am
proposing.
And, as explained before, the information in the "branch flow token" is
used to
route responses back to the UA.  But the original "flow token" is never
changed.
The original "flow token" would still be used when forwarding requests
to
the UA because the Edge Proxy (in your diagram) would've added it to the
Path.  So requests to the UA would still work.

Now I'm not sure about the security aspects.=20
What security problems could there be with "branch flow token" idea?

Regards,
Attila


-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: 16 November 2007 15:53
To: Attila Sipos
Subject: RE: [Sip] Can a transaction
statelessproxysupportOutbounddraft?Ifyes, how will the response be sent
back theUAbehind NAT



> I am starting to see the problems.
>
> If I understand correctly, your scenario is this...
>
> REGISTRAR--------PROXY----------NAT---------SIP UA
>
> Can you confirm?

more specifically my scenario is

REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA


where PROXY is a traditional SIP proxy


> And, since you were talking about scalability, you might also have=20
> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>
> is this right?


  About scalability I was thinking about


                        /EDGEPROXY1\
REGISTRAR/PROXY--------            ----------NAT---------SIP UA
                        \EDGEPROXY2/


  So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.


  I have no experience with registrars, I guess that in your case you
have a REGISTRAR/EDGEPROXY in the same process (or group of processes)
and not REGISTRAR--------EDGEPROXY (linked by other means).

  The problem with the above (separated elements) is that there is not
synchronization about the state of the socket descriptors. As mentioned
before, if the edge proxy crashes the socket descriptors used
immediately after reboot could result in delivering messages to
different flows.

  In my opinion the randomness included in the flow token avoids that to
happen, since after reboot the flowtoken can not be decoded and/or find
an existing flow and that cause the return a error response.
  Then another entry in the registrar binding will be used, i.e. other
flow token. If you have a second edge proxy (that does not crashed at
the same time that the first one :) and the flow token belongs to the
second edge proxy, the message will reach the UA over a flow previously
established to the second edge proxy.



BR

Sergio


Quoting Attila Sipos :

>
>
>>>>>> 3.
>>>>>>> In the Via header's branch parameter, it would encode the
> required
>>>>>>> flow token.
>>>>>>
>>>>>> Here is the issue : From were you get the flow token?
>>>>>> (In my previous email I mentioned 2 options... )
>>>>>>
>>>>
>>>> OK I'm starting to see your problem.
>>>>
>>>> The registration record stores the flow token (obviously)
>>>
>>> It seems that you are integrating the edge proxy and registrar in=20
>>> the
> same code, right?
>
> yes, that's it.
>
>
>>>> And the socket id for the flow would be stored as well (for
>>>
>>> Can you confirm that you call socket id to the socket/file=20
>>> descriptor
> of the connection?
>
> yes.
>
>>>> connection-oriented
>>>> protocols). So if you received a request on that socket, you could=20
>>>> match that up to one of the registration records and hence, one of
> the
>>>> flow tokens.
>>>>
>>>
>>>  Good approach. I assume that you have available the socket
> descriptor
>>> in the registrar, so basically you consider storing the socket
> descriptor
>>> (number) in the registrar tables. Then perhaps using a flow token it
> is not
>>> necessary since you have available in the socket descriptor all the
> information
>>> that describes a flow (TCP case).
>
> That's true.  I might not need the flow tokens.
>
>
>>>> I hope I have explained how the flow token might be mapped to the=20
>>>> socket.
>>>
>>>  Yes if my comments above make sense..
>>>
>>>> I can now see that my idea wouldn't work for UDP.
>>>
>>>  Now for UDP perhaps you can consider storing the socket descriptor
> for
>>> UDP and the IP and port for the flow from the NAT.
>
> yes, that would work I think.
>
>
>>>  Furthermore my registrar should not store socket descriptors due
> that
>>> if the edge proxy crashes, the registrar could have a number of
> descriptor
>>> that after the crash belong to other flows.
>>>
>>>  I generate the flow token with REGISTER and send it to the=20
>>> registrar (other node). The approach works as the draft says for=20
>>> incoming
> requests
>>> (to the Calle). Now when the Callee  sends requests, and the=20
>>> requests
> are
>>> sent over the flow, the responses of that request reach first the=20
>>> edge
> proxy
>>> and it can not forward them to the Callee over the flow, because=20
>>> these responses don't have the flow token (and the flow token is not

>>> stored
> in
>>> the edge proxy)...
>
> I am starting to see the problems.
>
> If I understand correctly, your scenario is this...
>
> REGISTRAR--------PROXY----------NAT---------SIP UA
>
> Can you confirm?
>
> And, since you were talking about scalability, you might also have=20
> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>
> is this right?
>
>
>>>> But what if you used the gruu in the contact to match up with the
> gruu
>>>> of a registration?  Then the registration record tells tells you
> about
>>>> the flow token.  That would work wouldn't it?
>>>
>>>  I have not background with gruu. Could you recommend what could I
> read about it?
>
> Sorry, I didn't mean gruu, I was mixing up my drafts!
> I was just looking for a unique identifier for the UA which is the=20
> sip.instance from the outbound draft (not gruu).
>
>
> Regards,
> Attila
>




_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 13:55:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It6Ly-0003kt-DP; Fri, 16 Nov 2007 13:55:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It6Lw-0003k0-Iu
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:55:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It6Lw-0003j0-6n
	for sip@ietf.org; Fri, 16 Nov 2007 13:55:44 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It6Lv-0000P7-1s
	for sip@ietf.org; Fri, 16 Nov 2007 13:55:44 -0500
Received: from rly09f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly09f.srv.mailcontrol.com (MailControl) with ESMTP id
	lAGItexP016403 for ; Fri, 16 Nov 2007 18:55:41 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly09f.srv.mailcontrol.com (MailControl) id lAGItAJM015415
	for sip@ietf.org; Fri, 16 Nov 2007 18:55:10 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly09f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lAGIrx55008722; Fri, 16 Nov 2007 18:55:10 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 18:55:46 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Can a transaction statelessproxysupportOutbounddraft?Ifyes,
	how will the response be sent back theUAbehind NAT
Date: Fri, 16 Nov 2007 18:55:09 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60A0302D@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can a transaction statelessproxysupportOutbounddraft?Ifyes,
	how will the response be sent back theUAbehind NAT
Thread-Index: AcgoaSxHUIkPyOoKSkS5DHEtZ3rQTgAE4QJgAAFYAZA=
From: "Attila Sipos" 
To: "Attila Sipos" , ,
	
X-OriginalArrivalTime: 16 Nov 2007 18:55:46.0465 (UTC)
	FILETIME=[4BEB9910:01C82882]
X-Scanned-By: MailControl A-08-00-02 (www.mailcontrol.com) on 10.70.1.119
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

>>So the Via header's branch parameter would contain encoded information
about:
>>1. the flow back to the UA (socket id, IP, port)
>>2. the reboot count=20

Oh and I'd also encode some kind of expiration time.

Regards,
	Attila



-----Original Message-----
From: Attila Sipos=20
Sent: 16 November 2007 18:52
To: 'sergiole@tml.hut.fi'; sip@ietf.org
Subject: RE: [Sip] Can a transaction
statelessproxysupportOutbounddraft?Ifyes, how will the response be sent
back theUAbehind NAT

=20
>>  The problem with the above (separated elements) is that there is not

>>synchronization about the state of the socket descriptors. As=20
>>mentioned before, if the edge proxy crashes the socket descriptors=20
>>used immediately after reboot could result in delivering messages to
different flows.
>>
>>  In my opinion the randomness included in the flow token avoids that=20
>>to happen, since after reboot the flowtoken can not be decoded and/or=20
>>find an existing flow and that cause the return a error response.


Yes, absolutely.  And this is a problem with stateful proxies too.

I have agreed with everything you've said.
However, I still think there is a way to do an outbound-compatible edge
proxy with a transaction-stateless/call-stateless proxy.

So I now go back to say something similar to what I said before.
But first, I will refer to something you said in an earlier mail:

>>  Furthermore my registrar should not store socket descriptors due=20
>>that if the edge proxy crashes, the registrar could have a number of=20
>>descriptor that after the crash belong to other flows.

I feel this would not be a problem for a stateless proxy providing that
it is not just a raw socket descriptor id that is passed to the
registrar.  The branch parameter in the Via would need some kind of
hashed/encrypted "reboot count" parameter as well as the socket id.
Then if the edge-proxy rebooted, it would know that the response coming
back is stale.  There are many ways to do the hashing/encryption - you
could use a method similar to that used in the gruu draft Appendix A.2.
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-15
.txt

So the Via header's branch parameter would contain encoded information
about:
1. the flow back to the UA (socket id, IP, port) 2. the reboot count

So now I go back to something else you said:
>> 2) generate again the flow token for every request (very bad from=20
>>security point of views) and destroys the consistency of the system=20
>>since you can send requests for non existing flows. Note that the=20
>>draft mentions that the flow and the flow token is only created with
REGISTERs.

So my proposal is generating some kind of flow token (but not THE same
"flow token"
as used in the REGISTER).  So there is the "flow token" as described in
the outbound draft and now there is also a "branch flow token" that I am
proposing.
And, as explained before, the information in the "branch flow token" is
used to route responses back to the UA.  But the original "flow token"
is never changed.
The original "flow token" would still be used when forwarding requests
to the UA because the Edge Proxy (in your diagram) would've added it to
the Path.  So requests to the UA would still work.

Now I'm not sure about the security aspects.=20
What security problems could there be with "branch flow token" idea?

Regards,
Attila


-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
Sent: 16 November 2007 15:53
To: Attila Sipos
Subject: RE: [Sip] Can a transaction
statelessproxysupportOutbounddraft?Ifyes, how will the response be sent
back theUAbehind NAT



> I am starting to see the problems.
>
> If I understand correctly, your scenario is this...
>
> REGISTRAR--------PROXY----------NAT---------SIP UA
>
> Can you confirm?

more specifically my scenario is

REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA


where PROXY is a traditional SIP proxy


> And, since you were talking about scalability, you might also have=20
> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>
> is this right?


  About scalability I was thinking about


                        /EDGEPROXY1\
REGISTRAR/PROXY--------            ----------NAT---------SIP UA
                        \EDGEPROXY2/


  So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.


  I have no experience with registrars, I guess that in your case you
have a REGISTRAR/EDGEPROXY in the same process (or group of processes)
and not REGISTRAR--------EDGEPROXY (linked by other means).

  The problem with the above (separated elements) is that there is not
synchronization about the state of the socket descriptors. As mentioned
before, if the edge proxy crashes the socket descriptors used
immediately after reboot could result in delivering messages to
different flows.

  In my opinion the randomness included in the flow token avoids that to
happen, since after reboot the flowtoken can not be decoded and/or find
an existing flow and that cause the return a error response.
  Then another entry in the registrar binding will be used, i.e. other
flow token. If you have a second edge proxy (that does not crashed at
the same time that the first one :) and the flow token belongs to the
second edge proxy, the message will reach the UA over a flow previously
established to the second edge proxy.



BR

Sergio


Quoting Attila Sipos :

>
>
>>>>>> 3.
>>>>>>> In the Via header's branch parameter, it would encode the
> required
>>>>>>> flow token.
>>>>>>
>>>>>> Here is the issue : From were you get the flow token?
>>>>>> (In my previous email I mentioned 2 options... )
>>>>>>
>>>>
>>>> OK I'm starting to see your problem.
>>>>
>>>> The registration record stores the flow token (obviously)
>>>
>>> It seems that you are integrating the edge proxy and registrar in=20
>>> the
> same code, right?
>
> yes, that's it.
>
>
>>>> And the socket id for the flow would be stored as well (for
>>>
>>> Can you confirm that you call socket id to the socket/file=20
>>> descriptor
> of the connection?
>
> yes.
>
>>>> connection-oriented
>>>> protocols). So if you received a request on that socket, you could=20
>>>> match that up to one of the registration records and hence, one of
> the
>>>> flow tokens.
>>>>
>>>
>>>  Good approach. I assume that you have available the socket
> descriptor
>>> in the registrar, so basically you consider storing the socket
> descriptor
>>> (number) in the registrar tables. Then perhaps using a flow token it
> is not
>>> necessary since you have available in the socket descriptor all the
> information
>>> that describes a flow (TCP case).
>
> That's true.  I might not need the flow tokens.
>
>
>>>> I hope I have explained how the flow token might be mapped to the=20
>>>> socket.
>>>
>>>  Yes if my comments above make sense..
>>>
>>>> I can now see that my idea wouldn't work for UDP.
>>>
>>>  Now for UDP perhaps you can consider storing the socket descriptor
> for
>>> UDP and the IP and port for the flow from the NAT.
>
> yes, that would work I think.
>
>
>>>  Furthermore my registrar should not store socket descriptors due
> that
>>> if the edge proxy crashes, the registrar could have a number of
> descriptor
>>> that after the crash belong to other flows.
>>>
>>>  I generate the flow token with REGISTER and send it to the=20
>>> registrar (other node). The approach works as the draft says for=20
>>> incoming
> requests
>>> (to the Calle). Now when the Callee  sends requests, and the=20
>>> requests
> are
>>> sent over the flow, the responses of that request reach first the=20
>>> edge
> proxy
>>> and it can not forward them to the Callee over the flow, because=20
>>> these responses don't have the flow token (and the flow token is not

>>> stored
> in
>>> the edge proxy)...
>
> I am starting to see the problems.
>
> If I understand correctly, your scenario is this...
>
> REGISTRAR--------PROXY----------NAT---------SIP UA
>
> Can you confirm?
>
> And, since you were talking about scalability, you might also have=20
> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>
> is this right?
>
>
>>>> But what if you used the gruu in the contact to match up with the
> gruu
>>>> of a registration?  Then the registration record tells tells you
> about
>>>> the flow token.  That would work wouldn't it?
>>>
>>>  I have not background with gruu. Could you recommend what could I
> read about it?
>
> Sorry, I didn't mean gruu, I was mixing up my drafts!
> I was just looking for a unique identifier for the UA which is the=20
> sip.instance from the outbound draft (not gruu).
>
>
> Regards,
> Attila
>




_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 14:14:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It6eS-0007QS-Ma; Fri, 16 Nov 2007 14:14:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It6eR-0007Oi-KX
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 14:14:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It6eR-0007OD-9M
	for sip@ietf.org; Fri, 16 Nov 2007 14:14:51 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It6eQ-0002eT-Rg
	for sip@ietf.org; Fri, 16 Nov 2007 14:14:51 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Fri, 16 Nov 2007 14:14:50 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Fri, 16 Nov 2007 14:14:50 -0500
From: Hadriel Kaplan 
To: "Dale.Worley@comcast.net" , "sip@ietf.org"
	
Date: Fri, 16 Nov 2007 14:14:38 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Index: AcgofBqdyWjrkaOPReOBFCs7zFP2lwAAQj1w
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	<200711112208.lABM8xh5016388@dragon.ariadne.com>
	<473DCE36.8070105@lucent.com>
	<200711161811.lAGIB6FL007091@dragon.ariadne.com>
In-Reply-To: <200711161811.lAGIB6FL007091@dragon.ariadne.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
>
>    > There is an overall conflating of two concepts as "connection reuse"=
.
>    > One is using one connection to send more than one request from one
>    > sender to one recipient.  The second is using one connection to send
>    > requests in both directions.  The first concept is already supported
>    > by RFC 3261; the second is what is being enabled by this I-D.  But
>    > the I-D implements both actions using one alias table, obfuscating
>    > the distinction and so obfuscating the changes that the I-D is
>    > introducing.
>
>    So this is an interesting and very relevant comment.  You are
>    absolutely right that there are indeed two concepts of connection
>    reuse.  However, I do not believe that the draft conflates them.
>
> It's using the same word for both, which requires very close reading
> to figure out which concept is being talked about at which time.  (I'm
> not claiming that *you* don't keep the two ideas straight, but I'm
> worried about the next 200 readers.)

Indeed, I had the exact same confusion and I'm worried about the next 199 t=
oo.  :)  I would call it "persistent connection", a la HTTP.

With regards to TCP "persistent connection", where you mean the client can =
reuse the same TCP connection for requests going to the same server, is tha=
t really necessary to put in a standard?  I mean it was always allowed, no?=
  I guess it's good to make it explicit, but I'm not sure how one knows whe=
n it's the right thing to do or not.

I agree there are clients creating new TCP connections per SIP session, and=
 tearing down old ones, and that's very bad in some situations, but it's es=
sentially a local policy decision.  A client is free to open and close TCP =
connections at will.  You can't make it keep one open forever.  And there i=
s nothing that the signaling is doing about it to help in this draft.  Like=
 for example if the server side stuck something in the response to indicate=
 "you may keep this connection open and send any future requests to me over=
 it if you can". (i.e., the Connection/Keep-Alive header model as in HTTP)

Some vendors restrict how many simultaneous connections they'll allow from =
the same client, for security reasons, so are you thinking along those line=
s?

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 15:25:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It7kn-0000Qh-C1; Fri, 16 Nov 2007 15:25:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It7kl-0000QR-8j
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 15:25:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It7kk-0000QJ-UX
	for sip@ietf.org; Fri, 16 Nov 2007 15:25:26 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It7kf-0000AG-Va
	for sip@ietf.org; Fri, 16 Nov 2007 15:25:26 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	2F89C207B5; Fri, 16 Nov 2007 21:25:21 +0100 (CET)
X-AuditID: c1b4fb3c-b161dbb000002c9b-b3-473dfcb01a8b
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	ED30720429; Fri, 16 Nov 2007 21:25:20 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 21:25:20 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 21:25:20 +0100
Received: from [131.160.126.48] (rvi2-126-48.lmf.ericsson.se [131.160.126.48])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 0C7E1246A;
	Fri, 16 Nov 2007 22:25:20 +0200 (EET)
Message-ID: <473DFCB0.7020401@ericsson.com>
Date: Fri, 16 Nov 2007 22:25:20 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: sip 
Subject: Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt
References: 
	<46DDD081.9030900@cisco.com>	<46DE8094.8060807@ericsson.com>
	<470FCEA4.3060101@ericsson.com>
In-Reply-To: <470FCEA4.3060101@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Nov 2007 20:25:20.0661 (UTC)
	FILETIME=[CF30D450:01C8288E]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b
Cc: Keith Drage , Paul Kyzivat ,
	Eric Burger , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,

FYI: we have just gotten their review:
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00110.html

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Folks,
> 
> FYI: we have requested the apps folks to have a look at this draft in 
> order to make sure we get all the MIME stuff right. We will make sure 
> the review is posted to this list.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> to be more concrete in our discussions, we need to make decisions on 
>> the following two issues:
>>
>> 1) Where in a SIP message is it allowed to reference a body part?
>>
>> a) in header fields and body parts within the same multipart/related 
>> as the referenced body part
>> b) in header fields and body parts that appear before the referenced 
>> body part
>> c) in header fields and any body part
>>
>> We discussed that doing c) would require to parse SIP messages twice 
>> to look for potential references. Therefore, we decided to do a) or 
>> b). The current draft specifies a), we doing b) might make sense as 
>> well (it would be less restrictive).
>>
>>
>> 2) If a receiver does not understand a reference to a body part:
>>
>> a) it should process (handle) it solely based on its disposition type 
>> (as a fall-back mechanism). If the sender does not want this to 
>> happen, it can use an option tag.
>>
>> b) the body part will have a disposition type of "only-by-reference". 
>> This way, since the receiver did not understand the reference, it 
>> knows it should not process the body.
>>
>> The current draft specifies a), but b) would be an interesting 
>> optimization (no need to use option tags and reissue requests). 
>> However, we would need to get the opinion of a MIME person on b).
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>>
>> Paul Kyzivat wrote:
>>>
>>>
>>> Eric Burger wrote:
>>>> I agree 100% with Paul.  However, one thing I would like to hear 
>>>> opinions on
>>>> is the following:
>>>>
>>>> Do we way body parts are always processed, no matter what?
>>>>
>>>> It would be convenient to say body parts get processed as needed.  
>>>> If there
>>>> is a related part that never gets referenced, then a conforming 
>>>> processor
>>>> might not process that part, as an optimization.
>>>
>>> This gets into semantics...
>>>
>>> For one thing, I guess we should talk about "handling" rather than 
>>> "processing" - this is tied to the C-D "handling=" parameter.
>>>
>>> But the key thing is what does it *mean* to say you have handled 
>>> something? Its one thing to understand the meaning of the type and 
>>> disposition. What you actually *do* once that is understood is 
>>> something else entirely.
>>>
>>> I would expect that somewhere there would be a normative 
>>> specification for each C-D of what it means to *handle* body parts 
>>> with that disposition. This is where we get into trouble with 
>>> "render", where we need a different definition for SIP than is used 
>>> for email.
>>>
>>> I presume that if we had such normative definitions, then that would 
>>> determine what sort of optimizations, such as lazy processing, are 
>>> allowed.
>>>
>>> For example, 3261 defines (barely) the C-D "alert". It says this 
>>> "should" (lower case) be rendered. Together with some words elsewhere 
>>> about Alert-Info that warn of security issues, its seems clear that 
>>> the UA is given discretion about actually rendering this. (But it is 
>>> not a stellar example of clarity.) I would interpret this to mean 
>>> that you can consider the "alert" body part to have been "handled" if 
>>> you have indeed understood it and then *either* rendered it or made 
>>> an explicit not to render it.
>>>
>>>> However, one thing we need to be mindful of are side effects.  MIME 
>>>> body
>>>> parts can make external references.  Those external references (to
>>>> http/https URI's) may hit application servers.  Those application 
>>>> servers
>>>> may do something based on the receipt of the URI.  It could be as 
>>>> simple as
>>>> recording the fact the body part was read (like a web beacon), or it 
>>>> could
>>>> be as complex as changing application state.
>>>
>>> We have similar issues with headers that contain URL references, that 
>>> might or might not be resolved. E.g. Call-Info.
>>>
>>> Again, I don't see any general answer better than the specification 
>>> of the particular header or C-D.
>>>
>>> Based on this discussion I am beginning to conclude that we might as 
>>> well treat each body part almost as if it were a header whose name is 
>>> its C-D.
>>>
>>>> What do people think of this?  Do we say that SIP engines are 
>>>> opportunistic,
>>>> and the side effect MUST happen if the body gets used, buy the side 
>>>> effect
>>>> MAY happen if the body does not get used?  That would be my vote, as 
>>>> the
>>>> alternative, that all side effects (external references get 
>>>> resolved) happen
>>>> puts a pretty big burden on User Agents.
>>>
>>> This is further complicated by intermediate nodes. They are 
>>> *permitted* to look at body parts. If, as a result, an intermediate 
>>> node dereferences a reference within a body part, you will 
>>> potentially have another side effect.
>>>
>>> I also agree that we should give the UA latitude in what processing 
>>> it does. For example, even though a request has a geopriv header with 
>>> a body part containing location data, and has specified 
>>> "handling=required", the UAS may have no use for the location. If it 
>>> doesn't intend to use it then why should it process it?
>>>
>>>     Paul
>>>
>>>> On 8/29/07 8:57 AM, "Paul Kyzivat"  wrote:
>>>>
>>>>> To clarify futher my last point below...
>>>>>
>>>>> What I am saying is that IMO body parts must always be processed
>>>>> according to their type and disposition, whether there are 
>>>>> references to
>>>>> them or not. If there is a reference, and it is understood, then it 
>>>>> can
>>>>> modify or supplement the processing, but if the reference is not
>>>>> recognized or understood then the other processing still occurs.
>>>>>
>>>>> If we want to support the possibility of a reference to a body part,
>>>>> where there is to be no processing of the body part when the reference
>>>>> is not understood, then we need a content-disposition that says "don't
>>>>> do anything with this unless you process a reference to it."
>>>>>
>>>>> An alternative is to simply assume there are no such cases, and warn
>>>>> people that use references to select a C-D for the referenced part 
>>>>> that
>>>>> will have an appropriate result if the reference is not understood.
>>>>>
>>>>> For instance, we have both the Alert-Info header and the "alert" 
>>>>> C-D. If
>>>>> you use an A-I with a CID reference, then you can use "alert" as 
>>>>> the C-D
>>>>> of that part. In that case, the A-I header is redundant unless it
>>>>> contains something that modifies the processing.
>>>>>
>>>>> An example where the problem I am concerned about may exist is in
>>>>> draft-ietf-sip-location-conveyance-08. It has an example of a
>>>>> Geolocation header referencing a body part. There is no C-D header in
>>>>> the example, so by default it is "render;handling=required". And 
>>>>> its C-T
>>>>> is application/pidf+xml. If a recipient of this message didn't
>>>>> understand the Geolocation header it would reach the conclusion 
>>>>> that it
>>>>> should render the pidf. Its debatable whether that is the desired
>>>>> conclusion - I think not. IMO the intent is that if the Geolocation
>>>>> header isn't processed then the pidf should be ignored. So, IMO this
>>>>> body part ought to contain:
>>>>>     Content-Disposition: by-reference;handling=optional
>>>>>
>>>>> (I don't care what name we use for the disposition, just that we 
>>>>> have one.)
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>> Paul Kyzivat wrote:
>>>>>> Gonzalo,
>>>>>>
>>>>>> Obviously we allow a "forward" reference from the sip message itself
>>>>>> (which from a mime perspective are just a bunch of mime headers.)
>>>>>>
>>>>>> I think that establishes a precedent that needs to be continued. An
>>>>>> example of why can be seen in sipfrag:
>>>>>>
>>>>>> If we had a valid sip response that had a reference into one of 
>>>>>> its body
>>>>>> parts, then if that was turned into a sipfrag and stuffed into the 
>>>>>> body
>>>>>> of a NOTIFY, then it must still be valid.
>>>>>>
>>>>>> I just did a quick scan of the new draft, so the following is a
>>>>>> tentative comment, until I can read it more carefully:
>>>>>>
>>>>>> I think the draft is now saying that the decision about whether to
>>>>>> process a body part according to a reference to it, or process
>>>>>> independently, is decided based on whether a reference is found. 
>>>>>> We had
>>>>>> this discussion before, and I think we agreed that wouldn't work 
>>>>>> well,
>>>>>> and that instead we would have a special C-D type for body parts that
>>>>>> are disposed of based on a reference.
>>>>>>
>>>>>> I don't think the introduction of issues related to multipart/related
>>>>>> changes this. The obvious cases are when there is a single
>>>>>> multipart/mixed containing some body parts. Some of those may be
>>>>>> referenced from CID URIs in sip headers, and others (e.g. SDP) may 
>>>>>> stand
>>>>>> on their own. It is entirely possible that a body part might be
>>>>>> referenced from some extension header that the recipient doesn't
>>>>>> understand. In that case it may erroneously decide to process the 
>>>>>> body
>>>>>> part on its own, when it should instead have ignored it because the
>>>>>> header isn't being processed.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>
>>>>>> Gonzalo Camarillo wrote:
>>>>>>> Folks,
>>>>>>>
>>>>>>> I have just submitted a new revision of the body handling draft. 
>>>>>>> Until
>>>>>>> it appears on the archives, you can fetch it from:
>>>>>>>
>>>>>>> http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt 
>>>>>>>
>>>>>>>
>>>>>>> Per our discussions in Chicago, the draft now states that only body
>>>>>>> parts within the same 'multipart/related' can reference each other
>>>>>>> using cid URIs.
>>>>>>>
>>>>>>> If this is too restrictive, we could also allow using forward
>>>>>>> references in any context (with no 'multipart/related' at all).
>>>>>>>
>>>>>>> Comments?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Gonzalo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>> Notice:  This email message, together with any attachments, may 
>>>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
>>>> affiliated entities,  that may be confidential,  proprietary,  
>>>> copyrighted  and/or legally privileged, and is intended solely for 
>>>> the use of the individual or entity named in this message. If you 
>>>> are not the intended recipient, and have received this message in 
>>>> error, please immediately return this by email and then delete it.
>>>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
> 
> 
> 
> _______________________________________________
> 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
> 



_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 15:48:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It86u-0007Dk-Dn; Fri, 16 Nov 2007 15:48:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It86t-0007Df-CX
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 15:48:19 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It86s-0007CN-Vd
	for sip@ietf.org; Fri, 16 Nov 2007 15:48:19 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It86s-0000Ma-7w
	for sip@ietf.org; Fri, 16 Nov 2007 15:48:18 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAGKmCG9017830; 
	Fri, 16 Nov 2007 14:48:14 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAGKmCj22937; Fri, 16 Nov 2007 14:48:12 -0600 (CST)
Message-ID: <473E020C.2080701@alcatel-lucent.com>
Date: Fri, 16 Nov 2007 14:48:12 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>	<200711112208.lABM8xh5016388@dragon.ariadne.com>	<473DCE36.8070105@lucent.com>
	<200711161811.lAGIB6FL007091@dragon.ariadne.com>
In-Reply-To: <200711161811.lAGIB6FL007091@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dale.Worley@comcast.net wrote:
vkg>    By "exactly as previously", do you mean handled as TLS?
> 
> No, as described in RFC 3261.

OK; I will wordsmith some text to refer to rfc3261.

> The problem I see is that the table is not labeled as a mataphor; it
> is described as if its existence is mandatory.  But what the standard
> will actually prescribe is the *behavior* that is carried out by the
> example mechanism you are describing; 

I think you are being too literal about the table; the table itself
is first described in S5, the opening paragraph of which is: "This
section is tutorial in nature, and does not specify any normative
behavior."  Thus, I do not see how one can construe that the existence
of the table is mandatory.  Furthermore, rfc3261 essentially uses
the same information in S18, where it talks about "These connections
are indexed by the tuple formed from the address, port, and transport
protocol at the far end of the connection."  The table in connect-
reuse is the same information, albeit in an easy to visualize manner.
I really do not see the harm.

> Not specifying behavior explicitly leads to versions of the "implement
> to example" problem that has plagued SIP since the early days.

"Implement to example" in SIP has resulted because either there
are many ways to do the same thing, or because due to insufficient
guidance, a developer latches on to an example and considers that
the canonical form for doing something in SIP.

I don't see how presenting information in a tabular forFrom sip-bounces@ietf.org Fri Nov 16 15:48:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It86u-0007Dk-Dn; Fri, 16 Nov 2007 15:48:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It86t-0007Df-CX
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 15:48:19 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It86s-0007CN-Vd
	for sip@ietf.org; Fri, 16 Nov 2007 15:48:19 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It86s-0000Ma-7w
	for sip@ietf.org; Fri, 16 Nov 2007 15:48:18 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAGKmCG9017830; 
	Fri, 16 Nov 2007 14:48:14 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAGKmCj22937; Fri, 16 Nov 2007 14:48:12 -0600 (CST)
Message-ID: <473E020C.2080701@alcatel-lucent.com>
Date: Fri, 16 Nov 2007 14:48:12 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>	<200711112208.lABM8xh5016388@dragon.ariadne.com>	<473DCE36.8070105@lucent.com>
	<200711161811.lAGIB6FL007091@dragon.ariadne.com>
In-Reply-To: <200711161811.lAGIB6FL007091@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dale.Worley@comcast.net wrote:
vkg>    By "exactly as previously", do you mean handled as TLS?
> 
> No, as described in RFC 3261.

OK; I will wordsmith some text to refer to rfc3261.

> The problem I see is that the table is not labeled as a mataphor; it
> is described as if its existence is mandatory.  But what the standard
> will actually prescribe is the *behavior* that is carried out by the
> example mechanism you are describing; 

I think you are being too literal about the table; the table itself
is first described in S5, the opening paragraph of which is: "This
section is tutorial in nature, and does not specify any normative
behavior."  Thus, I do not see how one can construe that the existence
of the table is mandatory.  Furthermore, rfc3261 essentially uses
the same information in S18, where it talks about "These connections
are indexed by the tuple formed from the address, port, and transport
protocol at the far end of the connection."  The table in connect-
reuse is the same information, albeit in an easy to visualize manner.
I really do not see the harm.

> Not specifying behavior explicitly leads to versions of the "implement
> to example" problem that has plagued SIP since the early days.

"Implement to example" in SIP has resulted because either there
are many ways to do the same thing, or because due to insufficient
guidance, a developer latches on to an example and considers that
the canonical form for doing something in SIP.

I don't see how presenting information in a tabular format leads
to implementation by example.  There is ample additional text
that explicitly specifies the behavior.

>    > The use of "alias descriptor" is unfortunate.  To start with, it is 
>    > confusing -- initially I mistook it for some sort of identification
>    > of the row of the alias table.  But the concept of "descriptor" as
>    > being a small integer identifying a network connection, as well as
>    > the very term "descriptor", are Unix-specific.
> 
>    Anything wrong with that :-) ?
> 
> In a standard?

Sure ... this is the IETF, right?  This protocol specification is
supposed to be read by programmers who would know what a Unix-
style file descriptor is.  In fact, if you go back to rfc2543, it
actually had actual *C code* for demonstrating how to write a forking
proxy (which I must say was great for understanding forking
mechanics when I wrote my first forking proxy back in 1998.)  Other
RFCs also have code and domain-specific nomenclature (see for example
drafts and RFCs in PKIX, many of which have ASN, BER, DER and other
encodings and cryptographic language pertinent to and rooted in that
domain.)

>    > There is an overall conflating of two concepts as "connection reuse".
>    > One is using one connection to send more than one request from one 
>    > sender to one recipient.  The second is using one connection to send 
>    > requests in both directions.  The first concept is already supported 
>    > by RFC 3261; the second is what is being enabled by this I-D.  But
>    > the I-D implements both actions using one alias table, obfuscating
>    > the distinction and so obfuscating the changes that the I-D is 
>    > introducing.
> 
>    So this is an interesting and very relevant comment.  You are
>    absolutely right that there are indeed two concepts of connection
>    reuse.  However, I do not believe that the draft conflates them.
> 
> It's using the same word for both, which requires very close reading
> to figure out which concept is being talked about at which time.  (I'm
> not claiming that *you* don't keep the two ideas straight, but I'm
> worried about the next 200 readers.)

OK; I think it may be good to separate the notion of persistent
connection (as suggested by Hadriel) and connection reuse.  The
former is when a client uses the same connection to send multiple
requests in the downstream direction, and the latter is when the
downstream entity can use the same connection to send new requests
upstream.  I will add this notion in the revision.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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

From sip-bounces@ietf.org Fri Nov 16 15:48:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It86y-0007EZ-4g; Fri, 16 Nov 2007 15:48:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It86x-0007Dz-5r
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 15:48:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It86w-0007Dr-Ql
	for sip@ietf.org; Fri, 16 Nov 2007 15:48:22 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It86w-0000Mf-9U
	for sip@ietf.org; Fri, 16 Nov 2007 15:48:22 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAGKmKdg017950; 
	Fri, 16 Nov 2007 14:48:20 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.cmat leads
to implementation by example.  There is ample additional text
that explicitly specifies the behavior.

>    > The use of "alias descriptor" is unfortunate.  To start with, it is 
>    > confusing -- initially I mistook it for some sort of identification
>    > of the row of the alias table.  But the concept of "descriptor" as
>    > being a small integer identifying a network connection, as well as
>    > the very term "descriptor", are Unix-specific.
> 
>    Anything wrong with that :-) ?
> 
> In a standard?

Sure ... this is the IETF, right?  This protocol specification is
supposed to be read by programmers who would know what a Unix-
style file descriptor is.  In fact, if you go back to rfc2543, it
actually had actual *C code* for demonstrating how to write a forking
proxy (which I must say was great for understanding forking
mechanics when I wrote my first forking proxy back in 1998.)  Other
RFCs also have code and domain-specific nomenclature (see for example
drafts and RFCs in PKIX, many of which have ASN, BER, DER and other
encodings and cryptographic language pertinent to and rooted in that
domain.)

>    > There is an overall conflating of two concepts as "connection reuse".
>    > One is using one connection to send more than one request from one 
>    > sender to one recipient.  The second is using one connection to send 
>    > requests in both directions.  The first concept is already supported 
>    > by RFC 3261; the second is what is being enabled by this I-D.  But
>    > the I-D implements both actions using one alias table, obfuscating
>    > the distinction and so obfuscating the changes that the I-D is 
>    > introducing.
> 
>    So this is an interesting and very relevant comment.  You are
>    absolutely right that there are indeed two concepts of connection
>    reuse.  However, I do not believe that the draft conflates them.
> 
> It's using the same word for both, which requires very close reading
> to figure out which concept is being talked about at which time.  (I'm
> not claiming that *you* don't keep the two ideas straight, but I'm
> worried about the next 200 readers.)

OK; I think it may be good to separate the notion of persistent
connection (as suggested by Hadriel) and connection reuse.  The
former is when a client uses the same connection to send multiple
requests in the downstream direction, and the latter is when the
downstream entity can use the same connection to send new requests
upstream.  I will add this notion in the revision.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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

From sip-bounces@ietf.org Fri Nov 16 15:48:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It86y-0007EZ-4g; Fri, 16 Nov 2007 15:48:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It86x-0007Dz-5r
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 15:48:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It86w-0007Dr-Ql
	for sip@ietf.org; Fri, 16 Nov 2007 15:48:22 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It86w-0000Mf-9U
	for sip@ietf.org; Fri, 16 Nov 2007 15:48:22 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAGKmKdg017950; 
	Fri, 16 Nov 2007 14:48:20 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAGKmFj22956; Fri, 16 Nov 2007 14:48:20 -0600 (CST)
Message-ID: <473E020F.2000908@alcatel-lucent.com>
Date: Fri, 16 Nov 2007 14:48:15 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: HKaplan@acmepacket.com
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>	<200711112208.lABM8xh5016388@dragon.ariadne.com>	<473DCE36.8070105@lucent.com>	<200711161811.lAGIB6FL007091@dragon.ariadne.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hadriel Kaplan wrote:
>> It's using the same word for both, which requires very close 
>> reading to figure out which concept is being talked about at which
>>  time.  (I'm not claiming that *you* don't keep the two ideas 
>> straight, but I'm worried about the next 200 readers.)
> 
> Indeed, I had the exact same confusion and I'm worried about the next
>  199 too.  :)  I would call it "persistent connection", a la HTTP.

OK -- that is a good suggestion; quoting from my last response
to Dale:

   OK; I think it may be good to separate the notion of persistent
   connection (as suggested by Hadriel) and connection reuse.  The
   former is when a client uses the same connection to send multiple
   requests in the downstream direction, and the latter is when the
   downstream entity can use the same connection to send new requests
   upstream.  I will add this notion in the revision.

> With regards to TCP "persistent connection", where you mean the 
> client can reuse the same TCP connection for requests going to the 
> same server, is that really necessary to put in a standard?  I mean 
> it was always allowed, no?  I guess it's good to make it explicit, 
> but I'm not sure how one knows when it's the right thing to do or 
> not.

The subtle difference here -- unlike in HTTP -- is that there
are requests coming towards the client from the server.  In HTTP,
the communication is one-way: the browser opens a connection to
the server and sends requests over that connection and can treat
that as a persistent connection for subsequent requests.  AFAIK,
in HTTP the server does not send a *request* towards the client
(the browser) over that same connection.

> I agree there are clients creating new TCP connections per SIP 
> session, and tearing down old ones, and that's very bad in some 
> situations, but it's essentially a local policy decision.  A client 
> is free to open and close TCP connections at will.  You can't make it
> keep one open forever. And there is nothing that the signaling is
> doing about it to help in this draft.

Agreed.

> Like for example if the server side stuck something in
> the response to indicate "you may keep this connection open and send 
> any future requests to me over it if you can". (i.e., the 
> Connection/Keep-Alive header model as in HTTP)

connect-reuse is arguing for this to be the default behavior in
SIP.  Except of course, requests in the backwards direction should
not use a connection that has not bom (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAGKmFj22956; Fri, 16 Nov 2007 14:48:20 -0600 (CST)
Message-ID: <473E020F.2000908@alcatel-lucent.com>
Date: Fri, 16 Nov 2007 14:48:15 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: HKaplan@acmepacket.com
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>	<200711112208.lABM8xh5016388@dragon.ariadne.com>	<473DCE36.8070105@lucent.com>	<200711161811.lAGIB6FL007091@dragon.ariadne.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hadriel Kaplan wrote:
>> It's using the same word for both, which requires very close 
>> reading to figure out which concept is being talked about at which
>>  time.  (I'm not claiming that *you* don't keep the two ideas 
>> straight, but I'm worried about the next 200 readers.)
> 
> Indeed, I had the exact same confusion and I'm worried about the next
>  199 too.  :)  I would call it "persistent connection", a la HTTP.

OK -- that is a good suggestion; quoting from my last response
to Dale:

   OK; I think it may be good to separate the notion of persistent
   connection (as suggested by Hadriel) and connection reuse.  The
   former is when a client uses the same connection to send multiple
   requests in the downstream direction, and the latter is when the
   downstream entity can use the same connection to send new requests
   upstream.  I will add this notion in the revision.

> With regards to TCP "persistent connection", where you mean the 
> client can reuse the same TCP connection for requests going to the 
> same server, is that really necessary to put in a standard?  I mean 
> it was always allowed, no?  I guess it's good to make it explicit, 
> but I'm not sure how one knows when it's the right thing to do or 
> not.

The subtle difference here -- unlike in HTTP -- is that there
are requests coming towards the client from the server.  In HTTP,
the communication is one-way: the browser opens a connection to
the server and sends requests over that connection and can treat
that as a persistent connection for subsequent requests.  AFAIK,
in HTTP the server does not send a *request* towards the client
(the browser) over that same connection.

> I agree there are clients creating new TCP connections per SIP 
> session, and tearing down old ones, and that's very bad in some 
> situations, but it's essentially a local policy decision.  A client 
> is free to open and close TCP connections at will.  You can't make it
> keep one open forever. And there is nothing that the signaling is
> doing about it to help in this draft.

Agreed.

> Like for example if the server side stuck something in
> the response to indicate "you may keep this connection open and send 
> any future requests to me over it if you can". (i.e., the 
> Connection/Keep-Alive header model as in HTTP)

connect-reuse is arguing for this to be the default behavior in
SIP.  Except of course, requests in the backwards direction should
not use a connection that has not been authenticated through TLS.

> Some vendors restrict how many simultaneous connections they'll allow
> from the same client, for security reasons, so are you thinking 
> along those lines?

Would that not in fact argue for persistent connections anyway?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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





een authenticated through TLS.

> Some vendors restrict how many simultaneous connections they'll allow
> from the same client, for security reasons, so are you thinking 
> along those lines?

Would that not in fact argue for persistent connections anyway?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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





From sip-bounces@ietf.org Fri Nov 16 17:09:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It9NH-0008Eo-WA; Fri, 16 Nov 2007 17:09:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1It9NE-0007U2-Fw
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 17:09:16 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It9ND-0007Jg-BW
	for sip@ietf.org; Fri, 16 Nov 2007 17:09:15 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It9NB-0003yE-WC
	for sip@ietf.org; Fri, 16 Nov 2007 17:09:15 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 16 Nov 2007 17:09:04 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAGM93Js026871; 
	Fri, 16 Nov 2007 17:09:03 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAGM8SWV019224; 
	Fri, 16 Nov 2007 22:09:03 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 17:08:45 -0500
Received: from [161.44.174.244] ([161.44.174.244]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Nov 2007 17:08:44 -0500
Message-ID: <473E14F0.7070606@cisco.com>
Date: Fri, 16 Nov 2007 17:08:48 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Gonzalo Camarillo 
Subject: Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt
References: 
	<46DDD081.9030900@cisco.com>	<46DE8094.8060807@ericsson.com>
	<470FCEA4.3060101@ericsson.com> <473DFCB0.7020401@ericsson.com>
In-Reply-To: <473DFCB0.7020401@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Nov 2007 22:08:44.0940 (UTC)
	FILETIME=[413AACC0:01C8289D]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15548.002
X-TM-AS-Result: No--23.645300-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13764; t=1195250943;
	x=1196114943; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20New=20revision=20of=20draft-ietf-sip-body-han
	dling-00.txt |Sender:=20
	|To:=20Gonzalo=20Camarillo=20;
	bh=KSboDjmPDL7/KH9xZF/6VqVoDFNR+Wt1ZKcNkPJglCM=;
	b=QlVUxcKyYs6+mVr5hxswoOSUJzdfoBGU9K7x2h/77dgKxm6miFv7jhCjRpFdZtVg3Y0hK09R
	7oGgkakRa+3HHGpC94CJTL3ARqqZ2MW3uIGPF63KFLkumqb4jnVNMt2Q;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b
Cc: sip , Keith Drage ,
	Eric Burger , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Gonzalo Camarillo wrote:
> Hi,
> 
> FYI: we have just gotten their review:
> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00110.html
> 
> Cheers,
> 
> Gonzalo

Looks like there is a *bit* more work to do. :-)

This is perhaps somewhat more feedback than we were hoping for. But 
honestly it does seem constructive.

However on several of what I thought were key points needing feedback I 
don't see the help I was hoping for. For instance regarding references. 
Perhaps more interaction is needed to get on the same wavelength so that 
Dave understands our concerns and we understand his answers.

	Paul


> Gonzalo Camarillo wrote:
>> Folks,
>>
>> FYI: we have requested the apps folks to have a look at this draft in 
>> order to make sure we get all the MIME stuff right. We will make sure 
>> the review is posted to this list.
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> Gonzalo Camarillo wrote:
>>> Hi,
>>>
>>> to be more concrete in our discussions, we need to make decisions on 
>>> the following two issues:
>>>
>>> 1) Where in a SIP message is it allowed to reference a body part?
>>>
>>> a) in header fields and body parts within the same multipart/related 
>>> as the referenced body part
>>> b) in header fields and body parts that appear before the referenced 
>>> body part
>>> c) in header fields and any body part
>>>
>>> We discussed that doing c) would require to parse SIP messages twice 
>>> to look for potential references. Therefore, we decided to do a) or 
>>> b). The current draft specifies a), we doing b) might make sense as 
>>> well (it would be less restrictive).
>>>
>>>
>>> 2) If a receiver does not understand a reference to a body part:
>>>
>>> a) it should process (handle) it solely based on its disposition type 
>>> (as a fall-back mechanism). If the sender does not want this to 
>>> happen, it can use an option tag.
>>>
>>> b) the body part will have a disposition type of "only-by-reference". 
>>> This way, since the receiver did not understand the reference, it 
>>> knows it should not process the body.
>>>
>>> The current draft specifies a), but b) would be an interesting 
>>> optimization (no need to use option tags and reissue requests). 
>>> However, we would need to get the opinion of a MIME person on b).
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>
>>>
>>>
>>> Paul Kyzivat wrote:
>>>>
>>>>
>>>> Eric Burger wrote:
>>>>> I agree 100% with Paul.  However, one thing I would like to hear 
>>>>> opinions on
>>>>> is the following:
>>>>>
>>>>> Do we way body parts are always processed, no matter what?
>>>>>
>>>>> It would be convenient to say body parts get processed as needed.  
>>>>> If there
>>>>> is a related part that never gets referenced, then a conforming 
>>>>> processor
>>>>> might not process that part, as an optimization.
>>>>
>>>> This gets into semantics...
>>>>
>>>> For one thing, I guess we should talk about "handling" rather than 
>>>> "processing" - this is tied to the C-D "handling=" parameter.
>>>>
>>>> But the key thing is what does it *mean* to say you have handled 
>>>> something? Its one thing to understand the meaning of the type and 
>>>> disposition. What you actually *do* once that is understood is 
>>>> something else entirely.
>>>>
>>>> I would expect that somewhere there would be a normative 
>>>> specification for each C-D of what it means to *handle* body parts 
>>>> with that disposition. This is where we get into trouble with 
>>>> "render", where we need a different definition for SIP than is used 
>>>> for email.
>>>>
>>>> I presume that if we had such normative definitions, then that would 
>>>> determine what sort of optimizations, such as lazy processing, are 
>>>> allowed.
>>>>
>>>> For example, 3261 defines (barely) the C-D "alert". It says this 
>>>> "should" (lower case) be rendered. Together with some words 
>>>> elsewhere about Alert-Info that warn of security issues, its seems 
>>>> clear that the UA is given discretion about actually rendering this. 
>>>> (But it is not a stellar example of clarity.) I would interpret this 
>>>> to mean that you can consider the "alert" body part to have been 
>>>> "handled" if you have indeed understood it and then *either* 
>>>> rendered it or made an explicit not to render it.
>>>>
>>>>> However, one thing we need to be mindful of are side effects.  MIME 
>>>>> body
>>>>> parts can make external references.  Those external references (to
>>>>> http/https URI's) may hit application servers.  Those application 
>>>>> servers
>>>>> may do something based on the receipt of the URI.  It could be as 
>>>>> simple as
>>>>> recording the fact the body part was read (like a web beacon), or 
>>>>> it could
>>>>> be as complex as changing application state.
>>>>
>>>> We have similar issues with headers that contain URL references, 
>>>> that might or might not be resolved. E.g. Call-Info.
>>>>
>>>> Again, I don't see any general answer better than the specification 
>>>> of the particular header or C-D.
>>>>
>>>> Based on this discussion I am beginning to conclude that we might as 
>>>> well treat each body part almost as if it were a header whose name 
>>>> is its C-D.
>>>>
>>>>> What do people think of this?  Do we say that SIP engines are 
>>>>> opportunistic,
>>>>> and the side effect MUST happen if the body gets used, buy the side 
>>>>> effect
>>>>> MAY happen if the body does not get used?  That would be my vote, 
>>>>> as the
>>>>> alternative, that all side effects (external references get 
>>>>> resolved) happen
>>>>> puts a pretty big burden on User Agents.
>>>>
>>>> This is further complicated by intermediate nodes. They are 
>>>> *permitted* to look at body parts. If, as a result, an intermediate 
>>>> node dereferences a reference within a body part, you will 
>>>> potentially have another side effect.
>>>>
>>>> I also agree that we should give the UA latitude in what processing 
>>>> it does. For example, even though a request has a geopriv header 
>>>> with a body part containing location data, and has specified 
>>>> "handling=required", the UAS may have no use for the location. If it 
>>>> doesn't intend to use it then why should it process it?
>>>>
>>>>     Paul
>>>>
>>>>> On 8/29/07 8:57 AM, "Paul Kyzivat"  wrote:
>>>>>
>>>>>> To clarify futher my last point below...
>>>>>>
>>>>>> What I am saying is that IMO body parts must always be processed
>>>>>> according to their type and disposition, whether there are 
>>>>>> references to
>>>>>> them or not. If there is a reference, and it is understood, then 
>>>>>> it can
>>>>>> modify or supplement the processing, but if the reference is not
>>>>>> recognized or understood then the other processing still occurs.
>>>>>>
>>>>>> If we want to support the possibility of a reference to a body part,
>>>>>> where there is to be no processing of the body part when the 
>>>>>> reference
>>>>>> is not understood, then we need a content-disposition that says 
>>>>>> "don't
>>>>>> do anything with this unless you process a reference to it."
>>>>>>
>>>>>> An alternative is to simply assume there are no such cases, and warn
>>>>>> people that use references to select a C-D for the referenced part 
>>>>>> that
>>>>>> will have an appropriate result if the reference is not understood.
>>>>>>
>>>>>> For instance, we have both the Alert-Info header and the "alert" 
>>>>>> C-D. If
>>>>>> you use an A-I with a CID reference, then you can use "alert" as 
>>>>>> the C-D
>>>>>> of that part. In that case, the A-I header is redundant unless it
>>>>>> contains something that modifies the processing.
>>>>>>
>>>>>> An example where the problem I am concerned about may exist is in
>>>>>> draft-ietf-sip-location-conveyance-08. It has an example of a
>>>>>> Geolocation header referencing a body part. There is no C-D header in
>>>>>> the example, so by default it is "render;handling=required". And 
>>>>>> its C-T
>>>>>> is application/pidf+xml. If a recipient of this message didn't
>>>>>> understand the Geolocation header it would reach the conclusion 
>>>>>> that it
>>>>>> should render the pidf. Its debatable whether that is the desired
>>>>>> conclusion - I think not. IMO the intent is that if the Geolocation
>>>>>> header isn't processed then the pidf should be ignored. So, IMO this
>>>>>> body part ought to contain:
>>>>>>     Content-Disposition: by-reference;handling=optional
>>>>>>
>>>>>> (I don't care what name we use for the disposition, just that we 
>>>>>> have one.)
>>>>>>
>>>>>> Thanks,
>>>>>> Paul
>>>>>>
>>>>>> Paul Kyzivat wrote:
>>>>>>> Gonzalo,
>>>>>>>
>>>>>>> Obviously we allow a "forward" reference from the sip message itself
>>>>>>> (which from a mime perspective are just a bunch of mime headers.)
>>>>>>>
>>>>>>> I think that establishes a precedent that needs to be continued. An
>>>>>>> example of why can be seen in sipfrag:
>>>>>>>
>>>>>>> If we had a valid sip response that had a reference into one of 
>>>>>>> its body
>>>>>>> parts, then if that was turned into a sipfrag and stuffed into 
>>>>>>> the body
>>>>>>> of a NOTIFY, then it must still be valid.
>>>>>>>
>>>>>>> I just did a quick scan of the new draft, so the following is a
>>>>>>> tentative comment, until I can read it more carefully:
>>>>>>>
>>>>>>> I think the draft is now saying that the decision about whether to
>>>>>>> process a body part according to a reference to it, or process
>>>>>>> independently, is decided based on whether a reference is found. 
>>>>>>> We had
>>>>>>> this discussion before, and I think we agreed that wouldn't work 
>>>>>>> well,
>>>>>>> and that instead we would have a special C-D type for body parts 
>>>>>>> that
>>>>>>> are disposed of based on a reference.
>>>>>>>
>>>>>>> I don't think the introduction of issues related to 
>>>>>>> multipart/related
>>>>>>> changes this. The obvious cases are when there is a single
>>>>>>> multipart/mixed containing some body parts. Some of those may be
>>>>>>> referenced from CID URIs in sip headers, and others (e.g. SDP) 
>>>>>>> may stand
>>>>>>> on their own. It is entirely possible that a body part might be
>>>>>>> referenced from some extension header that the recipient doesn't
>>>>>>> understand. In that case it may erroneously decide to process the 
>>>>>>> body
>>>>>>> part on its own, when it should instead have ignored it because the
>>>>>>> header isn't being processed.
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Paul
>>>>>>>
>>>>>>> Gonzalo Camarillo wrote:
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> I have just submitted a new revision of the body handling draft. 
>>>>>>>> Until
>>>>>>>> it appears on the archives, you can fetch it from:
>>>>>>>>
>>>>>>>> http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt 
>>>>>>>>
>>>>>>>>
>>>>>>>> Per our discussions in Chicago, the draft now states that only body
>>>>>>>> parts within the same 'multipart/related' can reference each other
>>>>>>>> using cid URIs.
>>>>>>>>
>>>>>>>> If this is too restrictive, we could also allow using forward
>>>>>>>> references in any context (with no 'multipart/related' at all).
>>>>>>>>
>>>>>>>> Comments?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Gonzalo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>> Notice:  This email message, together with any attachments, may 
>>>>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  
>>>>> and  affiliated entities,  that may be confidential,  proprietary,  
>>>>> copyrighted  and/or legally privileged, and is intended solely for 
>>>>> the use of the individual or entity named in this message. If you 
>>>>> are not the intended recipient, and have received this message in 
>>>>> error, please immediately return this by email and then delete it.
>>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
> 


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 18:05:17 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItAFJ-0002sD-IV; Fri, 16 Nov 2007 18:05:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItAFI-0002lq-6y
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 18:05:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItAFH-0002jS-PG
	for sip@ietf.org; Fri, 16 Nov 2007 18:05:07 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItAFG-0006De-Qr
	for sip@ietf.org; Fri, 16 Nov 2007 18:05:07 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lAGN4mfj029403; 
	Fri, 16 Nov 2007 17:04:48 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAGN4hj01910; Fri, 16 Nov 2007 17:04:44 -0600 (CST)
Message-ID: <473E220B.7020509@lucent.com>
Date: Fri, 16 Nov 2007 17:04:43 -0600
From: "Vijay K. Gurbani" 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: HKaplan@acmepacket.com
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hadriel Kaplan wrote:
> [note: I have not read Dale's comments yet, so there may be repeats 
> (I started drafting this before getting his email)]

Hadriel: Thanks for your in-depth WGLC review and feedback.
More inline.

> Technical: Sec 5.2: I am really confused why this section exists. The
> whole doc keeps repeating how TCP or SCTP alone (sans TLS) is not an
> appropriate connection for connection reuse, and indeed this section
> ultimately means the same.  So why is all the mechanics of this
> section in the doc?  Is there something different about TCP 
> connection handling in this than previously?  Why is it even added to
>  the alias table, when its entry cannot be used for aliasing?  This
> is quite confusing.  I recommend removing it.

S5.2 cautions against reusing TCP connections in the same manner
as TLS (i.e., a single connection used to send requests in
both directions.)  The reason this was added was to warn implementors
not to do so (for reasons in S9.3)  When I inherited connect-reuse
(-04), it talked mostly about TLS connection reuse and did not
mention TCP connection reuse at all.  Thus, I added some discussion
on TCP and SCTP connection reuse into the draft.

Based on the same feedback by Dale as well, I will wordsmith S5.2
to point to rfc3261.

> Section 5.1, p.7: "P1 determines through RFC3263 server resolution 
> process that the request should be sent to P2 on port 5061 using 
> TLS..." and same thing on page 8 for P2.  Now I'm no expert, but last
>  time I checked I thought SRV's allowed defining the port number, so 
> one did NOT need to use the well-known 5061 for TLS, but could use 
> anything.  So why is this restricting alias use to 5061 only?

You are absolutely right.  In that example I just assumed that the
DNS SRV for P2 pointed to the default port, 5061.  The example
is not implying that DNS SRV only yielded P2's IP address and
that P1 used the default port (5061) for TLS.  I will make that
a bit more clear maybe using the non-defaulted TLS port number.

> Sec 9.3, p.15: the argument used here against TCP or SCTP 
> connect-reuse (sans TLS) is one of malware hijacking on a multi-user 
> computer.  I don't find that argument convincing, because I think 
> it's a red herring.  If you have a malware program running on a proxy
>  responsible for a domain, you are in a world of hurt regardless. 
> (You're rearranging the deck chairs on the Titanic)

True; although when we (i.e., the co-authors) had initially fleshed
out the session hijacking scenario, we were thinking more about a user
agent and not a proxy per se (note the alias parameter can be used
between any neighboring user agents, i.e., UAC->Proxy, Proxy->Proxy,
Proxy->UAS, and UAC->UAS.)  I can drill down and talk about the
perils of a UAC->Proxy TCP connection reuse (i.e., connection
hijacking) and then talk about the perils of an un-authenticated
Proxy->Proxy TCP connection reuse as you outline below ...

> What *is* convincing is that without the certificate proof of
> identity inherent in TLS, the mechanism as defined in this draft
> would let a completely different machine, from a different IP,
> pretend to represent a legit domain's proxy by simply putting in the
> Via and alias param.  That would be bad.  And due to SCTP
> multi-homing coming from any IP, and load-balancing techniques and
> such, just restricting the source IP to avoid that problem won't work
> universally.  *That* should be the text in the draft for why TLS is
> required, vs. the "malware" excuse.  I am only mentioning this
> because not allowing TCP or SCTP alone is a major detractor for this
> draft, so the explanations for why not need to be strong.

... would that be an acceptable compromise?

> Sec 8.1, p.11: Regarding TCP/SCTP connections, it says "Subsequent 
> requests that resolve to the same IP address, port, and transport 
> tuple MUST reuse the same connection."  Since when is that mandatory,
> and why?  There is no connection reuse for TCP/SCTP.  If I want to 
> open two TCP connections to a server, for example due to head-of-line
> blocking or failure of previous, why can't I?  In fact, if I want to
> open two separate TLS connection why can't I?  This should at least 
> only be a SHOULD strength.

OK; good point.  I will downgrade the strength to a SHOULD.

> Sec 8.1, p.11: Further, next sentence says "It MUST only accept 
> responses over this connection and MUST NOT accept any requests over 
> this connection."  Why is that?  The far-end chose to send a request 
> over an open connection.  It's definitely not clear that the far-end 
> should have done so (nor how it would have resolved to do so), but is
> there anything wrong from a protocol perspective with the local end 
> accepting it?  For example if the far-end is manually configured to 
> do so.

The tact the draft takes is not to accept requests from the far
end unless the far end has been authenticated through TLS.  So I
would find it rather disconcerting if the draft allowed an entity
to accept a request over an unauthenticated connection.

> Sec 5.1, p.8 says: "The presence of the "alias" parameter indicates 
> that P1 does support aliasing.  P2 now authenticates the connection 
> (see Section 9.2) and if the authentication was successful, P2 
> creates an alias to P1 using the advertised address in the topmost 
> Via."  This implies a server-side authentication occurs for the 
> initial TLS connection, the request is sent from P1 to P2, P2 sees 
> the alias, and then P2 does a TLS renegotiation to get the client 
> side's cert?  I think it's important to spell this out in the draft, 
> because I'm not sure everyone supports this after the initial TLS 
> handshake is over (I think most mutual-TLS happens at the beginning 
> in the real world, but I could easily be wrong - IANAE).

OK; good point.  I will make this more explicit.

> Editorial: 1) Sec 3, page 4: "While this is adequate for TCP, and 
> indeed is the only way to securely do connection reuse over that 
> transport (see Section 9.3..." the words "connection reuse" should be
>  removed since it clearly does NOT reuse the connection in such a 
> case.

Yes ... good catch.  I will reword.

> 2) Section 5 is a bit confusing, because the diagram shows two UA's 
> and two proxies between them, then describes things in terms of "UAC"
>  and "UAS", whereas I'm fairly sure you mean the proxies instead.
> For example, second paragraph of sec 5.1 would imply the UAS uses
> P2's connection for all subsequent requests going to the UAC, which
> is NOT true.  If it has a record-route, then for in-dialog requests
> yes, but it has nothing to do with subsequent requests going to the
> UAC in general.

Yes, you are right.  Dale also pointed this out when he said in his
review that:

    Examples tend to discuss multiple user agents and proxies,
    when the entirety of the mechanism can be described by
    considering only the two SIP agents at the ends of the
    connection.

I think that approaching it as Dale has stated it -- two SIP agents
at the ends of the connection -- is the right way to go.  I will
change the text to reflect this in the new revision.

> 3) sec 5.2: "Connection reuse on the TCP transport is done 
> differently from the TLS case."  No, it's not done at all.  There is 
> no "reused connection".

Yes.

> 4) sec 5.2 says "The presence of the "alias" parameter in the topmost
>  Via for a TCP transport is not required."  Then later in section 8.1
>  it says "For TCP and SCTP transports, the client MUST NOT insert the
>  "alias" parameter in the topmost Via header.." (also note the 
> double-period at the end of that sentence)

I will fix this -- the double period is an easy fix.  Regarding
the first comment in the above paragraph, S5.2 and S8.1 agree insofar
as saying that TCP transports do not require an "alias" parameter.
However since S5 is informative only, I did not put in any normative
language.

Thanks for your review, Hadriel.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 18:30:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItAdQ-0005Em-8y; Fri, 16 Nov 2007 18:30:04 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItAdO-0005Ee-Mm
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 18:30:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItAdO-0005EW-Ah; Fri, 16 Nov 2007 18:30:02 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ItAdN-0006nO-V4; Fri, 16 Nov 2007 18:30:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id CFEAA26E31;
	Fri, 16 Nov 2007 23:30:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1ItAdN-0002Rq-Oc; Fri, 16 Nov 2007 18:30:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Fri, 16 Nov 2007 18:30:01 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-sips-07.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
	Author(s)       : F. Audet
	Filename        : draft-ietf-sip-sips-07.txt
	Pages           : 56
	Date            : 2007-11-16

This document provides clarifications and guidelines concerning the
use of the SIPS URI scheme in the Session Initiation Protocol (SIP).
It also makes normative changes to SIP.  This document also provides
a discussion of possible future steps in specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-07.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-sips-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-sips-07.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-16182730.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-sips-07.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-sips-07.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-16182730.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Fri Nov 16 18:46:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItAti-0003DM-8B; Fri, 16 Nov 2007 18:46:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItAtg-00034v-IG
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 18:46:52 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItAtg-00033O-4K
	for sip@ietf.org; Fri, 16 Nov 2007 18:46:52 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItAtf-0007Pp-5z
	for sip@ietf.org; Fri, 16 Nov 2007 18:46:52 -0500
Received: from [206.176.144.212] (206-176-144-212.waymark.net
	[206.176.144.212]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAGNke4D021112
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 16 Nov 2007 17:46:42 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
To: IETF SIP List 
Message-Id: <5839996C-D935-4B10-B37D-2F96798BF554@softarmor.com>
From: Dean Willis 
Date: Fri, 16 Nov 2007 17:46:22 -0600
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a
Cc: Cullen Jennings , Keith Drage 
Subject: [Sip] Another revised agenda for SIP at IETF 70
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0171816373=="
Errors-To: sip-bounces@ietf.org


--===============0171816373==
Content-Type: multipart/alternative; boundary=Apple-Mail-1-53733702


--Apple-Mail-1-53733702
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


Revised agenda posted at:

http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_70

mhtml hopefully follows:

Session 1, Monday December 3, 1740-1950 Salon A/B
Start Time
Topic
Discussion Lead
Reading List
1740
Agenda Bash and Status
Chairs
This document
1750
Outbound
Rohan Mahy
draft-ietf-sip-outbound-10
1830
Location Conveyance
Brian rosen, James Polk
draft-ietf-sip-location-conveyance-08
1900
Connection Reuse
Vijay Gurbani
draft-ietf-sip-connect-reuse-08
1930
Privacy
Mayumi Munakata
draft-ietf-sip-ua-privacy-00
1950
End



Session 2, Wednesday December 5, 0900-1130, Salon A/B
Start Time
Topic
Discussion Lead
Reading List
0900
Agenda Bash
Chairs
This Document
0930
RPH In Responses
James Polk
draft-polk-sip-rph-in-responses-00
1000
Media Identity
Dan Wing
draft-wing-sip-identity-media-01
1020
INFO Harmful
Eric Burger
draft-burger-sip-info-02
1050
INFO Events
Hadriel Kaplan
draft-kaplan-sip-info-events-00
1130
End



--Apple-Mail-1-53733702
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=US-ASCII




Revised agenda =
posted at:


mhtml =
hopefully follows:

Session 1, Monday =
December 3, 1740-1950 Salon A/B
  =
 =
 =
 =

  
Start Time
 		 
Topic
 		 
Discussion Lead
 		 
Reading List
 		 
 
 
1740
 		 
Agenda Bash and Status
 =
 
Chairs
 		 
This document
 		 
 
1750
 		 
Outbound
 		 
Rohan =
Mahy
 		   
 
 
1830
 		 
Location =
Conveyance
 		 
Brian rosen, James Polk
 =
   
 
1900
 		 
Connection Reuse
 
Vijay =
Gurbani
 		   
 
 
1930
 		 
Privacy
 		 
Mayumi =
Munakata
 		   
 
 
1950
 		 
End
 		 

 =
 

 =
 
  

Session 2, Wednesday =
December 5, 0900-1130, Salon A/B
  =
 =
 =
 =
 =

  
Start Time
 		 
Topic
 		 
Discussion Lead
 		 
Reading List
 		 
 
 
0900
 		 
Agenda Bash
 		 
Chairs
 		 
This Document
 		 
 
0930
 		 
RPH In Responses
 
James =
Polk
 		   
 
 
1000
 		 
Media Identity
 		 
Dan =
Wing
 		   
 
1020
 		 
INFO Harmful
 		 
Eric =
Burger
 		   
 
 
1050
 		 
INFO =
Events
 		 
Hadriel Kaplan
 		   
 
1130
 		 
End
 		 

 =
 

 =
 
  
=

--Apple-Mail-1-53733702--



--===============0171816373==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0171816373==--





From sip-bounces@ietf.org Fri Nov 16 21:11:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItD9k-00057w-1b; Fri, 16 Nov 2007 21:11:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItD9i-00056n-20
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 21:11:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItD9h-00056N-Kv
	for sip@ietf.org; Fri, 16 Nov 2007 21:11:33 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItD9g-0003Qq-8z
	for sip@ietf.org; Fri, 16 Nov 2007 21:11:33 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Fri, 16 Nov 2007 21:11:31 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Fri, 16 Nov 2007 21:11:31 -0500
From: Hadriel Kaplan 
To: "Vijay K. Gurbani" 
Date: Fri, 16 Nov 2007 21:10:51 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Index: AcgokgapA77zOpiOQ0+tCaOWSn9uTAAAJmaw
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	<200711112208.lABM8xh5016388@dragon.ariadne.com>
	<473DCE36.8070105@lucent.com>
	<200711161811.lAGIB6FL007091@dragon.ariadne.com>
	
	<473E020F.2000908@alcatel-lucent.com>
In-Reply-To: <473E020F.2000908@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]
> Sent: Friday, November 16, 2007 3:48 PM
>
> > With regards to TCP "persistent connection", where you mean the
> > client can reuse the same TCP connection for requests going to the
> > same server, is that really necessary to put in a standard?  I mean
> > it was always allowed, no?  I guess it's good to make it explicit,
> > but I'm not sure how one knows when it's the right thing to do or
> > not.
>
> The subtle difference here -- unlike in HTTP -- is that there
> are requests coming towards the client from the server.  In HTTP,
> the communication is one-way: the browser opens a connection to
> the server and sends requests over that connection and can treat
> that as a persistent connection for subsequent requests.  AFAIK,
> in HTTP the server does not send a *request* towards the client
> (the browser) over that same connection.

Right, but that's why I say it's the same thing as TCP persistent connectio=
ns in this draft.  You're not allowing upstream requests over TCP, only ove=
r TLS.  You're saying keep the TCP connection from the client to the server=
 open, and send subsequent requests over it in the downstream direction (cl=
ient->server).  Requests going the other direction are sent over a TCP clie=
nt->server connection from the other side.  In that way it's exactly like H=
TTP/1.1.


> > Like for example if the server side stuck something in
> > the response to indicate "you may keep this connection open and send
> > any future requests to me over it if you can". (i.e., the
> > Connection/Keep-Alive header model as in HTTP)
>
> connect-reuse is arguing for this to be the default behavior in
> SIP.

Oh. Ok.


> > Some vendors restrict how many simultaneous connections they'll allow
> > from the same client, for security reasons, so are you thinking
> > along those lines?
>
> Would that not in fact argue for persistent connections anyway?

Sure, but it doesn't solve it.  Persistent connections were always possible=
, so even if this new draft says to do it by default, the server has no way=
 to know it is or isn't being done, and the client has no way to be told to=
 do it. (not that I'm advocating that be done mind you)

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 16 22:21:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItEFE-0004IJ-8c; Fri, 16 Nov 2007 22:21:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItEFC-0004HL-0N
	for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 22:21:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItEFB-0004HD-LM
	for sip@ietf.org; Fri, 16 Nov 2007 22:21:17 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItEFB-0005uc-95
	for sip@ietf.org; Fri, 16 Nov 2007 22:21:17 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Fri, 16 Nov 2007 22:21:16 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Fri, 16 Nov 2007 22:21:14 -0500
From: Hadriel Kaplan 
To: "Vijay K. Gurbani" 
Date: Fri, 16 Nov 2007 22:20:29 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Index: AcgopSgb5TuSqrH2RxKhvZOe7OYsIgAGtiOQ
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
In-Reply-To: <473E220B.7020509@lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]
> Sent: Friday, November 16, 2007 6:05 PM
> To: Hadriel Kaplan
> Cc: IETF SIP List; Rohan Mahy; Brett Tate
> Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
>
> > Sec 8.1, p.11: Further, next sentence says "It MUST only accept
> > responses over this connection and MUST NOT accept any requests over
> > this connection."  Why is that?  The far-end chose to send a request
> > over an open connection.  It's definitely not clear that the far-end
> > should have done so (nor how it would have resolved to do so), but is
> > there anything wrong from a protocol perspective with the local end
> > accepting it?  For example if the far-end is manually configured to
> > do so.
>
> The tact the draft takes is not to accept requests from the far
> end unless the far end has been authenticated through TLS.  So I
> would find it rather disconcerting if the draft allowed an entity
> to accept a request over an unauthenticated connection.

I wouldn't. :)  It is no more "authenticated" than if the remote end opened=
 a connection using an ephemeral port to the local host's listen port.  The=
 local host client knows little about the validity of the remote end.  Actu=
ally, the client knows slightly more about the validity of a connection it =
opened to the far-end than the other way-around, especially if it did singl=
e-sided TLS to the far-end, so in that sense it makes more sense to accept =
requests over its client socket than over the listen port.  It just doesn't=
 make much sense for the remote end to send them over it, unless it can aut=
henticate (e.g., using digest).  And that's the rub.  Today certain types o=
f devices fix NAT traversal for SIP/TCP or SIP/TLS without needing the clie=
nt to do sip-outbound, so long as the client can accept requests over its p=
ersistent connection, because they can authenticate the client.  It's worke=
d so far, anyway.  But this new MUST would break it.

-hadriel


_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 17 02:12:30 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItHqs-00068v-Cs; Sat, 17 Nov 2007 02:12:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItHqr-00066p-Kz
	for sip-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 02:12:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItHqq-00064m-S7
	for sip@ietf.org; Sat, 17 Nov 2007 02:12:24 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItHql-0001dL-Rk
	for sip@ietf.org; Sat, 17 Nov 2007 02:12:24 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	F0E9C204DA; Sat, 17 Nov 2007 08:12:18 +0100 (CET)
X-AuditID: c1b4fb3e-af833bb0000007e1-f9-473e9452f23a
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	C9A57204A0; Sat, 17 Nov 2007 08:12:18 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Nov 2007 08:12:18 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Nov 2007 08:12:17 +0100
Received: from [131.160.126.48] (rvi2-126-48.lmf.ericsson.se [131.160.126.48])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 2FFE2232D;
	Sat, 17 Nov 2007 09:12:17 +0200 (EET)
Message-ID: <473E9451.4080103@ericsson.com>
Date: Sat, 17 Nov 2007 09:12:17 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Paul Kyzivat 
Subject: Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt
References: 
	<46DDD081.9030900@cisco.com>	<46DE8094.8060807@ericsson.com>
	<470FCEA4.3060101@ericsson.com> <473DFCB0.7020401@ericsson.com>
	<473E14F0.7070606@cisco.com>
In-Reply-To: <473E14F0.7070606@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Nov 2007 07:12:17.0901 (UTC)
	FILETIME=[301199D0:01C828E9]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83
Cc: sip , Keith Drage ,
	Eric Burger , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi Paul,

yes, I agree; that's what I thought as well when I read the review. 
Anyway, this is a good starting point for discussions. I will touch base 
with Dave and will start working on how to address his comments and how 
to get feedback on the points we did not get any.

In any case, I do not see the need to revise the draft before Vancouver.

Cheers,

Gonzalo

Paul Kyzivat wrote:
> 
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> FYI: we have just gotten their review:
>> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00110.html
>>
>> Cheers,
>>
>> Gonzalo
> 
> Looks like there is a *bit* more work to do. :-)
> 
> This is perhaps somewhat more feedback than we were hoping for. But 
> honestly it does seem constructive.
> 
> However on several of what I thought were key points needing feedback I 
> don't see the help I was hoping for. For instance regarding references. 
> Perhaps more interaction is needed to get on the same wavelength so that 
> Dave understands our concerns and we understand his answers.
> 
>     Paul
> 
> 
>> Gonzalo Camarillo wrote:
>>> Folks,
>>>
>>> FYI: we have requested the apps folks to have a look at this draft in 
>>> order to make sure we get all the MIME stuff right. We will make sure 
>>> the review is posted to this list.
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>
>>>
>>> Gonzalo Camarillo wrote:
>>>> Hi,
>>>>
>>>> to be more concrete in our discussions, we need to make decisions on 
>>>> the following two issues:
>>>>
>>>> 1) Where in a SIP message is it allowed to reference a body part?
>>>>
>>>> a) in header fields and body parts within the same multipart/related 
>>>> as the referenced body part
>>>> b) in header fields and body parts that appear before the referenced 
>>>> body part
>>>> c) in header fields and any body part
>>>>
>>>> We discussed that doing c) would require to parse SIP messages twice 
>>>> to look for potential references. Therefore, we decided to do a) or 
>>>> b). The current draft specifies a), we doing b) might make sense as 
>>>> well (it would be less restrictive).
>>>>
>>>>
>>>> 2) If a receiver does not understand a reference to a body part:
>>>>
>>>> a) it should process (handle) it solely based on its disposition 
>>>> type (as a fall-back mechanism). If the sender does not want this to 
>>>> happen, it can use an option tag.
>>>>
>>>> b) the body part will have a disposition type of 
>>>> "only-by-reference". This way, since the receiver did not understand 
>>>> the reference, it knows it should not process the body.
>>>>
>>>> The current draft specifies a), but b) would be an interesting 
>>>> optimization (no need to use option tags and reissue requests). 
>>>> However, we would need to get the opinion of a MIME person on b).
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>>
>>>> Paul Kyzivat wrote:
>>>>>
>>>>>
>>>>> Eric Burger wrote:
>>>>>> I agree 100% with Paul.  However, one thing I would like to hear 
>>>>>> opinions on
>>>>>> is the following:
>>>>>>
>>>>>> Do we way body parts are always processed, no matter what?
>>>>>>
>>>>>> It would be convenient to say body parts get processed as needed.  
>>>>>> If there
>>>>>> is a related part that never gets referenced, then a conforming 
>>>>>> processor
>>>>>> might not process that part, as an optimization.
>>>>>
>>>>> This gets into semantics...
>>>>>
>>>>> For one thing, I guess we should talk about "handling" rather than 
>>>>> "processing" - this is tied to the C-D "handling=" parameter.
>>>>>
>>>>> But the key thing is what does it *mean* to say you have handled 
>>>>> something? Its one thing to understand the meaning of the type and 
>>>>> disposition. What you actually *do* once that is understood is 
>>>>> something else entirely.
>>>>>
>>>>> I would expect that somewhere there would be a normative 
>>>>> specification for each C-D of what it means to *handle* body parts 
>>>>> with that disposition. This is where we get into trouble with 
>>>>> "render", where we need a different definition for SIP than is used 
>>>>> for email.
>>>>>
>>>>> I presume that if we had such normative definitions, then that 
>>>>> would determine what sort of optimizations, such as lazy 
>>>>> processing, are allowed.
>>>>>
>>>>> For example, 3261 defines (barely) the C-D "alert". It says this 
>>>>> "should" (lower case) be rendered. Together with some words 
>>>>> elsewhere about Alert-Info that warn of security issues, its seems 
>>>>> clear that the UA is given discretion about actually rendering 
>>>>> this. (But it is not a stellar example of clarity.) I would 
>>>>> interpret this to mean that you can consider the "alert" body part 
>>>>> to have been "handled" if you have indeed understood it and then 
>>>>> *either* rendered it or made an explicit not to render it.
>>>>>
>>>>>> However, one thing we need to be mindful of are side effects.  
>>>>>> MIME body
>>>>>> parts can make external references.  Those external references (to
>>>>>> http/https URI's) may hit application servers.  Those application 
>>>>>> servers
>>>>>> may do something based on the receipt of the URI.  It could be as 
>>>>>> simple as
>>>>>> recording the fact the body part was read (like a web beacon), or 
>>>>>> it could
>>>>>> be as complex as changing application state.
>>>>>
>>>>> We have similar issues with headers that contain URL references, 
>>>>> that might or might not be resolved. E.g. Call-Info.
>>>>>
>>>>> Again, I don't see any general answer better than the specification 
>>>>> of the particular header or C-D.
>>>>>
>>>>> Based on this discussion I am beginning to conclude that we might 
>>>>> as well treat each body part almost as if it were a header whose 
>>>>> name is its C-D.
>>>>>
>>>>>> What do people think of this?  Do we say that SIP engines are 
>>>>>> opportunistic,
>>>>>> and the side effect MUST happen if the body gets used, buy the 
>>>>>> side effect
>>>>>> MAY happen if the body does not get used?  That would be my vote, 
>>>>>> as the
>>>>>> alternative, that all side effects (external references get 
>>>>>> resolved) happen
>>>>>> puts a pretty big burden on User Agents.
>>>>>
>>>>> This is further complicated by intermediate nodes. They are 
>>>>> *permitted* to look at body parts. If, as a result, an intermediate 
>>>>> node dereferences a reference within a body part, you will 
>>>>> potentially have another side effect.
>>>>>
>>>>> I also agree that we should give the UA latitude in what processing 
>>>>> it does. For example, even though a request has a geopriv header 
>>>>> with a body part containing location data, and has specified 
>>>>> "handling=required", the UAS may have no use for the location. If 
>>>>> it doesn't intend to use it then why should it process it?
>>>>>
>>>>>     Paul
>>>>>
>>>>>> On 8/29/07 8:57 AM, "Paul Kyzivat"  wrote:
>>>>>>
>>>>>>> To clarify futher my last point below...
>>>>>>>
>>>>>>> What I am saying is that IMO body parts must always be processed
>>>>>>> according to their type and disposition, whether there are 
>>>>>>> references to
>>>>>>> them or not. If there is a reference, and it is understood, then 
>>>>>>> it can
>>>>>>> modify or supplement the processing, but if the reference is not
>>>>>>> recognized or understood then the other processing still occurs.
>>>>>>>
>>>>>>> If we want to support the possibility of a reference to a body part,
>>>>>>> where there is to be no processing of the body part when the 
>>>>>>> reference
>>>>>>> is not understood, then we need a content-disposition that says 
>>>>>>> "don't
>>>>>>> do anything with this unless you process a reference to it."
>>>>>>>
>>>>>>> An alternative is to simply assume there are no such cases, and warn
>>>>>>> people that use references to select a C-D for the referenced 
>>>>>>> part that
>>>>>>> will have an appropriate result if the reference is not understood.
>>>>>>>
>>>>>>> For instance, we have both the Alert-Info header and the "alert" 
>>>>>>> C-D. If
>>>>>>> you use an A-I with a CID reference, then you can use "alert" as 
>>>>>>> the C-D
>>>>>>> of that part. In that case, the A-I header is redundant unless it
>>>>>>> contains something that modifies the processing.
>>>>>>>
>>>>>>> An example where the problem I am concerned about may exist is in
>>>>>>> draft-ietf-sip-location-conveyance-08. It has an example of a
>>>>>>> Geolocation header referencing a body part. There is no C-D 
>>>>>>> header in
>>>>>>> the example, so by default it is "render;handling=required". And 
>>>>>>> its C-T
>>>>>>> is application/pidf+xml. If a recipient of this message didn't
>>>>>>> understand the Geolocation header it would reach the conclusion 
>>>>>>> that it
>>>>>>> should render the pidf. Its debatable whether that is the desired
>>>>>>> conclusion - I think not. IMO the intent is that if the Geolocation
>>>>>>> header isn't processed then the pidf should be ignored. So, IMO this
>>>>>>> body part ought to contain:
>>>>>>>     Content-Disposition: by-reference;handling=optional
>>>>>>>
>>>>>>> (I don't care what name we use for the disposition, just that we 
>>>>>>> have one.)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Paul
>>>>>>>
>>>>>>> Paul Kyzivat wrote:
>>>>>>>> Gonzalo,
>>>>>>>>
>>>>>>>> Obviously we allow a "forward" reference from the sip message 
>>>>>>>> itself
>>>>>>>> (which from a mime perspective are just a bunch of mime headers.)
>>>>>>>>
>>>>>>>> I think that establishes a precedent that needs to be continued. An
>>>>>>>> example of why can be seen in sipfrag:
>>>>>>>>
>>>>>>>> If we had a valid sip response that had a reference into one of 
>>>>>>>> its body
>>>>>>>> parts, then if that was turned into a sipfrag and stuffed into 
>>>>>>>> the body
>>>>>>>> of a NOTIFY, then it must still be valid.
>>>>>>>>
>>>>>>>> I just did a quick scan of the new draft, so the following is a
>>>>>>>> tentative comment, until I can read it more carefully:
>>>>>>>>
>>>>>>>> I think the draft is now saying that the decision about whether to
>>>>>>>> process a body part according to a reference to it, or process
>>>>>>>> independently, is decided based on whether a reference is found. 
>>>>>>>> We had
>>>>>>>> this discussion before, and I think we agreed that wouldn't work 
>>>>>>>> well,
>>>>>>>> and that instead we would have a special C-D type for body parts 
>>>>>>>> that
>>>>>>>> are disposed of based on a reference.
>>>>>>>>
>>>>>>>> I don't think the introduction of issues related to 
>>>>>>>> multipart/related
>>>>>>>> changes this. The obvious cases are when there is a single
>>>>>>>> multipart/mixed containing some body parts. Some of those may be
>>>>>>>> referenced from CID URIs in sip headers, and others (e.g. SDP) 
>>>>>>>> may stand
>>>>>>>> on their own. It is entirely possible that a body part might be
>>>>>>>> referenced from some extension header that the recipient doesn't
>>>>>>>> understand. In that case it may erroneously decide to process 
>>>>>>>> the body
>>>>>>>> part on its own, when it should instead have ignored it because the
>>>>>>>> header isn't being processed.
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Paul
>>>>>>>>
>>>>>>>> Gonzalo Camarillo wrote:
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> I have just submitted a new revision of the body handling 
>>>>>>>>> draft. Until
>>>>>>>>> it appears on the archives, you can fetch it from:
>>>>>>>>>
>>>>>>>>> http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Per our discussions in Chicago, the draft now states that only 
>>>>>>>>> body
>>>>>>>>> parts within the same 'multipart/related' can reference each other
>>>>>>>>> using cid URIs.
>>>>>>>>>
>>>>>>>>> If this is too restrictive, we could also allow using forward
>>>>>>>>> references in any context (with no 'multipart/related' at all).
>>>>>>>>>
>>>>>>>>> Comments?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Gonzalo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> Notice:  This email message, together with any attachments, may 
>>>>>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  
>>>>>> and  affiliated entities,  that may be confidential,  
>>>>>> proprietary,  copyrighted  and/or legally privileged, and is 
>>>>>> intended solely for the use of the individual or entity named in 
>>>>>> this message. If you are not the intended recipient, and have 
>>>>>> received this message in error, please immediately return this by 
>>>>>> email and then delete it.
>>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>



_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 17 10:16:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItPPK-0005rb-LZ; Sat, 17 Nov 2007 10:16:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItPPJ-0005oj-AX
	for sip-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 10:16:29 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItPPI-0005nG-2W
	for sip@ietf.org; Sat, 17 Nov 2007 10:16:28 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItPPG-0003bO-J6
	for sip@ietf.org; Sat, 17 Nov 2007 10:16:27 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 17 Nov 2007 10:16:26 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAHFGQmx028299; 
	Sat, 17 Nov 2007 10:16:26 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAHFG5Vt022187; 
	Sat, 17 Nov 2007 15:16:06 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Nov 2007 10:16:05 -0500
Received: from [10.86.243.29] ([10.86.243.29]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Nov 2007 10:16:05 -0500
Message-ID: <473F05B4.2060005@cisco.com>
Date: Sat, 17 Nov 2007 10:16:04 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Gonzalo Camarillo 
Subject: Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt
References: 
	<46DDD081.9030900@cisco.com>	<46DE8094.8060807@ericsson.com>
	<470FCEA4.3060101@ericsson.com> <473DFCB0.7020401@ericsson.com>
	<473E14F0.7070606@cisco.com> <473E9451.4080103@ericsson.com>
In-Reply-To: <473E9451.4080103@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Nov 2007 15:16:05.0424 (UTC)
	FILETIME=[C5D21B00:01C8292C]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15550.002
X-TM-AS-Result: No--33.023100-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15177; t=1195312586;
	x=1196176586; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20New=20revision=20of=20draft-ietf-sip-body-han
	dling-00.txt |Sender:=20
	|To:=20Gonzalo=20Camarillo=20;
	bh=P1tNC/Rb+AITmXB0uwVuNQakOD2yY+L6imyJ909qdlU=;
	b=hCo8sORSpZVyKT62LlHrXjROtQi8/HMbebne9wANBC/3WjcFBuf/pf6OtGpI+tWo60bCCCF+
	kZXEmvWmzrFwElh5U0T1Vs1ve9T8icbdtg2tuMplzm4cdROKPC1e/az8;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6
Cc: sip , Keith Drage ,
	Eric Burger , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Gonzalo Camarillo wrote:
> Hi Paul,
> 
> yes, I agree; that's what I thought as well when I read the review. 
> Anyway, this is a good starting point for discussions. I will touch base 
> with Dave and will start working on how to address his comments and how 
> to get feedback on the points we did not get any.
> 
> In any case, I do not see the need to revise the draft before Vancouver.

Yeah I agree.

Perhaps we can have a side conversation with Dave on this while in 
Vancouver.

	Thanks,
	Paul

> Cheers,
> 
> Gonzalo
> 
> Paul Kyzivat wrote:
>>
>>
>> Gonzalo Camarillo wrote:
>>> Hi,
>>>
>>> FYI: we have just gotten their review:
>>> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00110.html
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>
>> Looks like there is a *bit* more work to do. :-)
>>
>> This is perhaps somewhat more feedback than we were hoping for. But 
>> honestly it does seem constructive.
>>
>> However on several of what I thought were key points needing feedback 
>> I don't see the help I was hoping for. For instance regarding 
>> references. Perhaps more interaction is needed to get on the same 
>> wavelength so that Dave understands our concerns and we understand his 
>> answers.
>>
>>     Paul
>>
>>
>>> Gonzalo Camarillo wrote:
>>>> Folks,
>>>>
>>>> FYI: we have requested the apps folks to have a look at this draft 
>>>> in order to make sure we get all the MIME stuff right. We will make 
>>>> sure the review is posted to this list.
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>> Gonzalo Camarillo wrote:
>>>>> Hi,
>>>>>
>>>>> to be more concrete in our discussions, we need to make decisions 
>>>>> on the following two issues:
>>>>>
>>>>> 1) Where in a SIP message is it allowed to reference a body part?
>>>>>
>>>>> a) in header fields and body parts within the same 
>>>>> multipart/related as the referenced body part
>>>>> b) in header fields and body parts that appear before the 
>>>>> referenced body part
>>>>> c) in header fields and any body part
>>>>>
>>>>> We discussed that doing c) would require to parse SIP messages 
>>>>> twice to look for potential references. Therefore, we decided to do 
>>>>> a) or b). The current draft specifies a), we doing b) might make 
>>>>> sense as well (it would be less restrictive).
>>>>>
>>>>>
>>>>> 2) If a receiver does not understand a reference to a body part:
>>>>>
>>>>> a) it should process (handle) it solely based on its disposition 
>>>>> type (as a fall-back mechanism). If the sender does not want this 
>>>>> to happen, it can use an option tag.
>>>>>
>>>>> b) the body part will have a disposition type of 
>>>>> "only-by-reference". This way, since the receiver did not 
>>>>> understand the reference, it knows it should not process the body.
>>>>>
>>>>> The current draft specifies a), but b) would be an interesting 
>>>>> optimization (no need to use option tags and reissue requests). 
>>>>> However, we would need to get the opinion of a MIME person on b).
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Gonzalo
>>>>>
>>>>>
>>>>>
>>>>> Paul Kyzivat wrote:
>>>>>>
>>>>>>
>>>>>> Eric Burger wrote:
>>>>>>> I agree 100% with Paul.  However, one thing I would like to hear 
>>>>>>> opinions on
>>>>>>> is the following:
>>>>>>>
>>>>>>> Do we way body parts are always processed, no matter what?
>>>>>>>
>>>>>>> It would be convenient to say body parts get processed as 
>>>>>>> needed.  If there
>>>>>>> is a related part that never gets referenced, then a conforming 
>>>>>>> processor
>>>>>>> might not process that part, as an optimization.
>>>>>>
>>>>>> This gets into semantics...
>>>>>>
>>>>>> For one thing, I guess we should talk about "handling" rather than 
>>>>>> "processing" - this is tied to the C-D "handling=" parameter.
>>>>>>
>>>>>> But the key thing is what does it *mean* to say you have handled 
>>>>>> something? Its one thing to understand the meaning of the type and 
>>>>>> disposition. What you actually *do* once that is understood is 
>>>>>> something else entirely.
>>>>>>
>>>>>> I would expect that somewhere there would be a normative 
>>>>>> specification for each C-D of what it means to *handle* body parts 
>>>>>> with that disposition. This is where we get into trouble with 
>>>>>> "render", where we need a different definition for SIP than is 
>>>>>> used for email.
>>>>>>
>>>>>> I presume that if we had such normative definitions, then that 
>>>>>> would determine what sort of optimizations, such as lazy 
>>>>>> processing, are allowed.
>>>>>>
>>>>>> For example, 3261 defines (barely) the C-D "alert". It says this 
>>>>>> "should" (lower case) be rendered. Together with some words 
>>>>>> elsewhere about Alert-Info that warn of security issues, its seems 
>>>>>> clear that the UA is given discretion about actually rendering 
>>>>>> this. (But it is not a stellar example of clarity.) I would 
>>>>>> interpret this to mean that you can consider the "alert" body part 
>>>>>> to have been "handled" if you have indeed understood it and then 
>>>>>> *either* rendered it or made an explicit not to render it.
>>>>>>
>>>>>>> However, one thing we need to be mindful of are side effects.  
>>>>>>> MIME body
>>>>>>> parts can make external references.  Those external references (to
>>>>>>> http/https URI's) may hit application servers.  Those application 
>>>>>>> servers
>>>>>>> may do something based on the receipt of the URI.  It could be as 
>>>>>>> simple as
>>>>>>> recording the fact the body part was read (like a web beacon), or 
>>>>>>> it could
>>>>>>> be as complex as changing application state.
>>>>>>
>>>>>> We have similar issues with headers that contain URL references, 
>>>>>> that might or might not be resolved. E.g. Call-Info.
>>>>>>
>>>>>> Again, I don't see any general answer better than the 
>>>>>> specification of the particular header or C-D.
>>>>>>
>>>>>> Based on this discussion I am beginning to conclude that we might 
>>>>>> as well treat each body part almost as if it were a header whose 
>>>>>> name is its C-D.
>>>>>>
>>>>>>> What do people think of this?  Do we say that SIP engines are 
>>>>>>> opportunistic,
>>>>>>> and the side effect MUST happen if the body gets used, buy the 
>>>>>>> side effect
>>>>>>> MAY happen if the body does not get used?  That would be my vote, 
>>>>>>> as the
>>>>>>> alternative, that all side effects (external references get 
>>>>>>> resolved) happen
>>>>>>> puts a pretty big burden on User Agents.
>>>>>>
>>>>>> This is further complicated by intermediate nodes. They are 
>>>>>> *permitted* to look at body parts. If, as a result, an 
>>>>>> intermediate node dereferences a reference within a body part, you 
>>>>>> will potentially have another side effect.
>>>>>>
>>>>>> I also agree that we should give the UA latitude in what 
>>>>>> processing it does. For example, even though a request has a 
>>>>>> geopriv header with a body part containing location data, and has 
>>>>>> specified "handling=required", the UAS may have no use for the 
>>>>>> location. If it doesn't intend to use it then why should it 
>>>>>> process it?
>>>>>>
>>>>>>     Paul
>>>>>>
>>>>>>> On 8/29/07 8:57 AM, "Paul Kyzivat"  wrote:
>>>>>>>
>>>>>>>> To clarify futher my last point below...
>>>>>>>>
>>>>>>>> What I am saying is that IMO body parts must always be processed
>>>>>>>> according to their type and disposition, whether there are 
>>>>>>>> references to
>>>>>>>> them or not. If there is a reference, and it is understood, then 
>>>>>>>> it can
>>>>>>>> modify or supplement the processing, but if the reference is not
>>>>>>>> recognized or understood then the other processing still occurs.
>>>>>>>>
>>>>>>>> If we want to support the possibility of a reference to a body 
>>>>>>>> part,
>>>>>>>> where there is to be no processing of the body part when the 
>>>>>>>> reference
>>>>>>>> is not understood, then we need a content-disposition that says 
>>>>>>>> "don't
>>>>>>>> do anything with this unless you process a reference to it."
>>>>>>>>
>>>>>>>> An alternative is to simply assume there are no such cases, and 
>>>>>>>> warn
>>>>>>>> people that use references to select a C-D for the referenced 
>>>>>>>> part that
>>>>>>>> will have an appropriate result if the reference is not understood.
>>>>>>>>
>>>>>>>> For instance, we have both the Alert-Info header and the "alert" 
>>>>>>>> C-D. If
>>>>>>>> you use an A-I with a CID reference, then you can use "alert" as 
>>>>>>>> the C-D
>>>>>>>> of that part. In that case, the A-I header is redundant unless it
>>>>>>>> contains something that modifies the processing.
>>>>>>>>
>>>>>>>> An example where the problem I am concerned about may exist is in
>>>>>>>> draft-ietf-sip-location-conveyance-08. It has an example of a
>>>>>>>> Geolocation header referencing a body part. There is no C-D 
>>>>>>>> header in
>>>>>>>> the example, so by default it is "render;handling=required". And 
>>>>>>>> its C-T
>>>>>>>> is application/pidf+xml. If a recipient of this message didn't
>>>>>>>> understand the Geolocation header it would reach the conclusion 
>>>>>>>> that it
>>>>>>>> should render the pidf. Its debatable whether that is the desired
>>>>>>>> conclusion - I think not. IMO the intent is that if the Geolocation
>>>>>>>> header isn't processed then the pidf should be ignored. So, IMO 
>>>>>>>> this
>>>>>>>> body part ought to contain:
>>>>>>>>     Content-Disposition: by-reference;handling=optional
>>>>>>>>
>>>>>>>> (I don't care what name we use for the disposition, just that we 
>>>>>>>> have one.)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> Paul Kyzivat wrote:
>>>>>>>>> Gonzalo,
>>>>>>>>>
>>>>>>>>> Obviously we allow a "forward" reference from the sip message 
>>>>>>>>> itself
>>>>>>>>> (which from a mime perspective are just a bunch of mime headers.)
>>>>>>>>>
>>>>>>>>> I think that establishes a precedent that needs to be 
>>>>>>>>> continued. An
>>>>>>>>> example of why can be seen in sipfrag:
>>>>>>>>>
>>>>>>>>> If we had a valid sip response that had a reference into one of 
>>>>>>>>> its body
>>>>>>>>> parts, then if that was turned into a sipfrag and stuffed into 
>>>>>>>>> the body
>>>>>>>>> of a NOTIFY, then it must still be valid.
>>>>>>>>>
>>>>>>>>> I just did a quick scan of the new draft, so the following is a
>>>>>>>>> tentative comment, until I can read it more carefully:
>>>>>>>>>
>>>>>>>>> I think the draft is now saying that the decision about whether to
>>>>>>>>> process a body part according to a reference to it, or process
>>>>>>>>> independently, is decided based on whether a reference is 
>>>>>>>>> found. We had
>>>>>>>>> this discussion before, and I think we agreed that wouldn't 
>>>>>>>>> work well,
>>>>>>>>> and that instead we would have a special C-D type for body 
>>>>>>>>> parts that
>>>>>>>>> are disposed of based on a reference.
>>>>>>>>>
>>>>>>>>> I don't think the introduction of issues related to 
>>>>>>>>> multipart/related
>>>>>>>>> changes this. The obvious cases are when there is a single
>>>>>>>>> multipart/mixed containing some body parts. Some of those may be
>>>>>>>>> referenced from CID URIs in sip headers, and others (e.g. SDP) 
>>>>>>>>> may stand
>>>>>>>>> on their own. It is entirely possible that a body part might be
>>>>>>>>> referenced from some extension header that the recipient doesn't
>>>>>>>>> understand. In that case it may erroneously decide to process 
>>>>>>>>> the body
>>>>>>>>> part on its own, when it should instead have ignored it because 
>>>>>>>>> the
>>>>>>>>> header isn't being processed.
>>>>>>>>>
>>>>>>>>>     Thanks,
>>>>>>>>>     Paul
>>>>>>>>>
>>>>>>>>> Gonzalo Camarillo wrote:
>>>>>>>>>> Folks,
>>>>>>>>>>
>>>>>>>>>> I have just submitted a new revision of the body handling 
>>>>>>>>>> draft. Until
>>>>>>>>>> it appears on the archives, you can fetch it from:
>>>>>>>>>>
>>>>>>>>>> http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Per our discussions in Chicago, the draft now states that only 
>>>>>>>>>> body
>>>>>>>>>> parts within the same 'multipart/related' can reference each 
>>>>>>>>>> other
>>>>>>>>>> using cid URIs.
>>>>>>>>>>
>>>>>>>>>> If this is too restrictive, we could also allow using forward
>>>>>>>>>> references in any context (with no 'multipart/related' at all).
>>>>>>>>>>
>>>>>>>>>> Comments?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Gonzalo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> Notice:  This email message, together with any attachments, may 
>>>>>>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  
>>>>>>> and  affiliated entities,  that may be confidential,  
>>>>>>> proprietary,  copyrighted  and/or legally privileged, and is 
>>>>>>> intended solely for the use of the individual or entity named in 
>>>>>>> this message. If you are not the intended recipient, and have 
>>>>>>> received this message in error, please immediately return this by 
>>>>>>> email and then delete it.
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
> 


_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 17 13:13:01 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItSA7-0008Gm-Dz; Sat, 17 Nov 2007 13:12:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItSA6-0008Ga-EW
	for sip-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 13:12:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItSA6-0008G3-21
	for sip@ietf.org; Sat, 17 Nov 2007 13:12:58 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItSA5-0001Q7-NJ
	for sip@ietf.org; Sat, 17 Nov 2007 13:12:57 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Sat, 17 Nov 2007 13:12:57 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Sat, 17 Nov 2007 13:12:57 -0500
From: Hadriel Kaplan 
To: "Vijay K. Gurbani" 
Date: Sat, 17 Nov 2007 13:12:15 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Index: AcgopSgb5TuSqrH2RxKhvZOe7OYsIgAIMk1g
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
In-Reply-To: <473E220B.7020509@lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]
> Sent: Friday, November 16, 2007 6:05 PM
> To: Hadriel Kaplan
> Cc: IETF SIP List; Rohan Mahy; Brett Tate
> Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
>
> > What *is* convincing is that without the certificate proof of
> > identity inherent in TLS, the mechanism as defined in this draft
> > would let a completely different machine, from a different IP,
> > pretend to represent a legit domain's proxy by simply putting in the
> > Via and alias param.  That would be bad.  And due to SCTP
> > multi-homing coming from any IP, and load-balancing techniques and
> > such, just restricting the source IP to avoid that problem won't work
> > universally.  *That* should be the text in the draft for why TLS is
> > required, vs. the "malware" excuse.  I am only mentioning this
> > because not allowing TCP or SCTP alone is a major detractor for this
> > draft, so the explanations for why not need to be strong.
>
> ... would that be an acceptable compromise?

Sure.

BTW, out of curiosity, I thought at some point in the past there was an ema=
il saying that for UA's, sip-outbound would be the only draft for explicit =
connect-reuse behavior.  So that this draft was really for proxies, not UA'=
s.  Not true? (not that such use would be enforced in any way, just that th=
e focus had changed)

-hadriel


_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 17 13:23:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItSKd-0002Md-Op; Sat, 17 Nov 2007 13:23:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItSKc-0002ID-8V
	for sip-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 13:23:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItSKb-0002Dx-Gk
	for sip@ietf.org; Sat, 17 Nov 2007 13:23:49 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItSKa-0001hl-VV
	for sip@ietf.org; Sat, 17 Nov 2007 13:23:49 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JRN0097WXQWYB@siemenscomms.co.uk> for sip@ietf.org; Sat,
	17 Nov 2007 18:23:20 +0000 (GMT)
Date: Sat, 17 Nov 2007 18:23:47 +0000
From: "Elwell, John" 
In-reply-to: 
To: sip , Dan Wing 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: I-D Action:draft-wing-sip-identity-media-01.txt
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxA
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: 
Subject: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I think this is a very important draft. The problem it addresses is a
very real problem that not only stops RFC 4474/4916 being deployed
sensibly but also undermines the work on DTLS-SRTP.

John 

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
> Sent: 15 November 2007 21:00
> To: i-d-announce@ietf.org
> Subject: I-D Action:draft-wing-sip-identity-media-01.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : SIP Identity using Media Path
> 	Author(s)       : D. Wing, H. Kaplan
> 	Filename        : draft-wing-sip-identity-media-01.txt
> 	Pages           : 25
> 	Date            : 2007-11-15
> 
> The existing SIP identity mechanism (RFC4474) creates a signature
> over the SIP body, including the entire SDP.  As part of their normal
> operation, Session Border Controllers (SBCs) and SIP Back-to-Back
> User Agents (B2BUAs) modify various fields in the SDP which breaks
> that signature.
> 
> This document defines a new identity mechanism which operates with
> SBCs and B2BUAs.  This new identity mechanism creates a signature
> over certain SIP headers and certain SDP lines, and uses both SIP
> signaling and the media path to perform its identity function.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wing-sip-identity-me
> dia-01.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in 
> the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-wing-sip-identity-media-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-wing-sip-identity-media-01.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 


_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 17 20:30:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItYyw-0001M0-HF; Sat, 17 Nov 2007 20:29:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItYyv-0001Kx-4J
	for sip-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 20:29:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItYyu-0001Jn-Ik
	for sip@ietf.org; Sat, 17 Nov 2007 20:29:52 -0500
Received: from py-out-1112.google.com ([64.233.166.176])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItYyr-0003Hr-5O
	for sip@ietf.org; Sat, 17 Nov 2007 20:29:52 -0500
Received: by py-out-1112.google.com with SMTP id d32so9355125pye
	for ; Sat, 17 Nov 2007 17:29:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth;
	bh=ePYPHKOPpMimO8tjwAuaP6v1Chh5F1VK9Ig7Yp3K0OE=;
	b=srej5XojTDCGNbHixyGgiDPh6YtO4hVn4k2uU6I2MyrROk6l7Z+pCw58qGYaaPl1gsQxTRXrIFX9314YsOBdSX99Zrn/9UlCQt2r3MRbfZwGA7iZN7+YlMKHGzqdy51GjeGfCnT1UWKoGihd6vvRyiNGV45+z3SRyS+VE8UpRZg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth;
	b=cFaIY70SCDqtYCDSj+LztC2CvuINF4BwRrq8HqSbEVS1/g9aoCJKmrCD/tpwQrOYjYw11CFqfPKVxkKphgHFwBEaJpWEO6EnWhu5CCIBGjYIMLrn69Z08J/8EdO9/+8jWQfp3HbjhNEPpzbiZSgMDYtEQ3X6CHIeI5FehywosR8=
Received: by 10.142.191.2 with SMTP id o2mr866661wff.1195349387834;
	Sat, 17 Nov 2007 17:29:47 -0800 (PST)
Received: by 10.142.52.6 with HTTP; Sat, 17 Nov 2007 17:29:47 -0800 (PST)
Message-ID: 
Date: Sat, 17 Nov 2007 17:29:47 -0800
From: "Derek MacDonald" 
To: "Jonathan Rosenberg" 
MIME-Version: 1.0
X-Google-Sender-Auth: c741440cc06d6be2
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: Cullen Jennings , sip@ietf.org
Subject: [Sip] Transport parameters & transport switching in GRUU-15
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1359131551=="
Errors-To: sip-bounces@ietf.org

--===============1359131551==
Content-Type: multipart/alternative; 
	boundary="----=_Part_11033_9388580.1195349387835"

------=_Part_11033_9388580.1195349387835
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Jonathan,

I recently implemented gruu-15 and it left me w/ a couple of questions about
GRUU generation.  Specifically, does the transport parameter used in the
contact
of the REGISTER message influence GRUU generation? Does the scheme?

The issue I see is that if you are using GRUU in an environment where NATs
aren't forcing the us of outbound, that automatic protocol switching as
defined
in 18.1.1 3261 could cause some odd behaviour.

For example if an UA switched to TCP because it was making a large
dialog-forming
request but used a UDP GRUU...bad things could happen w/ messages going back
to
the UA in the dialog.

I think this is easy to fix w/ two modifications/clarifications:

* a different scheme or transport paramter results in a different GRUU being
  generated for an AOR/instance-id pair
* a GRUU contact should still have a transport parameter. The examples in
  gruu-15 don't have transport parameteres on the GRUUs, but all of the
examples
  are UDP. Maybe this is a clarification instead of a change.

An alternative approach is to allow registration of multiple transports to
the
same GRUU, w/ the location server selecting which one to use. This seems
too complicated.

-Derek

------=_Part_11033_9388580.1195349387835
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Jonathan,

I recently implemented gruu-15 and it left me w/ a couple of questions about
GRUU generation.  Specifically, does the transport parameter used in the contact
of the REGISTER message influence GRUU generation? Does the scheme?


The issue I see is that if you are using GRUU in an environment where NATs
aren't forcing the us of outbound, that automatic protocol switching as defined
in 18.1.1 3261 could cause some odd behaviour. 


For example if an UA switched to TCP because it was making a large dialog-forming
request but used a UDP GRUU...bad things could happen w/ messages going back to
the UA in the dialog.

I think this is easy to fix w/ two modifications/clarifications:


* a different scheme or transport paramter results in a different GRUU being
  generated for an AOR/instance-id pair
* a GRUU contact should still have a transport parameter. The examples in
  gruu-15 don't have transport parameteres on the GRUUs, but all of the examples

  are UDP. Maybe this is a clarification instead of a change.

An alternative approach is to allow registration of multiple transports to the
same GRUU, w/ the location server selecting which one to use. This seems

too complicated.

-Derek



------=_Part_11033_9388580.1195349387835--



--===============1359131551==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1359131551==--





From sip-bounces@ietf.org Sun Nov 18 14:20:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Itpgc-000513-AB; Sun, 18 Nov 2007 14:20:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItpgY-0004yj-Tk
	for sip-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 14:20:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItpgY-0004yb-KB; Sun, 18 Nov 2007 14:20:02 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ItpgY-0004dj-8X; Sun, 18 Nov 2007 14:20:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1AA8326E6E;
	Sun, 18 Nov 2007 19:20:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1ItpgY-0000QK-0S; Sun, 18 Nov 2007 14:20:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Sun, 18 Nov 2007 14:20:02 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-saml-03.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : SIP SAML Profile and Binding
	Author(s)       : H. Tschofenig, et al.
	Filename        : draft-ietf-sip-saml-03.txt
	Pages           : 43
	Date            : 2007-11-18

This document specifies a Session Initiation Protocol (SIP) profile
of Security Assertion Markup Language (SAML) as well as a SAML SIP
binding.  The defined SIP SAML Profile composes with the mechanisms
defined in the SIP Identity specification and satisfy requirements
presented in "Trait-based Authorization Requirements for the Session
Initiation Protocol (SIP)".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-03.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-saml-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-saml-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-18141346.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-saml-03.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-saml-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-18141346.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Sun Nov 18 20:54:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItvqR-000392-HR; Sun, 18 Nov 2007 20:54:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItvqQ-00033V-Et
	for sip-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 20:54:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvqQ-00032a-3l
	for sip@ietf.org; Sun, 18 Nov 2007 20:54:38 -0500
Received: from mail85.messagelabs.com ([216.82.240.99])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ItvqM-0008NF-Qt
	for sip@ietf.org; Sun, 18 Nov 2007 20:54:38 -0500
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-5.tower-85.messagelabs.com!1195437273!37316534!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 9771 invoked from network); 19 Nov 2007 01:54:33 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88)
	by server-5.tower-85.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2007 01:54:33 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta102.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id
	lAJ1tHdw027760 for ; Sun, 18 Nov 2007 20:55:18 -0500
In-Reply-To: 
To: Janet P Gunn 
Subject: Re: [Sip] Progression of draft-polk-sip-rph-in-responses-00
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn 
Message-ID: 
Date: Sun, 18 Nov 2007 20:54:29 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF180|March 29, 2007) at 11/18/2007 08:53:00 PM,
	Serialize complete at 11/18/2007 08:53:00 PM
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a0534e6179a1e260079328e8b03c7901
Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0243058488=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0243058488==
Content-Type: multipart/alternative;
	boundary="=_alternative 000A788585257398_="

This is a multipart message in MIME format.
--=_alternative 000A788585257398_=
Content-Type: text/plain; charset="US-ASCII"

In order to explain the use case for the requirements  for "RPH in 
Responses", we have submitted an Internet Draft.

http://www.ietf.org/internet-drafts/draft-gunn-sip-req-for-rph-in-responses-00.txt

Janet



Janet P Gunn/FED/CSC@CSC wrote on 09/24/2007 02:20:15 PM:

> 
> 
> 
> Those are valid concerns.  I said that I was oversimplifying, and 
> some of the oversimplification involves mechanisms to addresses some
> of those concerns. 
> 
> But we DO need to allow the situation where the first "hop" of a 
> "priority" call does not have RPH, but RPH is added for later hops. 
> 
> Janet
> 
> 
> Dean Willis  wrote on 09/24/2007 01:12:49 PM:
> 
> > Janet P Gunn wrote:
> > > Jeroen van Bemmel  wrote on 09/21/2007 03:19:09 
PM:
> > > 
> > >> Tim, Brian,
> > >>
> > >> First of all a question to clarify the requirements further: is it 
> > >> possible/valid for the request to have no specific priority while 
its 
> > >> response does, or should the RPH headers in a response always be 
the 
> > >> same or a subset of those in the request (i.e. copied)? I assume 
the 
> > > latter
> > > No, not a valid assumption. 
> > > 
> > > In order to support legacy applications, priority markings (e.g.RPH) 
may 
> > > be set based on the "dialed number"- e.g., by parsing the Request 
URI.
> > > 
> > > In some architectures (e.g. IMS) there may be RPH-capable SIP 
> actors (Type 
> > > A) which do not parse the Request URI looking for the key 
> strings.  Such a 
> > > SIP actor would send a SIP Invite WITHOUT RPH.  However, a 
subsequent 
> > > RPH-capable SIP actor (which DOES parse the Request URI looking for 
the 
> > > key strings) (Type B) would set RPH, both in Invites sent forward, 
and in 
> > > responses sent back.
> > > 
> > > So the "Type A" SIP actor could send out an Invite without RPH, but 
get 
> > > back a response WITH RPH.
> > > 
> > > I have oversimplified, but the point is that it is not a valid 
assumption.
> > >
> > 
> > Ok, so what keeps me as a Joe End User from putting a "higher priority
> > than the president" marking on every response I send? You can't
> > challenge a response or send me an error code if you don't like my
> > priority. Does every response require authentication of priority 
level?
> > 
> > Do we also have a new requirement for a node to "learn" the priority
> > level of a dialog from a response, and then include that priority 
level
> > in future requests on that dialog?
> > 
> > It seems like this mechanism could be used to "jack up" the priority
> > level of a dialog:
> > 
> > 1) Alice sends a low priority request to Bob.
> > 2) Bob replies with a high-priority marking in the response.
> > 3) Alice marks all future requests and responses in this dialog high
> > priority.
> > 
> > --
> > Dean_______________________________________________
> 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
--=_alternative 000A788585257398_=
Content-Type: text/html; charset="US-ASCII"



In order to explain the use case for
the requirements  for "RPH in Responses", we have submitted
an Internet Draft.



http://www.ietf.org/internet-drafts/draft-gunn-sip-req-for-rph-in-responses-00.txt



Janet







Janet P Gunn/FED/CSC@CSC wrote on 09/24/2007 02:20:15
PM:



> 

> 

> 

> Those are valid concerns.  I said that I was oversimplifying,
and 

> some of the oversimplification involves mechanisms to addresses some

> of those concerns. 

> 

> But we DO need to allow the situation where the first "hop"
of a 

> "priority" call does not have RPH, but RPH is added for
later hops. 

> 

> Janet

> 

> 

> Dean Willis <dean.willis@softarmor.com> wrote on 09/24/2007
01:12:49 PM:

> 

> > Janet P Gunn wrote:

> > > Jeroen van Bemmel <jbemmel@zonnet.nl> wrote on 09/21/2007
03:19:09 PM:

> > > 

> > >> Tim, Brian,

> > >>

> > >> First of all a question to clarify the requirements
further: is it 

> > >> possible/valid for the request to have no specific priority
while its 

> > >> response does, or should the RPH headers in a response
always be the 

> > >> same or a subset of those in the request (i.e. copied)?
I assume the 

> > > latter

> > > No, not a valid assumption. 

> > > 

> > > In order to support legacy applications, priority markings
(e.g.RPH) may 

> > > be set based on the "dialed number"- e.g., by
parsing the Request URI.

> > > 

> > > In some architectures (e.g. IMS) there may be RPH-capable
SIP 

> actors (Type 

> > > A) which do not parse the Request URI looking for the key


> strings.  Such a 

> > > SIP actor would send a SIP Invite WITHOUT RPH.  However,
a subsequent 

> > > RPH-capable SIP actor (which DOES parse the Request URI
looking for the 

> > > key strings) (Type B) would set RPH, both in Invites sent
forward, and in 

> > > responses sent back.

> > > 

> > > So the "Type A" SIP actor could send out an Invite
without RPH, but get 

> > > back a response WITH RPH.

> > > 

> > > I have oversimplified, but the point is that it is not a
valid assumption.

> > >

> > 

> > Ok, so what keeps me as a Joe End User from putting a "higher
priority

> > than the president" marking on every response I send? You
can't

> > challenge a response or send me an error code if you don't like
my

> > priority. Does every response require authentication of priority
level?

> > 

> > Do we also have a new requirement for a node to "learn"
the priority

> > level of a dialog from a response, and then include that priority
level

> > in future requests on that dialog?

> > 

> > It seems like this mechanism could be used to "jack up"
the priority

> > level of a dialog:

> > 

> > 1) Alice sends a low priority request to Bob.

> > 2) Bob replies with a high-priority marking in the response.

> > 3) Alice marks all future requests and responses in this dialog
high

> > priority.

> > 

> > --

> > Dean_______________________________________________

> 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
--=_alternative 000A788585257398_=--



--===============0243058488==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0243058488==--





From sip-bounces@ietf.org Sun Nov 18 21:30:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItwPG-0003Le-57; Sun, 18 Nov 2007 21:30:38 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItwPE-0003E0-Lh
	for sip-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 21:30:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItwPE-0003CX-AM; Sun, 18 Nov 2007 21:30:36 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ItwPA-0001BA-Bb; Sun, 18 Nov 2007 21:30:36 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 425C3328F0;
	Mon, 19 Nov 2007 02:30:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1ItwOg-0003n4-1Q; Sun, 18 Nov 2007 21:30:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Sun, 18 Nov 2007 21:30:02 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-media-security-requirements-01.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Requirements and Analysis of Media Security Management Protocols
	Author(s)       : D. Wing, et al.
	Filename        : draft-ietf-sip-media-security-requirements-01.txt
	Pages           : 44
	Date            : 2007-11-18

This documents describes requirements for a protocol to negotiate
security context for SIP-signaled SRTP media.  In addition to the
natural security requirements, this negotiation protocol must
interoperate well with SIP in certain ways.  A number of proposals
have been published and a summary of these proposals is in the
appendix of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements-01.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-media-security-requirements-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-media-security-requirements-01.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-18212521.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-media-security-requirements-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-media-security-requirements-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-18212521.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Sun Nov 18 21:41:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ItwZl-0008JA-TY; Sun, 18 Nov 2007 21:41:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1ItwZk-0008If-MA
	for sip-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 21:41:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwZj-0008AP-JK
	for sip@ietf.org; Sun, 18 Nov 2007 21:41:27 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItwZj-0006uf-4V
	for sip@ietf.org; Sun, 18 Nov 2007 21:41:27 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 18 Nov 2007 18:41:26 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAJ2fQx7009695
	for ; Sun, 18 Nov 2007 18:41:26 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAJ2fQGc029114
	for ; Mon, 19 Nov 2007 02:41:26 GMT
From: "Dan Wing" 
To: "SIP Working Group" 
Date: Sun, 18 Nov 2007 18:41:26 -0800
Message-ID: <035801c82a55$ae87a0d0$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcgqVa4xhA/wXXKURDysURysbAW1Ow==
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2707; t=1195440086;
	x=1196304086; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20media-security-requirements-01 |Sender:=20;
	bh=kUreakkcZgcyQpXEXcdRFTA5rDcqFEbj0YrsTbdPPq8=;
	b=TjAAvNHuh7MxlI6q31470RD7A+H8S2bpm3MOT2qAZ6bLgUYoeFwSwH8Wdn6t+uFacf/hDzEr
	5CSDtig145SZNNNWaIVtAVnexPZJbUXzo07fO4fGIHutLO5/ggCuzowv;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Subject: [Sip] media-security-requirements-01
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I just submitted draft-ietf-sip-media-security-requirements-01.  Changes from
-00 to -01 include:

  * Deleted R24 (which pertained to lawful intercept)
  * Categorized requirements (SIP Forking/Retargeting,
    security characteristics, performance consideration, 
    media considerations).
  * The text of several of the requirements was tightened
    up.
  * Additional justification was provided for several of
    the requirements.


In -01, I am aware of three outstanding issues:

1. Richard Barnes has suggested we remove R12, which is:

      R12:  The media security key management protocol 
            MUST NOT require 3rd parties to sign 
            certificates.

because no-one would be insane enough to design a 
protocol that required 3rd parties in order to
function.

Comments?


2. There has been some confusion regarding R15, and I don't 
know how to best resolve it.  R15 is:

      R15:  The media security key management protocol 
            SHOULD allow endpoints to start with RTP and 
            then upgrade to SRTP.
    
This has been interpreted differently by different people
and by different specifications.  In the document, I 
highlighted the different interpretations:

         Issue: Does this mean
         [I-D.ietf-mmusic-sdp-capability-negotiation] (which 
         overlaps with R1 and R2), allow RTP during early 
         media (and upgrade to SRTP when the SDP answer 
         arrives), or support an "Encrypt this call" 
         button on the phone?

I suggest splitting this requirement apart into those 
three parts:  MUST work with sdp-cap-neg, SHOULD allow
RTP early media with upgrade to SRTP, and SHOULD allow
upgrading from RTP to SRTP mid-call with a re-invite.  
Comments?


* Requirement R25 tries to describe the need for transcoders
to work with SRTP keying; however, I don't know how this would
actually be done except via Security Descriptions (where the
transcoder would just pretend to be the real endpoint, because
the transcoder has easy access to the SRTP key).  The current
text is:

      R25:  The media security key management protocol 
            MUST work when there are intermediate nodes 
            (e.g., transcoders), terminating or processing 
            media, between the end points.

Something like draft-wing-sipping-srtp-key could be helpful
to meet this requirement (so that the endpoint, which knows
it wants transcoding services, provides the transcoder with
the necessary keys).  However, this involves changes to call
flows and I don't know if anyone is yet willing/able to work
on such a call flow.

Comments on this requirement?

-d


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 01:58:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu0Zz-0004dm-58; Mon, 19 Nov 2007 01:57:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iu0Zx-0004dd-QB
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 01:57:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0Zx-0004dP-DU
	for sip@ietf.org; Mon, 19 Nov 2007 01:57:57 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu0Zv-0007a1-V6
	for sip@ietf.org; Mon, 19 Nov 2007 01:57:56 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	58C5A203BA; Mon, 19 Nov 2007 07:57:55 +0100 (CET)
X-AuditID: c1b4fb3e-af833bb0000007e1-a6-474133f342ac
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	3FFF420160; Mon, 19 Nov 2007 07:57:55 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 07:57:55 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
Date: Mon, 19 Nov 2007 07:57:54 +0100
Message-ID: 
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tA=
References: 
	<0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
From: "Christer Holmberg" 
To: "Elwell, John" , "sip" ,
	"Dan Wing" 
X-OriginalArrivalTime: 19 Nov 2007 06:57:55.0193 (UTC)
	FILETIME=[82AE4E90:01C82A79]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

A few comments/questions.

First, SBC/B2BUAs (as well as gates, as discussed in another thread)
normally don't open the media path until they have received an SDP
answer, so I hope you take that into consideration. Chapter 9 says that
entities must allow messages to be exchanged, but it doesn't say WHEN.

Second, regarding chapter 4.1 and the SIP header/header fields that you
use for the identity, it would be nice if you could add some words about
why it's "safe" to use these headers. Have you done a "SBC market
survey", or what do you base the these-headers-will-not-be-modified
assumption on?

Third, regarding chapter 9, if you are going to rely on an ICE based
mechanism in an environement with SBC/B2BUAs, I think you need to
describe HOW SBC/B2BUAs they are assumed to deal with ICE. As studies
done e.g. in 3GPP has shown (I am happy to discuss this with you more in
detail in off-line), it gets a little tricky when you also have media
proxy type-of-functionality in the SBC/B2BUA. ICE could even be
terminated by the SBC. Simply forwarding STUN messages unchanged will
cause problems with the relexive address information. (I don't know
whether this issue is valid also if you use tls, dtls and/or hip)

Regards,

Christer




=20

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]=20
> Sent: 17. marraskuuta 2007 20:24
> To: sip; Dan Wing
> Subject: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
>=20
> I think this is a very important draft. The problem it=20
> addresses is a very real problem that not only stops RFC=20
> 4474/4916 being deployed sensibly but also undermines the=20
> work on DTLS-SRTP.
>=20
> John=20
>=20
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: 15 November 2007 21:00
> > To: i-d-announce@ietf.org
> > Subject: I-D Action:draft-wing-sip-identity-media-01.txt
> >=20
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> > directories.
> >=20
> > 	Title           : SIP Identity using Media Path
> > 	Author(s)       : D. Wing, H. Kaplan
> > 	Filename        : draft-wing-sip-identity-media-01.txt
> > 	Pages           : 25
> > 	Date            : 2007-11-15
> >=20
> > The existing SIP identity mechanism (RFC4474) creates a=20
> signature over=20
> > the SIP body, including the entire SDP.  As part of their normal=20
> > operation, Session Border Controllers (SBCs) and SIP=20
> Back-to-Back User=20
> > Agents (B2BUAs) modify various fields in the SDP which breaks that=20
> > signature.
> >=20
> > This document defines a new identity mechanism which operates with=20
> > SBCs and B2BUAs.  This new identity mechanism creates a=20
> signature over=20
> > certain SIP headers and certain SDP lines, and uses both=20
> SIP signaling=20
> > and the media path to perform its identity function.
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-wing-sip-identity-me
> > dia-01.txt
> >=20
> > To remove yourself from the I-D Announcement list, send a=20
> message to=20
> > i-d-announce-request@ietf.org with the word unsubscribe in=20
> the body of=20
> > the message.
> > You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >=20
> > Internet-Drafts are also available by anonymous FTP. Login with the=20
> > username "anonymous" and a password of your e-mail address. After=20
> > logging in, type "cd internet-drafts" and then
> > 	"get draft-wing-sip-identity-media-01.txt".
> >=20
> > A list of Internet-Drafts directories can be found in=20
> > http://www.ietf.org/shadow.html or=20
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >=20
> > Internet-Drafts can also be obtained by e-mail.
> >=20
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE /internet-drafts/draft-wing-sip-identity-media-01.txt".
> >=20
> > NOTE:   The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >=20
> > Below is the data which will enable a MIME compliant mail reader=20
> > implementation to automatically retrieve the ASCII version of the=20
> > Internet-Draft.
> >=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 08:50:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu716-0003FI-NM; Mon, 19 Nov 2007 08:50:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iu70l-0002Nh-80
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:50:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu70k-0002NK-C2; Mon, 19 Nov 2007 08:50:02 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Iu70j-0008S9-VN; Mon, 19 Nov 2007 08:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DCDC32AC5E;
	Mon, 19 Nov 2007 13:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Iu70j-0004oO-KX; Mon, 19 Nov 2007 08:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Mon, 19 Nov 2007 08:50:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-outbound-11.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Managing Client Initiated Connections in the Session Initiation Protocol (SIP)
	Author(s)       : C. Jennings, R. Mahy
	Filename        : draft-ietf-sip-outbound-11.txt
	Pages           : 43
	Date            : 2007-11-19

The Session Initiation Protocol (SIP) allows proxy servers to
initiate TCP connections and send asynchronous UDP datagrams to User
Agents in order to deliver requests.  However, many practical
considerations, such as the existence of firewalls and Network
Address Translators (NATs), prevent servers from connecting to User
Agents in this way.  This specification defines behaviors for User
Agents, registrars and proxy servers that allow requests to be
delivered on existing connections established by the User Agent.  It
also defines keep alive behaviors needed to keep NAT bindings open
and specifies the usage of multiple connections from the User Agent
to its Registrar.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-11.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-outbound-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-outbound-11.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-19084019.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-outbound-11.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-outbound-11.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-19084019.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Mon Nov 19 11:01:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu934-0007hQ-TK; Mon, 19 Nov 2007 11:00:34 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iu932-0007fv-I9
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 11:00:32 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu932-0007eY-6f
	for sip@ietf.org; Mon, 19 Nov 2007 11:00:32 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu92z-0002cI-Lm
	for sip@ietf.org; Mon, 19 Nov 2007 11:00:30 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Mon, 19 Nov 2007 11:00:29 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Mon, 19 Nov 2007 11:00:23 -0500
From: Hadriel Kaplan 
To: Christer Holmberg , "Elwell, John"
	, sip , Dan Wing 
Date: Mon, 19 Nov 2007 10:59:03 -0500
Subject: RE: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
Thread-Topic: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tAAEmaLAA==
Message-ID: 
References: 
	<0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Monday, November 19, 2007 1:58 AM
> To: Elwell, John; sip; Dan Wing
> Subject: RE: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
>
>
> Hi,
>
> A few comments/questions.
>
> First, SBC/B2BUAs (as well as gates, as discussed in another thread)
> normally don't open the media path until they have received an SDP
> answer, so I hope you take that into consideration. Chapter 9 says that
> entities must allow messages to be exchanged, but it doesn't say WHEN.

That's Brian Stucker's draft. :)


> Second, regarding chapter 4.1 and the SIP header/header fields that you
> use for the identity, it would be nice if you could add some words about
> why it's "safe" to use these headers. Have you done a "SBC market
> survey", or what do you base the these-headers-will-not-be-modified
> assumption on?

I don't think we need to do a market survey.  SBCs can modify any header or=
 field, and even method.  That's not in debate.  What we're trying to do is=
 sign as few headers/fields as possible to increase the chances of it worki=
ng across SBCs, while at the same time providing strong identity.

The most contentious among these is undoubtedly the To/From addr-specs.  I =
know they get changed all the time.  That "works" when it's an E.164, as we=
 describe earlier in the draft, and the SBC changing those can re-sign the =
request with its own domain's cert without breaking rfc4474.  But it doesn'=
t work if the URIs are real email-style SIP-URIs.  In those cases the SBCs =
really can't change the domain portion, because it changes the fundamental =
identity of the caller/called.  If they do change it for such cases then th=
at's not a problem we need to deal with in the draft, I think?


> Third, regarding chapter 9, if you are going to rely on an ICE based
> mechanism in an environement with SBC/B2BUAs, I think you need to
> describe HOW SBC/B2BUAs they are assumed to deal with ICE. As studies
> done e.g. in 3GPP has shown (I am happy to discuss this with you more in
> detail in off-line), it gets a little tricky when you also have media
> proxy type-of-functionality in the SBC/B2BUA. ICE could even be
> terminated by the SBC. Simply forwarding STUN messages unchanged will
> cause problems with the relexive address information. (I don't know
> whether this issue is valid also if you use tls, dtls and/or hip)

I don't think we need to describe that because ICE is only one of the propo=
sed media-identity mechanisms?  ICE already says if a middle-box media rela=
y is detected (ie, if m=3D line does not match any candidate lines), ICE is=
 abandoned.  If an SBC wants to allow ICE it can do so by not relaying medi=
a (ie, not touching SDP) - but it could/would still change Contact/Call-id/=
etc. and thus would benefit from this draft.  If an SBC or any SIP hop want=
s to be ICE aware to such an extent as to become an ICE agent (ICE-lite or =
ICE-heavy), then it needs to understand STUN and not simply forward STUN me=
ssages unchanged, IMHO.  But I think the number of different things an SBC-=
type box could do given ICE is too big to tackle in this draft.  I mean wha=
t would we say?

I was not aware studies were done in 3GPP - it seemed like an obvious thing=
 to me that ICE doesn't work very well in media-relayed environments. ;)  S=
ome of the things media-relays do aren't solvable by an ICE approach (e.g.,=
 an SBC chooses a media address based on where the call gets routed to, whi=
ch could be one of numerous address spaces, and may or may not be the publi=
c Internet address space).

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 11:26:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu9Rx-0000mu-Ff; Mon, 19 Nov 2007 11:26:17 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iu9Rw-0000ml-5V
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 11:26:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9Rv-0000mZ-Eh
	for sip@ietf.org; Mon, 19 Nov 2007 11:26:15 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu9Rs-0006Cx-2p
	for sip@ietf.org; Mon, 19 Nov 2007 11:26:15 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAJGPrtX011281
	for ; Mon, 19 Nov 2007 10:26:11 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 10:25:25 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 17:25:23 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 19 Nov 2007 17:25:18 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019335E2@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-drage-sip-essential-correction-02.txt
Thread-Index: AcgqyMWjgoKp5mGCSXOwQwU3+HGWIQ==
From: "DRAGE, Keith \(Keith\)" 
To: "IETF SIP List" 
X-OriginalArrivalTime: 19 Nov 2007 16:25:23.0265 (UTC)
	FILETIME=[C8E9CB10:01C82AC8]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Subject: [Sip] draft-drage-sip-essential-correction-02.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I have submitted a new version of=20

http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction
-02.txt

This is the living document that provides the process for corrections to
the SIP RFCs.

I have added three things to the previous version:

-	a naming convention for drafts using this process, i.e. to
include "-fix" in the filename. This is being followed by many of the
drafts already.

-	a link to the web page giving details of the documents currently
in the process.

-	a new section for drafts to list the normative requirements
outside (and in addition to) the section structure documentation that is
already in the document. In doing this I have listed it as an open issue
and would welcome feedback as to whether this the correct wording or
not, or whether anything else needs to be stated.

Regards

Keith


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 11:36:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu9bi-0003CW-Cv; Mon, 19 Nov 2007 11:36:22 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iu9bg-0002q9-8f
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 11:36:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9bf-0002m3-PQ
	for sip@ietf.org; Mon, 19 Nov 2007 11:36:19 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Iu9bb-0007D1-HG for sip@ietf.org; Mon, 19 Nov 2007 11:36:19 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-1.cisco.com with ESMTP; 19 Nov 2007 08:36:15 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAJGaF1c029796
	for ; Mon, 19 Nov 2007 08:36:15 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAJGaE46008013
	for ; Mon, 19 Nov 2007 16:36:14 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 08:36:03 -0800
Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 08:36:03 -0800
Message-ID: <4741BB94.80202@cisco.com>
Date: Mon, 19 Nov 2007 11:36:36 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: IETF SIP List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Nov 2007 16:36:03.0470 (UTC)
	FILETIME=[468152E0:01C82ACA]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8752; t=1195490175;
	x=1196354175; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20; bh=DBC2DdL39zHTqThWrVkxFAtctOLM+LcwU8hXJLsRyZg=;
	b=MN7BnTe+TzXfIBQ+jG8q3wC46EDP8xWyWBU0SmxXeVBkrxFIo7sulvh88ArGrqyOgFimL2+4
	UGL9sxklH12e77ahDBToRuhtgDC4K47OQUtznpWFiu2XaddfbQwaQT/D;
Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Subject: [Sip] comments on draft-ietf-sip-dtls-framework
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I think there is an additional issue that should be discussed in the 
security considerations section.

The draft relies heavily on sip identity to provide integrity over the 
fingerprint. The underlying assumption is that a MITM downstream would 
need to modify the fingerprint and thus would also need to modify the 
identity since it couldn't resign with the original domain.

This assumption is a good one in deployments that use user@domain 
identifiers - joe@example.com. However, the unfortunate reality is that 
the majority of sip deployments today use phone numbers. These are often 
represented in sip URI form - sip:9739525060@example.com. However, when 
phone numbers are used, the domain part is often ignored and most of the 
time not even rendered to the user. Even if it were, its not a 
"significant" part of the identifier, in that a user won't normally know 
or care what the domain part is.

What this means is that when phone numbers are in use, a MITM can easily 
rewrite the From field. So if it was sip:9739525060@example.com they can 
rewrite to sip:9739525060@middle-domain.com, insert a media intermediary 
and new fingerprint and resign. The called UA or terminating proxy will 
verify that the identity is valid (which it is) and the called party is 
presented with the caller ID, which is JUST the phone number. So they 
don't notice a problem at all.

Thus, in practice, I fear dtls-srtp will easily allow proxies and SBCs 
on the chain to intercept and modify the media stream, similar to what 
they could do with sdescriptions. This is really a problem with sip 
identity itself that carries over here. But I think this issue needs to 
be mentioned and discussed. The draft makes itself out to be 
substantially more secure than sdescriptions or MIKEY because of its e2e 
nature but in practice I don't think it will be as effective.

Other minor comments:



> [RFC4572].  The Real-Time Protocol (RTP) [RFC3550] is used to
>    transmit real time media on top of UDP, TCP [RFC4571], and TLS
>    [RFC4572].


actually this isn't true; rfc4572 says it does not apply to RTP. From 
rfc4572:

    This document does not define any mechanism for securely transporting
    RTP and RTP Control Protocol (RTCP) packets over a
    connection-oriented channel.  There was no consensus in the working
    group as to whether it would be better to send Secure RTP packets
    [23] over a connection-oriented transport [24], or whether it would
    be better to send standard unsecured RTP packets over TLS using the
    mechanisms described in this document.  The group consensus was to
    wait until a use-case requiring secure connection-oriented RTP was
    presented.

> This draft provides guidelines on how to use and to
>    support for (a) transmission of media over DTLS and (b) to establish
>    SRTP security using extensions to DTLS (see
>    [I-D.ietf-avt-dtls-srtp]).

something is missing in this sentence. Maybe, "this draft provides 
guidelines on how to use and support DTLS for transmission of media and 
how to establish SRTP secureity using...."

> The media is transported over a mutually authenticated DTLS session
>    where both sides have certificates.  The certificate fingerprints are
>    sent in SDP over SIP as part of the offer/answer exchange.  The SIP
>    Identity mechanism [RFC4474] is used to provide integrity for the
>    fingerprints.  It is very important to note that certificates are
>    being used purely as a carrier for the public keys of the peers.
>    This is required because DTLS does not have a mode for carrying bare
>    keys, but it is purely an issue of formatting.  The certificates can
>    be self-signed and completely self-generated.  All major TLS stacks
>    have the capability to generate such certificates on demand.
>    However, third party certificates MAY also be used for extra
>    security.

suggest that the statements on self-signing get moved up to immediately 
after the first sentence. Otherwise, the reader is immediately confused, 
since most folks equate certificates with PKI, and the previous 
paragraph just said that no PKI is required.

> This approach differs from previous attempts to secure media traffic
>    where the authentication and key exchange protocol (e.g., MIKEY
>    [RFC3830]) is piggybacked in the signaling message exchange.  With
>    this approach, establishing the protection of the media traffic
>    between the endpoints is done by the media endpoints without
>    involving the SIP/SDP communication.

should be clear that "this appraoch" is referring to dtls-srtp and NOT 
mikey/sdesciptions. Also you might want to include a reference to 
sdescriptions here also.


Figure 1: the figure shows bidirectional arrows between elements, but 
the notations around authentication information indicate that this is 
really talking about an initial INVITE from alice to bob. Suggest that 
the arrows face right only in this flow.

Also, I think using the term, "signaling traffic" for the dtls handshake 
is confusing. Since folks equate, "signaling traffic" with sip. Suggest 
using a different term, perhaps "key management traffic" and use a 
different line style.

> Alice sends an SDP offer to Bob over SIP.  If Alice uses only self-
>    signed certificates for the communication with Bob, a fingerprint is
>    included in the SDP offer/answer exchange.  This fingerprint is
>    integrity protected using the identity mechanism defined in
>    Enhancements for Authenticated Identity Management in SIP [RFC4474].
>    When Bob receives the offer, Bob establishes a mutually authenticated
>    DTLS connection with Alice.  At this point Bob can begin sending
>    media to Alice.  Once Bob accepts Alice's offer and sends an SDP
>    answer to Alice, Alice can begin sending confidential media to Bob.


this is lacking from an overview of operations perspective. I suggest 
also mentioning that alice and bob will verify the fingerprints from the 
certs received over the dtls handshakes with those in the sip signaling, 
providing a correlation function. Mention that this provides the 
security property that you know your media traffic is going to the 
person you called, without necessarily providing a secure version of the 
identity of that person. This is the key idea of dtls-srtp that needs to 
be in here.

> DTLS/TLS uses the term "session" to refer to a long-lived set of
>    keying material that spans associations.  In this document,
>    consistent with SIP/SDP usage, we use it to refer to a multimedia
>    session and use the term "TLS session" to refer to the TLS construct.
>    We use the term "association" to refer to a particular DTLS
>    ciphersuite and keying material set. 

association and session both claim to use a single keying set. So its 
not clear what the difference is. Maybe associations use keys derived 
from the session keys? SHould clarify here.

> 6.1.  Anonymous Calls
> 
>    When making anonymous calls, a new self-signed certificate SHOULD be
>    used for each call so that the calls can not be correlated as to
>    being from the same caller.  

this is not even close to sufficient for anonymity. The IP address will 
be the same. So this needs to be called out that this is just referring 
to the DTLS part or else the rest of anonymity needs to be defined.

>  Note that in the situation where a request forks to multiple
>    endpoints that all share the same certificate, there is no way for
>    the caller to correlate the DTLS associations with the SIP dialogs.
>    Practically, this is not a problem, since the callees will terminate
>    the unused associations.

the issue isn't just which ones to keep; its correlating for UI 
purposes. For example, talking indicators or media hold. Each side needs 
to know which stream is associated with each dialog. Isn't a better 
solution to just have a unique certificate per device? Or else rely on 
something else for correlation (i.e., ice).

Indeed the draft should call out that when ice is used, ice itself will 
provide this correlation and it happens even prior to the start of dtls.

> be able to demultiplex STUN packets from DTLS packets.  STUN
>    [RFC3489] packets MUST NOT be sent over DTLS.

should reference 3489bis.



Thanks,
Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 11:55:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu9uP-0004ot-7M; Mon, 19 Nov 2007 11:55:41 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iu9uN-0004hm-Pv
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 11:55:39 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu9uN-0004ff-F2; Mon, 19 Nov 2007 11:55:39 -0500
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Iu9uN-0007mR-4a; Mon, 19 Nov 2007 11:55:39 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C8D29175BF;
	Mon, 19 Nov 2007 16:55:38 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Iu9uM-0000Dx-BV; Mon, 19 Nov 2007 11:55:38 -0500
X-test-idtracker: no
To: IETF-Announce 
From: The IESG 
Message-Id: 
Date: Mon, 19 Nov 2007 11:55:38 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: sip@ietf.org
Subject: [Sip] Last Call: draft-ietf-sip-multiple-refer (Referring to
 Multiple 
 Resources in the Session Initiation Protocol (SIP)) to Proposed 
 Standard 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

The IESG has received a request from the Session Initiation Protocol WG 
(sip) to consider the following documents:

- 'A Framework for Consent-based Communications in the Session Initiation
 
   Protocol (SIP) '
    as a Proposed Standard
- 'Referring to Multiple Resources in the Session Initiation Protocol 
   (SIP) '
    as a Proposed Standard
- 'Subscriptions to Request-Contained Resource Lists in the Session 
   Initiation Protocol (SIP) '
    as a Proposed Standard
- 'Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol

   (SIP) '
    as a Proposed Standard
- 'Conference Establishment Using Request-Contained Lists in the Session 
   Initiation Protocol (SIP) '
    as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2007-12-10. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-multiple-refer-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-subscribe-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-message-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-conferencing-02.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15182&rfc_flag=0



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 12:16:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuADZ-0004hf-Oq; Mon, 19 Nov 2007 12:15:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuADB-00041Y-Mw
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 12:15:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuADB-000415-6r; Mon, 19 Nov 2007 12:15:05 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IuADA-0002Tr-Dh; Mon, 19 Nov 2007 12:15:05 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AB8D0327C5;
	Mon, 19 Nov 2007 17:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IuAD8-0002oM-4l; Mon, 19 Nov 2007 12:15:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Mon, 19 Nov 2007 12:15:02 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-09.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Location Conveyance for the Session Initiation Protocol
	Author(s)	: J. Polk, B. Rosen
	Filename	: draft-ietf-sip-location-conveyance-09.txt
	Pages		: 43
	Date		: 2007-11-19
	
This document defines an extension to the Session Initiation 
   Protocol (SIP) to convey geographic location information from one 
   SIP entity to another SIP entity.  The extension covers end to end 
   conveyance as well as location-based routing, where proxy servers 
   make routing decisions based on the location of the SIP user agents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-09.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sip-location-conveyance-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-location-conveyance-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-19112843.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-location-conveyance-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-location-conveyance-09.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-19112843.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--






From sip-bounces@ietf.org Mon Nov 19 12:26:01 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuANj-0000QG-1Q; Mon, 19 Nov 2007 12:25:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuANh-0000Q1-8x
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 12:25:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuANg-0000Po-FX
	for sip@ietf.org; Mon, 19 Nov 2007 12:25:56 -0500
Received: from [74.95.2.169] (helo=delta.rtfm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuANf-00038x-Dp
	for sip@ietf.org; Mon, 19 Nov 2007 12:25:56 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 917BD33C2B;
	Mon, 19 Nov 2007 09:20:58 -0800 (PST)
Date: Mon, 19 Nov 2007 09:20:57 -0800
From: Eric Rescorla 
To: Jonathan Rosenberg 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
In-Reply-To: <4741BB94.80202@cisco.com>
References: <4741BB94.80202@cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071119172058.917BD33C2B@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At Mon, 19 Nov 2007 11:36:36 -0500,
Jonathan Rosenberg wrote:
> 
> I think there is an additional issue that should be discussed in the 
> security considerations section.
> 
> The draft relies heavily on sip identity to provide integrity over the 
> fingerprint. The underlying assumption is that a MITM downstream would 
> need to modify the fingerprint and thus would also need to modify the 
> identity since it couldn't resign with the original domain.
> 
> This assumption is a good one in deployments that use user@domain 
> identifiers - joe@example.com. However, the unfortunate reality is that 
> the majority of sip deployments today use phone numbers. These are often 
> represented in sip URI form - sip:9739525060@example.com. However, when 
> phone numbers are used, the domain part is often ignored and most of the 
> time not even rendered to the user. Even if it were, its not a 
> "significant" part of the identifier, in that a user won't normally know 
> or care what the domain part is.
> 
> What this means is that when phone numbers are in use, a MITM can easily 
> rewrite the From field. So if it was sip:9739525060@example.com they can 
> rewrite to sip:9739525060@middle-domain.com, insert a media intermediary 
> and new fingerprint and resign. The called UA or terminating proxy will 
> verify that the identity is valid (which it is) and the called party is 
> presented with the caller ID, which is JUST the phone number. So they 
> don't notice a problem at all.
> 
> Thus, in practice, I fear dtls-srtp will easily allow proxies and SBCs 
> on the chain to intercept and modify the media stream, similar to what 
> they could do with sdescriptions. This is really a problem with sip 
> identity itself that carries over here. But I think this issue needs to 
> be mentioned and discussed.

I don't know enough about implementations to know if this is correct,
so let's stipulate that it is. Fundamentally, this is a SIP problem
and not a DTLS-SRTP problem. Not knowing who the signally refers
to isn't any better just because you don't bother to encrypt the
media.

That said, I don't think this is as bad as you make it out to
be in terms of MITM. The calling party knows the URI and can
(and must) mechanically enforce the URI match that the callee
presents, including the domain name.  This prevents MITM
attacks. Impersonation attacks on the called party remain,
but this can't be solved without actually presenting all
the relevant identity information to the user, regardless of
what the media security layer does.



> The draft makes itself out to be 
> substantially more secure than sdescriptions or MIKEY because of its e2e 
> nature but in practice I don't think it will be as effective.

I don't understand this sentence. SDESCRIPTIONS doesn't even require
an active attack on the connection and MIKEY has exactly the same
issue unless you verify the certs, which of course you *can* do with
DTLS-SRTP.


> > DTLS/TLS uses the term "session" to refer to a long-lived set of
> >    keying material that spans associations.  In this document,
> >    consistent with SIP/SDP usage, we use it to refer to a multimedia
> >    session and use the term "TLS session" to refer to the TLS construct.
> >    We use the term "association" to refer to a particular DTLS
> >    ciphersuite and keying material set. 
> 
> association and session both claim to use a single keying set. So its 
> not clear what the difference is. Maybe associations use keys derived 
> from the session keys? SHould clarify here.

There's no such thing as a session key in TLS. A session is the
master_secret. The association refers to the traffic keys.


> > 6.1.  Anonymous Calls
> > 
> >    When making anonymous calls, a new self-signed certificate SHOULD be
> >    used for each call so that the calls can not be correlated as to
> >    being from the same caller.  
> 
> this is not even close to sufficient for anonymity.

Of course not. It's sufficient to stop DTLS from screwing up otherwise
working anonymity.


> The IP address will 
> be the same. So this needs to be called out that this is just referring 
> to the DTLS part or else the rest of anonymity needs to be defined.
> 
> >  Note that in the situation where a request forks to multiple
> >    endpoints that all share the same certificate, there is no way for
> >    the caller to correlate the DTLS associations with the SIP dialogs.
> >    Practically, this is not a problem, since the callees will terminate
> >    the unused associations.
> 
> the issue isn't just which ones to keep; its correlating for UI 
> purposes. For example, talking indicators or media hold. Each side needs 
> to know which stream is associated with each dialog. Isn't a better 
> solution to just have a unique certificate per device?

Not necessarily, no.


> Or else rely on 
> something else for correlation (i.e., ice).
>
> Indeed the draft should call out that when ice is used, ice itself will 
> provide this correlation and it happens even prior to the start of dtls.

Yes.

-Ekr


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 13:22:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuBGf-0004Fq-4A; Mon, 19 Nov 2007 13:22:45 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuBGd-0004Fe-4k
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:22:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBGc-0004FV-RA
	for sip@ietf.org; Mon, 19 Nov 2007 13:22:42 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBGZ-0000tJ-8G
	for sip@ietf.org; Mon, 19 Nov 2007 13:22:42 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAJIMb3h022228; 
	Mon, 19 Nov 2007 12:22:37 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAJIMUj16456; Mon, 19 Nov 2007 12:22:37 -0600 (CST)
Message-ID: <4741D466.3080608@alcatel-lucent.com>
Date: Mon, 19 Nov 2007 12:22:30 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>	<200711112208.lABM8xh5016388@dragon.ariadne.com>	<473DCE36.8070105@lucent.com>	<200711161811.lAGIB6FL007091@dragon.ariadne.com>
	
	<473E020F.2000908@alcatel-lucent.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hadriel Kaplan wrote:
>> The subtle difference here -- unlike in HTTP -- is that there are
>> requests coming towards the client from the server.  In HTTP, the
[...]
> Right, but that's why I say it's the same thing as TCP persistent
> connections in this draft.  You're not allowing upstream requests
> over TCP, only over TLS.  You're saying keep the TCP connection from
> the client to the server open, and send subsequent requests over it
> in the downstream direction (client->server).  Requests going the
> other direction are sent over a TCP client->server connection from
> the other side.  In that way it's exactly like HTTP/1.1.

OK; we are in vehement agreement, then.

> Sure, but it doesn't solve it.  Persistent connections were always
> possible, so even if this new draft says to do it by default, the
> server has no way to know it is or isn't being done, and the client
> has no way to be told to do it. (not that I'm advocating that be done
> mind you)

It is true what you write above; i.e., in SIP, the server has no way
of knowing whether the client is using persistent connections or not,
and the client has no way of signaling its intent (unlike in HTTP,
where the signaling makes this clear.)

However, as an implementor, there is some ambiguity in rfc3261 about
how long to keep connections open.  S18 is where this information
is concentrated, and it basically recommends implementations keep
connections open for at least (T1*64)s.  And I have observed wide
variability around this: some implementations close connections
after (T1*64)s, some keep them open for longer, while others even
open up a new TCP connection to send a response (and then promptly
close it.)  So, one aspect connect-reuse was trying to establish
was to establish a default behavior so that the connection stays
open for as long as possible; certainly beyond (64*T1)s, and in
fact, as long as the resources on a machine allow that connection
to remain open.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 13:23:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuBH2-0004aF-4P; Mon, 19 Nov 2007 13:23:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuBH0-0004Vm-PN
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:23:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBH0-0004V4-Ee
	for sip@ietf.org; Mon, 19 Nov 2007 13:23:06 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBGw-0000vB-5A
	for sip@ietf.org; Mon, 19 Nov 2007 13:23:06 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAJIMoV9022496; 
	Mon, 19 Nov 2007 12:22:50 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAJIMoj16573; Mon, 19 Nov 2007 12:22:50 -0600 (CST)
Message-ID: <4741D47A.4020502@alcatel-lucent.com>
Date: Mon, 19 Nov 2007 12:22:50 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hadriel Kaplan wrote:
>> ... would that be an acceptable compromise?
> 
> Sure.

OK; good.

> BTW, out of curiosity, I thought at some point in the past there was
> an email saying that for UA's, sip-outbound would be the only draft
> for explicit connect-reuse behavior.  So that this draft was really
> for proxies, not UA's.  Not true? (not that such use would be
> enforced in any way, just that the focus had changed)

True, after outbound came into the picture, connect-reuse has
been relegated mostly to proxies.  Although, as Dale accurately
observed, the draft tends "to discuss multiple user agents and proxies,
when the entirety of the mechanism can be described by considering
only the two SIP agents at the ends of the connection."

We could nail a line in the sand and make this more concrete (i.e.,
use between proxies only.)  Or we could take a middle road and allow
implementors who have reflective connectivity between a UA and a
(proxy) server use connect-reuse.  So far, the draft has been taking
the middle road.

Thoughts?

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 13:23:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuBHK-0005Al-D1; Mon, 19 Nov 2007 13:23:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuBHJ-0005A2-2n
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:23:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBHI-00059A-Ll
	for sip@ietf.org; Mon, 19 Nov 2007 13:23:24 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuBHI-0007tF-7b
	for sip@ietf.org; Mon, 19 Nov 2007 13:23:24 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAJIMlBg022456; 
	Mon, 19 Nov 2007 12:22:48 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAJIMej16528; Mon, 19 Nov 2007 12:22:40 -0600 (CST)
Message-ID: <4741D470.6030308@alcatel-lucent.com>
Date: Mon, 19 Nov 2007 12:22:40 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hadriel Kaplan wrote:
> I wouldn't. :)  It is no more "authenticated" than if the remote end
> opened a connection using an ephemeral port to the local host's
> listen port.  The local host client knows little about the validity
> of the remote end.  Actually, the client knows slightly more about
> the validity of a connection it opened to the far-end than the other
> way-around, especially if it did single-sided TLS to the far-end, so
> in that sense it makes more sense to accept requests over its client
> socket than over the listen port.  It just doesn't make much sense
> for the remote end to send them over it, unless it can authenticate
> (e.g., using digest).  And that's the rub.  Today certain types of
> devices fix NAT traversal for SIP/TCP or SIP/TLS without needing the
> client to do sip-outbound, so long as the client can accept requests
> over its persistent connection, because they can authenticate the
> client.  It's worked so far, anyway.  But this new MUST would break
> it.

Hadriel: So essentially you are arguing for one of the following
positions (assume A makes an active TCP connection to B to send a
request downstream):

   1) Allow B to send requests upstream (to A) as long as A can
    authenticate B, possibly using HTTP Digest (although how we
    will do so if A and B are proxies is an open question.)
   2) Downgrade the strength of S8.1 to something like the following:
    OLD:
     It MUST only accept responses over this connection and MUST NOT
     accept any requests over this connection.
    NEW:
     It accepts responses over this connection, but SHOULD NOT accept
     any requests.

Is that an accurate representation of your concern?  Given that the
problem of using HTTP Digest between proxies is a complete new
can of worms, the downgrade option seems more attractive.  Would be
nice to hear other opinions.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 13:32:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuBQ1-0004Ao-Tq; Mon, 19 Nov 2007 13:32:25 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuBPz-00047h-Pt
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:32:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBPz-00047U-Fg
	for sip@ietf.org; Mon, 19 Nov 2007 13:32:23 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuBPz-0000HT-2l
	for sip@ietf.org; Mon, 19 Nov 2007 13:32:23 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAJIWK61003640
	for ; Mon, 19 Nov 2007 12:32:20 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAJIWKj21221; Mon, 19 Nov 2007 12:32:20 -0600 (CST)
Message-ID: <4741D6B3.2040801@alcatel-lucent.com>
Date: Mon, 19 Nov 2007 12:32:19 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "DRAGE, Keith \(Keith\)" 
Subject: Re: [Sip] draft-drage-sip-essential-correction-02.txt
References: <5D1A7985295922448D5550C94DE29180019335E2@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180019335E2@DEEXC1U01.de.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

DRAGE, Keith (Keith) wrote:
> I have submitted a new version of 
> 
> http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction
> -02.txt
[...]
> -	a link to the web page giving details of the documents currently
> in the process.

Keith: Would the SIP ABNF IPv6 fix draft qualify?
   (http://tools.ietf.org/html/draft-gurbani-sip-ipv6-abnf-fix-00)
Need to discuss this in WG.

> -	a new section for drafts to list the normative requirements
> outside (and in addition to) the section structure documentation that is
> already in the document. In doing this I have listed it as an open issue
> and would welcome feedback as to whether this the correct wording or
> not, or whether anything else needs to be stated.

The template you give essentially follows the sections enumerated
in http://tools.ietf.org/html/draft-sparks-sip-invfix-00.  As a
means of codifying information, it seems reasonable.  Also, if
you eyeball the three other -fix drafts besides invfix-00 (i.e.,
http://tools.ietf.org/html/draft-ietf-sip-record-route-fix,
http://tools.ietf.org/html/draft-ietf-sip-fork-loop-fix, and
http://tools.ietf.org/html/draft-gurbani-sip-ipv6-abnf-fix-00)
they essentially follow the same template anyway.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 13:50:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuBgo-0007Lj-PL; Mon, 19 Nov 2007 13:49:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuBgl-0007L2-G6
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:49:43 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBgl-0007JX-4w
	for sip@ietf.org; Mon, 19 Nov 2007 13:49:43 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuBgi-0002IY-Oc
	for sip@ietf.org; Mon, 19 Nov 2007 13:49:41 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Mon, 19 Nov 2007 13:49:40 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Mon, 19 Nov 2007 13:49:40 -0500
From: Hadriel Kaplan 
To: Eric Rescorla , Jonathan Rosenberg
	
Date: Mon, 19 Nov 2007 13:48:23 -0500
Subject: RE: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Topic: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Index: Acgq0UOZy7hInuw6Q86VUcRtrD/NmAAA02ag
Message-ID: 
References: <4741BB94.80202@cisco.com>
	<20071119172058.917BD33C2B@delta.rtfm.com>
In-Reply-To: <20071119172058.917BD33C2B@delta.rtfm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]
> Sent: Monday, November 19, 2007 12:21 PM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
>
> At Mon, 19 Nov 2007 11:36:36 -0500,
> Jonathan Rosenberg wrote:
> >
> > Thus, in practice, I fear dtls-srtp will easily allow proxies and SBCs
> > on the chain to intercept and modify the media stream, similar to what
> > they could do with sdescriptions. This is really a problem with sip
> > identity itself that carries over here. But I think this issue needs to
> > be mentioned and discussed.
>
> I don't know enough about implementations to know if this is correct,
> so let's stipulate that it is. Fundamentally, this is a SIP problem
> and not a DTLS-SRTP problem. Not knowing who the signally refers
> to isn't any better just because you don't bother to encrypt the
> media.
>
> That said, I don't think this is as bad as you make it out to
> be in terms of MITM. The calling party knows the URI and can
> (and must) mechanically enforce the URI match that the callee
> presents, including the domain name.  This prevents MITM
> attacks. Impersonation attacks on the called party remain,
> but this can't be solved without actually presenting all
> the relevant identity information to the user, regardless of
> what the media security layer does.

I thought DTLS-SRTP was going to recommend the end users read out the finge=
rprint (or some section thereof), similar to the SAS model for ZRTP, no?  T=
hat is the only thing guaranteeing a middle-man hadn't done what Jonathan's=
 worried about.  I thought it was well understood a middle-box could do thi=
s even with 4474; at least we talked about it in the context of ZRTP.  And =
this isn't just URI-changing hops - if the identity signer or verifier doma=
in providers want to change the fingerprint+sdp and get cleartext, they can=
.  Human verification of the fingerprint is the only thing that would stop =
it. (and then only until real-time voice-spoofing becomes good enough)  No?

-hadriel


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 14:07:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuBxV-0002rp-Kf; Mon, 19 Nov 2007 14:07:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuBxU-0002rQ-Jq
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:07:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBxU-0002qv-A4
	for sip@ietf.org; Mon, 19 Nov 2007 14:07:00 -0500
Received: from [74.95.2.169] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBxR-0005R6-0s
	for sip@ietf.org; Mon, 19 Nov 2007 14:07:00 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 03F9433C2B;
	Mon, 19 Nov 2007 11:01:56 -0800 (PST)
Date: Mon, 19 Nov 2007 11:01:56 -0800
From: Eric Rescorla 
To: Hadriel Kaplan 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
In-Reply-To: 
References: <4741BB94.80202@cisco.com>
	<20071119172058.917BD33C2B@delta.rtfm.com>
	
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071119190157.03F9433C2B@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At Mon, 19 Nov 2007 13:48:23 -0500,
Hadriel Kaplan wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Eric Rescorla [mailto:ekr@networkresonance.com]
> > Sent: Monday, November 19, 2007 12:21 PM
> > To: Jonathan Rosenberg
> > Cc: IETF SIP List
> > Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
> >
> > At Mon, 19 Nov 2007 11:36:36 -0500,
> > Jonathan Rosenberg wrote:
> > >
> > > Thus, in practice, I fear dtls-srtp will easily allow proxies and SBCs
> > > on the chain to intercept and modify the media stream, similar to what
> > > they could do with sdescriptions. This is really a problem with sip
> > > identity itself that carries over here. But I think this issue needs to
> > > be mentioned and discussed.
> >
> > I don't know enough about implementations to know if this is correct,
> > so let's stipulate that it is. Fundamentally, this is a SIP problem
> > and not a DTLS-SRTP problem. Not knowing who the signally refers
> > to isn't any better just because you don't bother to encrypt the
> > media.
> >
> > That said, I don't think this is as bad as you make it out to
> > be in terms of MITM. The calling party knows the URI and can
> > (and must) mechanically enforce the URI match that the callee
> > presents, including the domain name.  This prevents MITM
> > attacks. Impersonation attacks on the called party remain,
> > but this can't be solved without actually presenting all
> > the relevant identity information to the user, regardless of
> > what the media security layer does.
> 
> I thought DTLS-SRTP was going to recommend the end users read out
> the fingerprint (or some section thereof), similar to the SAS model
> for ZRTP, no? 

No. That's impractical and insecure for reasons I indicated in my
presentation in Prague.


> That is the only thing guaranteeing a middle-man
> hadn't done what Jonathan's worried about.  I thought it was well
> understood a middle-box could do this even with 4474; at least we
> talked about it in the context of ZRTP.  And this isn't just
> URI-changing hops - if the identity signer or verifier domain
> providers want to change the fingerprint+sdp and get cleartext, they
> can.

Yes, as Jon Peterson observed in another context, the identity
signer, not you, owns your identity. They can do whatever they
want. If you're concerned about your identity provider mounting
a MITM attack on you, you either need:

1. A new identity provider.
2. To use third-party certificates as a backup.
3. Out-of-band verification of the peer's certificate fingerprint.

-Ekr


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 14:15:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuC5P-0006mF-92; Mon, 19 Nov 2007 14:15:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuC5H-0006Ly-9P
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:15:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuC5G-0006Jq-Ox; Mon, 19 Nov 2007 14:15:02 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IuC5G-0005xh-6O; Mon, 19 Nov 2007 14:15:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D4FA126E4D;
	Mon, 19 Nov 2007 19:15:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IuC5F-00009v-NX; Mon, 19 Nov 2007 14:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Mon, 19 Nov 2007 14:15:01 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-rph-new-namespaces-01.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Header Namespaces
	Author(s)	: J. Polk
	Filename	: draft-ietf-sip-rph-new-namespaces-01.txt
	Pages		: 12
	Date		: 2007-11-19
	
This document creates additional Session Initiation Protocol 
   Resource-Priority header namespaces, to be IANA registered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sip-rph-new-namespaces-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-rph-new-namespaces-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-19132201.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-rph-new-namespaces-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-rph-new-namespaces-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-19132201.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--






From sip-bounces@ietf.org Mon Nov 19 14:40:18 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuCT8-0006UB-JL; Mon, 19 Nov 2007 14:39:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuCT6-0006TV-Uf
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:39:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCT6-0006TE-KG
	for sip@ietf.org; Mon, 19 Nov 2007 14:39:40 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCT4-00089K-27
	for sip@ietf.org; Mon, 19 Nov 2007 14:39:40 -0500
Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net
	[70.242.127.246]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJJcHln051374
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Nov 2007 13:38:18 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <4741E624.9010805@nostrum.com>
Date: Mon, 19 Nov 2007 13:38:12 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] SIP IPv6 ABNF: Essential correction to RFC3261
References: <4730C66F.2070803@alcatel-lucent.com>
In-Reply-To: <4730C66F.2070803@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4845/Mon Nov 19 10:54:29 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: IETF SIP List ,
	Brian E Carpenter 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

For the record: this seems to be a real problem in the original ABNF, 
and the proposed fix appears correct to me. I support adding this to the 
next batch of essential corrections.

/a

Vijay K. Gurbani wrote:
> Folks: While performing the Gen-ART review of the
> draft-ietf-sipping-ipv6-torture-test document, an extant bug in
> the IPv6 ABNF production rules of RFC3261 was discovered.
>
> A quick dialog with the chairs resulted in the understanding
> that this could potentially be fixed as part of the SIP essential
> corrections process, once it was ratified by the WG.
>
> Brian and I have submitted a short draft describing this bug and
> its resolution to the IETF.  Until it appears in the archives, you
> can get a copy from
> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/draft-gurbani-sip-ipv6-abnf-fix-00.txt 
>
> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/draft-gurbani-sip-ipv6-abnf-fix-00.html 
>
>
> Thanks.
>
> - vijay



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 14:40:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuCUI-0007Xc-Rs; Mon, 19 Nov 2007 14:40:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuCUH-0007XN-6w
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:40:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCUG-0007XB-S3
	for sip@ietf.org; Mon, 19 Nov 2007 14:40:52 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuCUG-0006u3-15
	for sip@ietf.org; Mon, 19 Nov 2007 14:40:52 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	78AD6207D1; Mon, 19 Nov 2007 20:40:51 +0100 (CET)
X-AuditID: c1b4fb3c-aee18bb000002c9b-38-4741e6c38753
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	542D6206AB; Mon, 19 Nov 2007 20:40:51 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:40:51 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
Date: Mon, 19 Nov 2007 20:40:50 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tAAEmaLAAAIfvRJ
References: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
	
	
From: "Christer Holmberg" 
To: "Hadriel Kaplan" ,
	"Elwell, John" , "sip" ,
	"Dan Wing" 
X-OriginalArrivalTime: 19 Nov 2007 19:40:51.0288 (UTC)
	FILETIME=[175C1580:01C82AE4]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,
=20
>>First, SBC/B2BUAs (as well as gates, as discussed in another thread)
>>normally don't open the media path until they have received an SDP
>>answer, so I hope you take that into consideration. Chapter 9 says =
that
>>entities must allow messages to be exchanged, but it doesn't say WHEN.
>
>That's Brian Stucker's draft. :)

Ok, but are you assuming some specific outcome of that draft?

Also, I am not sure whether Brian's draft covers B2BUAs, eventhough I =
guess much of the gate issues also apply to B2BUAs.

>> Second, regarding chapter 4.1 and the SIP header/header fields that =
you
>> use for the identity, it would be nice if you could add some words =
about
>> why it's "safe" to use these headers. Have you done a "SBC market
>> survey", or what do you base the these-headers-will-not-be-modified
>> assumption on?
>
>I don't think we need to do a market survey.  SBCs can modify any =
header or field, and even method.  That's not in debate.  What we're =
trying to do is sign as few headers/fields as possible to increase the =
chances of it working >across SBCs, while at the same time providing =
strong identity.
>
>The most contentious among these is undoubtedly the To/From addr-specs. =


I agree, but I think the Date header could potentially also be an issue. =
For example, what happens if the UAC does not insert a Date header, but =
it is then inserted by an intermediate? How will the UAS know?

>I know they get changed all the time.  That "works" when it's an E.164, =
as we describe earlier in the draft, and the SBC changing those can =
re-sign the request with its own domain's cert without breaking rfc4474. =
 But it doesn't work >if the URIs are real email-style SIP-URIs.  In =
those cases the SBCs really can't change the domain portion, because it =
changes the fundamental identity of the caller/called.  If they do =
change it for such cases then that's not a >problem we need to deal with =
in the draft, I think?

Need to think a little more...


>> Third, regarding chapter 9, if you are going to rely on an ICE based
>> mechanism in an environement with SBC/B2BUAs, I think you need to
>> describe HOW SBC/B2BUAs they are assumed to deal with ICE. As studies
>> done e.g. in 3GPP has shown (I am happy to discuss this with you more =
in
>> detail in off-line), it gets a little tricky when you also have media
>> proxy type-of-functionality in the SBC/B2BUA. ICE could even be
>> terminated by the SBC. Simply forwarding STUN messages unchanged will
>> cause problems with the relexive address information. (I don't know
>> whether this issue is valid also if you use tls, dtls and/or hip)
>I don't think we need to describe that because ICE is only one of the =
proposed media-identity mechanisms?  ICE already says if a middle-box =
media relay is detected (ie, if m=3D line does not match any candidate =
lines), ICE is >abandoned.

Yes. But, I am talking of middle boxes which actually are able to =
process ICE in a way so that it is not abandoned.

> If an SBC wants to allow ICE it can do so by not relaying media (ie, =
not touching SDP)=20

There can be many reasons why an SBC wants to relay media, so you can't =
assume they will choose not to just because there is ICE...

>- but it could/would still change Contact/Call-id/etc. and thus would =
benefit from this draft.  If an SBC or any SIP hop wants to be ICE aware =
to such an extent as to become an ICE agent (ICE-lite or ICE-heavy), =
then it needs to >understand STUN and not simply forward STUN messages =
unchanged, IMHO.  But I think the number of different things an SBC-type =
box could do given ICE is too big to tackle in this draft.  I mean what =
would we say?

In one of the solution (which also seems to be the most preferable) =
studied in 3GPP the SBC will understand STUN. But, it will not forward =
STUN messages, but instead establish separate ICE sessions in each =
"direction". From a UA perspective it will look like end-to-end ICE, but =
it isn't. So, whatever information the UA sends in the STUN message will =
not reach the other UA.

>I was not aware studies were done in 3GPP=20
>
>- it seemed like an obvious thing to me that ICE doesn't work very well =
in media-relayed environments. ;)

I believe it is possible to make it work, but it assumes that SBCs (at =
least those relaying media) are ICE- and STUN aware.

Regards,

Christer

=20



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 14:49:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuCca-000651-IX; Mon, 19 Nov 2007 14:49:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuCcY-000644-Pm
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:49:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCcY-00063w-GB
	for sip@ietf.org; Mon, 19 Nov 2007 14:49:26 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCcU-0000Ca-8s
	for sip@ietf.org; Mon, 19 Nov 2007 14:49:26 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	BEEE4201DE; Mon, 19 Nov 2007 20:49:21 +0100 (CET)
X-AuditID: c1b4fb3e-b0835bb0000007e1-98-4741e8c1c736
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	A2D482009F; Mon, 19 Nov 2007 20:49:21 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:49:21 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Status of require headers in the re-INVITE request.
Date: Mon, 19 Nov 2007 20:45:42 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Status of require headers in the re-INVITE request.
Thread-Index: AcgoexQ0HjYaGBQbTSqjsWyq1b4EBACabB86
References: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>
	<473DDB80.8060507@cisco.com>
From: "Christer Holmberg" 
To: "Paul Kyzivat" ,
	
X-OriginalArrivalTime: 19 Nov 2007 19:49:21.0569 (UTC)
	FILETIME=[4782C910:01C82AE5]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,
=20
I think this discussion touches on an issue, which I know has caused =
some interop concerns:
=20
Is the Supported/Require header only transaction specific, or is it =
dialog specific?
=20
If it is dialog specific, I would say that you don't need to include =
anything in the re-INVITE, if it was already included in the INVITE. =
But, then it would also mean that whatever you indicated in the INVITE =
(e.g. 100rel) is also valid for the re-INVITE.
=20
Regards,
=20
Christer

________________________________

From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Fri 16/11/2007 19:03
To: nataraju.basavaraju@wipro.com
Cc: sip@ietf.org
Subject: Re: [Sip] Status of require headers in the re-INVITE request.





nataraju.basavaraju@wipro.com wrote:
> Paul,
>
> You are right, its not a mandatory that re-INVITE carry the same set =
of
> options which INVITE carried. It would vary from application to
> application.

And the meaning when it changes may also vary from implementation to
implementation because it is not standardized.

> To make the implementation simpler UAs might decide to send the same =
set
> of options negotiated during initial INVITE transaction.

That would be a safe thing to do, but may not always be possible.

> At least its
> not acceptable to add more options in re-INVITE, which were not
> negotiated during INTITE transaction.

I would say that it might not be wise, or might be asking for trouble,
but its not banned by the specs. Whether it is acceptable or not is
something that will be judged by the recipient.

> If so it might end up with a an
> issue with refresh (if remote guy does not support the new option).

Yes you might. So if you do it you had better be prepared to get a 420
error and recover.

More difficult that adding options is taking them away, which is what
the original poster wanted to do. There is no Unrequire header, and
while there is an Unsupported header it may only be used in a 420 =
response.

Suppose Alice originally called Bob, specifying Supported:100rel, and
Bob answered with Require:100rel and used reliable provisionals. Then
Alice wants to send a reinvite but doesn't want to use 100rel any
longer. She can omit Supported:100rel from the reinvite, but there is no
guarantee that Bob won't remember it and again put Require:100rel in the
response and use reliable provisionals. (If any provisionals are used at
all.) The best Alice can do is hope. If she gets a 1xx with
Require:100rel she has no real option except to send a PRACK.

Note that Supported and Require are among the things that are supposed
to be included in an OPTIONS response. OPTIONS is typically used outside
a dialog. For the Supported and Require values in the OPTIONS response
to have any utility they must remain valid beyond the transaction. One
would expect that they are valid until further notice I suppose.

Basically this is a mess.

        Paul

> As
> you said it has interoperability issue, because different people
> implement in different manner.

Yes.

> Regards,
> Nataraju A B
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, November 16, 2007 6:40 PM
> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
> Infrastructure)
> Cc: vineet.gupta@motorola.com; sip@ietf.org
> Subject: Re: [Sip] Status of require headers in the re-INVITE request.
>
> Nataraju,
>
> Why do you think this behavior is required?
>
> The scope of applicability of Supported, Require, etc. is not well
> defined. If you want to be certain, then you should repeat these in
> every request. But if you *don't* include them in every request it is
> still likely that some peers will remember a value you sent earlier =
and
> assume it still applies.
>
> This is a potential interoperability issue and should be fixed, but I
> think it will be difficult. To be useful these options generally need =
to
> have a scope longer than a single transaction, yet if you assume they
> should have longer scope then it becomes difficult to define when that
> scope ends.
>
> In your particular case, if you want to use PRACK for the initial =
INVITE
> but you don't want to use it for reINVITE, I guess you can try =
omitting
> the Require:100rel in the reINVITE and hope for the best. But don't =
get
> upset if somebody still sends you PRACKs.
>
>       Thanks,
>       Paul
>
> nataraju.basavaraju@wipro.com wrote:
>> Comments inline...
>>
>> *Regards,*
>> *Nataraju A B*
>>
>> =
----------------------------------------------------------------------
>> --
>> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
>> *Sent:* Friday, November 16, 2007 1:10 PM
>> *To:* sip@ietf.org
>> *Subject:* [Sip] Status of require headers in the re-INVITE request.
>>
>>     Hi,
>>    =20
>>     I have a doubt related to using Require:100rel in re-INVITE
> requests.
>>    =20
>>     *If a Require header was used in the INVITE request establishing
> the
>>     dialog, is it mandatory to include the same Require header in
>>     subsequent re-INVITE requests within the dialog?
>>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>>     Require header values that of INVITE.
>>    =20
>>     To be specific, if INVITE request contained Require:100rel, then
>>     inclusion of Require:100rel in re-INVITE would require the
>>     originator to handle Reliable provisional responses and respond
>>     accordingly. So, it would also imply that re-INVITE also takes
> same
>>     call establishment time (owing to multiple messages like 183
> session
>>     in Progress, PRACK, 180 ringing, PRACK etc.).
>>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>>     has to generate 1xx. if UAS generates 1xx responses for =
re-INVITE,
>>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it
> is
>>     not mandatory to send  1xx for re-INVITE, hence even if
>>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>>     with out PRACK transaction.
>>    =20
>>     I agree, that such delay in re-INVITE might be acceptable given
> that
>>     re-INVITE requires the user-intervention, but it complicates =
makes
>>     the re-INVITE handling as complicated as the INVITE handling.
> Also,
>>     if the initial INVITE involved procedures such as QoS negotiation
>>     the re-INVITE state-machine complicates even further.
>>    =20
>>     [ABN] In most of the cases, re-INVITE is not expected to undergo
>>     user-intervention. hence in most of the cases it would end up =
with
>>     re-INV, 200, ACK only...
>>    =20
>>     In general, re-INVITE is expected to perform subset of what
> happened
>>     in INVITE transaction. it should not create any issues to handle
> 1xx
>>     responses reliably.
>>    =20
>>     Hope this answers all your questions...
>>    =20
>>     Regards,
>>     Vineet.
>>    =20
>>     /"You're only given a little spark of madness. You mustn't lose
>> it."/
>>    =20
>>
>>
>> =
----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> 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
>
>
> The information contained in this electronic message and any =
attachments to this message are intended for the exclusive use of the =
addressee(s) and may contain proprietary, confidential or privileged =
information. If you are not the intended recipient, you should not =
disseminate, distribute or copy this e-mail. Please notify the sender =
immediately and destroy all copies of this message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient =
should check this email and any attachments for the presence of viruses. =
The company accepts no liability for any damage caused by any virus =
transmitted by this email.
>=20
> www.wipro.com
>


_______________________________________________
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




_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 15:21:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuD7l-0003Ro-BS; Mon, 19 Nov 2007 15:21:41 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuD7k-0003Rc-97
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:21:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD7j-0003RM-VM
	for sip@ietf.org; Mon, 19 Nov 2007 15:21:39 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuD7g-00021G-Ik
	for sip@ietf.org; Mon, 19 Nov 2007 15:21:39 -0500
Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net
	[70.242.127.246]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJKKCKu053887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Nov 2007 14:20:12 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <4741EFF6.6040204@nostrum.com>
Date: Mon, 19 Nov 2007 14:20:06 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Scott Lawrence 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4845/Mon Nov 19 10:54:29 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: sip@ietf.org
Subject: [Sip] Some confusion: draft-ietf-sip-eku-00.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

In reading through the procedures described in the SIP EKU document, 
there's some apparent strangeness around the handling of 
anyExtendedKeyUsage. Perhaps I'm just being dense, but here's what's 
bothering me:

   2.  If EKU is present and contains id-kp-sipDomain, accept the
       certificate.

   3.  If any EKU is present and contains both id-kp-anyExtendedKeyUsage
       and id-kp-sipDomain, accept the certificate.


To me, this would be reduced to code that looks something like:

    if (sipDomain || (sipDomain && anyExtendedKeyUsage))
    {
      acceptCertificate();
    }


By my reading, this is unnecessarily complex, and functionally identical to:

    if (sipDomain)
    {
      acceptCertificate();
    }


In all of the text in this draft, I can't see any situation in which the 
presence of "anyExtendedKeyUsage" has any impact on processing at all.

(There's some additional confusion in here; draft-ietf-sip-eku mandates 
that certs containing a sipDomain extended key usage MUST mark the 
extended key usage extension as critical; on the other hand, RFC 3280 
indicates that the extended key usage extension SHOULD NOT be marked as 
critical if it contains "anyExtendedKeyUsage" -- it would seem to me 
that the extensions are fundamentally immiscible. In other words, a 
natural consequence of the current text in draft-ietf-sip-eku and the 
text in RFC 3280 is that sipDomain SHOULD NOT appear in the same cert as 
anyExtendedKeyUsage).

It is potentially the case that the document goes through all this 
verbiage in an attempt to say something like, "anyExtendedKeyUsage is 
insufficient to indicate suitability of the certificate for use in 
identifying SIP hosts." If this is the case, then I think that should be 
stated more clearly (and suitably motivated).

Similarly, it's not clear to me why a certificate with a *non-critical* 
EKU is required (at a MUST strength) to be rejected for use in 
identifying a SIP domain. It seems far more in keeping with the 
intention of EKU criticality to leave such situations up to local policy 
(that is, hosts should be free to treat a certificate with a 
*non-critical* EKU as if it had no EKU at all).

/a


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 15:26:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDBo-0004YF-HN; Mon, 19 Nov 2007 15:25:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDBm-0004Y2-8W
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:25:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDBl-0004Xu-Ta
	for sip@ietf.org; Mon, 19 Nov 2007 15:25:49 -0500
Received: from ind-iport-1.cisco.com ([64.104.129.195])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuDBl-00012x-9b
	for sip@ietf.org; Mon, 19 Nov 2007 15:25:49 -0500
X-IronPort-AV: E=Sophos;i="4.21,438,1188757800"; d="scan'208";a="91357332"
Received: from hkg-dkim-2.cisco.com ([10.75.231.163])
	by ind-iport-1.cisco.com with ESMTP; 20 Nov 2007 15:01:26 +0530
Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94])
	by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAJKPkFJ004162; 
	Tue, 20 Nov 2007 04:25:46 +0800
Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com
	[64.104.123.69])
	by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJKNde9020379; 
	Mon, 19 Nov 2007 20:25:30 GMT
Received: from xbh-rtp-211.amer.cisco.com ([64.102.31.102]) by
	xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 04:25:27 +0800
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 15:25:24 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 15:25:23 -0500
Message-ID: <4741F132.6060300@cisco.com>
Date: Mon, 19 Nov 2007 15:25:22 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com>
In-Reply-To: <4741D470.6030308@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Nov 2007 20:25:24.0007 (UTC)
	FILETIME=[506CA370:01C82AEA]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15556.000
X-TM-AS-Result: No--20.856600-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2159; t=1195503946;
	x=1196367946; c=relaxed/simple; s=hkgdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20WGLC=3A=20draft-ietf-sip-connect-reuse-08.txt
	|Sender:=20; bh=IfSVb0Q4XRY8GF4EW3gHWx8rE08aQPq0eEz6dVgKACQ=;
	b=L43tr342xziZv7t2fguSsh6Z25j/88ziadA1S6t4nVbR7ZvdsYaRb44CW7YBRERnfRClHDQf
	Fff4vgeEHopBDFUQlKekH1pAnt1KU4lwvtBOSgHWts+/4dVmJWW2Bz2E/0hWjOSXBMb8ab7GEX
	RjqY7RDb4WTneR0hczNz4DToE=;
Authentication-Results: hkg-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/hkgdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Vijay K. Gurbani wrote:
> Hadriel Kaplan wrote:
>> I wouldn't. :)  It is no more "authenticated" than if the remote end
>> opened a connection using an ephemeral port to the local host's
>> listen port.  The local host client knows little about the validity
>> of the remote end.  Actually, the client knows slightly more about
>> the validity of a connection it opened to the far-end than the other
>> way-around, especially if it did single-sided TLS to the far-end, so
>> in that sense it makes more sense to accept requests over its client
>> socket than over the listen port.  It just doesn't make much sense
>> for the remote end to send them over it, unless it can authenticate
>> (e.g., using digest).  And that's the rub.  Today certain types of
>> devices fix NAT traversal for SIP/TCP or SIP/TLS without needing the
>> client to do sip-outbound, so long as the client can accept requests
>> over its persistent connection, because they can authenticate the
>> client.  It's worked so far, anyway.  But this new MUST would break
>> it.
> 
> Hadriel: So essentially you are arguing for one of the following
> positions (assume A makes an active TCP connection to B to send a
> request downstream):
> 
>   1) Allow B to send requests upstream (to A) as long as A can
>    authenticate B, possibly using HTTP Digest (although how we
>    will do so if A and B are proxies is an open question.)
>   2) Downgrade the strength of S8.1 to something like the following:
>    OLD:
>     It MUST only accept responses over this connection and MUST NOT
>     accept any requests over this connection.
>    NEW:
>     It accepts responses over this connection, but SHOULD NOT accept
>     any requests.

The above both seem like nonsense to me. Neither deals with the 
essential issue that B has no way of verifying that it is talking to A.

	Paul

> Is that an accurate representation of your concern?  Given that the
> problem of using HTTP Digest between proxies is a complete new
> can of worms, the downgrade option seems more attractive.  Would be
> nice to hear other opinions.
> 
> Thanks,
> 
> - vijay


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 15:43:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDSJ-0001MX-2S; Mon, 19 Nov 2007 15:42:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDSH-0001GC-U6
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:42:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDSH-0001Dk-9o
	for sip@ietf.org; Mon, 19 Nov 2007 15:42:53 -0500
Received: from zcars04e.nortel.com ([47.129.242.56])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuDSG-0001cq-Qd
	for sip@ietf.org; Mon, 19 Nov 2007 15:42:53 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	lAJKdjO14189; Mon, 19 Nov 2007 20:39:45 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] comments on draft-ietf-sip-dtls-framework
Date: Mon, 19 Nov 2007 14:42:14 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF1348A595@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4741BB94.80202@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Index: AcgqymSrexwmlEvvT8a6hE0UdbLcCQAH8lmA
References: <4741BB94.80202@cisco.com>
From: "Francois Audet" 
To: "Jonathan Rosenberg" , "IETF SIP List" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Jonathan,

What you are describing is actually a problem of non-compliance
with SIP, where people are improperly using SIP URIs
as if they were a Tel URI.

As you point out, they are adding a "bogus" domain name and
route purely on the phone number and ignore the domain
name.

This is quite unfortunate because, it=20
invalidates most "phone number-derived SIP URIs" in terms
of SIP Identity. It is unfortunate, since if people used
a native Tel URI for cases where the domain is=20
irrelevant, we wouldn't have this problem (and we couldn't
use DTLS-SRTP for this).

Basically, "telephone number routing" overlaid on top of
SIP breaks SIP routing. If I call somebody at +11015551212@example.com,=20
I really have no garantee that it won't end-up at=20
+11015551212@evil.org.

This problem more than a SIP Identity problem. It's more
of a SIP usage problem.

Not sure how to deal with it.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
> Sent: Monday, November 19, 2007 08:37
> To: IETF SIP List
> Subject: [Sip] comments on draft-ietf-sip-dtls-framework
>=20
> I think there is an additional issue that should be discussed=20
> in the security considerations section.
>=20
> The draft relies heavily on sip identity to provide integrity=20
> over the fingerprint. The underlying assumption is that a=20
> MITM downstream would need to modify the fingerprint and thus=20
> would also need to modify the identity since it couldn't=20
> resign with the original domain.
>=20
> This assumption is a good one in deployments that use=20
> user@domain identifiers - joe@example.com. However, the=20
> unfortunate reality is that the majority of sip deployments=20
> today use phone numbers. These are often represented in sip=20
> URI form - sip:9739525060@example.com. However, when phone=20
> numbers are used, the domain part is often ignored and most=20
> of the time not even rendered to the user. Even if it were,=20
> its not a "significant" part of the identifier, in that a=20
> user won't normally know or care what the domain part is.
>=20
> What this means is that when phone numbers are in use, a MITM=20
> can easily rewrite the From field. So if it was=20
> sip:9739525060@example.com they can rewrite to=20
> sip:9739525060@middle-domain.com, insert a media intermediary=20
> and new fingerprint and resign. The called UA or terminating=20
> proxy will verify that the identity is valid (which it is)=20
> and the called party is presented with the caller ID, which=20
> is JUST the phone number. So they don't notice a problem at all.
>=20
> Thus, in practice, I fear dtls-srtp will easily allow proxies=20
> and SBCs on the chain to intercept and modify the media=20
> stream, similar to what they could do with sdescriptions.=20
> This is really a problem with sip identity itself that=20
> carries over here. But I think this issue needs to be=20
> mentioned and discussed. The draft makes itself out to be=20
> substantially more secure than sdescriptions or MIKEY because=20
> of its e2e nature but in practice I don't think it will be as=20
> effective.


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 15:56:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDex-0001wl-Qo; Mon, 19 Nov 2007 15:55:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDew-0001wU-Cp
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:55:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDew-0001wH-1K
	for sip@ietf.org; Mon, 19 Nov 2007 15:55:58 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuDev-0002MW-DS
	for sip@ietf.org; Mon, 19 Nov 2007 15:55:57 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJKtp0O074588
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for ; Mon, 19 Nov 2007 14:55:56 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <753B4BA1-2934-4A88-A6F0-5B55801E0A76@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sip List 
From: Robert Sparks 
Date: Mon, 19 Nov 2007 14:55:53 -0600
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Subject: [Sip] SIPit 21 summary
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

SIPit 21 was hosted by the BII Group and the Beijing University of  
Posts and Telecommunications, November 5-9 in Beijing, China.

The event was a little smaller than the most recent SIPits:
There were 94 attendees from 38 companies visiting from 15 countries.
There were 44 teams and around 70 distinct implementations.

The majority of the testing I saw was focusing on advanced scenarios  
rather than basic registration and call setup.

As with SIPit 20, the most common area of interoperability problems  
centered around offer/answer, particularly when attempting to  
negotiate alternate versions of streams or to explicitly state  
parameters to be used with a given stream.

Forty of the attending teams completed the survey - from those answers:

The roles represented (some implementations act in more than one role):
21 endpoints
10 proxy/registrars
   3 standalone registrars
   5 event servers
   4 gateways
   6 automaton UAs (voicemail, conference, appserver, etc)
   8 b2bua/sbcs
   4 UAs with signaling, but without media
   1 test/monitoring tool

Implementations using each transport for SIP messages:
   UDP	100%
   TCP	 82%
   TLS	 49% (server auth only)
   TLS	  6% (mutual auth)
   SCTP	  3%
   DTLS	  0%

36% of the implementations supported SIP over IPv6 (up from 25% at  
SIPit20)
18% supported SIP over IPSec

For DNS we had support for:
    Full RFC3263		: 61%
    SRV only		: 21%
    A records only	:  9%
    no DNS support	:  9%

Support for various items:
   61% rport
   15% sigcomp
   22% enum
   21% sending multiplexing STUN and SIP
   28% receiving multiplexed STUN and SIP
   22% RFC4320 fixes
   12% identity
   70% session-timer

There was one implementation of parts of the session-policy framework.
There was one implementation of the sip-consent framework.
There were two implementations of parts of the sip-config framework  
(I do not know yet if they worked together).
There were three implementations of outbound and four of GRUU.
There were two implementations of MSRP present.

The endpoints implemented these methods:
100% INVITE, CANCEL, ACK, BYE
   87% REGISTER
   87% OPTIONS
   87% NOTIFY <- still a lot of unsolicted NOTIFYs
   87% REFER
   77% SUBSCRIBE
   77% INFO
   70% UPDATE
   67% PRACK
   47% MESSAGE
   33% PUBLISH

Support for various extensions in the endpoints:
   43%	RFC3323 privacy
   41%	RFC3327 path
   13%   RFC3840 pref
   13%	RFC3841 caller-prefs
   59%   RFC3891 replaces
   20%	RFC4488 norefersub
    0%   RFC4538 target-dialog <- There were several folks starting  
to talk about supporting this

Support for various things in the endpoints:
   10%   ICE (but there was no interoperability - see below)
    0%   ICE-TCP
   13%	STUNbis
   17%	TURN (again, there was no interoperability)
   75%	symmetric RTP
   25%	SRTP
    0%	RTP over DTLS

This is how the endpoints answered how they supported multipart/mime:

   7%	I break if someone sends me multipart/mime
30%    I pretend multipart mime doesn't exist if someone sends it to me
20%	I ignore multipart/mime, but will proxy it or hand it to my  
application if it shows up
17%	I try to do something useful with multipart/mime I receive, but I  
never send it
   3%	I ignore multipart/mime I receive, but I try to send it to do  
something useful
20%	I try to do something useful with multipart/mime I send and receive

There were 4 endpoints that would send media over TCP - none of them  
supported RFC4145 comedia.
One of those supported media over TLS.

Implementation is all over the map for fork-loop-fix. However, only 3  
of the proxy/b2buas present were still vulnerable to the simple form  
of the attack described in the draft.

There were no implementations present with support for location- 
conveyance or the geopriv common-policy framework.
There was one implementation present with support for the RFC4967  
dial-string parameter, and one with support for the ecrit service-urn.

Of the SIP-Events implementations, the following packages were  
supported:
   62%	refer
   48%	message-summary
   38%	presence
   29%	dialog
   19%	reg
   19%	conf

There was one implementation of each of the following packages:
   ua-profile
   certificate/credentials
   vx-rtcpxp (sipping-rtcp-summary)

There was only one implementation of event-lists present.

Only 20% of the SIP-Events implementations supported winfo.

We had a multiparty sesssion for a full morning focusing on NAT  
traversal. Basic use of STUN with SIP is hightly interoperable.
No two implementations of TURN could even start trying to talk to  
each other (each having implemented to different points in the recent  
torrent of changes). I don't think we'll get much implementation  
feedback until the spec stops making big changes so frequently. No  
two implementations of ICE worked together. The closest was between  
two implementations that have worked in the past, but failed during  
this session when the connectivity checks arrived before the SDP.




_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 15:59:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDhx-0005qf-Mt; Mon, 19 Nov 2007 15:59:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDhW-0003jz-LI
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:58:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDhW-0003jr-Be
	for sip@ietf.org; Mon, 19 Nov 2007 15:58:38 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDhT-0003Yu-ML
	for sip@ietf.org; Mon, 19 Nov 2007 15:58:38 -0500
Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net
	[70.242.127.246]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJKvGO0074630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Nov 2007 14:57:17 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <4741F8A7.204@nostrum.com>
Date: Mon, 19 Nov 2007 14:57:11 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: "sip@ietf.org" ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

In general, I think the mechanism outlined in 
draft-kaplan-sip-info-events-00 is a good starting place for 
disambiguating multiple usages of INFO, and I'd like to thank Hadriel 
and Christer for putting forth the effort to submit a concrete proposal. 
I have a number of specific suggestions for improving the mechanism that 
I'd like to offer up at some point in the future.

However, I can't support the document in its current form.

The current document conflates INFO packages with Event packages in a 
way that is quite dangerous -- even going so far as to call INFO 
packages "Event packages" in a few places (c.f. section 4: "The general 
concept is that the UAC generating an INVITE request includes the Event 
packages it supports sending and receiving, in two new headers: 
Send-Event and Recv-Event."). It confusingly re-uses the "Event" header 
field from RFC 3265, and even suggests that common packages can be 
defined for RFC 3265 and for INFO.

This harmful conflation between RFC 3265 event packages and INFO 
packages pervades the document. Until this issue becomes less confused 
in the text, I strongly believe that the document will do far, far more 
damage than good.

/a

Hadriel Kaplan wrote:
> Howdy,
> Just an FYI that Christer and I submitted a draft for SIP INFO events, based on the email discussion.  This is on the agenda for Vancouver.
> Cheers,
> -hadriel
>
>   
>> -----Original Message-----
>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>> Sent: Thursday, November 08, 2007 11:00 PM
>> To: i-d-announce@ietf.org
>> Subject: I-D Action:draft-kaplan-sip-info-events-00.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>         Title           : SIP INFO Event Framework
>>         Author(s)       : H. Kaplan, et al.
>>         Filename        : draft-kaplan-sip-info-events-00.txt
>>         Pages           : 12
>>         Date            : 2007-11-08
>>
>> This document defines a proposed solution for defining, negotiating
>> and exchanging info-event notifications in INFO messages, within SIP
>> invite-created dialogs, for applications which need to exchange
>> session-related information inside the invite-created dialog.  This
>> draft addresses issues and open items from RFC 2976, and updates it.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-events-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request@ietf.org with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>>         "get draft-kaplan-sip-info-events-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>         mailserv@ietf.org.
>> In the body type:
>>         "FILE /internet-drafts/draft-kaplan-sip-info-events-00.txt".
>>
>> NOTE:   The mail server at ietf.org can return the document in
>>         MIME-encoded form by using the "mpack" utility.  To use this
>>         feature, insert the command "ENCODING mime" before the "FILE"
>>         command.  To decode the response(s), you will need "munpack" or
>>         a MIME-compliant mail reader.  Different MIME-compliant mail
>> readers
>>         exhibit different behavior, especially when dealing with
>>         "multipart" MIME messages (i.e. documents which have been split
>>         up into multiple messages), so check your local documentation on
>>         how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>     
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:00:36 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDjQ-0003D0-01; Mon, 19 Nov 2007 16:00:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDjO-0003Cc-4H
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:00:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDjN-0003CE-LD
	for sip@ietf.org; Mon, 19 Nov 2007 16:00:33 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDjJ-0003cd-Jh
	for sip@ietf.org; Mon, 19 Nov 2007 16:00:33 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Mon, 19 Nov 2007 16:00:29 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Mon, 19 Nov 2007 16:00:29 -0500
From: Hadriel Kaplan 
To: Christer Holmberg , "Elwell, John"
	, sip , Dan Wing 
Date: Mon, 19 Nov 2007 15:59:12 -0500
Subject: RE: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
Thread-Topic: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tAAEmaLAAAIfvRJAAFU1zA=
Message-ID: 
References: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
	
	
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Monday, November 19, 2007 2:41 PM
> To: Hadriel Kaplan; Elwell, John; sip; Dan Wing
> Subject: RE: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
>
> >That's Brian Stucker's draft. :)
>
> Ok, but are you assuming some specific outcome of that draft?

I am assuming that draft gets discussed, and whether the issues need to be =
fixed or not (and how) gets decided in its own context.  If it doesn't get =
addressed it still doesn't negate the need or usefulness of this draft, it =
just reduces the breadth of its applicability I guess.  But I take your poi=
nt we should put some tie-in note.


> Also, I am not sure whether Brian's draft covers B2BUAs, eventhough I
> guess much of the gate issues also apply to B2BUAs.

The way I read it, it is really about any media-path middle-box (ie, B2BUAs=
, SBCs, P-CSCFs, etc.).  My guess is using the MIDCOM terminology was just =
a nice way to frame it in an IETF-defined manner, as very few devices actua=
lly really use MIDCOM per se, AFAIK.



> >The most contentious among these is undoubtedly the To/From addr-specs.
>
> I agree, but I think the Date header could potentially also be an issue.
> For example, what happens if the UAC does not insert a Date header, but i=
t
> is then inserted by an intermediate? How will the UAS know?

I believe per RFC4474 the authenticator (signer) can and must add a Date he=
ader if the UAC did not.  Since the Date header is included in the headers =
being signed, you'll know if a middle-man changed it because the signature =
would be invalid.

[I'm separating the ICE stuff into a different email]

-hadriel


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:04:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDn9-0000Rw-IY; Mon, 19 Nov 2007 16:04:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDn8-0000Rr-TK
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:04:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDn8-0000Ri-Je
	for sip@ietf.org; Mon, 19 Nov 2007 16:04:26 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDn5-0003r7-62
	for sip@ietf.org; Mon, 19 Nov 2007 16:04:26 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Mon, 19 Nov 2007 16:04:22 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Mon, 19 Nov 2007 16:04:17 -0500
From: Hadriel Kaplan 
To: Christer Holmberg , "Elwell, John"
	, sip , Dan Wing 
Date: Mon, 19 Nov 2007 16:02:55 -0500
Thread-Topic: ICE and draft-wing-sip-identity-media-01.txt
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tAAEmaLAAAIfvRJAAJtfGA=
Message-ID: 
References: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
	
	
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: 
Subject: [Sip] RE: ICE and draft-wing-sip-identity-media-01.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

[separating ICE-specific bit into this thread]

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Monday, November 19, 2007 2:41 PM
> To: Hadriel Kaplan; Elwell, John; sip; Dan Wing
> Subject: RE: [Sip] RE: I-D Action:draft-wing-sip-identity-media-01.txt
>
> >I don't think we need to describe that because ICE is only one of the
> proposed media-identity mechanisms?  ICE already says if a middle-box
> media relay is detected (ie, if m=3D line does not match any candidate
> lines), ICE is >abandoned.
>
> Yes. But, I am talking of middle boxes which actually are able to process
> ICE in a way so that it is not abandoned.

If they are able to do so (and I don't disagree it is possible), then they =
need to figure out how to do so on their own.  ICE does not cover such boxe=
s today, so I don't know why this draft should?  I mean it's not that I thi=
nk it's wrong, I just don't know why it needs to be in this draft unless it=
 changes how this draft works for ICE from the UAs' perspectives.  The ques=
tion is, does it? [more on that below]


> > If an SBC wants to allow ICE it can do so by not relaying media (ie, no=
t
> touching SDP)
>
> There can be many reasons why an SBC wants to relay media, so you can't
> assume they will choose not to just because there is ICE...

Oh trust me I don't assume that at all.  ;)
I actually usually assume the inverse: the existence of ICE won't make the =
SBC stop relaying media at all, because they often relay media for very dif=
ferent reasons than ICE's reasons.


> In one of the solution (which also seems to be the most preferable)
> studied in 3GPP the SBC will understand STUN. But, it will not forward
> STUN messages, but instead establish separate ICE sessions in each
> "direction". From a UA perspective it will look like end-to-end ICE, but
> it isn't. So, whatever information the UA sends in the STUN message will
> not reach the other UA.

Yeah, and that's something I actually think should be taken to mmusic or be=
have as a draft, because it would be better to make it explicitly signaled.=
  STUN usage sans ICE has its advantages too, for example.


> >I was not aware studies were done in 3GPP
> >
> >- it seemed like an obvious thing to me that ICE doesn't work very well
> in media-relayed environments. ;)
>
> I believe it is possible to make it work, but it assumes that SBCs (at
> least those relaying media) are ICE- and STUN aware.

Yeah but that's where I was saying "it would have to be ICE aware". :)

I think though the point you're trying to get to is if the ice-pub-key is s=
igned, but some middle-box outside of the originating or terminating domain=
 wants to terminate ICE/STUN, it can't.  Right?
I don't disagree that is the case.  But I think that's the right thing to h=
appen.  You can't allow the mid-domains to change or remove the pub-key, be=
cause that obviously invalidates the assertion of media identity.

Actually, as I was about to write up a "here's how it could work" thing wit=
h regards to middle-boxes doing STUN, it occurred to me the ice-pub-key thi=
ng described in our draft is easily defeatible.  I'll email Dan about it to=
 see if I'm missing something.

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:08:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDqW-0001qL-O8; Mon, 19 Nov 2007 16:07:56 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDqV-0001hs-Ao
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:07:55 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDqU-0001fY-VW
	for sip@ietf.org; Mon, 19 Nov 2007 16:07:55 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuDqU-0002wS-JH
	for sip@ietf.org; Mon, 19 Nov 2007 16:07:54 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJL7sTk075239
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for ; Mon, 19 Nov 2007 15:07:54 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sip List 
From: Robert Sparks 
Date: Mon, 19 Nov 2007 15:07:52 -0600
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Subject: [Sip] SIPit 21 : Topics that attendees argued about
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Digging through my notes:

Here are some of the topics where people were arguing. I'm capturing  
the smaller topics here. Larger arguments will get their own message.

* There were arguments about the dynamic payload map from numbers to  
codecs (identified in the SDP and sent in the RTP) being the same in  
the offer and the answer . The spec says they SHOULD. Some  
implementations were insisting they MUST.
* There were arguments around preserving the relative order of codecs  
on an m-line between the offer and the answer. The specs say SHOULD.
* There were implementations that offered an m-line with codecs A, B,  
and C, got an answer with C, then got upset when they got RTP with A  
(which is quite legal).
* There were arguments about deleting rejected m-lines on re-invites  
(which you cannot do), and on reusing the slot they occupy in re- 
invites (which you can do).
* There were implementations that didn't add the refresher tag in a  
session-refresh message when they were the refresher and there were  
arguments about whether that meant the other side could take the role.
* Several implementations handled a=sendonly as a session attribute,  
but not a media attribute - it can appear in either place.



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:08:38 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDrB-0002lO-Vf; Mon, 19 Nov 2007 16:08:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDrA-0002kT-Tv
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:08:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDrA-0002j7-JL
	for sip@ietf.org; Mon, 19 Nov 2007 16:08:36 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDr7-0003xy-BL
	for sip@ietf.org; Mon, 19 Nov 2007 16:08:36 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Mon, 19 Nov 2007 16:08:33 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Mon, 19 Nov 2007 16:08:32 -0500
From: Hadriel Kaplan 
To: Adam Roach 
Date: Mon, 19 Nov 2007 16:07:16 -0500
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Thread-Index: Acgq7syf8K2Jo/ZvSfqo7EbSHcSgAAAANJCA
Message-ID: 
References: 
	<4741F8A7.204@nostrum.com>
In-Reply-To: <4741F8A7.204@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: "sip@ietf.org" ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Yeah my bad for not re-writing that whole thing.  It started out as a "rfc3=
265 Event Packages for INFO" type thing, but after your emails on the subje=
ct we were convinced that was a bad way to go.  I apologize for not cleanin=
g it up better before submission.  Do you want me to re-submit using better=
 terminology?  (unfortunately due to the submission deadlines I don't think=
 I can do so officially?)

I was thinking this was really just a discussion point doc for the Vancouve=
r meeting, and if the concept in general was adopted we'd fix all the termi=
nology.

Sorry 'bout that.  :(

-hadriel


> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Monday, November 19, 2007 3:57 PM
> To: Hadriel Kaplan
> Cc: sip@ietf.org; Christer Holmberg
> Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
>
> In general, I think the mechanism outlined in
> draft-kaplan-sip-info-events-00 is a good starting place for
> disambiguating multiple usages of INFO, and I'd like to thank Hadriel
> and Christer for putting forth the effort to submit a concrete proposal.
> I have a number of specific suggestions for improving the mechanism that
> I'd like to offer up at some point in the future.
>
> However, I can't support the document in its current form.
>
> The current document conflates INFO packages with Event packages in a
> way that is quite dangerous -- even going so far as to call INFO
> packages "Event packages" in a few places (c.f. section 4: "The general
> concept is that the UAC generating an INVITE request includes the Event
> packages it supports sending and receiving, in two new headers:
> Send-Event and Recv-Event."). It confusingly re-uses the "Event" header
> field from RFC 3265, and even suggests that common packages can be
> defined for RFC 3265 and for INFO.
>
> This harmful conflation between RFC 3265 event packages and INFO
> packages pervades the document. Until this issue becomes less confused
> in the text, I strongly believe that the document will do far, far more
> damage than good.
>
> /a
>
> Hadriel Kaplan wrote:
> > Howdy,
> > Just an FYI that Christer and I submitted a draft for SIP INFO events,
> based on the email discussion.  This is on the agenda for Vancouver.
> > Cheers,
> > -hadriel
> >
> >
> >> -----Original Message-----
> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >> Sent: Thursday, November 08, 2007 11:00 PM
> >> To: i-d-announce@ietf.org
> >> Subject: I-D Action:draft-kaplan-sip-info-events-00.txt
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>
> >>         Title           : SIP INFO Event Framework
> >>         Author(s)       : H. Kaplan, et al.
> >>         Filename        : draft-kaplan-sip-info-events-00.txt
> >>         Pages           : 12
> >>         Date            : 2007-11-08
> >>
> >> This document defines a proposed solution for defining, negotiating
> >> and exchanging info-event notifications in INFO messages, within SIP
> >> invite-created dialogs, for applications which need to exchange
> >> session-related information inside the invite-created dialog.  This
> >> draft addresses issues and open items from RFC 2976, and updates it.
> >>
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-events-00.tx=
t
> >>
> >> To remove yourself from the I-D Announcement list, send a message to
> >> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> >> the message.
> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> >> to change your subscription settings.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login with the
> >> username "anonymous" and a password of your e-mail address. After
> >> logging in, type "cd internet-drafts" and then
> >>         "get draft-kaplan-sip-info-events-00.txt".
> >>
> >> A list of Internet-Drafts directories can be found in
> >> http://www.ietf.org/shadow.html
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >>         mailserv@ietf.org.
> >> In the body type:
> >>         "FILE /internet-drafts/draft-kaplan-sip-info-events-00.txt".
> >>
> >> NOTE:   The mail server at ietf.org can return the document in
> >>         MIME-encoded form by using the "mpack" utility.  To use this
> >>         feature, insert the command "ENCODING mime" before the "FILE"
> >>         command.  To decode the response(s), you will need "munpack" o=
r
> >>         a MIME-compliant mail reader.  Different MIME-compliant mail
> >> readers
> >>         exhibit different behavior, especially when dealing with
> >>         "multipart" MIME messages (i.e. documents which have been spli=
t
> >>         up into multiple messages), so check your local documentation
> on
> >>         how to manipulate these messages.
> >>
> >> Below is the data which will enable a MIME compliant mail reader
> >> implementation to automatically retrieve the ASCII version of the
> >> Internet-Draft.
> >>
> >
> >
> > -----------------------------------------------------------------------=
-
> >
> > _______________________________________________
> > 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



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:15:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuDxS-0001wJ-ON; Mon, 19 Nov 2007 16:15:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuDxP-0001vt-6n
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:15:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDxO-0001vl-TP
	for sip@ietf.org; Mon, 19 Nov 2007 16:15:02 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDxL-00049F-KQ
	for sip@ietf.org; Mon, 19 Nov 2007 16:15:02 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJLDhud075524
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for ; Mon, 19 Nov 2007 15:13:44 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <63087CF3-F420-4256-89A5-D523A45285AB@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sip List 
From: Robert Sparks 
Date: Mon, 19 Nov 2007 15:13:42 -0600
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

There was a lot of discussion and disagreement at SIPit21 about  
whether the following 200 OK is allowed (or should) have SDP in it:

INVITE (offer)
-------->
18x (with 100rel) (answer)
<--------
PRACK
--------->
200 OK (can this carry SDP?)
<---------
ACK
--------->

I couldn't find anything definitive in RFC form. Paul's offeranswer  
draft talks about this I think.

If I understand things, the right answer here is that it's not  
supposed to carry any SDP and that you should ignore it if it shows up.

The question is, other than waste, what can go wrong if it is there?  
When we end up with clear text around the requirement, will
it say SDP SHOULD NOT, or MUST NOT appear?

Or do I have this wrong?

RjS


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:19:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuE1B-000565-ME; Mon, 19 Nov 2007 16:18:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuE1A-00054b-5d
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:18:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuE19-00053q-7d
	for sip@ietf.org; Mon, 19 Nov 2007 16:18:55 -0500
Received: from mail.xcastlabs.com ([66.153.122.23] helo=vpbx.xcastlabs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuE15-0004QT-9W
	for sip@ietf.org; Mon, 19 Nov 2007 16:18:55 -0500
Received: from victorgr ([10.10.10.51])
	by vpbx.xcastlabs.com (8.13.1/8.13.1) with ESMTP id lAJLIo6D032657;
	Mon, 19 Nov 2007 15:18:50 -0600
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
From: Victor Grinberg 
To: Robert Sparks 
In-Reply-To: <63087CF3-F420-4256-89A5-D523A45285AB@nostrum.com>
References: <63087CF3-F420-4256-89A5-D523A45285AB@nostrum.com>
Content-Type: text/plain
Date: Mon, 19 Nov 2007 15:18:50 -0600
Message-Id: <1195507130.8131.1.camel@victorgr>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) 
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	DKIM_POLICY_SIGNSOME autolearn=no version=3.2.2
X-Spam-Checker-Version: SpamAssassin 3.2.2 (2007-07-23) on vpbx.xcastlabs.com
X-Virus-Scanned: ClamAV version 0.91.2,
	clamav-milter version 0.91.2 on vpbx.xcastlabs.com
X-Virus-Status: Clean
X-Spam-Score: -0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

On Mon, 2007-11-19 at 15:13 -0600, Robert Sparks wrote:
> There was a lot of discussion and disagreement at SIPit21 about  
> whether the following 200 OK is allowed (or should) have SDP in it:
> 
> INVITE (offer)
> -------->
> 18x (with 100rel) (answer)
> <--------
> PRACK
> --------->
> 200 OK (can this carry SDP?)
> <---------
> ACK
> --------->
> 
> I couldn't find anything definitive in RFC form. Paul's offeranswer  
> draft talks about this I think.
> 
> If I understand things, the right answer here is that it's not  
> supposed to carry any SDP and that you should ignore it if it shows up.
> 
> The question is, other than waste, what can go wrong if it is there?  
> When we end up with clear text around the requirement, will
> it say SDP SHOULD NOT, or MUST NOT appear?
> 

What if INVITE forked and you got 18x from one of destinations and 200
from another?

--
VictorG




_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:19:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuE1C-00057B-OM; Mon, 19 Nov 2007 16:18:58 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuE1B-00055U-1S
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:18:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuE1A-00054Z-2V
	for sip@ietf.org; Mon, 19 Nov 2007 16:18:56 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuE17-0004R5-Rf
	for sip@ietf.org; Mon, 19 Nov 2007 16:18:56 -0500
Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net
	[70.242.127.246]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJLHabn075767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Nov 2007 15:17:37 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <4741FD6B.10507@nostrum.com>
Date: Mon, 19 Nov 2007 15:17:31 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Dan Wing 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<20071111224707.68E5033C21@delta.rtfm.com>
	<008701c824d4$096ca180$c4f0200a@cisco.com>
In-Reply-To: <008701c824d4$096ca180$c4f0200a@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: 'IETF SIP List' 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

On 11/11/07 8:30 PM, Dan Wing wrote:
>
> If 3GPP decides to use something other than DTLS-SRTP, we will have
> two standards for SRTP keying -- the IETF standard and the non-IETF
> standard.  I do not consider that desirable.
>   

Why should crypto be different than the underlying protocol? The 
bifurcation between "IETF SIP" and "3GPP SIP" already exists in the market.



/a


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:19:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuE1u-0006Cy-5F; Mon, 19 Nov 2007 16:19:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuE1s-0006CD-CG
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:19:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuE1s-0006Bk-02
	for sip@ietf.org; Mon, 19 Nov 2007 16:19:40 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuE1l-0004WX-4i
	for sip@ietf.org; Mon, 19 Nov 2007 16:19:39 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2007 16:19:33 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAJLJWTw018856; 
	Mon, 19 Nov 2007 16:19:32 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJLJMx9012548; 
	Mon, 19 Nov 2007 21:19:28 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 16:19:22 -0500
Received: from [161.44.182.92] ([161.44.182.92]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 16:19:21 -0500
Message-ID: <4741FDDA.6000902@cisco.com>
Date: Mon, 19 Nov 2007 16:19:22 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Christer Holmberg 
Subject: Re: [Sip] Status of require headers in the re-INVITE request.
References: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>
	<473DDB80.8060507@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Nov 2007 21:19:22.0022 (UTC)
	FILETIME=[DA6E8460:01C82AF1]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--25.278500-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9534; t=1195507172;
	x=1196371172; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20Status=20of=20require=20headers=20in=20the=20
	re-INVITE=20request. |Sender:=20
	|To:=20Christer=20Holmberg=20;
	bh=tbtr9sUVOGMnUrk/ozpiayQWbn46H9R1w2jdx3NWXO0=;
	b=NKt5gdV6xSgoUpVao6Ad6Bcky3At+Q3I/KfI0o1dMCvFVk26AjjYydVFChT475U2+CE49dmc
	zowwfx8lZxQ15/WDVKV2z1Iop74DWHhbx2a3DC5qub73vJezHsdHN5If;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Christer Holmberg wrote:
> Hi,
>  
> I think this discussion touches on an issue, which I know has caused some interop concerns:
>  
> Is the Supported/Require header only transaction specific, or is it dialog specific?
>  
> If it is dialog specific, I would say that you don't need to include anything in the re-INVITE, if it was already included in the INVITE. But, then it would also mean that whatever you indicated in the INVITE (e.g. 100rel) is also valid for the re-INVITE.

For many usages it must have a scope longer than a single transaction. 
And dialog scope isn't always right either. (Some apply to non-dialog 
usages.) In practice, anything that seems to have dialog scope will be 
broken by 3pcc and so will at best have to be "from henceforth in the 
dialog until overridden". And overrides are themselves a problem because 
there is no Unrequired header.

I haven't tried to do an exhaustive analysis of all the different 
options, but I have gut feeling that there is no single definition of 
scope that will work for all of them - that there will be examples that 
assume different scopes.

	Paul

> Regards,
>  
> Christer
> 
> ________________________________
> 
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Fri 16/11/2007 19:03
> To: nataraju.basavaraju@wipro.com
> Cc: sip@ietf.org
> Subject: Re: [Sip] Status of require headers in the re-INVITE request.
> 
> 
> 
> 
> 
> nataraju.basavaraju@wipro.com wrote:
>> Paul,
>>
>> You are right, its not a mandatory that re-INVITE carry the same set of
>> options which INVITE carried. It would vary from application to
>> application.
> 
> And the meaning when it changes may also vary from implementation to
> implementation because it is not standardized.
> 
>> To make the implementation simpler UAs might decide to send the same set
>> of options negotiated during initial INVITE transaction.
> 
> That would be a safe thing to do, but may not always be possible.
> 
>> At least its
>> not acceptable to add more options in re-INVITE, which were not
>> negotiated during INTITE transaction.
> 
> I would say that it might not be wise, or might be asking for trouble,
> but its not banned by the specs. Whether it is acceptable or not is
> something that will be judged by the recipient.
> 
>> If so it might end up with a an
>> issue with refresh (if remote guy does not support the new option).
> 
> Yes you might. So if you do it you had better be prepared to get a 420
> error and recover.
> 
> More difficult that adding options is taking them away, which is what
> the original poster wanted to do. There is no Unrequire header, and
> while there is an Unsupported header it may only be used in a 420 response.
> 
> Suppose Alice originally called Bob, specifying Supported:100rel, and
> Bob answered with Require:100rel and used reliable provisionals. Then
> Alice wants to send a reinvite but doesn't want to use 100rel any
> longer. She can omit Supported:100rel from the reinvite, but there is no
> guarantee that Bob won't remember it and again put Require:100rel in the
> response and use reliable provisionals. (If any provisionals are used at
> all.) The best Alice can do is hope. If she gets a 1xx with
> Require:100rel she has no real option except to send a PRACK.
> 
> Note that Supported and Require are among the things that are supposed
> to be included in an OPTIONS response. OPTIONS is typically used outside
> a dialog. For the Supported and Require values in the OPTIONS response
> to have any utility they must remain valid beyond the transaction. One
> would expect that they are valid until further notice I suppose.
> 
> Basically this is a mess.
> 
>         Paul
> 
>> As
>> you said it has interoperability issue, because different people
>> implement in different manner.
> 
> Yes.
> 
>> Regards,
>> Nataraju A B
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: Friday, November 16, 2007 6:40 PM
>> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
>> Infrastructure)
>> Cc: vineet.gupta@motorola.com; sip@ietf.org
>> Subject: Re: [Sip] Status of require headers in the re-INVITE request.
>>
>> Nataraju,
>>
>> Why do you think this behavior is required?
>>
>> The scope of applicability of Supported, Require, etc. is not well
>> defined. If you want to be certain, then you should repeat these in
>> every request. But if you *don't* include them in every request it is
>> still likely that some peers will remember a value you sent earlier and
>> assume it still applies.
>>
>> This is a potential interoperability issue and should be fixed, but I
>> think it will be difficult. To be useful these options generally need to
>> have a scope longer than a single transaction, yet if you assume they
>> should have longer scope then it becomes difficult to define when that
>> scope ends.
>>
>> In your particular case, if you want to use PRACK for the initial INVITE
>> but you don't want to use it for reINVITE, I guess you can try omitting
>> the Require:100rel in the reINVITE and hope for the best. But don't get
>> upset if somebody still sends you PRACKs.
>>
>>       Thanks,
>>       Paul
>>
>> nataraju.basavaraju@wipro.com wrote:
>>> Comments inline...
>>>
>>> *Regards,*
>>> *Nataraju A B*
>>>
>>> ----------------------------------------------------------------------
>>> --
>>> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
>>> *Sent:* Friday, November 16, 2007 1:10 PM
>>> *To:* sip@ietf.org
>>> *Subject:* [Sip] Status of require headers in the re-INVITE request.
>>>
>>>     Hi,
>>>     
>>>     I have a doubt related to using Require:100rel in re-INVITE
>> requests.
>>>     
>>>     *If a Require header was used in the INVITE request establishing
>> the
>>>     dialog, is it mandatory to include the same Require header in
>>>     subsequent re-INVITE requests within the dialog?
>>>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>>>     Require header values that of INVITE.
>>>     
>>>     To be specific, if INVITE request contained Require:100rel, then
>>>     inclusion of Require:100rel in re-INVITE would require the
>>>     originator to handle Reliable provisional responses and respond
>>>     accordingly. So, it would also imply that re-INVITE also takes
>> same
>>>     call establishment time (owing to multiple messages like 183
>> session
>>>     in Progress, PRACK, 180 ringing, PRACK etc.).
>>>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>>>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>>>     has to generate 1xx. if UAS generates 1xx responses for re-INVITE,
>>>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it
>> is
>>>     not mandatory to send  1xx for re-INVITE, hence even if
>>>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>>>     with out PRACK transaction.
>>>     
>>>     I agree, that such delay in re-INVITE might be acceptable given
>> that
>>>     re-INVITE requires the user-intervention, but it complicates makes
>>>     the re-INVITE handling as complicated as the INVITE handling.
>> Also,
>>>     if the initial INVITE involved procedures such as QoS negotiation
>>>     the re-INVITE state-machine complicates even further.
>>>     
>>>     [ABN] In most of the cases, re-INVITE is not expected to undergo
>>>     user-intervention. hence in most of the cases it would end up with
>>>     re-INV, 200, ACK only...
>>>     
>>>     In general, re-INVITE is expected to perform subset of what
>> happened
>>>     in INVITE transaction. it should not create any issues to handle
>> 1xx
>>>     responses reliably.
>>>     
>>>     Hope this answers all your questions...
>>>     
>>>     Regards,
>>>     Vineet.
>>>     
>>>     /"You're only given a little spark of madness. You mustn't lose
>>> it."/
>>>     
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --
>>>
>>> _______________________________________________
>>> 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
>>
>> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
>>
>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
>>
>> www.wipro.com
>>
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:22:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuE4X-0001PN-2C; Mon, 19 Nov 2007 16:22:25 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuE4U-0001Oo-TL
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:22:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuE4U-0001Of-JX
	for sip@ietf.org; Mon, 19 Nov 2007 16:22:22 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuE4N-0004jS-Fa
	for sip@ietf.org; Mon, 19 Nov 2007 16:22:22 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 19 Nov 2007 13:22:15 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAJLMEc9011356; 
	Mon, 19 Nov 2007 13:22:14 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAJLM14E015909;
	Mon, 19 Nov 2007 21:22:14 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 16:22:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Mon, 19 Nov 2007 16:22:00 -0500
Message-ID: <8983EC086A9D954BA74D9763E853CF3E0437ED50@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <63087CF3-F420-4256-89A5-D523A45285AB@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: SDP in a 200OK when using 100rel
Thread-Index: Acgq8VC+zFhSLd5dQ5+PGB1DTyvdgwAAEJJA
From: "Sanjay Sinha (sanjsinh)" 
To: "Robert Sparks" , "sip List" 
X-OriginalArrivalTime: 19 Nov 2007 21:22:11.0304 (UTC)
	FILETIME=[3F54E680:01C82AF2]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--18.161400-8.000000-2
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1873; t=1195507335;
	x=1196371335; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20
	|Subject:=20RE=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20;
	bh=/3qmmff6DZwaMVRTLEw//EL2trKjKzy36WZNkioeCtA=;
	b=nWduxCbgb0XsZjGaqS4UsmozmzxGJMVQXoB68vaw6Ed5yhRLj6mRcOZj97uj06wr1VxB35oA
	lKAuHZioU6P0SLIlxd0aEZ2ESrwp2GzbaNd6ghojdlwpb/mI4j8DpwtI;
Authentication-Results: sj-dkim-3; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

It is not clear from the call flow if the 200 OK is for PRACK or INVITE?

I guess you meant 200 OK for Invite. If that is the case, I think the
RFC is clear that the answer sdp is optional in it and if it does have
an answer sdp, it MUST be idential to answer in 18x. But I think the
offer-answer draft has clarified it further that it should not have any
answer sdp. This is probably harsh in case of one offer-answer exchange,
but makes sense if there are multiple early dialog offer-answer
exchanges in say Prack/200 OK or using UPDATE.

Sanjay

>-----Original Message-----
>From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
>Sent: Monday, November 19, 2007 4:14 PM
>To: sip List
>Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>
>There was a lot of discussion and disagreement at SIPit21=20
>about whether the following 200 OK is allowed (or should) have=20
>SDP in it:
>
>INVITE (offer)
>-------->
>18x (with 100rel) (answer)
><--------
>PRACK
>--------->
>200 OK (can this carry SDP?)
><---------
>ACK
>--------->
>
>I couldn't find anything definitive in RFC form. Paul's=20
>offeranswer draft talks about this I think.
>
>If I understand things, the right answer here is that it's not=20
>supposed to carry any SDP and that you should ignore it if it shows up.
>
>The question is, other than waste, what can go wrong if it is there? =20
>When we end up with clear text around the requirement, will it=20
>say SDP SHOULD NOT, or MUST NOT appear?
>
>Or do I have this wrong?
>
>RjS
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:26:05 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuE83-0004Ys-H4; Mon, 19 Nov 2007 16:26:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuE82-0004YG-6L
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:26:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuE81-0004Y8-Rt
	for sip@ietf.org; Mon, 19 Nov 2007 16:26:01 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuE81-0003of-GS
	for sip@ietf.org; Mon, 19 Nov 2007 16:26:01 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2007 16:26:01 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAJLQ1NV021759; 
	Mon, 19 Nov 2007 16:26:01 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJLQ0wp014814; 
	Mon, 19 Nov 2007 21:26:00 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 16:25:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Mon, 19 Nov 2007 16:25:34 -0500
Message-ID: <8983EC086A9D954BA74D9763E853CF3E0437ED54@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <1195507130.8131.1.camel@victorgr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: SDP in a 200OK when using 100rel
Thread-Index: Acgq8duAFGceVsfqQDC0m5sHI723NgAAIq6w
From: "Sanjay Sinha (sanjsinh)" 
To: "Victor Grinberg" ,
	"Robert Sparks" 
X-OriginalArrivalTime: 19 Nov 2007 21:25:45.0335 (UTC)
	FILETIME=[BEE77070:01C82AF2]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--18.574900-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1678; t=1195507561;
	x=1196371561; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20
	|Subject:=20RE=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20
	|To:=20=22Victor=20Grinberg=22=20,
	=0A=20=20=20=20=
	20=20=20=20=22Robert=20Sparks=22=20;
	bh=6GvkJnAPfbwjijMrf9bfp87FE1Vub3p/20pMUEJHIv8=;
	b=FFfmcYVRW+Syw4F+DYIwAob6btGpbDKIIMVNPLg9czIv1CiGBnp0t/SKmfnCV0ce1efzNI7U
	m0+XqaFQ2ew0LPFcgSOtU8PhXSXw4UqbXaQ9Iaa1n4ywAWJLrMi8Y41V;
Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Forking is different, since there is different to-tags from forked legs
and so offer-answer applies to each leg.

Sanjay=20

>-----Original Message-----
>From: Victor Grinberg [mailto:VictorG@xcastlabs.com]=20
>Sent: Monday, November 19, 2007 4:19 PM
>To: Robert Sparks
>Cc: sip List
>Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
>
>On Mon, 2007-11-19 at 15:13 -0600, Robert Sparks wrote:
>> There was a lot of discussion and disagreement at SIPit21 about=20
>> whether the following 200 OK is allowed (or should) have SDP in it:
>>=20
>> INVITE (offer)
>> -------->
>> 18x (with 100rel) (answer)
>> <--------
>> PRACK
>> --------->
>> 200 OK (can this carry SDP?)
>> <---------
>> ACK
>> --------->
>>=20
>> I couldn't find anything definitive in RFC form. Paul's offeranswer=20
>> draft talks about this I think.
>>=20
>> If I understand things, the right answer here is that it's not=20
>> supposed to carry any SDP and that you should ignore it if=20
>it shows up.
>>=20
>> The question is, other than waste, what can go wrong if it=20
>is there? =20
>> When we end up with clear text around the requirement, will=20
>it say SDP=20
>> SHOULD NOT, or MUST NOT appear?
>>=20
>
>What if INVITE forked and you got 18x from one of destinations=20
>and 200 from another?
>
>--
>VictorG
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:26:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuE8a-0004p2-VC; Mon, 19 Nov 2007 16:26:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuE8Z-0004ox-SE
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:26:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuE8Z-0004op-Il
	for sip@ietf.org; Mon, 19 Nov 2007 16:26:35 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuE8W-0004tg-7G
	for sip@ietf.org; Mon, 19 Nov 2007 16:26:35 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJLPGfP076295
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for ; Mon, 19 Nov 2007 15:25:16 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: 
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sip List 
From: Robert Sparks 
Date: Mon, 19 Nov 2007 15:25:15 -0600
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [Sip] SIPit 21: Forking Notifys and record-routing mid-dialog
	requests
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

One of the topics that got bantered about during SIPit 21 was re- 
discovering that if a SUBSCRIBE forks and proxies don't record-route  
the NOTIFYs (which are mid-dialog requests), the subscriber doesn't  
end up with the right route-set for the NOTIFYs from dialogs other  
than the one matching the 200 OK to the SUBSCRIBE.

3261 says proxies SHOULD record-route mid-dialog requests, but it  
doesn't provide enough motivation (I think it was originally  
motivated by the
notion of allowing rebooting UAs to reconstitute dialog state rather  
than anticipating the problem we have with HERFP here).

By and large, proxies ignore that SHOULD since endpoints are required  
to ignore any attempt to change the route-set mid-dialog.

This is a real problem, and it will eventually cause failure in the  
deployment of any SIP Event application where the SUBSCRIBE might fork.

Now, is actually record-routing all mid-dialog requests really the  
right thing to do? It really is a waste of bits in any message that  
isn't going to create a dialog.
Would it make more sense to work on an extension that would allow an  
endpoint to indicate "this request is going to establish a dialog -  
you better record-route it" instead?

RjS

p.s. (I've thought all along that we should allow mid-dialog requests  
to modify the route-set, and that would require all requests, mid- 
dialog or not to be record-routed, but that's not how the consensus  
landed).


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:35:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuEGq-0006qI-LG; Mon, 19 Nov 2007 16:35:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuEGo-0006qA-Qt
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:35:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEGo-0006q2-GJ
	for sip@ietf.org; Mon, 19 Nov 2007 16:35:06 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuEGo-00046w-3h
	for sip@ietf.org; Mon, 19 Nov 2007 16:35:06 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJLZ4gr076855
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for ; Mon, 19 Nov 2007 15:35:05 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sip List 
From: Robert Sparks 
Date: Mon, 19 Nov 2007 15:35:03 -0600
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Subject: [Sip] SIPit21: BNF future-proofing problem?
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

The BNF in 3261 says the following:

extension-header  =  header-name HCOLON header-value
header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)

This is intended to be the catch-all field for all future extensions  
- older parsers working against this BNF shouldn't barf
when we introduce a new header field.

Now, we may have new fields in the future that look like:

NewHeader = new-header-name HCOLON quoted-string

And down inside quoted-string, we get:

       quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
       qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
                         / UTF8-NONASCII
       quoted-pair  =  "\" (%x00-09 / %x0B-0C
                        / %x0E-7F)

So, for instance, we could have inside a quoted string the 2 byte  
sequence \ NULL

This does not parse against header-value above...

Is this a problem? Some of the SIPit21 participants argued that it is.

The projects I've been involved in don't parse unknown headers and  
the stacks will just hand up an unparsed bucket of bits (the only rules
used are those necessary to identify the next header-field starting).

Would it be worth the effort to make the BNF reflect that rather than  
continuing with the incongruity that we currently specify?

RjS


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:42:01 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuENP-0007kM-OX; Mon, 19 Nov 2007 16:41:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuENO-0007jA-EQ
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:41:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuENO-0007j2-4r
	for sip@ietf.org; Mon, 19 Nov 2007 16:41:54 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuENK-0005M3-Uj
	for sip@ietf.org; Mon, 19 Nov 2007 16:41:54 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJLeZmA077171
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for ; Mon, 19 Nov 2007 15:40:35 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sip List 
From: Robert Sparks 
Date: Mon, 19 Nov 2007 15:40:33 -0600
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Subject: [Sip] SIPit 21: BNF and DIGEST authentication
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

We are _still_ seeing interoperability problems because of quotes  
around the qop parameter value in challenges and responses.

What's specified now is that quotes MUST appear in challenges (it's a  
list of things) and MUST NOT appear in responses (it's a choice of  
one thing).

This causes lots of people to write broken code.

For the code that does work, this causes people to either build  
separate parsers for headers with the same name, using the knowledge  
of whether its a challenge or response to invoke the right parser, or  
to build parsers that don't follow the BNF we've provided.

Would it make more sense to change the BNF to allow the quotes  
optionally in either the challenge or the response?

Nobody that I've asked is actually re-using an HTTP parser for this,  
and nobody seems to be getting the number of values for the parameter  
wrong. Most of the folks I ask are building their parsers this way  
anyhow

What would be bad about making this change to the spec?

RjS



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:48:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuEU5-0005hO-9q; Mon, 19 Nov 2007 16:48:49 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuEU4-0005hC-EB
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:48:48 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEU4-0005h3-3w
	for sip@ietf.org; Mon, 19 Nov 2007 16:48:48 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuEU3-0004Vu-M8
	for sip@ietf.org; Mon, 19 Nov 2007 16:48:48 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJLmkkI077627
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for ; Mon, 19 Nov 2007 15:48:47 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <5F06E0FE-117D-40D2-9026-2B010D21548E@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sip List 
From: Robert Sparks 
Date: Mon, 19 Nov 2007 15:48:41 -0600
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Subject: [Sip] SIPit 21: REFER with Replaces - and Require: replaces
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Here's a really interesting one.

Lots of people are sending REFER with a Refer-To URI that has an  
embedded Replaces header.
This is what we're specifying in cc-transfer.

Nobody puts Require: replaces in the REFER request (and I don't think  
they should - does anybody disagree?)

However, very few implementations are putting Require: replaces in  
the triggered INVITE. They're copying the Replaces header into
the INVITE though.

This will cause very wrong things to happen if that triggered INVITE  
forks.

 From talking to people at SIPit 21, I don't think leaving the  
Require off of the INVITE was done on purpose - just that the code
path followed blindly copied the headers from the URI into the  
triggered request and didn't check to see if it needed to explicitly
signal an extension.

We might look for places to tighten up the text on extensions so that  
implementors get this one right.

One implementor was including the Require: replaces as an imbedded  
header in the Refer-To URI. That shouldn't break anything,
but it also shouldn't be required.

What can we do to make this better?

RjS





_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 16:54:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuEZa-0000xg-SB; Mon, 19 Nov 2007 16:54:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuEZa-0000xb-9u
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:54:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEZZ-0000wz-W1
	for sip@ietf.org; Mon, 19 Nov 2007 16:54:29 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuEZW-0005iQ-Na
	for sip@ietf.org; Mon, 19 Nov 2007 16:54:29 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJLrBkd077873
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for ; Mon, 19 Nov 2007 15:53:11 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sip List 
From: Robert Sparks 
Date: Mon, 19 Nov 2007 15:53:09 -0600
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [Sip] SIPit 21: Question about offer answer
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Here's one I don't know the answer to off the top of my head:

Right now, we can offer the same SDP we've offered before (not  
changing the o line). This is used, for instance, with session-timer  
when we want to use
a re-INVITE but don't really want to change the session.

However, the specs allow the answer to such a non-changed offer to be  
different from the previous answer.

What was the motivation? There were a few attendees at SIPit 21  
arguing that implementation would be simpler for them if this answer  
had to be a copy of the previous answer as well. Did we allow it to  
change just because we could? Or is there an application I'm not  
remembering that really needs this flexibility? If not, would we be  
willing to add this restriction?

RjS


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 17:03:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuEiW-0006Dv-4n; Mon, 19 Nov 2007 17:03:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuEiV-0006Dg-G0
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:03:43 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEiV-0006DV-3i
	for sip@ietf.org; Mon, 19 Nov 2007 17:03:43 -0500
Received: from smtp-1.hut.fi ([130.233.228.91])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuEiT-00050M-K3
	for sip@ietf.org; Mon, 19 Nov 2007 17:03:42 -0500
Received: from localhost (katosiko.hut.fi [130.233.228.115])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAJM3enJ007894;
	Tue, 20 Nov 2007 00:03:40 +0200
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new,
	port 10024)
	with LMTP id 15629-07-6; Tue, 20 Nov 2007 00:03:38 +0200 (EET)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAJM2CBk007251;
	Tue, 20 Nov 2007 00:02:12 +0200
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 5CD653A2CDE;
	Tue, 20 Nov 2007 00:02:12 +0200 (EET)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 02695-09; Tue, 20 Nov 2007 00:02:10 +0200 (EET)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id 2E41E3A2CD8;
	Tue, 20 Nov 2007 00:02:10 +0200 (EET)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Tue, 20 Nov 2007 00:02:09 +0200
Message-ID: <20071120000209.1j03lfc0g80ogcc0@horde-intra.tml.hut.fi>
Date: Tue, 20 Nov 2007 00:02:09 +0200
From: sergiole@tml.hut.fi
To: Attila Sipos 
Subject: RE: [Sip] Can a transaction
	statelessproxysupportOutbounddraft?Ifyes, how will the response be sent
	back theUAbehind NAT
References: <680808427CF931459462C3D78CB5EC60A03029@EXVS02.nasstar-t1.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC60A03029@EXVS02.nasstar-t1.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Hi,


> I feel this would not be a problem for a stateless proxy providing that
> it is not just a raw socket descriptor id that is passed to
> the registrar.  The branch parameter in the Via would need
> some kind of hashed/encrypted "reboot count" parameter as well
> as the socket id.  Then if the edge-proxy rebooted, it would know that
> the response coming back is stale.  There are many ways to do the
> hashing/encryption - you could use a method similar to that used
> in the gruu draft Appendix A.2.
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-15
> .txt

   In outbound 10, 5.2.  Generating Flow Tokens :

"When the proxy boots it selects a 20-octet crypto
        random key called K that only the Edge Proxy knows."


   Instead to using the 'reboot count', the approach mentioned in the =20
draft already considers the case of old flow tokens that can remain =20
stored in the registrar by using a different key every time the proxy =20
reboots.



> So the Via header's branch parameter would contain encoded
> information about:
> 1. the flow back to the UA (socket id, IP, port)
> 2. the reboot count

   Our approach tries to use the flow token also in responses: we just =20
put the flow token in the Via. As mentioned before:
   -the UA stores the flow token when it receives a 200 OK after REGISTER;
   -then it puts it into every SIP request that is sent over a flow;
   -then the edge proxy copies the flow token to the URI part of the Via whe=
n
it composes the Via before to forward the message.
   -Later, when the response arrives at the edge proxy, it tries to decode
the flow token in the Via, if it succeeds, it  forwards the response over
the flow indicated in the flow token.


> So my proposal is generating some kind of flow token (but not THE same
> "flow token"as used in the REGISTER).  So there is the "flow token" as
described in
> theoutbound draft and now there is also a "branch flow token" that I am
?proposing.

   Perhaps can be a possible solution but seems complex.
   At what moment you generate the "branch flow token" (for example, =20
when the Via is created?)
   I can not understand completely the idea, from my point of view it is eas=
ier
to use the same flow token. Considering that the flow token considers =20
the reboot, why it could be an advantage to use the "branch flow =20
token" instead of the flow-token ?


Regards,

Sergio

Quoting Attila Sipos :

>
>>>  The problem with the above (separated elements) is that there is not
>>> synchronization about the state of the socket descriptors. As
> mentioned
>>> before, if the edge proxy crashes the socket descriptors used
> immediately
>>> after reboot could result in delivering messages to different flows.
>>>
>>>  In my opinion the randomness included in the flow token avoids that
> to
>>> happen, since after reboot the flowtoken can not be decoded and/or
> find an
>>> existing flow and that cause the return a error response.
>
>
> Yes, absolutely.  And this is a problem with stateful proxies too.
>
> I have agreed with everything you've said.
> However, I still think there is a way to do an outbound-compatible
> edge proxy with a transaction-stateless/call-stateless proxy.
>
> So I now go back to say something similar to what I said before.
> But first, I will refer to something you said in an earlier mail:
>
>>>  Furthermore my registrar should not store socket descriptors
>>> due that if the edge proxy crashes, the registrar could have a
>>> number of descriptor that after the crash belong to other flows.
>
> I feel this would not be a problem for a stateless proxy providing that
> it is not just a raw socket descriptor id that is passed to
> the registrar.  The branch parameter in the Via would need
> some kind of hashed/encrypted "reboot count" parameter as well
> as the socket id.  Then if the edge-proxy rebooted, it would know that
> the response coming back is stale.  There are many ways to do the
> hashing/encryption - you could use a method similar to that used
> in the gruu draft Appendix A.2.
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-15
> .txt
>
> So the Via header's branch parameter would contain encoded
> information about:
> 1. the flow back to the UA (socket id, IP, port)
> 2. the reboot count
>
> So now I go back to something else you said:
>>> 2) generate again the flow token for every request (very bad from
>>> security point of views) and destroys the consistency of the system
>>> since you can send requests for non existing flows. Note that the
>>> draft mentions that the flow and the flow token is only created with
> REGISTERs.
>
> So my proposal is generating some kind of flow token (but not THE same
> "flow token"
> as used in the REGISTER).  So there is the "flow token" as described in
> the
> outbound draft and now there is also a "branch flow token" that I am
> proposing.
> And, as explained before, the information in the "branch flow token" is
> used to
> route responses back to the UA.  But the original "flow token" is never
> changed.
> The original "flow token" would still be used when forwarding requests
> to
> the UA because the Edge Proxy (in your diagram) would've added it to the
> Path.  So requests to the UA would still work.
>
> Now I'm not sure about the security aspects.
> What security problems could there be with "branch flow token" idea?
>
> Regards,
> Attila
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 16 November 2007 15:53
> To: Attila Sipos
> Subject: RE: [Sip] Can a transaction
> statelessproxysupportOutbounddraft?Ifyes, how will the response be sent
> back theUAbehind NAT
>
>
>
>> I am starting to see the problems.
>>
>> If I understand correctly, your scenario is this...
>>
>> REGISTRAR--------PROXY----------NAT---------SIP UA
>>
>> Can you confirm?
>
> more specifically my scenario is
>
> REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA
>
>
> where PROXY is a traditional SIP proxy
>
>
>> And, since you were talking about scalability, you might also have
>> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>>
>> is this right?
>
>
>   About scalability I was thinking about
>
>
>                         /EDGEPROXY1\
> REGISTRAR/PROXY--------            ----------NAT---------SIP UA
>                         \EDGEPROXY2/
>
>
>   So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.
>
>
>   I have no experience with registrars, I guess that in your case you
> have a REGISTRAR/EDGEPROXY in the same process (or group of processes)
> and not REGISTRAR--------EDGEPROXY (linked by other means).
>
>   The problem with the above (separated elements) is that there is not
> synchronization about the state of the socket descriptors. As mentioned
> before, if the edge proxy crashes the socket descriptors used
> immediately after reboot could result in delivering messages to
> different flows.
>
>   In my opinion the randomness included in the flow token avoids that to
> happen, since after reboot the flowtoken can not be decoded and/or find
> an existing flow and that cause the return a error response.
>   Then another entry in the registrar binding will be used, i.e. other
> flow token. If you have a second edge proxy (that does not crashed at
> the same time that the first one :) and the flow token belongs to the
> second edge proxy, the message will reach the UA over a flow previously
> established to the second edge proxy.
>
>
>
> BR
>
> Sergio
>
>
> Quoting Attila Sipos :
>
>>
>>
>>>>>>> 3.
>>>>>>>> In the Via header's branch parameter, it would encode the
>> required
>>>>>>>> flow token.
>>>>>>>
>>>>>>> Here is the issue : From were you get the flow token?
>>>>>>> (In my previous email I mentioned 2 options... )
>>>>>>>
>>>>>
>>>>> OK I'm starting to see your problem.
>>>>>
>>>>> The registration record stores the flow token (obviously)
>>>>
>>>> It seems that you are integrating the edge proxy and registrar in
>>>> the
>> same code, right?
>>
>> yes, that's it.
>>
>>
>>>>> And the socket id for the flow would be stored as well (for
>>>>
>>>> Can you confirm that you call socket id to the socket/file
>>>> descriptor
>> of the connection?
>>
>> yes.
>>
>>>>> connection-oriented
>>>>> protocols). So if you received a request on that socket, you could
>>>>> match that up to one of the registration records and hence, one of
>> the
>>>>> flow tokens.
>>>>>
>>>>
>>>>  Good approach. I assume that you have available the socket
>> descriptor
>>>> in the registrar, so basically you consider storing the socket
>> descriptor
>>>> (number) in the registrar tables. Then perhaps using a flow token it
>> is not
>>>> necessary since you have available in the socket descriptor all the
>> information
>>>> that describes a flow (TCP case).
>>
>> That's true.  I might not need the flow tokens.
>>
>>
>>>>> I hope I have explained how the flow token might be mapped to the
>>>>> socket.
>>>>
>>>>  Yes if my comments above make sense..
>>>>
>>>>> I can now see that my idea wouldn't work for UDP.
>>>>
>>>>  Now for UDP perhaps you can consider storing the socket descriptor
>> for
>>>> UDP and the IP and port for the flow from the NAT.
>>
>> yes, that would work I think.
>>
>>
>>>>  Furthermore my registrar should not store socket descriptors due
>> that
>>>> if the edge proxy crashes, the registrar could have a number of
>> descriptor
>>>> that after the crash belong to other flows.
>>>>
>>>>  I generate the flow token with REGISTER and send it to the
>>>> registrar (other node). The approach works as the draft says for
>>>> incoming
>> requests
>>>> (to the Calle). Now when the Callee  sends requests, and the
>>>> requests
>> are
>>>> sent over the flow, the responses of that request reach first the
>>>> edge
>> proxy
>>>> and it can not forward them to the Callee over the flow, because
>>>> these responses don't have the flow token (and the flow token is not
>
>>>> stored
>> in
>>>> the edge proxy)...
>>
>> I am starting to see the problems.
>>
>> If I understand correctly, your scenario is this...
>>
>> REGISTRAR--------PROXY----------NAT---------SIP UA
>>
>> Can you confirm?
>>
>> And, since you were talking about scalability, you might also have
>> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>>
>> is this right?
>>
>>
>>>>> But what if you used the gruu in the contact to match up with the
>> gruu
>>>>> of a registration?  Then the registration record tells tells you
>> about
>>>>> the flow token.  That would work wouldn't it?
>>>>
>>>>  I have not background with gruu. Could you recommend what could I
>> read about it?
>>
>> Sorry, I didn't mean gruu, I was mixing up my drafts!
>> I was just looking for a unique identifier for the UA which is the
>> sip.instance from the outbound draft (not gruu).
>>
>>
>> Regards,
>> Attila
>>
>
>
>





_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 17:25:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuF2z-000663-Ig; Mon, 19 Nov 2007 17:24:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuF2x-0005zl-E0
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:24:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF2x-0005zc-0L
	for sip@ietf.org; Mon, 19 Nov 2007 17:24:51 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuF2u-0006fm-JJ
	for sip@ietf.org; Mon, 19 Nov 2007 17:24:50 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJMNVtR079555
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 19 Nov 2007 16:23:32 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E0437ED50@xmb-rtp-215.amer.cisco.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437ED50@xmb-rtp-215.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6A10822E-CAC9-49DB-8DF5-200EFB342BF9@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Mon, 19 Nov 2007 16:23:29 -0600
To: "Sanjay Sinha (sanjsinh)" 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4846/Mon Nov 19 12:26:19 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Yes, I did mean 200 INVITE.

On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:

> It is not clear from the call flow if the 200 OK is for PRACK or  
> INVITE?
>
> I guess you meant 200 OK for Invite. If that is the case, I think the
> RFC is clear that the answer sdp is optional in it and if it does have
> an answer sdp, it MUST be idential to answer in 18x.
>

Really? Point me to where you find this please.

> But I think the
> offer-answer draft has clarified it further that it should not have  
> any
> answer sdp. This is probably harsh in case of one offer-answer  
> exchange,
> but makes sense if there are multiple early dialog offer-answer
> exchanges in say Prack/200 OK or using UPDATE.
>
> Sanjay
>
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: Monday, November 19, 2007 4:14 PM
>> To: sip List
>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>
>> There was a lot of discussion and disagreement at SIPit21
>> about whether the following 200 OK is allowed (or should) have
>> SDP in it:
>>
>> INVITE (offer)
>> -------->
>> 18x (with 100rel) (answer)
>> <--------
>> PRACK
>> --------->
>> 200 OK (can this carry SDP?)
>> <---------
>> ACK
>> --------->
>>
>> I couldn't find anything definitive in RFC form. Paul's
>> offeranswer draft talks about this I think.
>>
>> If I understand things, the right answer here is that it's not
>> supposed to carry any SDP and that you should ignore it if it  
>> shows up.
>>
>> The question is, other than waste, what can go wrong if it is there?
>> When we end up with clear text around the requirement, will it
>> say SDP SHOULD NOT, or MUST NOT appear?
>>
>> Or do I have this wrong?
>>
>> RjS
>>
>>
>> _______________________________________________
>> 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
>>



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 17:44:05 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuFLT-0001ex-Io; Mon, 19 Nov 2007 17:43:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuFLR-0001KN-7i
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:43:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuFLQ-00015l-7W; Mon, 19 Nov 2007 17:43:56 -0500
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IuFLP-000660-F7; Mon, 19 Nov 2007 17:43:55 -0500
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60653
	helo=[192.168.0.4])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1IuFLN-0008GH-8p; Mon, 19 Nov 2007 22:43:53 +0000
In-Reply-To: <4741E624.9010805@nostrum.com>
References: <4730C66F.2070803@alcatel-lucent.com>
	<4741E624.9010805@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8F34894D-AB5F-45F0-95C0-7326A6F2E5CA@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins 
Subject: Re: [Sip] SIP IPv6 ABNF: Essential correction to RFC3261
Date: Mon, 19 Nov 2007 22:44:02 +0000
To: Adam Roach 
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: IETF SIP List ,
	Brian E Carpenter ,
	MMUSIC WG 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Can someone familiar with the issue also check the ABNF in RFC 4566  
(SDP)? From a quick look, it seems that it has a similar problem...

Colin



On 19 Nov 2007, at 19:38, Adam Roach wrote:
> For the record: this seems to be a real problem in the original  
> ABNF, and the proposed fix appears correct to me. I support adding  
> this to the next batch of essential corrections.
>
> /a
>
> Vijay K. Gurbani wrote:
>> Folks: While performing the Gen-ART review of the
>> draft-ietf-sipping-ipv6-torture-test document, an extant bug in
>> the IPv6 ABNF production rules of RFC3261 was discovered.
>>
>> A quick dialog with the chairs resulted in the understanding
>> that this could potentially be fixed as part of the SIP essential
>> corrections process, once it was ratified by the WG.
>>
>> Brian and I have submitted a short draft describing this bug and
>> its resolution to the IETF.  Until it appears in the archives, you
>> can get a copy from
>> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/ 
>> draft-gurbani-sip-ipv6-abnf-fix-00.txt
>> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/ 
>> draft-gurbani-sip-ipv6-abnf-fix-00.html
>>
>> Thanks.
>>
>> - vijay


-- 
Colin Perkins
http://csperkins.org/




_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 17:56:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuFXf-0007E8-Re; Mon, 19 Nov 2007 17:56:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuFXf-0007Dk-6Y
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:56:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuFXe-0007Da-S5; Mon, 19 Nov 2007 17:56:34 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IuFXe-0006Lj-G0; Mon, 19 Nov 2007 17:56:34 -0500
Received: from orthrus.local (ppp-70-242-127-246.dsl.rcsntx.swbell.net
	[70.242.127.246]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAJMuU5H081416
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Nov 2007 16:56:31 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <4742149C.70401@nostrum.com>
Date: Mon, 19 Nov 2007 16:56:28 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Colin Perkins 
Subject: Re: [Sip] SIP IPv6 ABNF: Essential correction to RFC3261
References: <4730C66F.2070803@alcatel-lucent.com>	<4741E624.9010805@nostrum.com>
	<8F34894D-AB5F-45F0-95C0-7326A6F2E5CA@csperkins.org>
In-Reply-To: <8F34894D-AB5F-45F0-95C0-7326A6F2E5CA@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4847/Mon Nov 19 16:17:49 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: IETF SIP List ,
	Brian E Carpenter ,
	MMUSIC WG 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

On 11/19/07 4:44 PM, Colin Perkins wrote:
> Can someone familiar with the issue also check the ABNF in RFC 4566 
> (SDP)? From a quick look, it seems that it has a similar problem...

By my readying, you are correct -- the ABNF rules in 4566 suffer from 
the same flaw. From an ANBF perspective, I would propose that the 
solution is the same as Vijay and Brian detail in their draft. From a 
process perspective, I don't know how to handle it (outside of the 
relatively invisible RFC errata process).

/a

>
>
> Colin
>
>
>
> On 19 Nov 2007, at 19:38, Adam Roach wrote:
>> For the record: this seems to be a real problem in the original ABNF, 
>> and the proposed fix appears correct to me. I support adding this to 
>> the next batch of essential corrections.
>>
>> /a
>>
>> Vijay K. Gurbani wrote:
>>> Folks: While performing the Gen-ART review of the
>>> draft-ietf-sipping-ipv6-torture-test document, an extant bug in
>>> the IPv6 ABNF production rules of RFC3261 was discovered.
>>>
>>> A quick dialog with the chairs resulted in the understanding
>>> that this could potentially be fixed as part of the SIP essential
>>> corrections process, once it was ratified by the WG.
>>>
>>> Brian and I have submitted a short draft describing this bug and
>>> its resolution to the IETF.  Until it appears in the archives, you
>>> can get a copy from
>>> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/draft-gurbani-sip-ipv6-abnf-fix-00.txt 
>>>
>>> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/draft-gurbani-sip-ipv6-abnf-fix-00.html 
>>>
>>>
>>> Thanks.
>>>
>>> - vijay
>
>



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 17:59:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuFZz-0004hB-8h; Mon, 19 Nov 2007 17:58:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuFZw-0004h6-OQ
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:58:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFZw-0004gy-Eb
	for sip@ietf.org; Mon, 19 Nov 2007 17:58:56 -0500
Received: from qmta06.westchester.pa.mail.comcast.net ([76.96.62.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuFZt-0007V4-67
	for sip@ietf.org; Mon, 19 Nov 2007 17:58:56 -0500
Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44])
	by QMTA06.westchester.pa.mail.comcast.net with comcast
	id EmuS1Y00X0xGWP80500x00; Mon, 19 Nov 2007 22:58:52 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA12.westchester.pa.mail.comcast.net with comcast
	id Emys1Y00J0umElk0300000; Mon, 19 Nov 2007 22:58:53 +0000
X-Authority-Analysis: v=1.0 c=1 a=DqGMTaB2pgUA:10 a=qGZtNZ3Y1cSr-afpUPwA:9
	a=jlPRu3cG0ac0iTbGIAcA:7 a=ZEkOe_LFGhnpJVHkykrzkFlQwskA:4
	a=0MAqpqVwYqEA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAJMwqSV029581
	for ; Mon, 19 Nov 2007 17:58:52 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAJMwqu8029577;
	Mon, 19 Nov 2007 17:58:52 -0500
Date: Mon, 19 Nov 2007 17:58:52 -0500
Message-Id: <200711192258.lAJMwqu8029577@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <5F06E0FE-117D-40D2-9026-2B010D21548E@nostrum.com>
	(rjsparks@nostrum.com)
Subject: Re: [Sip] SIPit 21: REFER with Replaces - and Require: replaces
References: <5F06E0FE-117D-40D2-9026-2B010D21548E@nostrum.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Robert Sparks 

   Here's a really interesting one.

   Lots of people are sending REFER with a Refer-To URI that has an  
   embedded Replaces header.
   This is what we're specifying in cc-transfer.

   Nobody puts Require: replaces in the REFER request (and I don't think  
   they should - does anybody disagree?)

   However, very few implementations are putting Require: replaces in  
   the triggered INVITE. They're copying the Replaces header into
   the INVITE though.

That's OK, the UA that processes the REFER isn't *supposed* to put a
"Require: replaces" header into the generated INVITE unless there is a
"?Require=replaces" header parameter in the Refer-To URI.

(Because otherwise the sender of the REFER couldn't specify "I want
you to send an INVITE with a Replaces header but without a 'Require:
replaces' header.  Such an INVITE is clearly legal and its effects are
well-defined, although not very useful.)

   This will cause very wrong things to happen if that triggered INVITE  
   forks.

Or if the intended destination of the INVITE doesn't happen to support
Replaces.  Hence, the sender of the REFER should always include
"?Refer=replaces" in the Refer-To URI.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 18:34:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuG7x-0001iK-94; Mon, 19 Nov 2007 18:34:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuG7v-0001i1-Fe
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 18:34:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuG7v-0001hn-5Q
	for sip@ietf.org; Mon, 19 Nov 2007 18:34:03 -0500
Received: from smtp1.versatel.nl ([62.58.50.88])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuG7q-0008DJ-LU
	for sip@ietf.org; Mon, 19 Nov 2007 18:34:03 -0500
Received: (qmail 14514 invoked by uid 0); 19 Nov 2007 23:35:08 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6])
	([87.212.11.198]) (envelope-sender )
	by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 19 Nov 2007 23:35:08 -0000
Message-ID: <47421D62.3040908@zonnet.nl>
Date: Tue, 20 Nov 2007 00:33:54 +0100
From: Jeroen van Bemmel 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Paul Kyzivat 
Subject: Re: [Sip] Status of require headers in the re-INVITE request.
References: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>	<473DDB80.8060507@cisco.com>	
	<4741FDDA.6000902@cisco.com>
In-Reply-To: <4741FDDA.6000902@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798
Cc: sip@ietf.org, Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Christer,

RFC3261 is pretty clear on the intended scope:

8.1.1.9 Supported and Require

   If the UAC supports extensions to SIP that can be applied by the
   server *_to the response_*, the UAC SHOULD include a Supported header
   field in the request listing the option tags (Section 19.2) for those
   extensions.

Still, some drafts / RFC may have sneaked through that use a different 
interpretation of scope. RFC3329 (sec-agree) came up with a "creative" 
use, for example.

Regards,
Jeroen

Paul Kyzivat wrote:
>
>
> Christer Holmberg wrote:
>> Hi,
>>  
>> I think this discussion touches on an issue, which I know has caused 
>> some interop concerns:
>>  
>> Is the Supported/Require header only transaction specific, or is it 
>> dialog specific?
>>  
>> If it is dialog specific, I would say that you don't need to include 
>> anything in the re-INVITE, if it was already included in the INVITE. 
>> But, then it would also mean that whatever you indicated in the 
>> INVITE (e.g. 100rel) is also valid for the re-INVITE.
>
> For many usages it must have a scope longer than a single transaction. 
> And dialog scope isn't always right either. (Some apply to non-dialog 
> usages.) In practice, anything that seems to have dialog scope will be 
> broken by 3pcc and so will at best have to be "from henceforth in the 
> dialog until overridden". And overrides are themselves a problem 
> because there is no Unrequired header.
>
> I haven't tried to do an exhaustive analysis of all the different 
> options, but I have gut feeling that there is no single definition of 
> scope that will work for all of them - that there will be examples 
> that assume different scopes.
>
>     Paul
>
>> Regards,
>>  
>> Christer
>>
>> ________________________________
>>
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: Fri 16/11/2007 19:03
>> To: nataraju.basavaraju@wipro.com
>> Cc: sip@ietf.org
>> Subject: Re: [Sip] Status of require headers in the re-INVITE request.
>>
>>
>>
>>
>>
>> nataraju.basavaraju@wipro.com wrote:
>>> Paul,
>>>
>>> You are right, its not a mandatory that re-INVITE carry the same set of
>>> options which INVITE carried. It would vary from application to
>>> application.
>>
>> And the meaning when it changes may also vary from implementation to
>> implementation because it is not standardized.
>>
>>> To make the implementation simpler UAs might decide to send the same 
>>> set
>>> of options negotiated during initial INVITE transaction.
>>
>> That would be a safe thing to do, but may not always be possible.
>>
>>> At least its
>>> not acceptable to add more options in re-INVITE, which were not
>>> negotiated during INTITE transaction.
>>
>> I would say that it might not be wise, or might be asking for trouble,
>> but its not banned by the specs. Whether it is acceptable or not is
>> something that will be judged by the recipient.
>>
>>> If so it might end up with a an
>>> issue with refresh (if remote guy does not support the new option).
>>
>> Yes you might. So if you do it you had better be prepared to get a 420
>> error and recover.
>>
>> More difficult that adding options is taking them away, which is what
>> the original poster wanted to do. There is no Unrequire header, and
>> while there is an Unsupported header it may only be used in a 420 
>> response.
>>
>> Suppose Alice originally called Bob, specifying Supported:100rel, and
>> Bob answered with Require:100rel and used reliable provisionals. Then
>> Alice wants to send a reinvite but doesn't want to use 100rel any
>> longer. She can omit Supported:100rel from the reinvite, but there is no
>> guarantee that Bob won't remember it and again put Require:100rel in the
>> response and use reliable provisionals. (If any provisionals are used at
>> all.) The best Alice can do is hope. If she gets a 1xx with
>> Require:100rel she has no real option except to send a PRACK.
>>
>> Note that Supported and Require are among the things that are supposed
>> to be included in an OPTIONS response. OPTIONS is typically used outside
>> a dialog. For the Supported and Require values in the OPTIONS response
>> to have any utility they must remain valid beyond the transaction. One
>> would expect that they are valid until further notice I suppose.
>>
>> Basically this is a mess.
>>
>>         Paul
>>
>>> As
>>> you said it has interoperability issue, because different people
>>> implement in different manner.
>>
>> Yes.
>>
>>> Regards,
>>> Nataraju A B
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>> Sent: Friday, November 16, 2007 6:40 PM
>>> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
>>> Infrastructure)
>>> Cc: vineet.gupta@motorola.com; sip@ietf.org
>>> Subject: Re: [Sip] Status of require headers in the re-INVITE request.
>>>
>>> Nataraju,
>>>
>>> Why do you think this behavior is required?
>>>
>>> The scope of applicability of Supported, Require, etc. is not well
>>> defined. If you want to be certain, then you should repeat these in
>>> every request. But if you *don't* include them in every request it is
>>> still likely that some peers will remember a value you sent earlier and
>>> assume it still applies.
>>>
>>> This is a potential interoperability issue and should be fixed, but I
>>> think it will be difficult. To be useful these options generally 
>>> need to
>>> have a scope longer than a single transaction, yet if you assume they
>>> should have longer scope then it becomes difficult to define when that
>>> scope ends.
>>>
>>> In your particular case, if you want to use PRACK for the initial 
>>> INVITE
>>> but you don't want to use it for reINVITE, I guess you can try omitting
>>> the Require:100rel in the reINVITE and hope for the best. But don't get
>>> upset if somebody still sends you PRACKs.
>>>
>>>       Thanks,
>>>       Paul
>>>
>>> nataraju.basavaraju@wipro.com wrote:
>>>> Comments inline...
>>>>
>>>> *Regards,*
>>>> *Nataraju A B*
>>>>
>>>> ----------------------------------------------------------------------
>>>> -- 
>>>> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
>>>> *Sent:* Friday, November 16, 2007 1:10 PM
>>>> *To:* sip@ietf.org
>>>> *Subject:* [Sip] Status of require headers in the re-INVITE request.
>>>>
>>>>     Hi,
>>>>         I have a doubt related to using Require:100rel in re-INVITE
>>> requests.
>>>>         *If a Require header was used in the INVITE request 
>>>> establishing
>>> the
>>>>     dialog, is it mandatory to include the same Require header in
>>>>     subsequent re-INVITE requests within the dialog?
>>>>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>>>>     Require header values that of INVITE.
>>>>         To be specific, if INVITE request contained Require:100rel, 
>>>> then
>>>>     inclusion of Require:100rel in re-INVITE would require the
>>>>     originator to handle Reliable provisional responses and respond
>>>>     accordingly. So, it would also imply that re-INVITE also takes
>>> same
>>>>     call establishment time (owing to multiple messages like 183
>>> session
>>>>     in Progress, PRACK, 180 ringing, PRACK etc.).
>>>>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>>>>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>>>>     has to generate 1xx. if UAS generates 1xx responses for re-INVITE,
>>>>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it
>>> is
>>>>     not mandatory to send  1xx for re-INVITE, hence even if
>>>>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>>>>     with out PRACK transaction.
>>>>         I agree, that such delay in re-INVITE might be acceptable 
>>>> given
>>> that
>>>>     re-INVITE requires the user-intervention, but it complicates makes
>>>>     the re-INVITE handling as complicated as the INVITE handling.
>>> Also,
>>>>     if the initial INVITE involved procedures such as QoS negotiation
>>>>     the re-INVITE state-machine complicates even further.
>>>>         [ABN] In most of the cases, re-INVITE is not expected to 
>>>> undergo
>>>>     user-intervention. hence in most of the cases it would end up with
>>>>     re-INV, 200, ACK only...
>>>>         In general, re-INVITE is expected to perform subset of what
>>> happened
>>>>     in INVITE transaction. it should not create any issues to handle
>>> 1xx
>>>>     responses reliably.
>>>>         Hope this answers all your questions...
>>>>         Regards,
>>>>     Vineet.
>>>>         /"You're only given a little spark of madness. You mustn't 
>>>> lose
>>>> it."/
>>>>    
>>>>
>>>> ----------------------------------------------------------------------
>>>> -- 
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> The information contained in this electronic message and any 
>>> attachments to this message are intended for the exclusive use of 
>>> the addressee(s) and may contain proprietary, confidential or 
>>> privileged information. If you are not the intended recipient, you 
>>> should not disseminate, distribute or copy this e-mail. Please 
>>> notify the sender immediately and destroy all copies of this message 
>>> and any attachments.
>>>
>>> WARNING: Computer viruses can be transmitted via email. The 
>>> recipient should check this email and any attachments for the 
>>> presence of viruses. The company accepts no liability for any damage 
>>> caused by any virus transmitted by this email.
>>>
>>> www.wipro.com
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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
>


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 18:45:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuGIM-00014Y-If; Mon, 19 Nov 2007 18:44:50 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuGIL-00014P-TR
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 18:44:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuGIL-00014G-JI
	for sip@ietf.org; Mon, 19 Nov 2007 18:44:49 -0500
Received: from smtp2.versatel.nl ([62.58.50.89])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuGIL-0007TD-3G
	for sip@ietf.org; Mon, 19 Nov 2007 18:44:49 -0500
Received: (qmail 20667 invoked by uid 0); 19 Nov 2007 23:44:47 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6])
	([87.212.11.198]) (envelope-sender )
	by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 19 Nov 2007 23:44:47 -0000
Message-ID: <47421FED.5020604@zonnet.nl>
Date: Tue, 20 Nov 2007 00:44:45 +0100
From: Jeroen van Bemmel 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Robert Sparks 
Subject: Re: [Sip] SIPit 21: BNF and DIGEST authentication
References: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
In-Reply-To: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Robert,

We cannot make the quotes optional in the challenge, but we could make 
them mandatory in both cases. That would at least be easier to get 
right. Parsers would still need to support unquoted responses though

Regards,
Jeroen

Robert Sparks wrote:
> We are _still_ seeing interoperability problems because of quotes 
> around the qop parameter value in challenges and responses.
>
> What's specified now is that quotes MUST appear in challenges (it's a 
> list of things) and MUST NOT appear in responses (it's a choice of one 
> thing).
>
> This causes lots of people to write broken code.
>
> For the code that does work, this causes people to either build 
> separate parsers for headers with the same name, using the knowledge 
> of whether its a challenge or response to invoke the right parser, or 
> to build parsers that don't follow the BNF we've provided.
>
> Would it make more sense to change the BNF to allow the quotes 
> optionally in either the challenge or the response?
>
> Nobody that I've asked is actually re-using an HTTP parser for this, 
> and nobody seems to be getting the number of values for the parameter 
> wrong. Most of the folks I ask are building their parsers this way anyhow
>
> What would be bad about making this change to the spec?
>
> RjS
>
>
>
> _______________________________________________
> 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
>


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 19:11:38 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuGi7-0003Br-8c; Mon, 19 Nov 2007 19:11:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuGi5-0003Bm-0T
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 19:11:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuGi4-0003Bd-Mo
	for sip@ietf.org; Mon, 19 Nov 2007 19:11:24 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuGi0-0000TM-V4
	for sip@ietf.org; Mon, 19 Nov 2007 19:11:24 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2007 19:11:20 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAK0BK3n014966; 
	Mon, 19 Nov 2007 19:11:20 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAK0BCWN017027; 
	Tue, 20 Nov 2007 00:11:20 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 19:10:58 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 19:10:58 -0500
Message-ID: <47422614.5020406@cisco.com>
Date: Mon, 19 Nov 2007 19:11:00 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Francois Audet 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
References: <4741BB94.80202@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1348A595@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1348A595@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 00:10:58.0159 (UTC)
	FILETIME=[D36857F0:01C82B09]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--22.282700-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4204; t=1195517480;
	x=1196381480; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20 |To:=20Francois=20Audet=20;
	bh=f2w/ycqV+1t0XVDi6Y48nE6op6e7jo2oc4oG9WIMSlQ=;
	b=aYveiGZjnYFaCW1Mr8ZV1uwcjjChtpQKnHKYh67QBzwyJqHkdzQ4NbAWh4jvq8tzxqpAvh9w
	4eH3ZosfdHElq5aPOv/9+UqBZQqu+DKFqa2dApl2wKvfGInZkW1ieUhS;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

This problem has bugged me for a *long* time. I've tried to encourage 
use of tel: when the target address is a phone number, and I've tried to 
encourage care in what is used to display caller id. (Don't just strip 
the domain and display the number.) But I haven't had much luck.

Of course, not having an identity solution for phone numbers is also a 
serious problem, with no known solution that I am aware of.

Perhaps we need to start using the ENUM mappings of telephone numbers as 
the basis of identity. E.g.

	From: "+1-978-555-1234" 

and then apply sip identity to that.

	Thanks,
	Paul

Francois Audet wrote:
> Jonathan,
> 
> What you are describing is actually a problem of non-compliance
> with SIP, where people are improperly using SIP URIs
> as if they were a Tel URI.
> 
> As you point out, they are adding a "bogus" domain name and
> route purely on the phone number and ignore the domain
> name.
> 
> This is quite unfortunate because, it 
> invalidates most "phone number-derived SIP URIs" in terms
> of SIP Identity. It is unfortunate, since if people used
> a native Tel URI for cases where the domain is 
> irrelevant, we wouldn't have this problem (and we couldn't
> use DTLS-SRTP for this).
> 
> Basically, "telephone number routing" overlaid on top of
> SIP breaks SIP routing. If I call somebody at +11015551212@example.com, 
> I really have no garantee that it won't end-up at 
> +11015551212@evil.org.
> 
> This problem more than a SIP Identity problem. It's more
> of a SIP usage problem.
> 
> Not sure how to deal with it.
> 
>> -----Original Message-----
>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] 
>> Sent: Monday, November 19, 2007 08:37
>> To: IETF SIP List
>> Subject: [Sip] comments on draft-ietf-sip-dtls-framework
>>
>> I think there is an additional issue that should be discussed 
>> in the security considerations section.
>>
>> The draft relies heavily on sip identity to provide integrity 
>> over the fingerprint. The underlying assumption is that a 
>> MITM downstream would need to modify the fingerprint and thus 
>> would also need to modify the identity since it couldn't 
>> resign with the original domain.
>>
>> This assumption is a good one in deployments that use 
>> user@domain identifiers - joe@example.com. However, the 
>> unfortunate reality is that the majority of sip deployments 
>> today use phone numbers. These are often represented in sip 
>> URI form - sip:9739525060@example.com. However, when phone 
>> numbers are used, the domain part is often ignored and most 
>> of the time not even rendered to the user. Even if it were, 
>> its not a "significant" part of the identifier, in that a 
>> user won't normally know or care what the domain part is.
>>
>> What this means is that when phone numbers are in use, a MITM 
>> can easily rewrite the From field. So if it was 
>> sip:9739525060@example.com they can rewrite to 
>> sip:9739525060@middle-domain.com, insert a media intermediary 
>> and new fingerprint and resign. The called UA or terminating 
>> proxy will verify that the identity is valid (which it is) 
>> and the called party is presented with the caller ID, which 
>> is JUST the phone number. So they don't notice a problem at all.
>>
>> Thus, in practice, I fear dtls-srtp will easily allow proxies 
>> and SBCs on the chain to intercept and modify the media 
>> stream, similar to what they could do with sdescriptions. 
>> This is really a problem with sip identity itself that 
>> carries over here. But I think this issue needs to be 
>> mentioned and discussed. The draft makes itself out to be 
>> substantially more secure than sdescriptions or MIKEY because 
>> of its e2e nature but in practice I don't think it will be as 
>> effective.
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 19:18:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuGoz-0003Vv-Lj; Mon, 19 Nov 2007 19:18:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuGoy-0003SV-JD
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 19:18:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuGoy-0003SC-9W
	for sip@ietf.org; Mon, 19 Nov 2007 19:18:32 -0500
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuGov-0000d7-Lo
	for sip@ietf.org; Mon, 19 Nov 2007 19:18:32 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	lAK0FIp15103; Tue, 20 Nov 2007 00:15:18 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] comments on draft-ietf-sip-dtls-framework
Date: Mon, 19 Nov 2007 18:17:05 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF134D2F0E@zrc2hxm0.corp.nortel.com>
In-Reply-To: <47422614.5020406@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Index: AcgrCeP8lykL1PyzSgirpAiYkFzNqwAAI3ZA
References: <4741BB94.80202@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1348A595@zrc2hxm0.corp.nortel.com>
	<47422614.5020406@cisco.com>
From: "Francois Audet" 
To: "Paul Kyzivat" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Funny you should say that... I was also thinking of ENUM when I wrote =
this.

But I wasn't thinking of putting the ENUM in the From. I was thinking
of doing enum on the phone number, to verify the domain of the owner, =
and
correlate it with Identity.=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Monday, November 19, 2007 16:11
> To: Audet, Francois (SC100:3055)
> Cc: Jonathan Rosenberg; IETF SIP List
> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
>=20
> This problem has bugged me for a *long* time. I've tried to=20
> encourage use of tel: when the target address is a phone=20
> number, and I've tried to encourage care in what is used to=20
> display caller id. (Don't just strip the domain and display=20
> the number.) But I haven't had much luck.
>=20
> Of course, not having an identity solution for phone numbers=20
> is also a serious problem, with no known solution that I am aware of.
>=20
> Perhaps we need to start using the ENUM mappings of telephone=20
> numbers as the basis of identity. E.g.
>=20
> 	From: "+1-978-555-1234" 
>=20
> and then apply sip identity to that.
>=20
> 	Thanks,
> 	Paul
>=20
> Francois Audet wrote:
> > Jonathan,
> >=20
> > What you are describing is actually a problem of=20
> non-compliance with=20
> > SIP, where people are improperly using SIP URIs as if they=20
> were a Tel=20
> > URI.
> >=20
> > As you point out, they are adding a "bogus" domain name and route=20
> > purely on the phone number and ignore the domain name.
> >=20
> > This is quite unfortunate because, it invalidates most "phone=20
> > number-derived SIP URIs" in terms of SIP Identity. It is=20
> unfortunate,=20
> > since if people used a native Tel URI for cases where the domain is=20
> > irrelevant, we wouldn't have this problem (and we couldn't use=20
> > DTLS-SRTP for this).
> >=20
> > Basically, "telephone number routing" overlaid on top of SIP breaks=20
> > SIP routing. If I call somebody at=20
> +11015551212@example.com, I really=20
> > have no garantee that it won't end-up at
> > +11015551212@evil.org.
> >=20
> > This problem more than a SIP Identity problem. It's more of a SIP=20
> > usage problem.
> >=20
> > Not sure how to deal with it.
> >=20
> >> -----Original Message-----
> >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> >> Sent: Monday, November 19, 2007 08:37
> >> To: IETF SIP List
> >> Subject: [Sip] comments on draft-ietf-sip-dtls-framework
> >>
> >> I think there is an additional issue that should be=20
> discussed in the=20
> >> security considerations section.
> >>
> >> The draft relies heavily on sip identity to provide integrity over=20
> >> the fingerprint. The underlying assumption is that a MITM=20
> downstream=20
> >> would need to modify the fingerprint and thus would also need to=20
> >> modify the identity since it couldn't resign with the original=20
> >> domain.
> >>
> >> This assumption is a good one in deployments that use user@domain=20
> >> identifiers - joe@example.com. However, the unfortunate reality is=20
> >> that the majority of sip deployments today use phone=20
> numbers. These=20
> >> are often represented in sip URI form -=20
> sip:9739525060@example.com.=20
> >> However, when phone numbers are used, the domain part is often=20
> >> ignored and most of the time not even rendered to the=20
> user. Even if=20
> >> it were, its not a "significant" part of the identifier, in that a=20
> >> user won't normally know or care what the domain part is.
> >>
> >> What this means is that when phone numbers are in use, a MITM can=20
> >> easily rewrite the From field. So if it was=20
> >> sip:9739525060@example.com they can rewrite to=20
> >> sip:9739525060@middle-domain.com, insert a media=20
> intermediary and new=20
> >> fingerprint and resign. The called UA or terminating proxy will=20
> >> verify that the identity is valid (which it is) and the=20
> called party=20
> >> is presented with the caller ID, which is JUST the phone=20
> number. So=20
> >> they don't notice a problem at all.
> >>
> >> Thus, in practice, I fear dtls-srtp will easily allow proxies and=20
> >> SBCs on the chain to intercept and modify the media=20
> stream, similar=20
> >> to what they could do with sdescriptions.
> >> This is really a problem with sip identity itself that=20
> carries over=20
> >> here. But I think this issue needs to be mentioned and=20
> discussed. The=20
> >> draft makes itself out to be substantially more secure than=20
> >> sdescriptions or MIKEY because of its e2e nature but in practice I=20
> >> don't think it will be as effective.
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 19:36:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuH5p-0003r0-HI; Mon, 19 Nov 2007 19:35:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuH5o-0003qq-BA
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 19:35:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuH5o-0003qh-1F
	for sip@ietf.org; Mon, 19 Nov 2007 19:35:56 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuH5k-0000zb-HX
	for sip@ietf.org; Mon, 19 Nov 2007 19:35:56 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2007 19:35:52 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAK0ZqGc022380; 
	Mon, 19 Nov 2007 19:35:52 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAK0ZqVt023382; 
	Tue, 20 Nov 2007 00:35:52 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 19:35:51 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Mon, 19 Nov 2007 19:35:52 -0500
Message-ID: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <6A10822E-CAC9-49DB-8DF5-200EFB342BF9@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: SDP in a 200OK when using 100rel
Thread-Index: Acgq+taGp4KgOrXLSeKFgl3GjzubwwABoENg
From: "Sanjay Sinha (sanjsinh)" 
To: "Robert Sparks" 
X-OriginalArrivalTime: 20 Nov 2007 00:35:51.0922 (UTC)
	FILETIME=[4DC27D20:01C82B0D]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--28.326500-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3120; t=1195518952;
	x=1196382952; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20
	|Subject:=20RE=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20
	|To:=20=22Robert=20Sparks=22=20;
	bh=+VuH8yXQMdWyFw9mow1gmkco+a+Kmw6yD7SorCnQqGA=;
	b=VW/aI4JqLmqZxYyZVDYaQ5ns6n1Uul0kt6SEp7Cco1a2pho3gA5sfW6AHENgj0Uxyoe6TjM8
	x4VnA3asHe5kt7AvOhhZRDpd8F0ZzMuwQbpCwTsLHvpSOEbGfmrTxnZp;
Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Pl. see inline...

>-----Original Message-----
>From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
>Sent: Monday, November 19, 2007 5:23 PM
>To: Sanjay Sinha (sanjsinh)
>Cc: sip List
>Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
>
>Yes, I did mean 200 INVITE.
>
>On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
>
>> It is not clear from the call flow if the 200 OK is for PRACK or=20
>> INVITE?
>>
>> I guess you meant 200 OK for Invite. If that is the case, I=20
>think the=20
>> RFC is clear that the answer sdp is optional in it and if it=20
>does have=20
>> an answer sdp, it MUST be idential to answer in 18x.
>>
>
>Really? Point me to where you find this please.

I was referring to sec. 13.2.1 of RFC 3261.

 o  If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
 correlated to that INVITE.  For this specification, that is
only the final 2xx response to that INVITE.  That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer.  The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.=20

The strengths of assertion may not be what you are looking for here.

Thanks
Sanjay



>
>> But I think the
>> offer-answer draft has clarified it further that it should not have=20
>> any answer sdp. This is probably harsh in case of one offer-answer=20
>> exchange, but makes sense if there are multiple early dialog=20
>> offer-answer exchanges in say Prack/200 OK or using UPDATE.
>>
>> Sanjay
>>
>>> -----Original Message-----
>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>> Sent: Monday, November 19, 2007 4:14 PM
>>> To: sip List
>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>>
>>> There was a lot of discussion and disagreement at SIPit21 about=20
>>> whether the following 200 OK is allowed (or should) have SDP in it:
>>>
>>> INVITE (offer)
>>> -------->
>>> 18x (with 100rel) (answer)
>>> <--------
>>> PRACK
>>> --------->
>>> 200 OK (can this carry SDP?)
>>> <---------
>>> ACK
>>> --------->
>>>
>>> I couldn't find anything definitive in RFC form. Paul's offeranswer=20
>>> draft talks about this I think.
>>>
>>> If I understand things, the right answer here is that it's not=20
>>> supposed to carry any SDP and that you should ignore it if it shows=20
>>> up.
>>>
>>> The question is, other than waste, what can go wrong if it is there?
>>> When we end up with clear text around the requirement, will it say=20
>>> SDP SHOULD NOT, or MUST NOT appear?
>>>
>>> Or do I have this wrong?
>>>
>>> RjS
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use=20
>>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>>> sipping@ietf.org for new developments on the application of sip
>>>
>


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 19:51:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuHKQ-0000XO-FQ; Mon, 19 Nov 2007 19:51:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuHKO-0000XJ-5h
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 19:51:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuHKN-0000XB-SL
	for sip@ietf.org; Mon, 19 Nov 2007 19:50:59 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuHKI-0001RK-LS
	for sip@ietf.org; Mon, 19 Nov 2007 19:50:59 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2007 19:50:44 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAK0oifV026443; 
	Mon, 19 Nov 2007 19:50:44 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAK0oYVx027394; 
	Tue, 20 Nov 2007 00:50:39 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 19:49:51 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 19:49:50 -0500
Message-ID: <47422F2F.2080008@cisco.com>
Date: Mon, 19 Nov 2007 19:49:51 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Robert Sparks 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
References: <8983EC086A9D954BA74D9763E853CF3E0437ED50@xmb-rtp-215.amer.cisco.com>
	<6A10822E-CAC9-49DB-8DF5-200EFB342BF9@nostrum.com>
In-Reply-To: <6A10822E-CAC9-49DB-8DF5-200EFB342BF9@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 00:49:50.0735 (UTC)
	FILETIME=[41BB31F0:01C82B0F]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--31.614200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3801; t=1195519844;
	x=1196383844; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20
	|To:=20Robert=20Sparks=20;
	bh=+1ZYIm/rS+7q7g33qBJaB7R+Nz55oSHeI/Y0xSGqILY=;
	b=MwB+zzmiBRCUlkm8WaJ9SQwNLWaNb6pu/mYAGyK2KJaHFsABFwei51JNZw018dw+qOF8OPL/
	yKkw7u9XllN62y1RUMtU6qNCBGKRGH7rQ1PUUA9WMNBkx365JDzSnPUh;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Robert Sparks wrote:
> Yes, I did mean 200 INVITE.
> 
> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
> 
>> It is not clear from the call flow if the 200 OK is for PRACK or INVITE?
>>
>> I guess you meant 200 OK for Invite. If that is the case, I think the
>> RFC is clear that the answer sdp is optional in it and if it does have
>> an answer sdp, it MUST be idential to answer in 18x.
>>
> 
> Really? Point me to where you find this please.

Mostly in 3261 sec 13.2.1. It says:

       o  If the initial offer is in an INVITE, the answer MUST be in a
          reliable non-failure message from UAS back to UAC which is
          correlated to that INVITE.  For this specification, that is
          only the final 2xx response to that INVITE.  That same exact
          answer MAY also be placed in any provisional responses sent
          prior to the answer.  The UAC MUST treat the first session
          description it receives as the answer, and MUST ignore any
          session descriptions in subsequent responses to the initial
          INVITE.

The first three sentences are the clearly normative part. When combined 
with RFC 3262 definition of reliable provisionals, they say that the 
reliable provisional contains the answer.

The last sentence doesn't really say the UAS may include sdp in 
subsequent responses to the invite transaction, but neither does it say 
you can't. It does say the UAC should ignore them if present, which 
implies they can be present, but says nothing about what value they must 
have if they are present.

AFAIK there is nothing that says the answer may be repeated in the 200. 
However it is seemingly done a lot, so one had better beware.

	Paul

>> But I think the
>> offer-answer draft has clarified it further that it should not have any
>> answer sdp. This is probably harsh in case of one offer-answer exchange,
>> but makes sense if there are multiple early dialog offer-answer
>> exchanges in say Prack/200 OK or using UPDATE.



>> Sanjay
>>
>>> -----Original Message-----
>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>> Sent: Monday, November 19, 2007 4:14 PM
>>> To: sip List
>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>>
>>> There was a lot of discussion and disagreement at SIPit21
>>> about whether the following 200 OK is allowed (or should) have
>>> SDP in it:
>>>
>>> INVITE (offer)
>>> -------->
>>> 18x (with 100rel) (answer)
>>> <--------
>>> PRACK
>>> --------->
>>> 200 OK (can this carry SDP?)
>>> <---------
>>> ACK
>>> --------->
>>>
>>> I couldn't find anything definitive in RFC form. Paul's
>>> offeranswer draft talks about this I think.
>>>
>>> If I understand things, the right answer here is that it's not
>>> supposed to carry any SDP and that you should ignore it if it shows up.
>>>
>>> The question is, other than waste, what can go wrong if it is there?
>>> When we end up with clear text around the requirement, will it
>>> say SDP SHOULD NOT, or MUST NOT appear?
>>>
>>> Or do I have this wrong?
>>>
>>> RjS
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
> 
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 20:11:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuHdk-0005DQ-3Z; Mon, 19 Nov 2007 20:11:00 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuHdi-0005DK-Nq
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 20:10:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuHdi-0005DC-D1
	for sip@ietf.org; Mon, 19 Nov 2007 20:10:58 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuHdh-0000yZ-Vx
	for sip@ietf.org; Mon, 19 Nov 2007 20:10:58 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2007 20:10:57 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAK1AvbL007041; 
	Mon, 19 Nov 2007 20:10:57 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAK1AnVv002232; 
	Tue, 20 Nov 2007 01:10:57 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:10:54 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:10:53 -0500
Message-ID: <4742341F.7070906@cisco.com>
Date: Mon, 19 Nov 2007 20:10:55 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Robert Sparks 
Subject: Re: [Sip] SIPit 21: REFER with Replaces - and Require: replaces
References: <5F06E0FE-117D-40D2-9026-2B010D21548E@nostrum.com>
In-Reply-To: <5F06E0FE-117D-40D2-9026-2B010D21548E@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 01:10:53.0754 (UTC)
	FILETIME=[328C99A0:01C82B12]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--26.337800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2918; t=1195521057;
	x=1196385057; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit=2021=3A=20REFER=20with=20Replaces=20-=2
	0and=20Require=3A=20replaces |Sender:=20
	|To:=20Robert=20Sparks=20;
	bh=CU/KzzYOtq+3ehXQUKAJLZqRjrOpCLAKy4k/ttqUSlc=;
	b=XgdYL2Mck4HLcQNBFTn5kt3g9VM4NNNOpMt6icH9pPEkD6jzYf/Z49XZB8uGQ0HQN6xWcNmu
	hiY3mhirLHM59v15sdN99EXEvgfkZZ46NuiIiG4cdRoPnACOCF2S//WR;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Robert Sparks wrote:
> Here's a really interesting one.
> 
> Lots of people are sending REFER with a Refer-To URI that has an 
> embedded Replaces header.
> This is what we're specifying in cc-transfer.
> 
> Nobody puts Require: replaces in the REFER request (and I don't think 
> they should - does anybody disagree?)
> 
> However, very few implementations are putting Require: replaces in the 
> triggered INVITE. They're copying the Replaces header into
> the INVITE though.
> 
> This will cause very wrong things to happen if that triggered INVITE forks.
> 
>  From talking to people at SIPit 21, I don't think leaving the Require 
> off of the INVITE was done on purpose - just that the code
> path followed blindly copied the headers from the URI into the triggered 
> request and didn't check to see if it needed to explicitly
> signal an extension.

And what would make the referee think it *should* put a Require:replaces 
into the INVITE? That is supposed to be inserted if the UAC requires 
that the Replaces be honored. But the referee doesn't require that - it 
is the referror who does. The referee may not even understand the 
"replaces" option, isn't required to, and otherwise doesn't need to.

> We might look for places to tighten up the text on extensions so that 
> implementors get this one right.
> 
> One implementor was including the Require: replaces as an imbedded 
> header in the Refer-To URI. That shouldn't break anything,
> but it also shouldn't be required.

Unpleasant as it seems, that seems to be the proper solution.

I guess another path would be to ammend 3891 so that if there was a 
Require:replaces in the REFER then the referee MUST put a 
Require:replaces in the INVITE. But backward compatibility will cause 
such a change to be useless.

This is another manifestation of the "REFER means 'do what I mean', not 
'do what I say'" situation.

> What can we do to make this better?

I see nothing better than requiring the referror to embed the 
Require:replaces. Or else live with the consequences of having the 
Replaces be ignored by those that don't support it.

Of course this isn't a problem if you already know that the refer target 
supports Replaces. This is likely to be the case most of the time. (You 
will have seen a Supported:replaces in your earlier dialog with it.) But 
it can be a problem if you are sending the INVITE to an AOR (because 
there is no gruu support) and it forks to multiple devices, some of 
which don't support Replaces.

	Paul

> RjS
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 20:17:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuHjo-000395-NF; Mon, 19 Nov 2007 20:17:16 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuHjn-00038z-Ud
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 20:17:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuHjn-000384-JV
	for sip@ietf.org; Mon, 19 Nov 2007 20:17:15 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuHjn-00017g-8F
	for sip@ietf.org; Mon, 19 Nov 2007 20:17:15 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2007 20:17:14 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAK1HER4000812; 
	Mon, 19 Nov 2007 20:17:14 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAK1Grx7021319; 
	Tue, 20 Nov 2007 01:17:14 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:17:12 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:17:12 -0500
Message-ID: <4742359B.1060301@cisco.com>
Date: Mon, 19 Nov 2007 20:17:15 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Robert Sparks 
Subject: Re: [Sip] SIPit 21: Question about offer answer
References: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com>
In-Reply-To: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 01:17:12.0343 (UTC)
	FILETIME=[1434B270:01C82B13]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--17.931700-8.000000-2
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1571; t=1195521434;
	x=1196385434; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit=2021=3A=20Question=20about=20offer=20an
	swer |Sender:=20
	|To:=20Robert=20Sparks=20;
	bh=ve0VJstfZ5zczvxPJdtMK9lIBX4zELZ0O0yVMX+xzg0=;
	b=oywan/EVn8v4iM1jTzvZ9P4kyfj+hlzqhm095ttj9pwl8DczHCdC5d6oflHFYNAkqoUOn6n0
	edPwAFWs1lgpa7cuXqRm0OplJ7MYwdFhhQqgNxFi5L4AspfNqO/BY5ri;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Robert Sparks wrote:
> Here's one I don't know the answer to off the top of my head:
> 
> Right now, we can offer the same SDP we've offered before (not changing 
> the o line). This is used, for instance, with session-timer when we want 
> to use
> a re-INVITE but don't really want to change the session.
> 
> However, the specs allow the answer to such a non-changed offer to be 
> different from the previous answer.
> 
> What was the motivation? There were a few attendees at SIPit 21 arguing 
> that implementation would be simpler for them if this answer had to be a 
> copy of the previous answer as well. Did we allow it to change just 
> because we could? Or is there an application I'm not remembering that 
> really needs this flexibility? If not, would we be willing to add this 
> restriction?

3PCC is a source of an almost unlimited set of corner cases. :-)

A 3pcc controller doing a transfer may well send an offerless invite to 
one UA and then send the offer it gets back to an entirely different UA 
than had been in the session before. So of course the answer will be 
entirely different.

There are probably other reasons, but I need more time to think of them.

	Thanks,
	Paul

> RjS
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 20:38:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuI48-0003ZL-54; Mon, 19 Nov 2007 20:38:16 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuI47-0003ZG-9Y
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 20:38:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuI47-0003Z8-01
	for sip@ietf.org; Mon, 19 Nov 2007 20:38:15 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuI42-0002Xe-OP
	for sip@ietf.org; Mon, 19 Nov 2007 20:38:14 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2007 20:38:10 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAK1cArW014523; 
	Mon, 19 Nov 2007 20:38:10 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAK1bhWL008625; 
	Tue, 20 Nov 2007 01:38:10 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:38:05 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:38:04 -0500
Message-ID: <47423A7E.6020204@cisco.com>
Date: Mon, 19 Nov 2007 20:38:06 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jeroen van Bemmel 
Subject: Re: [Sip] Status of require headers in the re-INVITE request.
References: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>	<473DDB80.8060507@cisco.com>	
	<4741FDDA.6000902@cisco.com> <47421D62.3040908@zonnet.nl>
In-Reply-To: <47421D62.3040908@zonnet.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 01:38:04.0592 (UTC)
	FILETIME=[FE9ABB00:01C82B15]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--28.419000-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11616; t=1195522690;
	x=1196386690; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20Status=20of=20require=20headers=20in=20the=20
	re-INVITE=20request. |Sender:=20
	|To:=20Jeroen=20van=20Bemmel=20;
	bh=U/CMzOOe8Cad3p8EK7yl26RTNfHRZUJKFqKJKn74MOo=;
	b=c9yaFoE68W+qZZWhSt0xBPVB8DZmpzA57u4W96YwU/tjMyg7BlBrpFs9VgwwQ7irOt5hZim+
	+muVj+KJOIIPpkSjnicvzF8bcP4otdno8wwYC8zLYR13CUsBdhqHIFPg;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 410b68b37343617c6913e76d02180b14
Cc: sip@ietf.org, Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Jeroen van Bemmel wrote:
> Christer,
> 
> RFC3261 is pretty clear on the intended scope:
> 
> 8.1.1.9 Supported and Require
> 
>   If the UAC supports extensions to SIP that can be applied by the
>   server *_to the response_*, the UAC SHOULD include a Supported header
>   field in the request listing the option tags (Section 19.2) for those
>   extensions.

That seems to imply that you can change the Supported options from 
request to request. But how do you reconcile that with the use of 
Supported in OPTIONS? For the response to OPTIONS to mean anything at 
all it must imply that you will respond affirmatively to a Require for 
the listed options at some time in the future. But when does that time end?

> Still, some drafts / RFC may have sneaked through that use a different 
> interpretation of scope. RFC3329 (sec-agree) came up with a "creative" 
> use, for example.

I haven't done a survey, but I think there are probably a lot of 
creative interpretations of the scope.

It seems that some assume that Supported in a non-OPTIONS request or 
response has similar meaning to what it would have in an OPTIONS response.

	Paul

> Regards,
> Jeroen
> 
> Paul Kyzivat wrote:
>>
>>
>> Christer Holmberg wrote:
>>> Hi,
>>>  
>>> I think this discussion touches on an issue, which I know has caused 
>>> some interop concerns:
>>>  
>>> Is the Supported/Require header only transaction specific, or is it 
>>> dialog specific?
>>>  
>>> If it is dialog specific, I would say that you don't need to include 
>>> anything in the re-INVITE, if it was already included in the INVITE. 
>>> But, then it would also mean that whatever you indicated in the 
>>> INVITE (e.g. 100rel) is also valid for the re-INVITE.
>>
>> For many usages it must have a scope longer than a single transaction. 
>> And dialog scope isn't always right either. (Some apply to non-dialog 
>> usages.) In practice, anything that seems to have dialog scope will be 
>> broken by 3pcc and so will at best have to be "from henceforth in the 
>> dialog until overridden". And overrides are themselves a problem 
>> because there is no Unrequired header.
>>
>> I haven't tried to do an exhaustive analysis of all the different 
>> options, but I have gut feeling that there is no single definition of 
>> scope that will work for all of them - that there will be examples 
>> that assume different scopes.
>>
>>     Paul
>>
>>> Regards,
>>>  
>>> Christer
>>>
>>> ________________________________
>>>
>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>> Sent: Fri 16/11/2007 19:03
>>> To: nataraju.basavaraju@wipro.com
>>> Cc: sip@ietf.org
>>> Subject: Re: [Sip] Status of require headers in the re-INVITE request.
>>>
>>>
>>>
>>>
>>>
>>> nataraju.basavaraju@wipro.com wrote:
>>>> Paul,
>>>>
>>>> You are right, its not a mandatory that re-INVITE carry the same set of
>>>> options which INVITE carried. It would vary from application to
>>>> application.
>>>
>>> And the meaning when it changes may also vary from implementation to
>>> implementation because it is not standardized.
>>>
>>>> To make the implementation simpler UAs might decide to send the same 
>>>> set
>>>> of options negotiated during initial INVITE transaction.
>>>
>>> That would be a safe thing to do, but may not always be possible.
>>>
>>>> At least its
>>>> not acceptable to add more options in re-INVITE, which were not
>>>> negotiated during INTITE transaction.
>>>
>>> I would say that it might not be wise, or might be asking for trouble,
>>> but its not banned by the specs. Whether it is acceptable or not is
>>> something that will be judged by the recipient.
>>>
>>>> If so it might end up with a an
>>>> issue with refresh (if remote guy does not support the new option).
>>>
>>> Yes you might. So if you do it you had better be prepared to get a 420
>>> error and recover.
>>>
>>> More difficult that adding options is taking them away, which is what
>>> the original poster wanted to do. There is no Unrequire header, and
>>> while there is an Unsupported header it may only be used in a 420 
>>> response.
>>>
>>> Suppose Alice originally called Bob, specifying Supported:100rel, and
>>> Bob answered with Require:100rel and used reliable provisionals. Then
>>> Alice wants to send a reinvite but doesn't want to use 100rel any
>>> longer. She can omit Supported:100rel from the reinvite, but there is no
>>> guarantee that Bob won't remember it and again put Require:100rel in the
>>> response and use reliable provisionals. (If any provisionals are used at
>>> all.) The best Alice can do is hope. If she gets a 1xx with
>>> Require:100rel she has no real option except to send a PRACK.
>>>
>>> Note that Supported and Require are among the things that are supposed
>>> to be included in an OPTIONS response. OPTIONS is typically used outside
>>> a dialog. For the Supported and Require values in the OPTIONS response
>>> to have any utility they must remain valid beyond the transaction. One
>>> would expect that they are valid until further notice I suppose.
>>>
>>> Basically this is a mess.
>>>
>>>         Paul
>>>
>>>> As
>>>> you said it has interoperability issue, because different people
>>>> implement in different manner.
>>>
>>> Yes.
>>>
>>>> Regards,
>>>> Nataraju A B
>>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>>> Sent: Friday, November 16, 2007 6:40 PM
>>>> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
>>>> Infrastructure)
>>>> Cc: vineet.gupta@motorola.com; sip@ietf.org
>>>> Subject: Re: [Sip] Status of require headers in the re-INVITE request.
>>>>
>>>> Nataraju,
>>>>
>>>> Why do you think this behavior is required?
>>>>
>>>> The scope of applicability of Supported, Require, etc. is not well
>>>> defined. If you want to be certain, then you should repeat these in
>>>> every request. But if you *don't* include them in every request it is
>>>> still likely that some peers will remember a value you sent earlier and
>>>> assume it still applies.
>>>>
>>>> This is a potential interoperability issue and should be fixed, but I
>>>> think it will be difficult. To be useful these options generally 
>>>> need to
>>>> have a scope longer than a single transaction, yet if you assume they
>>>> should have longer scope then it becomes difficult to define when that
>>>> scope ends.
>>>>
>>>> In your particular case, if you want to use PRACK for the initial 
>>>> INVITE
>>>> but you don't want to use it for reINVITE, I guess you can try omitting
>>>> the Require:100rel in the reINVITE and hope for the best. But don't get
>>>> upset if somebody still sends you PRACKs.
>>>>
>>>>       Thanks,
>>>>       Paul
>>>>
>>>> nataraju.basavaraju@wipro.com wrote:
>>>>> Comments inline...
>>>>>
>>>>> *Regards,*
>>>>> *Nataraju A B*
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> -- 
>>>>> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
>>>>> *Sent:* Friday, November 16, 2007 1:10 PM
>>>>> *To:* sip@ietf.org
>>>>> *Subject:* [Sip] Status of require headers in the re-INVITE request.
>>>>>
>>>>>     Hi,
>>>>>         I have a doubt related to using Require:100rel in re-INVITE
>>>> requests.
>>>>>         *If a Require header was used in the INVITE request 
>>>>> establishing
>>>> the
>>>>>     dialog, is it mandatory to include the same Require header in
>>>>>     subsequent re-INVITE requests within the dialog?
>>>>>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>>>>>     Require header values that of INVITE.
>>>>>         To be specific, if INVITE request contained Require:100rel, 
>>>>> then
>>>>>     inclusion of Require:100rel in re-INVITE would require the
>>>>>     originator to handle Reliable provisional responses and respond
>>>>>     accordingly. So, it would also imply that re-INVITE also takes
>>>> same
>>>>>     call establishment time (owing to multiple messages like 183
>>>> session
>>>>>     in Progress, PRACK, 180 ringing, PRACK etc.).
>>>>>     [ABN] Yes, UA's should be ready to handle PRACK txn triggered by
>>>>>     re-INVITE txn. Also sending 100rel in re-INVITE does not mean UAS
>>>>>     has to generate 1xx. if UAS generates 1xx responses for re-INVITE,
>>>>>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 200-PRK, ... it
>>>> is
>>>>>     not mandatory to send  1xx for re-INVITE, hence even if
>>>>>     Require:100rel is in re-INVITE, re-INVITE txn could be completed
>>>>>     with out PRACK transaction.
>>>>>         I agree, that such delay in re-INVITE might be acceptable 
>>>>> given
>>>> that
>>>>>     re-INVITE requires the user-intervention, but it complicates makes
>>>>>     the re-INVITE handling as complicated as the INVITE handling.
>>>> Also,
>>>>>     if the initial INVITE involved procedures such as QoS negotiation
>>>>>     the re-INVITE state-machine complicates even further.
>>>>>         [ABN] In most of the cases, re-INVITE is not expected to 
>>>>> undergo
>>>>>     user-intervention. hence in most of the cases it would end up with
>>>>>     re-INV, 200, ACK only...
>>>>>         In general, re-INVITE is expected to perform subset of what
>>>> happened
>>>>>     in INVITE transaction. it should not create any issues to handle
>>>> 1xx
>>>>>     responses reliably.
>>>>>         Hope this answers all your questions...
>>>>>         Regards,
>>>>>     Vineet.
>>>>>         /"You're only given a little spark of madness. You mustn't 
>>>>> lose
>>>>> it."/
>>>>>   
>>>>> ----------------------------------------------------------------------
>>>>> -- 
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> The information contained in this electronic message and any 
>>>> attachments to this message are intended for the exclusive use of 
>>>> the addressee(s) and may contain proprietary, confidential or 
>>>> privileged information. If you are not the intended recipient, you 
>>>> should not disseminate, distribute or copy this e-mail. Please 
>>>> notify the sender immediately and destroy all copies of this message 
>>>> and any attachments.
>>>>
>>>> WARNING: Computer viruses can be transmitted via email. The 
>>>> recipient should check this email and any attachments for the 
>>>> presence of viruses. The company accepts no liability for any damage 
>>>> caused by any virus transmitted by this email.
>>>>
>>>> www.wipro.com
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 20:38:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuI4l-0004h2-O9; Mon, 19 Nov 2007 20:38:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuI4j-0004f2-Vz
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 20:38:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuI4j-0004es-MT
	for sip@ietf.org; Mon, 19 Nov 2007 20:38:53 -0500
Received: from qmta10.westchester.pa.mail.comcast.net ([76.96.62.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuI4f-0002Yp-2v
	for sip@ietf.org; Mon, 19 Nov 2007 20:38:53 -0500
Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43])
	by QMTA10.westchester.pa.mail.comcast.net with comcast
	id EmtV1Y00E0vyq2s050Q900; Tue, 20 Nov 2007 01:38:48 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA05.westchester.pa.mail.comcast.net with comcast
	id Epeo1Y0060umElk0300000; Tue, 20 Nov 2007 01:38:48 +0000
X-Authority-Analysis: v=1.0 c=1 a=FYHUp7u3Ir8A:10 a=y6X_9txupGGYmNkRSogA:9
	a=LDryyxnAgnkSiaHtwqUlptn4yNIA:4 a=JfD0Fch1gWkA:10
	a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAK1cmSV008948
	for ; Mon, 19 Nov 2007 20:38:48 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAK1cmun008944;
	Mon, 19 Nov 2007 20:38:48 -0500
Date: Mon, 19 Nov 2007 20:38:48 -0500
Message-Id: <200711200138.lAK1cmun008944@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <4742359B.1060301@cisco.com> (pkyzivat@cisco.com)
Subject: Re: [Sip] SIPit 21: Question about offer answer
References: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com>
	<4742359B.1060301@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Paul Kyzivat 

   A 3pcc controller doing a transfer may well send an offerless invite to 
   one UA and then send the offer it gets back to an entirely different UA 
   than had been in the session before. So of course the answer will be 
   entirely different.

Hmmm, "my" music-on-hold proposal does that, too.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 20:43:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuI9D-0001BK-Ip; Mon, 19 Nov 2007 20:43:31 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuI9A-0001BE-TR
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 20:43:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuI9A-0001B6-Jw
	for sip@ietf.org; Mon, 19 Nov 2007 20:43:28 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuI95-0002ft-Kt
	for sip@ietf.org; Mon, 19 Nov 2007 20:43:28 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2007 20:43:24 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAK1hNHG008130; 
	Mon, 19 Nov 2007 20:43:23 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAK1hNVt010027; 
	Tue, 20 Nov 2007 01:43:23 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:43:23 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Nov 2007 20:43:22 -0500
Message-ID: <47423BBC.4030108@cisco.com>
Date: Mon, 19 Nov 2007 20:43:24 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jeroen van Bemmel 
Subject: Re: [Sip] SIPit 21: BNF and DIGEST authentication
References: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
	<47421FED.5020604@zonnet.nl>
In-Reply-To: <47421FED.5020604@zonnet.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 01:43:22.0666 (UTC)
	FILETIME=[BC30F8A0:01C82B16]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002
X-TM-AS-Result: No--17.773100-8.000000-2
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2469; t=1195523003;
	x=1196387003; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit=2021=3A=20BNF=20and=20DIGEST=20authenti
	cation |Sender:=20
	|To:=20Jeroen=20van=20Bemmel=20;
	bh=7zZePNZGDm/AwPKCrsBBVxAnjPz6a1osNKde/D4g5Q4=;
	b=pvDnIrSuvWcscoVajTm6QaIC7lw8guMK2j8ia/Wn/mj0zRmiZWumpIFKvmIMGgdCWB7E2U6S
	W1qaeDe4QAUgs/5SU49koXyZxMxxNUUrw9KiDhXZsBFzBfqdiZJ65+54;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Jeroen van Bemmel wrote:
> Robert,
> 
> We cannot make the quotes optional in the challenge,

technically, or for reasons of backward compatibility?

Technically it would be ok as long as there was only one in the list. 
(No commas.) But I guess you are stuck for backward compatibility.

> but we could make 
> them mandatory in both cases. That would at least be easier to get 
> right. Parsers would still need to support unquoted responses though

Technically you could make them optional in the response.
But again backward compatibility causes trouble.

I don't see how you can improve things without breaking backward 
compatibility.

	Paul

> Regards,
> Jeroen
> 
> Robert Sparks wrote:
>> We are _still_ seeing interoperability problems because of quotes 
>> around the qop parameter value in challenges and responses.
>>
>> What's specified now is that quotes MUST appear in challenges (it's a 
>> list of things) and MUST NOT appear in responses (it's a choice of one 
>> thing).
>>
>> This causes lots of people to write broken code.
>>
>> For the code that does work, this causes people to either build 
>> separate parsers for headers with the same name, using the knowledge 
>> of whether its a challenge or response to invoke the right parser, or 
>> to build parsers that don't follow the BNF we've provided.
>>
>> Would it make more sense to change the BNF to allow the quotes 
>> optionally in either the challenge or the response?
>>
>> Nobody that I've asked is actually re-using an HTTP parser for this, 
>> and nobody seems to be getting the number of values for the parameter 
>> wrong. Most of the folks I ask are building their parsers this way anyhow
>>
>> What would be bad about making this change to the spec?
>>
>> RjS
>>
>>
>>
>> _______________________________________________
>> 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
>>
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 19 20:45:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuIAp-0002oG-T5; Mon, 19 Nov 2007 20:45:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuIAn-0002h2-Kf
	for sip-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 20:45:09 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIAn-0002cS-60
	for sip@ietf.org; Mon, 19 Nov 2007 20:45:09 -0500
Received: from qmta09.emeryville.ca.mail.comcast.net ([76.96.30.96])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuIAm-0001jj-Og
	for sip@ietf.org; Mon, 19 Nov 2007 20:45:09 -0500
Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27])
	by QMTA09.emeryville.ca.mail.comcast.net with comcast
	id Eowl1Y0070b6N640A05L00; Tue, 20 Nov 2007 01:45:11 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA03.emeryville.ca.mail.comcast.net with comcast
	id Epl81Y00P0umElk0800000; Tue, 20 Nov 2007 01:45:10 +0000
X-Authority-Analysis: v=1.0 c=1 a=DqGMTaB2pgUA:10 a=LuQc20nlEKh6qQANpi0A:9
	a=Wgh1YgED3-PRytsWG_cA:7 a=N2JxX_QsLs1mB3VWYlkyW_fYMyoA:4
	a=si9q_4b84H0A:10 a=efIPqAt-WZ8A:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAK1j5SV009443
	for ; Mon, 19 Nov 2007 20:45:05 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAK1j5X1009439;
	Mon, 19 Nov 2007 20:45:05 -0500
Date: Mon, 19 Nov 2007 20:45:05 -0500
Message-Id: <200711200145.lAK1j5X1009439@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <200711192258.lAJMwqu8029577@dragon.ariadne.com>
	(Dale.Worley@comcast.net)
Subject: Re: [Sip] SIPit 21: REFER with Replaces - and Require: replaces
References: <5F06E0FE-117D-40D2-9026-2B010D21548E@nostrum.com>
	<200711192258.lAJMwqu8029577@dragon.ariadne.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Dale.Worley@comcast.net

   (Because otherwise the sender of the REFER couldn't specify "I want
   you to send an INVITE with a Replaces header but without a 'Require:
   replaces' header.  Such an INVITE is clearly legal and its effects are
   well-defined, although not very useful.)

Our company's software did generate such REFERs for a while.  The idea
being that during a call transfer or pick-up sequence, even if the
refer target UA didn't support Replaces, at least the call would come
in "on another line", and the UA user could switch to it.

(The folly of this idea was proved when the refer target was a PSTN
gateway.  The inbound PSTN caller received a call-waiting indication
from the second call, but nothing to indicate that they should switch
to that call to complete the transfer sequence.)

Dale


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 00:14:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuLQi-00047h-42; Tue, 20 Nov 2007 00:13:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuLQg-00043V-8r
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 00:13:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuLQf-00040j-Qx
	for sip@ietf.org; Tue, 20 Nov 2007 00:13:45 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IuLQc-00073h-9M for sip@ietf.org; Tue, 20 Nov 2007 00:13:45 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-1.cisco.com with ESMTP; 19 Nov 2007 21:13:41 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAK5DfBA006680; 
	Mon, 19 Nov 2007 21:13:41 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAK5DWUV020204;
	Tue, 20 Nov 2007 05:13:32 GMT
From: "Dan Wing" 
To: "'Hadriel Kaplan'" ,
	"'Christer Holmberg'" ,
	"'Elwell, John'" , "'sip'" 
References: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
	
	
	
	
Date: Mon, 19 Nov 2007 21:13:32 -0800
Message-ID: <042801c82b34$1d930fd0$91da46ab@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tAAEmaLAAAIfvRJAAJtfGAAEcZU0A==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2463; t=1195535621;
	x=1196399621; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20ICE=20and=20draft-wing-sip-identity-media-01.txt
	|Sender:=20; bh=T6/RNjXgYp6egwiP/4GLfou1pupmpwyySsbwuX8UFBk=;
	b=gnvpxFArzDKE0kfx4sjqUWEedIatPZjMRkeD9p77Jg4sY70kt77YWWJKwMyGaYtaVBKE/dkd
	3VICQsBKMlw9ZTskq6Gjqx2XRs0gtDChOPwE30mo85oIPC1nE3L4fhPi;
Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 
Subject: [Sip] RE: ICE and draft-wing-sip-identity-media-01.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

...
> > >I was not aware studies were done in 3GPP
> > >
> > >- it seemed like an obvious thing to me that ICE doesn't 
> > > work very well
> > in media-relayed environments. ;)
> >
> > I believe it is possible to make it work, but it assumes 
> > that SBCs (at least those relaying media) are ICE- and 
> > STUN aware.
> 
> Yeah but that's where I was saying "it would have to be ICE aware". :)
> 
> I think though the point you're trying to get to is if the 
> ice-pub-key is signed, but some middle-box outside of the 
> originating or terminating domain wants to terminate 
> ICE/STUN, it can't.  Right?
> I don't disagree that is the case.  But I think that's the 
> right thing to happen.  You can't allow the mid-domains to 
> change or remove the pub-key, because that obviously 
> invalidates the assertion of media identity.

They can pass along the pub-key, and the encrypted information,
though.  This would make their ICE processing more complex.

The overall weakness with sip-identity-media's inclusion of
ICE as an identity assertion is that, in the end, anything
along that path could inject any RTP stream it wanted to
inject.  We can't fix that except to use SRTP and to use
end-to-end keying with SRTP (e.g., DTLS-SRTP).

> Actually, as I was about to write up a "here's how it could 
> work" thing with regards to middle-boxes doing STUN, it 
> occurred to me the ice-pub-key thing described in our draft 
> is easily defeatible.  I'll email Dan about it to see if I'm 
> missing something.

Yes, it is easy to defeat.  All you can really know is that,
at the time you sent the Connectivity Request, there really
was a viable media path to the other party.  But you have
no real assurance that the audio (or video) you are receiving
is from that party.  For that, we need authenticated RTP
which we get with SRTP and end-to-end keying of SRTP.

ICE is in sip-identity-media so that everyone can see how
we could build steps towards doing DTLS-SRTP, as the 
attackers get more sophisticated or as the threat of those
attackers gets more severe.  The end goal for sip-identity-
media is DTLS-SRTP, and not the ICE pub-key technique.  The
ICE pub-key technique is a stepping stone.  

Perhaps, after more people read the draft, we will conclude
that the ICE pub-key technique is not useful enough to 
retain because doing RTP afterwards results in too many
opportunities for attack.

-d


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 00:45:16 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuLv4-0005Vi-IG; Tue, 20 Nov 2007 00:45:10 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuLv3-0005VT-Gd
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 00:45:09 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuLv3-0005VL-4x
	for sip@ietf.org; Tue, 20 Nov 2007 00:45:09 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuLv2-0007CM-Dw
	for sip@ietf.org; Tue, 20 Nov 2007 00:45:09 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	9430F204DD; Tue, 20 Nov 2007 06:45:07 +0100 (CET)
X-AuditID: c1b4fb3c-b061bbb000002c9b-a1-47427463ca65
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	77B63203FC; Tue, 20 Nov 2007 06:45:07 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 06:45:07 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Nov 2007 06:45:07 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ICE and draft-wing-sip-identity-media-01.txt
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tAAEmaLAAAIfvRJAAJtfGAAEcZU0AABDy7F
References: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
	
	
	
	
	<042801c82b34$1d930fd0$91da46ab@cisco.com>
From: "Christer Holmberg" 
To: "Dan Wing" , "Hadriel Kaplan" ,
	"Elwell, John" , "sip" 
X-OriginalArrivalTime: 20 Nov 2007 05:45:07.0368 (UTC)
	FILETIME=[81AADA80:01C82B38]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: 
Subject: [Sip] RE: ICE and draft-wing-sip-identity-media-01.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,
=20
Not specific to this topic, but I am getting a little worried about this =
"protocol overloading" I start to see.
=20
ICE was done to solve user plane NAT traversal - nothing more, nothing =
less. Many people spent a lot of work before it reached ice-19.
=20
But, now we want to start using ICE for functions it was not meant to. =
First people decided to deprecate ANAT and ICE instead - and now all =
this security negotiation stuff...
=20
Take PRACK as an example. Initially it was meant simply to acknowledge =
reliable provisional responses. Then someone figured out that if you are =
using it for reliable provisional responses you can at the same time =
also throw in an SDP offer or answer. And, now we have the problems with =
PRACK and offer/answer (how to reject an offer in PRACK etc).
=20
But, my main issue here is: do not assume the information you include in =
your STUN will be end-to-end.
=20
Regards,
Christer

________________________________

From: Dan Wing [mailto:dwing@cisco.com]
Sent: Tue 20/11/2007 06:13
To: 'Hadriel Kaplan'; Christer Holmberg; 'Elwell, John'; 'sip'
Subject: RE: ICE and draft-wing-sip-identity-media-01.txt



...
> > >I was not aware studies were done in 3GPP
> > >
> > >- it seemed like an obvious thing to me that ICE doesn't
> > > work very well
> > in media-relayed environments. ;)
> >
> > I believe it is possible to make it work, but it assumes
> > that SBCs (at least those relaying media) are ICE- and
> > STUN aware.
>
> Yeah but that's where I was saying "it would have to be ICE aware". :)
>
> I think though the point you're trying to get to is if the
> ice-pub-key is signed, but some middle-box outside of the
> originating or terminating domain wants to terminate
> ICE/STUN, it can't.  Right?
> I don't disagree that is the case.  But I think that's the
> right thing to happen.  You can't allow the mid-domains to
> change or remove the pub-key, because that obviously
> invalidates the assertion of media identity.

They can pass along the pub-key, and the encrypted information,
though.  This would make their ICE processing more complex.

The overall weakness with sip-identity-media's inclusion of
ICE as an identity assertion is that, in the end, anything
along that path could inject any RTP stream it wanted to
inject.  We can't fix that except to use SRTP and to use
end-to-end keying with SRTP (e.g., DTLS-SRTP).

> Actually, as I was about to write up a "here's how it could
> work" thing with regards to middle-boxes doing STUN, it
> occurred to me the ice-pub-key thing described in our draft
> is easily defeatible.  I'll email Dan about it to see if I'm
> missing something.

Yes, it is easy to defeat.  All you can really know is that,
at the time you sent the Connectivity Request, there really
was a viable media path to the other party.  But you have
no real assurance that the audio (or video) you are receiving
is from that party.  For that, we need authenticated RTP
which we get with SRTP and end-to-end keying of SRTP.

ICE is in sip-identity-media so that everyone can see how
we could build steps towards doing DTLS-SRTP, as the
attackers get more sophisticated or as the threat of those
attackers gets more severe.  The end goal for sip-identity-
media is DTLS-SRTP, and not the ICE pub-key technique.  The
ICE pub-key technique is a stepping stone.=20

Perhaps, after more people read the draft, we will conclude
that the ICE pub-key technique is not useful enough to
retain because doing RTP afterwards results in too many
opportunities for attack.

-d




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 01:08:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuMHY-0000eu-Dr; Tue, 20 Nov 2007 01:08:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuMHW-0000em-QN
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 01:08:22 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuMHV-0000d4-Rk
	for sip@ietf.org; Tue, 20 Nov 2007 01:08:21 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuMHV-0007nF-4D
	for sip@ietf.org; Tue, 20 Nov 2007 01:08:21 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-5.cisco.com with ESMTP; 19 Nov 2007 22:08:20 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAK68KWm024672; 
	Mon, 19 Nov 2007 22:08:20 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAK68F40026459;
	Tue, 20 Nov 2007 06:08:15 GMT
From: "Dan Wing" 
To: "'Christer Holmberg'" ,
	"'Hadriel Kaplan'" ,
	"'Elwell, John'" , "'sip'" 
References: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
	
	
	
	
	<042801c82b34$1d930fd0$91da46ab@cisco.com>
	
Date: Mon, 19 Nov 2007 22:08:14 -0800
Message-ID: <043e01c82b3b$bfce43d0$91da46ab@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tAAEmaLAAAIfvRJAAJtfGAAEcZU0AABDy7FAAEKquA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4371; t=1195538900;
	x=1196402900; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20ICE=20and=20draft-wing-sip-identity-media-01.txt
	|Sender:=20; bh=aCJ54v31h7On6Mn6l0UFXCxqaLlkRy7LRdzGuFkD2NY=;
	b=AnH1fLc5qjFbESE4xVC9q3MeS9H08g3/Moud1uh8zuI9n7mIeyrF5EfI0boNdZot8pbmVYUB
	vlUzTygqzC5JggoM1V7ukiDfaE7YuySwqzu4xXVacazmph0RH1aQy2zA;
Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: 
Subject: [Sip] RE: ICE and draft-wing-sip-identity-media-01.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
> Sent: Monday, November 19, 2007 9:45 PM
> To: Dan Wing; Hadriel Kaplan; Elwell, John; sip
> Subject: RE: ICE and draft-wing-sip-identity-media-01.txt
> 
> Hi,
>  
> Not specific to this topic, but I am getting a little worried 
> about this "protocol overloading" I start to see.
>  
> ICE was done to solve user plane NAT traversal - nothing 
> more, nothing less. Many people spent a lot of work before it 
> reached ice-19.
>  
> But, now we want to start using ICE for functions it was not 
> meant to. First people decided to deprecate ANAT and ICE 
> instead - and now all this security negotiation stuff...
>  
> Take PRACK as an example. Initially it was meant simply to 
> acknowledge reliable provisional responses. Then someone 
> figured out that if you are using it for reliable provisional 
> responses you can at the same time also throw in an SDP offer 
> or answer. And, now we have the problems with PRACK and 
> offer/answer (how to reject an offer in PRACK etc).
>  
> But, my main issue here is: do not assume the information you 
> include in your STUN will be end-to-end.

To prove identity across SBCs, all four identity proof 
techniques proposed in sip-identity-media (DTLS-SRTP, TLS, 
ICE with pub-key extension, and HIP) require information to 
be sent end-to-end.

Is there a way to prove end-to-end identity without sending 
information end-to-end?

-d


> Regards,
> Christer
> 
> ________________________________
> 
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Tue 20/11/2007 06:13
> To: 'Hadriel Kaplan'; Christer Holmberg; 'Elwell, John'; 'sip'
> Subject: RE: ICE and draft-wing-sip-identity-media-01.txt
> 
> 
> 
> ...
> > > >I was not aware studies were done in 3GPP
> > > >
> > > >- it seemed like an obvious thing to me that ICE doesn't
> > > > work very well
> > > in media-relayed environments. ;)
> > >
> > > I believe it is possible to make it work, but it assumes
> > > that SBCs (at least those relaying media) are ICE- and
> > > STUN aware.
> >
> > Yeah but that's where I was saying "it would have to be ICE 
> aware". :)
> >
> > I think though the point you're trying to get to is if the
> > ice-pub-key is signed, but some middle-box outside of the
> > originating or terminating domain wants to terminate
> > ICE/STUN, it can't.  Right?
> > I don't disagree that is the case.  But I think that's the
> > right thing to happen.  You can't allow the mid-domains to
> > change or remove the pub-key, because that obviously
> > invalidates the assertion of media identity.
> 
> They can pass along the pub-key, and the encrypted information,
> though.  This would make their ICE processing more complex.
> 
> The overall weakness with sip-identity-media's inclusion of
> ICE as an identity assertion is that, in the end, anything
> along that path could inject any RTP stream it wanted to
> inject.  We can't fix that except to use SRTP and to use
> end-to-end keying with SRTP (e.g., DTLS-SRTP).
> 
> > Actually, as I was about to write up a "here's how it could
> > work" thing with regards to middle-boxes doing STUN, it
> > occurred to me the ice-pub-key thing described in our draft
> > is easily defeatible.  I'll email Dan about it to see if I'm
> > missing something.
> 
> Yes, it is easy to defeat.  All you can really know is that,
> at the time you sent the Connectivity Request, there really
> was a viable media path to the other party.  But you have
> no real assurance that the audio (or video) you are receiving
> is from that party.  For that, we need authenticated RTP
> which we get with SRTP and end-to-end keying of SRTP.
> 
> ICE is in sip-identity-media so that everyone can see how
> we could build steps towards doing DTLS-SRTP, as the
> attackers get more sophisticated or as the threat of those
> attackers gets more severe.  The end goal for sip-identity-
> media is DTLS-SRTP, and not the ICE pub-key technique.  The
> ICE pub-key technique is a stepping stone. 
> 
> Perhaps, after more people read the draft, we will conclude
> that the ICE pub-key technique is not useful enough to
> retain because doing RTP afterwards results in too many
> opportunities for attack.
> 
> -d


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 02:04:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuN91-0006Cg-FG; Tue, 20 Nov 2007 02:03:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuN90-0006Cb-Jc
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 02:03:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuN90-0006CT-7Y
	for sip@ietf.org; Tue, 20 Nov 2007 02:03:38 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuN8x-0000tx-M9
	for sip@ietf.org; Tue, 20 Nov 2007 02:03:38 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	F277F20018; Tue, 20 Nov 2007 08:03:34 +0100 (CET)
X-AuditID: c1b4fb3c-ae617bb000002c9b-f6-474286c60837
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	E1E662005D; Tue, 20 Nov 2007 08:03:34 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 08:03:34 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Nov 2007 08:03:34 +0100
Message-ID: 
In-Reply-To: <043e01c82b3b$bfce43d0$91da46ab@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ICE and draft-wing-sip-identity-media-01.txt
Thread-Index: AcgnysPkHVnNDqhEQvCO8CSpRTLp5ABe/uxAAEvz5tAAEmaLAAAIfvRJAAJtfGAAEcZU0AABDy7FAAEKquAAAdTv4A==
References: <0D5F89FAC29E2C41B98A6A762007F5D0441033@GBNTHT12009MSX.gb002.siemens.net>
	
	
	
	
	<042801c82b34$1d930fd0$91da46ab@cisco.com>
	
	<043e01c82b3b$bfce43d0$91da46ab@cisco.com>
From: "Christer Holmberg" 
To: "Dan Wing" , "Hadriel Kaplan" ,
	"Elwell, John" , "sip" 
X-OriginalArrivalTime: 20 Nov 2007 07:03:34.0774 (UTC)
	FILETIME=[77800160:01C82B43]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: 
Subject: [Sip] RE: ICE and draft-wing-sip-identity-media-01.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,=20

>>Not specific to this topic, but I am getting a little worried about=20
>>this "protocol overloading" I start to see.
>> =20
>>ICE was done to solve user plane NAT traversal - nothing more, nothing

>>less. Many people spent a lot of work before it reached ice-19.
>> =20
>>But, now we want to start using ICE for functions it was not meant to.

>>First people decided to deprecate ANAT and ICE instead - and now all=20
>>this security negotiation stuff...
>> =20
>>Take PRACK as an example. Initially it was meant simply to acknowledge

>>reliable provisional responses. Then someone figured out that if you=20
>>are using it for reliable provisional responses you can at the same=20
>>time also throw in an SDP offer or answer. And, now we have the=20
>>problems with PRACK and offer/answer (how to reject an offer in PRACK=20
>>etc).
>> =20
>>But, my main issue here is: do not assume the information you include=20
>>in your STUN will be end-to-end.
>=20
>To prove identity across SBCs, all four identity proof=20
>techniques proposed in sip-identity-media (DTLS-SRTP, TLS,=20
>ICE with pub-key extension, and HIP) require information to=20
>be sent end-to-end.
>=20
>Is there a way to prove end-to-end identity without sending=20
>information end-to-end?

All I am saying is that there are proposed ICE mechanisms where STUN
would not be sent end-to-end.

Now, if we find out that those mechanisms don't work, we of course have
an issue with those mechanisms.

Regards,

Christer



_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 02:15:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuNKG-0006oR-RS; Tue, 20 Nov 2007 02:15:16 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuNKF-0006lj-HS
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 02:15:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNKF-0006lb-7t
	for sip@ietf.org; Tue, 20 Nov 2007 02:15:15 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuNKA-00014h-LN
	for sip@ietf.org; Tue, 20 Nov 2007 02:15:15 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	04AAD201ED; Tue, 20 Nov 2007 08:15:10 +0100 (CET)
X-AuditID: c1b4fb3e-b0835bb0000007e1-f7-4742897df3fd
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	EF22B20122; Tue, 20 Nov 2007 08:15:09 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 08:15:09 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21: Question about offer answer
Date: Tue, 20 Nov 2007 08:15:09 +0100
Message-ID: 
In-Reply-To: <200711200138.lAK1cmun008944@dragon.ariadne.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21: Question about offer answer
Thread-Index: AcgrFiA90gPohVGFSreq2w87KbkagwALosxg
References: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com><4742359B.1060301@cisco.com>
	<200711200138.lAK1cmun008944@dragon.ariadne.com>
From: "Christer Holmberg" 
To: ,
	
X-OriginalArrivalTime: 20 Nov 2007 07:15:09.0875 (UTC)
	FILETIME=[15D00030:01C82B45]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

What if the offerer is not "prepared" to receive an updated answer (it
only included the "offer" because it had to)? How can it "reject" the
answer?=20

I personally think that an unchanged o- line in the offer should not
allow the answer to change.

One could of course change the o- line in the offer - even if the offer
itself hasn't changed - and that would then allow the answer to be
changed.

Just some thinking...

Regards,

Christer



> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20
> Sent: 20. marraskuuta 2007 3:39
> To: sip@ietf.org
> Subject: Re: [Sip] SIPit 21: Question about offer answer
>=20
>    From: Paul Kyzivat 
>=20
>    A 3pcc controller doing a transfer may well send an=20
> offerless invite to=20
>    one UA and then send the offer it gets back to an entirely=20
> different UA=20
>    than had been in the session before. So of course the=20
> answer will be=20
>    entirely different.
>=20
> Hmmm, "my" music-on-hold proposal does that, too.
>=20
> Dale
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 02:18:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuNNF-00051y-S2; Tue, 20 Nov 2007 02:18:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuNND-0004z2-NU
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 02:18:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNND-0004xB-D0
	for sip@ietf.org; Tue, 20 Nov 2007 02:18:19 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuNN7-00019d-RO
	for sip@ietf.org; Tue, 20 Nov 2007 02:18:19 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	61DEE207E2; Tue, 20 Nov 2007 08:18:13 +0100 (CET)
X-AuditID: c1b4fb3c-b061bbb000002c9b-f0-47428a354e0e
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	51B1020551; Tue, 20 Nov 2007 08:18:13 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 08:18:13 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
Date: Tue, 20 Nov 2007 08:18:12 +0100
Message-ID: 
In-Reply-To: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: BNF future-proofing problem?
Thread-Index: Acgq9BdGBEyARGSvR9ehw2vhNcQrpAAUSaMQ
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com>
From: "Christer Holmberg" 
To: "Robert Sparks" ,
	"sip List" 
X-OriginalArrivalTime: 20 Nov 2007 07:18:13.0159 (UTC)
	FILETIME=[830EEB70:01C82B45]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi Robert,

I am not really sure what you are proposing, but if we would mandate
parsers not to parse unknown headers something is REALLY wrong with the
BNF...=20

Regards,

Christer



> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
> Sent: 19. marraskuuta 2007 23:35
> To: sip List
> Subject: [Sip] SIPit21: BNF future-proofing problem?
>=20
> The BNF in 3261 says the following:
>=20
> extension-header  =3D  header-name HCOLON header-value
> header-value      =3D  *(TEXT-UTF8char / UTF8-CONT / LWS)
>=20
> This is intended to be the catch-all field for all future extensions
> - older parsers working against this BNF shouldn't barf when=20
> we introduce a new header field.
>=20
> Now, we may have new fields in the future that look like:
>=20
> NewHeader =3D new-header-name HCOLON quoted-string
>=20
> And down inside quoted-string, we get:
>=20
>        quoted-string  =3D  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
>        qdtext         =3D  LWS / %x21 / %x23-5B / %x5D-7E
>                          / UTF8-NONASCII
>        quoted-pair  =3D  "\" (%x00-09 / %x0B-0C
>                         / %x0E-7F)
>=20
> So, for instance, we could have inside a quoted string the 2=20
> byte sequence \ NULL
>=20
> This does not parse against header-value above...
>=20
> Is this a problem? Some of the SIPit21 participants argued that it is.
>=20
> The projects I've been involved in don't parse unknown=20
> headers and the stacks will just hand up an unparsed bucket=20
> of bits (the only rules used are those necessary to identify=20
> the next header-field starting).
>=20
> Would it be worth the effort to make the BNF reflect that=20
> rather than continuing with the incongruity that we currently specify?
>=20
> RjS
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 02:47:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuNpp-0002aX-7K; Tue, 20 Nov 2007 02:47:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuNpo-0002aS-7c
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 02:47:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNpj-0002aH-4k
	for sip@ietf.org; Tue, 20 Nov 2007 02:47:47 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuNpd-0001xL-M6
	for sip@ietf.org; Tue, 20 Nov 2007 02:47:47 -0500
Received: from rly13f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly13f.srv.mailcontrol.com (MailControl) with ESMTP id
	lAK7leF1021124 for ; Tue, 20 Nov 2007 07:47:40 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly13f.srv.mailcontrol.com (MailControl) id lAK7labn021102
	for sip@ietf.org; Tue, 20 Nov 2007 07:47:36 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly13f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lAK7lD8S019231; Tue, 20 Nov 2007 07:47:36 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 07:44:29 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Can a transactionstatelessproxysupportOutbounddraft?Ifyes,
	how will the response be sentback theUAbehind NAT
Date: Tue, 20 Nov 2007 07:43:47 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60AE6AF9@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can a transactionstatelessproxysupportOutbounddraft?Ifyes,
	how will the response be sentback theUAbehind NAT
Thread-Index: Acgq+CeeHUyywot2QpqRF7NuTZrDFQATo24w
From: "Attila Sipos" 
To: 
X-OriginalArrivalTime: 20 Nov 2007 07:44:29.0150 (UTC)
	FILETIME=[2E6C0FE0:01C82B49]
X-Scanned-By: MailControl A-08-00-02 (www.mailcontrol.com) on 10.70.1.123
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

>>   Our approach tries to use the flow token also in responses: we just
>>put the flow token in the Via. As mentioned before:
>>   -the UA stores the flow token when it receives a 200 OK after
REGISTER;

So the flow token is stored in the UA's route set?

>>   -then it puts it into every SIP request that is sent over a flow;

So it goes into the Route headers.

>>   -then the edge proxy copies the flow token to the URI part of the
Via
>>when it composes the Via before to forward the message.
ok

>>   -Later, when the response arrives at the edge proxy, it tries to
>>decode the flow token in the Via, if it succeeds, it  forwards the
>>response over the flow indicated in the flow token.

yes, looks good to me.

>>   At what moment you generate the "branch flow token"
>>(for example, when the Via is created?)

yes, that was the idea.

>>   I can not understand completely the idea, from my point of view
>>it is easier to use the same flow token. Considering that the flow
>>token considers the reboot, why it could be an advantage to use the
>>"branch flow token" instead of the flow-token ?

Well that's what I had thought originally (that it is
easier to use the same flow token).

In an earlier e-mail, I had said:
>>3.
>>> In the Via header's branch parameter, it would encode the required=20
>>> flow token.
>>

But you challenged that with this problem:
>>Here is the issue : From were you get the flow token?
>>(In my previous email I mentioned 2 options... )

So, I'm a bit confused.  Is there a problem with using the
flow token in the Via or not?  I think the answer is no.

Anyway, the conclusion is this:
 "Yes, it is possible for a transaction-stateless proxy
 to support the outbound draft".

Regards,

Attila
=20

-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: 19 November 2007 22:02
To: Attila Sipos
Cc: sip@ietf.org
Subject: RE: [Sip] Can a
transactionstatelessproxysupportOutbounddraft?Ifyes, how will the
response be sentback theUAbehind NAT



Hi,


> I feel this would not be a problem for a stateless proxy providing=20
> that it is not just a raw socket descriptor id that is passed to the=20
> registrar.  The branch parameter in the Via would need some kind of=20
> hashed/encrypted "reboot count" parameter as well as the socket id. =20
> Then if the edge-proxy rebooted, it would know that the response=20
> coming back is stale.  There are many ways to do the=20
> hashing/encryption - you could use a method similar to that used in=20
> the gruu draft Appendix A.2.
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-
> 15
> .txt

   In outbound 10, 5.2.  Generating Flow Tokens :

"When the proxy boots it selects a 20-octet crypto
        random key called K that only the Edge Proxy knows."


   Instead to using the 'reboot count', the approach mentioned in the
draft already considers the case of old flow tokens that can remain
stored in the registrar by using a different key every time the proxy
reboots.



> So the Via header's branch parameter would contain encoded information

> about:
> 1. the flow back to the UA (socket id, IP, port) 2. the reboot count

   Our approach tries to use the flow token also in responses: we just
put the flow token in the Via. As mentioned before:
   -the UA stores the flow token when it receives a 200 OK after
REGISTER;
   -then it puts it into every SIP request that is sent over a flow;
   -then the edge proxy copies the flow token to the URI part of the Via
when it composes the Via before to forward the message.
   -Later, when the response arrives at the edge proxy, it tries to
decode the flow token in the Via, if it succeeds, it  forwards the
response over the flow indicated in the flow token.


> So my proposal is generating some kind of flow token (but not THE same

> "flow token"as used in the REGISTER).  So there is the "flow token" as
described in
> theoutbound draft and now there is also a "branch flow token" that I=20
> am
?proposing.

   Perhaps can be a possible solution but seems complex.
   At what moment you generate the "branch flow token" (for example,
when the Via is created?)
   I can not understand completely the idea, from my point of view it is
easier to use the same flow token. Considering that the flow token
considers the reboot, why it could be an advantage to use the "branch
flow token" instead of the flow-token ?


Regards,

Sergio

Quoting Attila Sipos :

>
>>>  The problem with the above (separated elements) is that there is=20
>>> not synchronization about the state of the socket descriptors. As
> mentioned
>>> before, if the edge proxy crashes the socket descriptors used
> immediately
>>> after reboot could result in delivering messages to different flows.
>>>
>>>  In my opinion the randomness included in the flow token avoids that
> to
>>> happen, since after reboot the flowtoken can not be decoded and/or
> find an
>>> existing flow and that cause the return a error response.
>
>
> Yes, absolutely.  And this is a problem with stateful proxies too.
>
> I have agreed with everything you've said.
> However, I still think there is a way to do an outbound-compatible=20
> edge proxy with a transaction-stateless/call-stateless proxy.
>
> So I now go back to say something similar to what I said before.
> But first, I will refer to something you said in an earlier mail:
>
>>>  Furthermore my registrar should not store socket descriptors due=20
>>> that if the edge proxy crashes, the registrar could have a number of

>>> descriptor that after the crash belong to other flows.
>
> I feel this would not be a problem for a stateless proxy providing=20
> that it is not just a raw socket descriptor id that is passed to the=20
> registrar.  The branch parameter in the Via would need some kind of=20
> hashed/encrypted "reboot count" parameter as well as the socket id. =20
> Then if the edge-proxy rebooted, it would know that the response=20
> coming back is stale.  There are many ways to do the=20
> hashing/encryption - you could use a method similar to that used in=20
> the gruu draft Appendix A.2.
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-
> 15
> .txt
>
> So the Via header's branch parameter would contain encoded information

> about:
> 1. the flow back to the UA (socket id, IP, port) 2. the reboot count
>
> So now I go back to something else you said:
>>> 2) generate again the flow token for every request (very bad from=20
>>> security point of views) and destroys the consistency of the system=20
>>> since you can send requests for non existing flows. Note that the=20
>>> draft mentions that the flow and the flow token is only created with
> REGISTERs.
>
> So my proposal is generating some kind of flow token (but not THE same

> "flow token"
> as used in the REGISTER).  So there is the "flow token" as described=20
> in the outbound draft and now there is also a "branch flow token" that

> I am proposing.
> And, as explained before, the information in the "branch flow token"=20
> is used to route responses back to the UA.  But the original "flow=20
> token" is never changed.
> The original "flow token" would still be used when forwarding requests

> to the UA because the Edge Proxy (in your diagram) would've added it=20
> to the Path.  So requests to the UA would still work.
>
> Now I'm not sure about the security aspects.
> What security problems could there be with "branch flow token" idea?
>
> Regards,
> Attila
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 16 November 2007 15:53
> To: Attila Sipos
> Subject: RE: [Sip] Can a transaction
> statelessproxysupportOutbounddraft?Ifyes, how will the response be=20
> sent back theUAbehind NAT
>
>
>
>> I am starting to see the problems.
>>
>> If I understand correctly, your scenario is this...
>>
>> REGISTRAR--------PROXY----------NAT---------SIP UA
>>
>> Can you confirm?
>
> more specifically my scenario is
>
> REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA
>
>
> where PROXY is a traditional SIP proxy
>
>
>> And, since you were talking about scalability, you might also have=20
>> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>>
>> is this right?
>
>
>   About scalability I was thinking about
>
>
>                         /EDGEPROXY1\
> REGISTRAR/PROXY--------            ----------NAT---------SIP UA
>                         \EDGEPROXY2/
>
>
>   So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.
>
>
>   I have no experience with registrars, I guess that in your case you=20
> have a REGISTRAR/EDGEPROXY in the same process (or group of processes)

> and not REGISTRAR--------EDGEPROXY (linked by other means).
>
>   The problem with the above (separated elements) is that there is not

> synchronization about the state of the socket descriptors. As=20
> mentioned before, if the edge proxy crashes the socket descriptors=20
> used immediately after reboot could result in delivering messages to=20
> different flows.
>
>   In my opinion the randomness included in the flow token avoids that=20
> to happen, since after reboot the flowtoken can not be decoded and/or=20
> find an existing flow and that cause the return a error response.
>   Then another entry in the registrar binding will be used, i.e. other

> flow token. If you have a second edge proxy (that does not crashed at=20
> the same time that the first one :) and the flow token belongs to the=20
> second edge proxy, the message will reach the UA over a flow=20
> previously established to the second edge proxy.
>
>
>
> BR
>
> Sergio
>
>
> Quoting Attila Sipos :
>
>>
>>
>>>>>>> 3.
>>>>>>>> In the Via header's branch parameter, it would encode the
>> required
>>>>>>>> flow token.
>>>>>>>
>>>>>>> Here is the issue : From were you get the flow token?
>>>>>>> (In my previous email I mentioned 2 options... )
>>>>>>>
>>>>>
>>>>> OK I'm starting to see your problem.
>>>>>
>>>>> The registration record stores the flow token (obviously)
>>>>
>>>> It seems that you are integrating the edge proxy and registrar in=20
>>>> the
>> same code, right?
>>
>> yes, that's it.
>>
>>
>>>>> And the socket id for the flow would be stored as well (for
>>>>
>>>> Can you confirm that you call socket id to the socket/file=20
>>>> descriptor
>> of the connection?
>>
>> yes.
>>
>>>>> connection-oriented
>>>>> protocols). So if you received a request on that socket, you could

>>>>> match that up to one of the registration records and hence, one of
>> the
>>>>> flow tokens.
>>>>>
>>>>
>>>>  Good approach. I assume that you have available the socket
>> descriptor
>>>> in the registrar, so basically you consider storing the socket
>> descriptor
>>>> (number) in the registrar tables. Then perhaps using a flow token=20
>>>> it
>> is not
>>>> necessary since you have available in the socket descriptor all the
>> information
>>>> that describes a flow (TCP case).
>>
>> That's true.  I might not need the flow tokens.
>>
>>
>>>>> I hope I have explained how the flow token might be mapped to the=20
>>>>> socket.
>>>>
>>>>  Yes if my comments above make sense..
>>>>
>>>>> I can now see that my idea wouldn't work for UDP.
>>>>
>>>>  Now for UDP perhaps you can consider storing the socket descriptor
>> for
>>>> UDP and the IP and port for the flow from the NAT.
>>
>> yes, that would work I think.
>>
>>
>>>>  Furthermore my registrar should not store socket descriptors due
>> that
>>>> if the edge proxy crashes, the registrar could have a number of
>> descriptor
>>>> that after the crash belong to other flows.
>>>>
>>>>  I generate the flow token with REGISTER and send it to the=20
>>>> registrar (other node). The approach works as the draft says for=20
>>>> incoming
>> requests
>>>> (to the Calle). Now when the Callee  sends requests, and the=20
>>>> requests
>> are
>>>> sent over the flow, the responses of that request reach first the=20
>>>> edge
>> proxy
>>>> and it can not forward them to the Callee over the flow, because=20
>>>> these responses don't have the flow token (and the flow token is=20
>>>> not
>
>>>> stored
>> in
>>>> the edge proxy)...
>>
>> I am starting to see the problems.
>>
>> If I understand correctly, your scenario is this...
>>
>> REGISTRAR--------PROXY----------NAT---------SIP UA
>>
>> Can you confirm?
>>
>> And, since you were talking about scalability, you might also have=20
>> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>>
>> is this right?
>>
>>
>>>>> But what if you used the gruu in the contact to match up with the
>> gruu
>>>>> of a registration?  Then the registration record tells tells you
>> about
>>>>> the flow token.  That would work wouldn't it?
>>>>
>>>>  I have not background with gruu. Could you recommend what could I
>> read about it?
>>
>> Sorry, I didn't mean gruu, I was mixing up my drafts!
>> I was just looking for a unique identifier for the UA which is the=20
>> sip.instance from the outbound draft (not gruu).
>>
>>
>> Regards,
>> Attila
>>
>
>
>





_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 05:59:44 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuQp3-0007N2-I8; Tue, 20 Nov 2007 05:59:17 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuQp1-0007Mf-V5
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 05:59:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQp1-0007MS-L8
	for sip@ietf.org; Tue, 20 Nov 2007 05:59:15 -0500
Received: from poster2.unibo.it ([137.204.24.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuQoy-0006ID-4s
	for sip@ietf.org; Tue, 20 Nov 2007 05:59:15 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by poster2.unibo.it (Postfix) with ESMTP id 6204347B
	for ; Tue, 20 Nov 2007 11:59:11 +0100 (CET)
Received: from EXBK03 (unknown [137.204.25.211])
	by poster2.unibo.it (Postfix) with ESMTP id E1DA64A2
	for ; Tue, 20 Nov 2007 11:59:01 +0100 (CET)
Received: from exfe03.personale.dir.unibo.it ([10.11.1.3]) by EXBK03 with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 11:59:01 +0100
Received: from [137.204.107.60] ([137.204.107.60]) by
	exfe03.personale.dir.unibo.it over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 11:59:01 +0100
Message-ID: <4742BDF5.9040302@unibo.it>
Date: Tue, 20 Nov 2007 11:59:01 +0100
From: Daniel Grotti 
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: IETF SIP List 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 10:59:01.0495 (UTC)
	FILETIME=[5BAE9070:01C82B64]
X-Virus-Scanned: Cineca AppOs 1.00 at poster2.unibo.it
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [Sip] a question about IETF draft location conveyance 09 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi all,
I'd like to ask a question about 
"draft-ietf-sip-location-conveyance-09.txt".

How does Proxy Server have to work when a Geolocation Header contain 
"recipient=endpoint" parameter ?
Does the Proxy server just have to forward the SIP message (without do 
anything else) or can it read the information conveyed ?
 
thanks,
Regards
daniel

-- 

---------------------------------------------------
Daniel Grotti
DEIS - University of Bologna
Via Venezia, 52 - 47023 Cesena (FC) - ITALY

Contacts
e-mail : daniel.grotti@unibo.it
Skype name : Daniel Grotti
---------------------------------------------------



_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 06:52:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuRek-0006KX-4D; Tue, 20 Nov 2007 06:52:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuRei-0006D5-3f
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 06:52:40 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuReg-00065C-7s; Tue, 20 Nov 2007 06:52:38 -0500
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IuRef-00081B-KZ; Tue, 20 Nov 2007 06:52:37 -0500
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49877)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1IuRee-0000Xe-2Y; Tue, 20 Nov 2007 11:52:36 +0000
In-Reply-To: <4742149C.70401@nostrum.com>
References: <4730C66F.2070803@alcatel-lucent.com>	<4741E624.9010805@nostrum.com>
	<8F34894D-AB5F-45F0-95C0-7326A6F2E5CA@csperkins.org>
	<4742149C.70401@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5620BA3C-FA3B-4FF1-9E7E-B8AA720D79AC@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins 
Subject: Re: [Sip] SIP IPv6 ABNF: Essential correction to RFC3261
Date: Tue, 20 Nov 2007 11:52:47 +0000
To: Adam Roach 
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: IETF SIP List ,
	Brian E Carpenter ,
	MMUSIC WG 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

On 19 Nov 2007, at 22:56, Adam Roach wrote:
> On 11/19/07 4:44 PM, Colin Perkins wrote:
>> Can someone familiar with the issue also check the ABNF in RFC  
>> 4566 (SDP)? From a quick look, it seems that it has a similar  
>> problem...
>
> By my readying, you are correct -- the ABNF rules in 4566 suffer  
> from the same flaw. From an ANBF perspective, I would propose that  
> the solution is the same as Vijay and Brian detail in their draft.  
> From a process perspective, I don't know how to handle it (outside  
> of the relatively invisible RFC errata process).

If the MMUSIC chairs agree, I could submit draft-ietf-mmusic- 
rfc4566bis-00.txt after the meeting, with just this fix. That can be  
kept alive for a couple of years, collecting any other bug fixes  
found, and eventually be published as an updated RFC.

-- 
Colin Perkins
http://csperkins.org/




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 09:22:20 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuTzH-0003EA-D3; Tue, 20 Nov 2007 09:22:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuTzF-0003DB-5P
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:22:01 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTzE-0003D3-QW
	for sip@ietf.org; Tue, 20 Nov 2007 09:22:00 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuTzE-00044q-DQ
	for sip@ietf.org; Tue, 20 Nov 2007 09:22:00 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2007 09:21:59 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAKEM0sm012365; 
	Tue, 20 Nov 2007 09:22:00 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAKELxwt001627; 
	Tue, 20 Nov 2007 14:21:59 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 09:21:35 -0500
Received: from [10.86.240.168] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 09:21:34 -0500
Message-ID: <4742ED6D.5030103@cisco.com>
Date: Tue, 20 Nov 2007 09:21:33 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Christer Holmberg 
Subject: Re: [Sip] SIPit 21: Question about offer answer
References: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com><4742359B.1060301@cisco.com>	<200711200138.lAK1cmun008944@dragon.ariadne.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 14:21:35.0048 (UTC)
	FILETIME=[A7C39480:01C82B80]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15556.002
X-TM-AS-Result: No--14.384300-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2832; t=1195568520;
	x=1196432520; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit=2021=3A=20Question=20about=20offer=20an
	swer |Sender:=20
	|To:=20Christer=20Holmberg=20;
	bh=i4zGeTFu2OeJbY3SkiGcjspBrZLWWZ6GJpstH0ycU6M=;
	b=A4XhDdTp7QBIKm4KrzyTal2ghUPtiLPn+1+L+lnZ0qsZA2w+FCCdzIh8dC8tXYLHjQeKj3pB
	35EFhb+HWPsD+J+E/rTNiFOlPN6n/ElBUjsg/ejr838HdRbw0INzFsLV;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Christer Holmberg wrote:
> Hi,
> 
> What if the offerer is not "prepared" to receive an updated answer (it
> only included the "offer" because it had to)? How can it "reject" the
> answer? 

It can't. At best it can make a counter offer after the fact, or 
terminate the call after the fact.

But that clearly isn't a good policy. You should design your UA so that 
this isn't an issue. When you make an offer you must always be prepared 
for the answer be anything that is compatible with the offer.

> I personally think that an unchanged o- line in the offer should not
> allow the answer to change.
> 
> One could of course change the o- line in the offer - even if the offer
> itself hasn't changed - and that would then allow the answer to be
> changed.

Personally I think the o-line changing or not is just an extra 
complication that should never have been there as a factor. Whether the 
o-line changes or not isn't what matters. What matters is whether the 
rest of the SDP changes. At best the o-line is a hint about whether the 
rest changed or not, and simply introduces the potential error case 
where the SDP doesn't agree with what the o-line is hinting. (So what 
should you do if the o-line is unchanged but the SDP is changed?)

But as things are written, you are expected to make the o-line the same 
if the rest of the SDP is the same. The o-line in the offer has 
*nothing* to do with what is in the answer.

	Paul

> Just some thinking...
> 
> Regards,
> 
> Christer
> 
> 
> 
>> -----Original Message-----
>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] 
>> Sent: 20. marraskuuta 2007 3:39
>> To: sip@ietf.org
>> Subject: Re: [Sip] SIPit 21: Question about offer answer
>>
>>    From: Paul Kyzivat 
>>
>>    A 3pcc controller doing a transfer may well send an 
>> offerless invite to 
>>    one UA and then send the offer it gets back to an entirely 
>> different UA 
>>    than had been in the session before. So of course the 
>> answer will be 
>>    entirely different.
>>
>> Hmmm, "my" music-on-hold proposal does that, too.
>>
>> Dale
>>
>>
>> _______________________________________________
>> 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
>>
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 09:47:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuUO8-0008RH-Pe; Tue, 20 Nov 2007 09:47:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuUO7-0008RC-8e
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:47:43 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUO6-0008Qc-TT
	for sip@ietf.org; Tue, 20 Nov 2007 09:47:42 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuUO5-0004kB-Vz
	for sip@ietf.org; Tue, 20 Nov 2007 09:47:42 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	338CA20F26; Tue, 20 Nov 2007 15:43:57 +0100 (CET)
X-AuditID: c1b4fb3c-a5cbbbb0000076c8-65-4742c58986e3
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	4128F2149D; Tue, 20 Nov 2007 12:31:20 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 12:31:03 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Date: Tue, 20 Nov 2007 12:31:02 +0100
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Thread-Index: Acgq7syf8K2Jo/ZvSfqo7EbSHcSgAAAANJCAAB4nE8A=
References: 
	<4741F8A7.204@nostrum.com>
	
From: "Christer Holmberg" 
To: "Hadriel Kaplan" , "Adam Roach" 
X-OriginalArrivalTime: 20 Nov 2007 11:31:03.0683 (UTC)
	FILETIME=[D5652D30:01C82B68]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

We shall note Adam's comment (Thanks for reading the draft, btw! :), but
I am not sure we need to re-submit before Vancouver. As Hadriel said, I
think we shall first discuss the concept, and then we can fix the
wording.

Regards,

Christer

=20

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20
> Sent: 19. marraskuuta 2007 23:07
> To: Adam Roach
> Cc: sip@ietf.org; Christer Holmberg
> Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
>=20
> Yeah my bad for not re-writing that whole thing.  It started=20
> out as a "rfc3265 Event Packages for INFO" type thing, but=20
> after your emails on the subject we were convinced that was a=20
> bad way to go.  I apologize for not cleaning it up better=20
> before submission.  Do you want me to re-submit using better=20
> terminology?  (unfortunately due to the submission deadlines=20
> I don't think I can do so officially?)
>=20
> I was thinking this was really just a discussion point doc=20
> for the Vancouver meeting, and if the concept in general was=20
> adopted we'd fix all the terminology.
>=20
> Sorry 'bout that.  :(
>=20
> -hadriel
>=20
>=20
> > -----Original Message-----
> > From: Adam Roach [mailto:adam@nostrum.com]
> > Sent: Monday, November 19, 2007 3:57 PM
> > To: Hadriel Kaplan
> > Cc: sip@ietf.org; Christer Holmberg
> > Subject: Re: [Sip] FW: I-D=20
> Action:draft-kaplan-sip-info-events-00.txt
> >
> > In general, I think the mechanism outlined in=20
> > draft-kaplan-sip-info-events-00 is a good starting place for=20
> > disambiguating multiple usages of INFO, and I'd like to=20
> thank Hadriel=20
> > and Christer for putting forth the effort to submit a=20
> concrete proposal.
> > I have a number of specific suggestions for improving the mechanism=20
> > that I'd like to offer up at some point in the future.
> >
> > However, I can't support the document in its current form.
> >
> > The current document conflates INFO packages with Event=20
> packages in a=20
> > way that is quite dangerous -- even going so far as to call INFO=20
> > packages "Event packages" in a few places (c.f. section 4: "The=20
> > general concept is that the UAC generating an INVITE=20
> request includes=20
> > the Event packages it supports sending and receiving, in=20
> two new headers:
> > Send-Event and Recv-Event."). It confusingly re-uses the "Event"=20
> > header field from RFC 3265, and even suggests that common=20
> packages can=20
> > be defined for RFC 3265 and for INFO.
> >
> > This harmful conflation between RFC 3265 event packages and INFO=20
> > packages pervades the document. Until this issue becomes=20
> less confused=20
> > in the text, I strongly believe that the document will do far, far=20
> > more damage than good.
> >
> > /a
> >
> > Hadriel Kaplan wrote:
> > > Howdy,
> > > Just an FYI that Christer and I submitted a draft for SIP INFO=20
> > > events,
> > based on the email discussion.  This is on the agenda for Vancouver.
> > > Cheers,
> > > -hadriel
> > >
> > >
> > >> -----Original Message-----
> > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > >> Sent: Thursday, November 08, 2007 11:00 PM
> > >> To: i-d-announce@ietf.org
> > >> Subject: I-D Action:draft-kaplan-sip-info-events-00.txt
> > >>
> > >> A New Internet-Draft is available from the on-line=20
> Internet-Drafts=20
> > >> directories.
> > >>
> > >>         Title           : SIP INFO Event Framework
> > >>         Author(s)       : H. Kaplan, et al.
> > >>         Filename        : draft-kaplan-sip-info-events-00.txt
> > >>         Pages           : 12
> > >>         Date            : 2007-11-08
> > >>
> > >> This document defines a proposed solution for defining,=20
> negotiating=20
> > >> and exchanging info-event notifications in INFO messages, within=20
> > >> SIP invite-created dialogs, for applications which need=20
> to exchange=20
> > >> session-related information inside the invite-created=20
> dialog.  This=20
> > >> draft addresses issues and open items from RFC 2976, and=20
> updates it.
> > >>
> > >>
> > >> A URL for this Internet-Draft is:
> > >>=20
> http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-events-00
> > >> .txt
> > >>
> > >> To remove yourself from the I-D Announcement list, send=20
> a message=20
> > >> to i-d-announce-request@ietf.org with the word=20
> unsubscribe in the=20
> > >> body of the message.
> > >> You can also visit=20
> > >> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > >> to change your subscription settings.
> > >>
> > >> Internet-Drafts are also available by anonymous FTP.=20
> Login with the=20
> > >> username "anonymous" and a password of your e-mail=20
> address. After=20
> > >> logging in, type "cd internet-drafts" and then
> > >>         "get draft-kaplan-sip-info-events-00.txt".
> > >>
> > >> A list of Internet-Drafts directories can be found in=20
> > >> http://www.ietf.org/shadow.html or=20
> > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >>
> > >> Internet-Drafts can also be obtained by e-mail.
> > >>
> > >> Send a message to:
> > >>         mailserv@ietf.org.
> > >> In the body type:
> > >>         "FILE=20
> /internet-drafts/draft-kaplan-sip-info-events-00.txt".
> > >>
> > >> NOTE:   The mail server at ietf.org can return the document in
> > >>         MIME-encoded form by using the "mpack" utility. =20
> To use this
> > >>         feature, insert the command "ENCODING mime"=20
> before the "FILE"
> > >>         command.  To decode the response(s), you will=20
> need "munpack" or
> > >>         a MIME-compliant mail reader.  Different MIME-compliant=20
> > >> mail readers
> > >>         exhibit different behavior, especially when dealing with
> > >>         "multipart" MIME messages (i.e. documents which=20
> have been split
> > >>         up into multiple messages), so check your local=20
> > >> documentation
> > on
> > >>         how to manipulate these messages.
> > >>
> > >> Below is the data which will enable a MIME compliant mail reader=20
> > >> implementation to automatically retrieve the ASCII=20
> version of the=20
> > >> Internet-Draft.
> > >>
> > >
> > >
> > >=20
> --------------------------------------------------------------------
> > > ----
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use=20
> > > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > > sipping@ietf.org for new developments on the application of sip
>=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 09:54:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuUUN-0007zV-T3; Tue, 20 Nov 2007 09:54:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuUUN-0007zF-8O
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:54:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUUM-0007z7-UN
	for sip@ietf.org; Tue, 20 Nov 2007 09:54:10 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuUUM-0004Kg-5k
	for sip@ietf.org; Tue, 20 Nov 2007 09:54:10 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAKEs3bE030663
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 20 Nov 2007 08:54:04 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Tue, 20 Nov 2007 08:54:01 -0600
To: "Sanjay Sinha (sanjsinh)" 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4855/Tue Nov 20 03:49:20 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Yeah - that's not it - it doesn't match your assertion even.
That text says that _if_ SDP shows up in the 200, you have to ignore it.
It doesn't say anything about it matching the 18x, and it doesn't say  
anything about whether the UAS is allowed to put it in the 200 in the  
first place.

Btw - that passage _IS BEING USED_ to argue that it's ok, and even  
_right_, to put SDP in the 200 OK since things MUST ignore it.

RjS

On Nov 19, 2007, at 6:35 PM, Sanjay Sinha (sanjsinh) wrote:

> Pl. see inline...
>
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: Monday, November 19, 2007 5:23 PM
>> To: Sanjay Sinha (sanjsinh)
>> Cc: sip List
>> Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>
>> Yes, I did mean 200 INVITE.
>>
>> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
>>
>>> It is not clear from the call flow if the 200 OK is for PRACK or
>>> INVITE?
>>>
>>> I guess you meant 200 OK for Invite. If that is the case, I
>> think the
>>> RFC is clear that the answer sdp is optional in it and if it
>> does have
>>> an answer sdp, it MUST be idential to answer in 18x.
>>>
>>
>> Really? Point me to where you find this please.
>
> I was referring to sec. 13.2.1 of RFC 3261.
>
>  o  If the initial offer is in an INVITE, the answer MUST be in a
> reliable non-failure message from UAS back to UAC which is
>  correlated to that INVITE.  For this specification, that is
> only the final 2xx response to that INVITE.  That same exact
> answer MAY also be placed in any provisional responses sent
> prior to the answer.  The UAC MUST treat the first session
> description it receives as the answer, and MUST ignore any
> session descriptions in subsequent responses to the initial
> INVITE.
>
> The strengths of assertion may not be what you are looking for here.
>
> Thanks
> Sanjay
>
>
>
>>
>>> But I think the
>>> offer-answer draft has clarified it further that it should not have
>>> any answer sdp. This is probably harsh in case of one offer-answer
>>> exchange, but makes sense if there are multiple early dialog
>>> offer-answer exchanges in say Prack/200 OK or using UPDATE.
>>>
>>> Sanjay
>>>
>>>> -----Original Message-----
>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>>> Sent: Monday, November 19, 2007 4:14 PM
>>>> To: sip List
>>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>>>
>>>> There was a lot of discussion and disagreement at SIPit21 about
>>>> whether the following 200 OK is allowed (or should) have SDP in it:
>>>>
>>>> INVITE (offer)
>>>> -------->
>>>> 18x (with 100rel) (answer)
>>>> <--------
>>>> PRACK
>>>> --------->
>>>> 200 OK (can this carry SDP?)
>>>> <---------
>>>> ACK
>>>> --------->
>>>>
>>>> I couldn't find anything definitive in RFC form. Paul's offeranswer
>>>> draft talks about this I think.
>>>>
>>>> If I understand things, the right answer here is that it's not
>>>> supposed to carry any SDP and that you should ignore it if it shows
>>>> up.
>>>>
>>>> The question is, other than waste, what can go wrong if it is  
>>>> there?
>>>> When we end up with clear text around the requirement, will it say
>>>> SDP SHOULD NOT, or MUST NOT appear?
>>>>
>>>> Or do I have this wrong?
>>>>
>>>> RjS
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>



_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 10:01:36 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuUbO-0004HV-Eo; Tue, 20 Nov 2007 10:01:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuUbN-0004CC-3A
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:01:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuUbM-00047l-7g; Tue, 20 Nov 2007 10:01:24 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IuUbL-0005AU-UC; Tue, 20 Nov 2007 10:01:24 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAKF1K0q025009; 
	Tue, 20 Nov 2007 09:01:21 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAKF1Kj23923; Tue, 20 Nov 2007 09:01:20 -0600 (CST)
Message-ID: <4742F6BF.8070300@alcatel-lucent.com>
Date: Tue, 20 Nov 2007 09:01:19 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Colin Perkins 
Subject: Re: [Sip] SIP IPv6 ABNF: Essential correction to RFC3261
References: <4730C66F.2070803@alcatel-lucent.com>
	<4741E624.9010805@nostrum.com>
	<8F34894D-AB5F-45F0-95C0-7326A6F2E5CA@csperkins.org>
In-Reply-To: <8F34894D-AB5F-45F0-95C0-7326A6F2E5CA@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: IETF SIP List , Adam Roach ,
	MMUSIC WG ,
	Brian E Carpenter 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Colin Perkins wrote:
> Can someone familiar with the issue also check the ABNF in RFC 4566 
> (SDP)? From a quick look, it seems that it has a similar problem...

Colin: Yes, it appears to.  Insofar as the rfc4566 ABNF is based on
rfc2373 Appendix B, it will have similar problems.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 10:07:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuUh8-0007T9-0h; Tue, 20 Nov 2007 10:07:22 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuUh6-0007L3-Oq
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:07:20 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUh6-0007F9-9E
	for sip@ietf.org; Tue, 20 Nov 2007 10:07:20 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuUh3-0005KV-Os
	for sip@ietf.org; Tue, 20 Nov 2007 10:07:18 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Tue, 20 Nov 2007 10:07:17 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Tue, 20 Nov 2007 10:07:16 -0500
From: Hadriel Kaplan 
To: Paul Kyzivat , "Vijay K. Gurbani"
	
Date: Tue, 20 Nov 2007 10:05:02 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Index: Acgq6mM+6iXFaGbmTbWZfi3sJKpJvAAmiuyQ
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
In-Reply-To: <4741F132.6060300@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, November 19, 2007 3:25 PM
> To: Vijay K. Gurbani
> Cc: Hadriel Kaplan; IETF SIP List; Rohan Mahy; Brett Tate
> Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
>
>
>
> Vijay K. Gurbani wrote:
> > Hadriel Kaplan wrote:
> >> I wouldn't. :)  It is no more "authenticated" than if the remote end
> >> opened a connection using an ephemeral port to the local host's
> >> listen port.  The local host client knows little about the validity
> >> of the remote end.  Actually, the client knows slightly more about
> >> the validity of a connection it opened to the far-end than the other
> >> way-around, especially if it did single-sided TLS to the far-end, so
> >> in that sense it makes more sense to accept requests over its client
> >> socket than over the listen port.  It just doesn't make much sense
> >> for the remote end to send them over it, unless it can authenticate
> >> (e.g., using digest).  And that's the rub.  Today certain types of
> >> devices fix NAT traversal for SIP/TCP or SIP/TLS without needing the
> >> client to do sip-outbound, so long as the client can accept requests
> >> over its persistent connection, because they can authenticate the
> >> client.  It's worked so far, anyway.  But this new MUST would break
> >> it.
> >
> > Hadriel: So essentially you are arguing for one of the following
> > positions (assume A makes an active TCP connection to B to send a
> > request downstream):
> >
> >   1) Allow B to send requests upstream (to A) as long as A can
> >    authenticate B, possibly using HTTP Digest (although how we
> >    will do so if A and B are proxies is an open question.)
> >   2) Downgrade the strength of S8.1 to something like the following:
> >    OLD:
> >     It MUST only accept responses over this connection and MUST NOT
> >     accept any requests over this connection.
> >    NEW:
> >     It accepts responses over this connection, but SHOULD NOT accept
> >     any requests.
>
> The above both seem like nonsense to me. Neither deals with the
> essential issue that B has no way of verifying that it is talking to A.
>
>         Paul

No, B does have a way of verifying it's talking to A.  B can digest challen=
ge A for the requests it got from A over that same connection previously.  =
As written in the draft, B has no way to verify it's talking to A when it c=
reates a new TCP connection to A, other than to believe the TCP listener is=
 A and SYN/ACK exchange is happening with A.  But we don't have to say anyt=
hing about this.  Just remove the MUST statement in the draft that A must n=
ot accept requests from B over a TCP or single-sided TLS connection created=
 by A to B.  You already say B must not reuse the connection to A because i=
t's not authenticated.  Leave it at that.

I am not arguing this just for the sake of argument.  Today this property o=
f reusing the connection from A to B for requests back to A is already depl=
oyed, and is essential for NAT traversal to work.  It works, and is as secu=
re as could be under the circumstances.  A creates a TCP or client-TLS conn=
ection to B.  A sends a request, B challenges it, A answers the challenge. =
 B can then knowingly send requests over the connection to A, and there's n=
o reason for A to reject them.  This is in fact the premise for sip-outboun=
d as well.

-hadriel


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 10:08:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuUi8-0008G9-Qi; Tue, 20 Nov 2007 10:08:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuUi7-0008Fw-IA
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:08:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUi7-0008Fm-3Z
	for sip@ietf.org; Tue, 20 Nov 2007 10:08:23 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuUi6-0005Lw-GK
	for sip@ietf.org; Tue, 20 Nov 2007 10:08:23 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2007 10:08:20 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAKF8KQT000543; 
	Tue, 20 Nov 2007 10:08:20 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAKF8AW9017108; 
	Tue, 20 Nov 2007 15:08:15 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 10:08:05 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Tue, 20 Nov 2007 10:08:07 -0500
Message-ID: <8983EC086A9D954BA74D9763E853CF3E0437EF96@xmb-rtp-215.amer.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: SDP in a 200OK when using 100rel
Thread-Index: AcgrhTjl79R2427sSG6tbH1qZIAv1gAAaDng
From: "Sanjay Sinha (sanjsinh)" 
To: "Robert Sparks" 
X-OriginalArrivalTime: 20 Nov 2007 15:08:05.0759 (UTC)
	FILETIME=[272848F0:01C82B87]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15556.002
X-TM-AS-Result: No--31.585200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4250; t=1195571300;
	x=1196435300; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20
	|Subject:=20RE=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20
	|To:=20=22Robert=20Sparks=22=20;
	bh=mUI3zL3p1SYxDccgyVB35LlhYDOC9BMe2GEK9I4XeU8=;
	b=Oih4eIHXVTb+oiEdJUmB31ghLw5k9F5bVhjPA9QEorG7O4nn/byinXMJpaRkZJqKeIicKfE7
	efBrmr8PfnjPPhXUJ5hSR762OYo1tXyQlMbNTbF6qJa2lF/5i6DM8qhm;
Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Okay, then it can probably be clarified in the offer-answer draft, if it
is not already.

Sanjay

>-----Original Message-----
>From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
>Sent: Tuesday, November 20, 2007 9:54 AM
>To: Sanjay Sinha (sanjsinh)
>Cc: sip List
>Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
>
>Yeah - that's not it - it doesn't match your assertion even.
>That text says that _if_ SDP shows up in the 200, you have to=20
>ignore it.
>It doesn't say anything about it matching the 18x, and it=20
>doesn't say anything about whether the UAS is allowed to put=20
>it in the 200 in the first place.
>
>Btw - that passage _IS BEING USED_ to argue that it's ok, and=20
>even _right_, to put SDP in the 200 OK since things MUST ignore it.
>
>RjS
>
>On Nov 19, 2007, at 6:35 PM, Sanjay Sinha (sanjsinh) wrote:
>
>> Pl. see inline...
>>
>>> -----Original Message-----
>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>> Sent: Monday, November 19, 2007 5:23 PM
>>> To: Sanjay Sinha (sanjsinh)
>>> Cc: sip List
>>> Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>>
>>> Yes, I did mean 200 INVITE.
>>>
>>> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
>>>
>>>> It is not clear from the call flow if the 200 OK is for PRACK or=20
>>>> INVITE?
>>>>
>>>> I guess you meant 200 OK for Invite. If that is the case, I
>>> think the
>>>> RFC is clear that the answer sdp is optional in it and if it
>>> does have
>>>> an answer sdp, it MUST be idential to answer in 18x.
>>>>
>>>
>>> Really? Point me to where you find this please.
>>
>> I was referring to sec. 13.2.1 of RFC 3261.
>>
>>  o  If the initial offer is in an INVITE, the answer MUST be in a=20
>> reliable non-failure message from UAS back to UAC which is =20
>correlated=20
>> to that INVITE.  For this specification, that is only the final 2xx=20
>> response to that INVITE.  That same exact answer MAY also be=20
>placed in=20
>> any provisional responses sent prior to the answer.  The UAC MUST=20
>> treat the first session description it receives as the answer, and=20
>> MUST ignore any session descriptions in subsequent responses to the=20
>> initial INVITE.
>>
>> The strengths of assertion may not be what you are looking for here.
>>
>> Thanks
>> Sanjay
>>
>>
>>
>>>
>>>> But I think the
>>>> offer-answer draft has clarified it further that it should=20
>not have=20
>>>> any answer sdp. This is probably harsh in case of one offer-answer=20
>>>> exchange, but makes sense if there are multiple early dialog=20
>>>> offer-answer exchanges in say Prack/200 OK or using UPDATE.
>>>>
>>>> Sanjay
>>>>
>>>>> -----Original Message-----
>>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>>>> Sent: Monday, November 19, 2007 4:14 PM
>>>>> To: sip List
>>>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>>>>
>>>>> There was a lot of discussion and disagreement at SIPit21 about=20
>>>>> whether the following 200 OK is allowed (or should) have=20
>SDP in it:
>>>>>
>>>>> INVITE (offer)
>>>>> -------->
>>>>> 18x (with 100rel) (answer)
>>>>> <--------
>>>>> PRACK
>>>>> --------->
>>>>> 200 OK (can this carry SDP?)
>>>>> <---------
>>>>> ACK
>>>>> --------->
>>>>>
>>>>> I couldn't find anything definitive in RFC form. Paul's=20
>offeranswer=20
>>>>> draft talks about this I think.
>>>>>
>>>>> If I understand things, the right answer here is that it's not=20
>>>>> supposed to carry any SDP and that you should ignore it=20
>if it shows=20
>>>>> up.
>>>>>
>>>>> The question is, other than waste, what can go wrong if it is=20
>>>>> there?
>>>>> When we end up with clear text around the requirement,=20
>will it say=20
>>>>> SDP SHOULD NOT, or MUST NOT appear?
>>>>>
>>>>> Or do I have this wrong?
>>>>>
>>>>> RjS
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>> This list is for NEW development of the core SIP Protocol Use=20
>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>>>>> sipping@ietf.org for new developments on the application of sip
>>>>>
>>>
>


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 10:26:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuUzS-00060h-8Y; Tue, 20 Nov 2007 10:26:18 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuUzR-00060W-5S
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:26:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUzQ-00060L-S5
	for sip@ietf.org; Tue, 20 Nov 2007 10:26:16 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuUzM-0005Dj-Ml
	for sip@ietf.org; Tue, 20 Nov 2007 10:26:16 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAKFPgYF025428; 
	Tue, 20 Nov 2007 09:25:42 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAKFPcj07528; Tue, 20 Nov 2007 09:25:41 -0600 (CST)
Message-ID: <4742FC72.2090806@alcatel-lucent.com>
Date: Tue, 20 Nov 2007 09:25:38 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: IETF SIP List , Rohan Mahy ,
	Paul Kyzivat , Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Trying to drill down to the mechanics of how this will work so the
draft can be updated...

Hadriel Kaplan wrote:
> No, B does have a way of verifying it's talking to A.  B can digest
> challenge A for the requests it got from A over that same connection
> previously.  

What if A and B are proxies?  Digest will not work in that case.

> As written in the draft, B has no way to verify it's
> talking to A when it creates a new TCP connection to A, other than to
> believe the TCP listener is A and SYN/ACK exchange is happening with
> A.  

Well, insofar if you trust DNS (yes, I know the fallacy of that
assumption, but ...), B has some  semblance that it is talking to A
since it got A's routing address from a DNS query.

> But we don't have to say anything about this.  Just remove the
> MUST statement in the draft that A must not accept requests from B
> over a TCP or single-sided TLS connection created by A to B.  You
> already say B must not reuse the connection to A because it's not
> authenticated.  Leave it at that.

Remove the statement, or soften the normative tone to a SHOULD?

> I am not arguing this just for the sake of argument.  Today this
> property of reusing the connection from A to B for requests back to A
> is already deployed, and is essential for NAT traversal to work.  It
> works, and is as secure as could be under the circumstances.  A
> creates a TCP or client-TLS connection to B.  A sends a request, B
> challenges it, A answers the challenge.  B can then knowingly send
> requests over the connection to A, and there's no reason for A to
> reject them.

Problem is that this challenge-response mode in SIP is defined
in HTTP Digest, and that is applicable only between a proxy/registrar
and a UA.  What happens if A and B are proxies?  Or am I missing
something?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 11:56:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuWOe-0001Ep-3L; Tue, 20 Nov 2007 11:56:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuWOc-00015U-Kw
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 11:56:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWOc-00012f-91
	for sip@ietf.org; Tue, 20 Nov 2007 11:56:22 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IuWOY-000824-Ae for sip@ietf.org; Tue, 20 Nov 2007 11:56:22 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-3.cisco.com with ESMTP; 20 Nov 2007 08:56:17 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAKGuHYE014880; 
	Tue, 20 Nov 2007 08:56:17 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAKGuGH0029891;
	Tue, 20 Nov 2007 16:56:17 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 08:56:16 -0800
Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 08:56:16 -0800
Message-ID: <474311D0.30409@cisco.com>
Date: Tue, 20 Nov 2007 11:56:48 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Paul Kyzivat 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
References: <8983EC086A9D954BA74D9763E853CF3E0437ED50@xmb-rtp-215.amer.cisco.com>	<6A10822E-CAC9-49DB-8DF5-200EFB342BF9@nostrum.com>
	<47422F2F.2080008@cisco.com>
In-Reply-To: <47422F2F.2080008@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 16:56:16.0234 (UTC)
	FILETIME=[43C82CA0:01C82B96]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5050; t=1195577777;
	x=1196441777; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20;
	bh=s3qlQl+JkG2hnzUutkImpM2CVGRQwk/7WcxRUow91bU=;
	b=qSyndrBGj1UcrPmAPHLhoBY+BaxJk0WBZkJ8DA5gFGz3ZECuq/qJy3Jh6kiR/AIQUTMAYiYx
	YOqZk3KUkz0EOlD9iv2biJ8IDZqtXXOuLAa95/iDBaHFRXBWcPfqUXUf;
Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

The intention was that, when reliable provisionals are used, the answer 
would NOT appear in the 200 OK to the original INVITE. The paragraph in 
RFC3261 is talking specifically about the case of an unreliable 
provisional response.

The drawback of sending the answer in the reliable 18x and then 
repeating it in the 200 OK, is what if they are not the same. It gets 
really complicated if there are multiple O/A exchanges in UPDATE/PRACK 
prior to the final 200 OK.

-Jonathan R.

Paul Kyzivat wrote:
> 
> 
> Robert Sparks wrote:
>> Yes, I did mean 200 INVITE.
>>
>> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
>>
>>> It is not clear from the call flow if the 200 OK is for PRACK or INVITE?
>>>
>>> I guess you meant 200 OK for Invite. If that is the case, I think the
>>> RFC is clear that the answer sdp is optional in it and if it does have
>>> an answer sdp, it MUST be idential to answer in 18x.
>>>
>>
>> Really? Point me to where you find this please.
> 
> Mostly in 3261 sec 13.2.1. It says:
> 
>       o  If the initial offer is in an INVITE, the answer MUST be in a
>          reliable non-failure message from UAS back to UAC which is
>          correlated to that INVITE.  For this specification, that is
>          only the final 2xx response to that INVITE.  That same exact
>          answer MAY also be placed in any provisional responses sent
>          prior to the answer.  The UAC MUST treat the first session
>          description it receives as the answer, and MUST ignore any
>          session descriptions in subsequent responses to the initial
>          INVITE.
> 
> The first three sentences are the clearly normative part. When combined 
> with RFC 3262 definition of reliable provisionals, they say that the 
> reliable provisional contains the answer.
> 
> The last sentence doesn't really say the UAS may include sdp in 
> subsequent responses to the invite transaction, but neither does it say 
> you can't. It does say the UAC should ignore them if present, which 
> implies they can be present, but says nothing about what value they must 
> have if they are present.
> 
> AFAIK there is nothing that says the answer may be repeated in the 200. 
> However it is seemingly done a lot, so one had better beware.
> 
>     Paul
> 
>>> But I think the
>>> offer-answer draft has clarified it further that it should not have any
>>> answer sdp. This is probably harsh in case of one offer-answer exchange,
>>> but makes sense if there are multiple early dialog offer-answer
>>> exchanges in say Prack/200 OK or using UPDATE.
> 
> 
> 
>>> Sanjay
>>>
>>>> -----Original Message-----
>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>>> Sent: Monday, November 19, 2007 4:14 PM
>>>> To: sip List
>>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>>>
>>>> There was a lot of discussion and disagreement at SIPit21
>>>> about whether the following 200 OK is allowed (or should) have
>>>> SDP in it:
>>>>
>>>> INVITE (offer)
>>>> -------->
>>>> 18x (with 100rel) (answer)
>>>> <--------
>>>> PRACK
>>>> --------->
>>>> 200 OK (can this carry SDP?)
>>>> <---------
>>>> ACK
>>>> --------->
>>>>
>>>> I couldn't find anything definitive in RFC form. Paul's
>>>> offeranswer draft talks about this I think.
>>>>
>>>> If I understand things, the right answer here is that it's not
>>>> supposed to carry any SDP and that you should ignore it if it shows up.
>>>>
>>>> The question is, other than waste, what can go wrong if it is there?
>>>> When we end up with clear text around the requirement, will it
>>>> say SDP SHOULD NOT, or MUST NOT appear?
>>>>
>>>> Or do I have this wrong?
>>>>
>>>> RjS
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
> 
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 12:06:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuWY0-00013y-At; Tue, 20 Nov 2007 12:06:04 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuWXy-00013j-Ji
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:06:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWXy-00013W-6W
	for sip@ietf.org; Tue, 20 Nov 2007 12:06:02 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuWXx-0000qC-On
	for sip@ietf.org; Tue, 20 Nov 2007 12:06:02 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-3.cisco.com with ESMTP; 20 Nov 2007 09:06:01 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAKH60HN032448; 
	Tue, 20 Nov 2007 09:06:00 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAKH5xUZ022409;
	Tue, 20 Nov 2007 17:06:00 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 09:05:58 -0800
Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 09:05:58 -0800
Message-ID: <47431417.1090205@cisco.com>
Date: Tue, 20 Nov 2007 12:06:31 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Francois Audet 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
References: <4741BB94.80202@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1348A595@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1348A595@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 17:05:58.0300 (UTC)
	FILETIME=[9EB865C0:01C82B97]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1863; t=1195578360;
	x=1196442360; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20; bh=/sC4nla6EUp1okUX8C+ADPiTkuaxCP5CK53DcTehAzs=;
	b=b3e1/EBhR5KHNYdVW7Pi3Xm6I+/t5XeLZlUZ+vK45bQFgxyk9KjwWEi7e1eOWq3slUl7RjpW
	ZbDrggM9YsgojjMdDBFcJbIkEblsEL+ZqBKmy5SI1REQxSyk66A+2nACSUP8nxCOkI/5leghuE
	9D8UsuBz4d7dS5UaaUUV/aitQ=;
Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

inline:

Francois Audet wrote:
> Jonathan,
> 
> What you are describing is actually a problem of non-compliance
> with SIP, where people are improperly using SIP URIs
> as if they were a Tel URI.

I don't think its a non-compliance issue; there is nothing in the spec 
that says you need to render to the domain part.

> 
> As you point out, they are adding a "bogus" domain name and
> route purely on the phone number and ignore the domain
> name.

Its ignored on the terminating UA; clearly within request-URI it is used 
to route the request along. But my point is that it is not a significant 
part of the identifier that a *user* cares about or validates.

> 
> This is quite unfortunate because, it 
> invalidates most "phone number-derived SIP URIs" in terms
> of SIP Identity. It is unfortunate, since if people used
> a native Tel URI for cases where the domain is 
> irrelevant, we wouldn't have this problem (and we couldn't
> use DTLS-SRTP for this).

Or SIP Identity.

> 
> Basically, "telephone number routing" overlaid on top of
> SIP breaks SIP routing. If I call somebody at +11015551212@example.com, 
> I really have no garantee that it won't end-up at 
> +11015551212@evil.org.
> 
> This problem more than a SIP Identity problem. It's more
> of a SIP usage problem.
> 
> Not sure how to deal with it.

Right now, I'm not proposing to deal with it at all. I'm just saying, 
this is a practical consideration that ought to be mentioned in the 
security considerations of draft-ietf-sip-dtls-framework.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 12:22:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuWnu-0000dE-Sv; Tue, 20 Nov 2007 12:22:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuWnt-0000d4-J3
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:22:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWnt-0000cA-8g
	for sip@ietf.org; Tue, 20 Nov 2007 12:22:29 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuWnp-0000ep-VR
	for sip@ietf.org; Tue, 20 Nov 2007 12:22:29 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lAKHMK725023; Tue, 20 Nov 2007 17:22:20 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] comments on draft-ietf-sip-dtls-framework
Date: Tue, 20 Nov 2007 11:21:07 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF134D3788@zrc2hxm0.corp.nortel.com>
In-Reply-To: <47431417.1090205@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Index: Acgrl6N8+0ANLkj3T+i9RxnIqy/H7wAAgBMA
References: <4741BB94.80202@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1348A595@zrc2hxm0.corp.nortel.com>
	<47431417.1090205@cisco.com>
From: "Francois Audet" 
To: "Jonathan Rosenberg" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
> Sent: Tuesday, November 20, 2007 09:07
> To: Audet, Francois (SC100:3055)
> Cc: IETF SIP List; Eric Rescorla
> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
>=20
> inline:
>=20
> Francois Audet wrote:
> > Jonathan,
> >=20
> > What you are describing is actually a problem of=20
> non-compliance with=20
> > SIP, where people are improperly using SIP URIs as if they=20
> were a Tel=20
> > URI.
>=20
> I don't think its a non-compliance issue; there is nothing in=20
> the spec that says you need to render to the domain part.

It's not the rendering I'm worried about.

It's the fact that the domain is ignored for routing, and only the =
userpart
is used.


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 13:15:44 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuXdC-00064k-ID; Tue, 20 Nov 2007 13:15:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuXdA-00064M-TA
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:15:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXdA-00064C-Dv
	for sip@ietf.org; Tue, 20 Nov 2007 13:15:28 -0500
Received: from smtp-1.hut.fi ([130.233.228.91])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXd2-0002Wi-4b
	for sip@ietf.org; Tue, 20 Nov 2007 13:15:28 -0500
Received: from localhost (katosiko.hut.fi [130.233.228.115])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAKIFIsk030350;
	Tue, 20 Nov 2007 20:15:18 +0200
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new,
	port 10024)
	with LMTP id 01908-17; Tue, 20 Nov 2007 20:15:17 +0200 (EET)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id lAKIEIJF029535;
	Tue, 20 Nov 2007 20:14:18 +0200
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 12DF03A2CDE;
	Tue, 20 Nov 2007 20:14:18 +0200 (EET)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 05680-07; Tue, 20 Nov 2007 20:14:15 +0200 (EET)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id 15D313A2CD8;
	Tue, 20 Nov 2007 20:14:15 +0200 (EET)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Tue, 20 Nov 2007 20:14:14 +0200
Message-ID: <20071120201414.rlay7fshwkssoo0w@horde-intra.tml.hut.fi>
Date: Tue, 20 Nov 2007 20:14:14 +0200
From: sergiole@tml.hut.fi
To: Attila Sipos 
Subject: RE: [Sip] Can a transactionstatelessproxysupportOutbounddraft?Ifyes,
	how will the response be sentback theUAbehind NAT
References: <680808427CF931459462C3D78CB5EC60AE6AF9@EXVS02.nasstar-t1.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC60AE6AF9@EXVS02.nasstar-t1.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org




>>>   Our approach tries to use the flow token also in responses: we just
>>> put the flow token in the Via. As mentioned before:
>>>   -the UA stores the flow token when it receives a 200 OK after
> REGISTER;
>
> So the flow token is stored in the UA's route set?


  I don't know how to answer where the flow token should be stored in =20
the UA. I did not studied about the UA details.
  We consider that the Edge Proxy is stateless but UACs are stateful.
  We assume that in an UAC  every flow will be associated to a =20
transaction and the transaction can store the flow token.
  We did not research about the UAC storing the flow token; so any =20
comments about  feasibility are welcome.

>
>>>   -then it puts it into every SIP request that is sent over a flow;
>
> So it goes into the Route headers.

Yes


> But you challenged that with this problem:
>>> Here is the issue : From were you get the flow token?
>>> (In my previous email I mentioned 2 options... )
>
> So, I'm a bit confused.  Is there a problem with using the
> flow token in the Via or not?  I think the answer is no.



  I think that NO if we do as we propose.

  And Yes, it is a problem if we limit only to the draft because the =20
draft does not say anything explicitly about
1) In the UA: storing the flow-token in the UA
2) In the UA: putting the flow token in the Route header if the flow =20
is used for outgoing requests
3) In the Ed.proxy : copying the flow token to the Via header.

  This is the approach we propose.


  It could be suggested that since the origin IP and port and so on =20
are known in the Edge Proxy, the flow token can be generated at any =20
time when request arrives.

  I don't know way we did not discuss this option before (our approach =20
was storing the flow token in the UA and your approach was retrieving =20
it from the registrar).

  One problem that I see generating the flow token at any time is =20
about the proxy rebooting; it will generate a flow token for a non =20
existent flow (although this issue is for discussing hours, because =20
depending on the implementation and protocols one can argue that if =20
the edge proxy rebooted, the UAC can no longer use the flow because it =20
disappeared.). Anyway the most important characteristic of our =20
approach is that the edge proxy can know that what arrives comes from =20
an outbound flow and then have a criteria to determine that the Via =20
header must have a flow token. Nevertheless I recognize that the =20
discussion is not complete. The edge proxy must have some kind of =20
mapping between the flow-tokens and socket descriptors that we did not =20
discuss... we sent to publish an abstract proposing a solution at =20
application level about this issue.

  After all these discussions we should remember that in fact the =20
draft does not discusses about using a flow for outbound requests; and =20
that a UAC can always avoid using the flow for outgoing requests just =20
by using the traditional approach (the UAC is behind the NAT and is =20
free to form any number of connections independent of outbound flows)

Sergio



Quoting Attila Sipos :

>>>   Our approach tries to use the flow token also in responses: we just
>>> put the flow token in the Via. As mentioned before:
>>>   -the UA stores the flow token when it receives a 200 OK after
> REGISTER;
>
> So the flow token is stored in the UA's route set?
>
>>>   -then it puts it into every SIP request that is sent over a flow;
>
> So it goes into the Route headers.
>
>>>   -then the edge proxy copies the flow token to the URI part of the
> Via
>>> when it composes the Via before to forward the message.
> ok
>
>>>   -Later, when the response arrives at the edge proxy, it tries to
>>> decode the flow token in the Via, if it succeeds, it  forwards the
>>> response over the flow indicated in the flow token.
>
> yes, looks good to me.
>
>>>   At what moment you generate the "branch flow token"
>>> (for example, when the Via is created?)
>
> yes, that was the idea.
>
>>>   I can not understand completely the idea, from my point of view
>>> it is easier to use the same flow token. Considering that the flow
>>> token considers the reboot, why it could be an advantage to use the
>>> "branch flow token" instead of the flow-token ?
>
> Well that's what I had thought originally (that it is
> easier to use the same flow token).
>
> In an earlier e-mail, I had said:
>>> 3.
>>>> In the Via header's branch parameter, it would encode the required
>>>> flow token.
>>>
>
> But you challenged that with this problem:
>>> Here is the issue : From were you get the flow token?
>>> (In my previous email I mentioned 2 options... )
>
> So, I'm a bit confused.  Is there a problem with using the
> flow token in the Via or not?  I think the answer is no.
>
> Anyway, the conclusion is this:
>  "Yes, it is possible for a transaction-stateless proxy
>  to support the outbound draft".
>
> Regards,
>
> Attila
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 19 November 2007 22:02
> To: Attila Sipos
> Cc: sip@ietf.org
> Subject: RE: [Sip] Can a
> transactionstatelessproxysupportOutbounddraft?Ifyes, how will the
> response be sentback theUAbehind NAT
>
>
>
> Hi,
>
>
>> I feel this would not be a problem for a stateless proxy providing
>> that it is not just a raw socket descriptor id that is passed to the
>> registrar.  The branch parameter in the Via would need some kind of
>> hashed/encrypted "reboot count" parameter as well as the socket id.
>> Then if the edge-proxy rebooted, it would know that the response
>> coming back is stale.  There are many ways to do the
>> hashing/encryption - you could use a method similar to that used in
>> the gruu draft Appendix A.2.
>> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-
>> 15
>> .txt
>
>    In outbound 10, 5.2.  Generating Flow Tokens :
>
> "When the proxy boots it selects a 20-octet crypto
>         random key called K that only the Edge Proxy knows."
>
>
>    Instead to using the 'reboot count', the approach mentioned in the
> draft already considers the case of old flow tokens that can remain
> stored in the registrar by using a different key every time the proxy
> reboots.
>
>
>
>> So the Via header's branch parameter would contain encoded information
>
>> about:
>> 1. the flow back to the UA (socket id, IP, port) 2. the reboot count
>
>    Our approach tries to use the flow token also in responses: we just
> put the flow token in the Via. As mentioned before:
>    -the UA stores the flow token when it receives a 200 OK after
> REGISTER;
>    -then it puts it into every SIP request that is sent over a flow;
>    -then the edge proxy copies the flow token to the URI part of the Via
> when it composes the Via before to forward the message.
>    -Later, when the response arrives at the edge proxy, it tries to
> decode the flow token in the Via, if it succeeds, it  forwards the
> response over the flow indicated in the flow token.
>
>
>> So my proposal is generating some kind of flow token (but not THE same
>
>> "flow token"as used in the REGISTER).  So there is the "flow token" as
> described in
>> theoutbound draft and now there is also a "branch flow token" that I
>> am
> ?proposing.
>
>    Perhaps can be a possible solution but seems complex.
>    At what moment you generate the "branch flow token" (for example,
> when the Via is created?)
>    I can not understand completely the idea, from my point of view it is
> easier to use the same flow token. Considering that the flow token
> considers the reboot, why it could be an advantage to use the "branch
> flow token" instead of the flow-token ?
>
>
> Regards,
>
> Sergio
>
> Quoting Attila Sipos :
>
>>
>>>>  The problem with the above (separated elements) is that there is
>>>> not synchronization about the state of the socket descriptors. As
>> mentioned
>>>> before, if the edge proxy crashes the socket descriptors used
>> immediately
>>>> after reboot could result in delivering messages to different flows.
>>>>
>>>>  In my opinion the randomness included in the flow token avoids that
>> to
>>>> happen, since after reboot the flowtoken can not be decoded and/or
>> find an
>>>> existing flow and that cause the return a error response.
>>
>>
>> Yes, absolutely.  And this is a problem with stateful proxies too.
>>
>> I have agreed with everything you've said.
>> However, I still think there is a way to do an outbound-compatible
>> edge proxy with a transaction-stateless/call-stateless proxy.
>>
>> So I now go back to say something similar to what I said before.
>> But first, I will refer to something you said in an earlier mail:
>>
>>>>  Furthermore my registrar should not store socket descriptors due
>>>> that if the edge proxy crashes, the registrar could have a number of
>
>>>> descriptor that after the crash belong to other flows.
>>
>> I feel this would not be a problem for a stateless proxy providing
>> that it is not just a raw socket descriptor id that is passed to the
>> registrar.  The branch parameter in the Via would need some kind of
>> hashed/encrypted "reboot count" parameter as well as the socket id.
>> Then if the edge-proxy rebooted, it would know that the response
>> coming back is stale.  There are many ways to do the
>> hashing/encryption - you could use a method similar to that used in
>> the gruu draft Appendix A.2.
>> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-
>> 15
>> .txt
>>
>> So the Via header's branch parameter would contain encoded information
>
>> about:
>> 1. the flow back to the UA (socket id, IP, port) 2. the reboot count
>>
>> So now I go back to something else you said:
>>>> 2) generate again the flow token for every request (very bad from
>>>> security point of views) and destroys the consistency of the system
>>>> since you can send requests for non existing flows. Note that the
>>>> draft mentions that the flow and the flow token is only created with
>> REGISTERs.
>>
>> So my proposal is generating some kind of flow token (but not THE same
>
>> "flow token"
>> as used in the REGISTER).  So there is the "flow token" as described
>> in the outbound draft and now there is also a "branch flow token" that
>
>> I am proposing.
>> And, as explained before, the information in the "branch flow token"
>> is used to route responses back to the UA.  But the original "flow
>> token" is never changed.
>> The original "flow token" would still be used when forwarding requests
>
>> to the UA because the Edge Proxy (in your diagram) would've added it
>> to the Path.  So requests to the UA would still work.
>>
>> Now I'm not sure about the security aspects.
>> What security problems could there be with "branch flow token" idea?
>>
>> Regards,
>> Attila
>>
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: 16 November 2007 15:53
>> To: Attila Sipos
>> Subject: RE: [Sip] Can a transaction
>> statelessproxysupportOutbounddraft?Ifyes, how will the response be
>> sent back theUAbehind NAT
>>
>>
>>
>>> I am starting to see the problems.
>>>
>>> If I understand correctly, your scenario is this...
>>>
>>> REGISTRAR--------PROXY----------NAT---------SIP UA
>>>
>>> Can you confirm?
>>
>> more specifically my scenario is
>>
>> REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA
>>
>>
>> where PROXY is a traditional SIP proxy
>>
>>
>>> And, since you were talking about scalability, you might also have
>>> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>>>
>>> is this right?
>>
>>
>>   About scalability I was thinking about
>>
>>
>>                         /EDGEPROXY1\
>> REGISTRAR/PROXY--------            ----------NAT---------SIP UA
>>                         \EDGEPROXY2/
>>
>>
>>   So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.
>>
>>
>>   I have no experience with registrars, I guess that in your case you
>> have a REGISTRAR/EDGEPROXY in the same process (or group of processes)
>
>> and not REGISTRAR--------EDGEPROXY (linked by other means).
>>
>>   The problem with the above (separated elements) is that there is not
>
>> synchronization about the state of the socket descriptors. As
>> mentioned before, if the edge proxy crashes the socket descriptors
>> used immediately after reboot could result in delivering messages to
>> different flows.
>>
>>   In my opinion the randomness included in the flow token avoids that
>> to happen, since after reboot the flowtoken can not be decoded and/or
>> find an existing flow and that cause the return a error response.
>>   Then another entry in the registrar binding will be used, i.e. other
>
>> flow token. If you have a second edge proxy (that does not crashed at
>> the same time that the first one :) and the flow token belongs to the
>> second edge proxy, the message will reach the UA over a flow
>> previously established to the second edge proxy.
>>
>>
>>
>> BR
>>
>> Sergio
>>
>>
>> Quoting Attila Sipos :
>>
>>>
>>>
>>>>>>>> 3.
>>>>>>>>> In the Via header's branch parameter, it would encode the
>>> required
>>>>>>>>> flow token.
>>>>>>>>
>>>>>>>> Here is the issue : From were you get the flow token?
>>>>>>>> (In my previous email I mentioned 2 options... )
>>>>>>>>
>>>>>>
>>>>>> OK I'm starting to see your problem.
>>>>>>
>>>>>> The registration record stores the flow token (obviously)
>>>>>
>>>>> It seems that you are integrating the edge proxy and registrar in
>>>>> the
>>> same code, right?
>>>
>>> yes, that's it.
>>>
>>>
>>>>>> And the socket id for the flow would be stored as well (for
>>>>>
>>>>> Can you confirm that you call socket id to the socket/file
>>>>> descriptor
>>> of the connection?
>>>
>>> yes.
>>>
>>>>>> connection-oriented
>>>>>> protocols). So if you received a request on that socket, you could
>
>>>>>> match that up to one of the registration records and hence, one of
>>> the
>>>>>> flow tokens.
>>>>>>
>>>>>
>>>>>  Good approach. I assume that you have available the socket
>>> descriptor
>>>>> in the registrar, so basically you consider storing the socket
>>> descriptor
>>>>> (number) in the registrar tables. Then perhaps using a flow token
>>>>> it
>>> is not
>>>>> necessary since you have available in the socket descriptor all the
>>> information
>>>>> that describes a flow (TCP case).
>>>
>>> That's true.  I might not need the flow tokens.
>>>
>>>
>>>>>> I hope I have explained how the flow token might be mapped to the
>>>>>> socket.
>>>>>
>>>>>  Yes if my comments above make sense..
>>>>>
>>>>>> I can now see that my idea wouldn't work for UDP.
>>>>>
>>>>>  Now for UDP perhaps you can consider storing the socket descriptor
>>> for
>>>>> UDP and the IP and port for the flow from the NAT.
>>>
>>> yes, that would work I think.
>>>
>>>
>>>>>  Furthermore my registrar should not store socket descriptors due
>>> that
>>>>> if the edge proxy crashes, the registrar could have a number of
>>> descriptor
>>>>> that after the crash belong to other flows.
>>>>>
>>>>>  I generate the flow token with REGISTER and send it to the
>>>>> registrar (other node). The approach works as the draft says for
>>>>> incoming
>>> requests
>>>>> (to the Calle). Now when the Callee  sends requests, and the
>>>>> requests
>>> are
>>>>> sent over the flow, the responses of that request reach first the
>>>>> edge
>>> proxy
>>>>> and it can not forward them to the Callee over the flow, because
>>>>> these responses don't have the flow token (and the flow token is
>>>>> not
>>
>>>>> stored
>>> in
>>>>> the edge proxy)...
>>>
>>> I am starting to see the problems.
>>>
>>> If I understand correctly, your scenario is this...
>>>
>>> REGISTRAR--------PROXY----------NAT---------SIP UA
>>>
>>> Can you confirm?
>>>
>>> And, since you were talking about scalability, you might also have
>>> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>>>
>>> is this right?
>>>
>>>
>>>>>> But what if you used the gruu in the contact to match up with the
>>> gruu
>>>>>> of a registration?  Then the registration record tells tells you
>>> about
>>>>>> the flow token.  That would work wouldn't it?
>>>>>
>>>>>  I have not background with gruu. Could you recommend what could I
>>> read about it?
>>>
>>> Sorry, I didn't mean gruu, I was mixing up my drafts!
>>> I was just looking for a unique identifier for the UA which is the
>>> sip.instance from the outbound draft (not gruu).
>>>
>>>
>>> Regards,
>>> Attila
>>>
>>
>>
>>
>
>
>
>





_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 13:41:24 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuY2B-0002ys-1V; Tue, 20 Nov 2007 13:41:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuY2A-0002yn-8k
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:41:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY29-0002yf-TN
	for sip@ietf.org; Tue, 20 Nov 2007 13:41:17 -0500
Received: from postal.iol.unh.edu ([132.177.123.84])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuY29-0005MC-7Y
	for sip@ietf.org; Tue, 20 Nov 2007 13:41:17 -0500
Received: from [132.177.121.70] (aeowen.iol.unh.edu [132.177.121.70])
	(authenticated bits=0)
	by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP id lAKIfCVk030571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Nov 2007 13:41:13 -0500
Message-ID: <47432A49.7070804@iol.unh.edu>
Date: Tue, 20 Nov 2007 13:41:13 -0500
From: "Lincoln Y. Lavoie" 
Organization: UNH-IOL
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jonathan Rosenberg 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
References: <8983EC086A9D954BA74D9763E853CF3E0437ED50@xmb-rtp-215.amer.cisco.com>	<6A10822E-CAC9-49DB-8DF5-200EFB342BF9@nostrum.com>	<47422F2F.2080008@cisco.com>
	<474311D0.30409@cisco.com>
In-Reply-To: <474311D0.30409@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.91.2/4855/Tue Nov 20 04:49:20 2007 on
	postal.iol.unh.edu
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: lylavoie@iol.unh.edu
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Isn't that exactly what preconditions does.  That is, use the 1xx 
messages to pas SDP back and forth until both sides have agreed on the 
media conditions required.

Jonathan Rosenberg wrote:
> The intention was that, when reliable provisionals are used, the answer 
> would NOT appear in the 200 OK to the original INVITE. The paragraph in 
> RFC3261 is talking specifically about the case of an unreliable 
> provisional response.
> 
> The drawback of sending the answer in the reliable 18x and then 
> repeating it in the 200 OK, is what if they are not the same. It gets 
> really complicated if there are multiple O/A exchanges in UPDATE/PRACK 
> prior to the final 200 OK.
> 
> -Jonathan R.
> 
> Paul Kyzivat wrote:
>>
>>
>> Robert Sparks wrote:
>>> Yes, I did mean 200 INVITE.
>>>
>>> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
>>>
>>>> It is not clear from the call flow if the 200 OK is for PRACK or 
>>>> INVITE?
>>>>
>>>> I guess you meant 200 OK for Invite. If that is the case, I think the
>>>> RFC is clear that the answer sdp is optional in it and if it does have
>>>> an answer sdp, it MUST be idential to answer in 18x.
>>>>
>>>
>>> Really? Point me to where you find this please.
>>
>> Mostly in 3261 sec 13.2.1. It says:
>>
>>       o  If the initial offer is in an INVITE, the answer MUST be in a
>>          reliable non-failure message from UAS back to UAC which is
>>          correlated to that INVITE.  For this specification, that is
>>          only the final 2xx response to that INVITE.  That same exact
>>          answer MAY also be placed in any provisional responses sent
>>          prior to the answer.  The UAC MUST treat the first session
>>          description it receives as the answer, and MUST ignore any
>>          session descriptions in subsequent responses to the initial
>>          INVITE.
>>
>> The first three sentences are the clearly normative part. When 
>> combined with RFC 3262 definition of reliable provisionals, they say 
>> that the reliable provisional contains the answer.
>>
>> The last sentence doesn't really say the UAS may include sdp in 
>> subsequent responses to the invite transaction, but neither does it 
>> say you can't. It does say the UAC should ignore them if present, 
>> which implies they can be present, but says nothing about what value 
>> they must have if they are present.
>>
>> AFAIK there is nothing that says the answer may be repeated in the 
>> 200. However it is seemingly done a lot, so one had better beware.
>>
>>     Paul
>>
>>>> But I think the
>>>> offer-answer draft has clarified it further that it should not have any
>>>> answer sdp. This is probably harsh in case of one offer-answer 
>>>> exchange,
>>>> but makes sense if there are multiple early dialog offer-answer
>>>> exchanges in say Prack/200 OK or using UPDATE.
>>
>>
>>
>>>> Sanjay
>>>>
>>>>> -----Original Message-----
>>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>>>> Sent: Monday, November 19, 2007 4:14 PM
>>>>> To: sip List
>>>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>>>>
>>>>> There was a lot of discussion and disagreement at SIPit21
>>>>> about whether the following 200 OK is allowed (or should) have
>>>>> SDP in it:
>>>>>
>>>>> INVITE (offer)
>>>>> -------->
>>>>> 18x (with 100rel) (answer)
>>>>> <--------
>>>>> PRACK
>>>>> --------->
>>>>> 200 OK (can this carry SDP?)
>>>>> <---------
>>>>> ACK
>>>>> --------->
>>>>>
>>>>> I couldn't find anything definitive in RFC form. Paul's
>>>>> offeranswer draft talks about this I think.
>>>>>
>>>>> If I understand things, the right answer here is that it's not
>>>>> supposed to carry any SDP and that you should ignore it if it shows 
>>>>> up.
>>>>>
>>>>> The question is, other than waste, what can go wrong if it is there?
>>>>> When we end up with clear text around the requirement, will it
>>>>> say SDP SHOULD NOT, or MUST NOT appear?
>>>>>
>>>>> Or do I have this wrong?
>>>>>
>>>>> RjS
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
> 

-- 
**********************************************************************
Lincoln Lavoie
Senior Engineer
UNH InterOperability Laboratory
121 Technology Drive, Suite 2, Durham, NH 03824
+1-603-862-4809
AIM: LincolnAtIOL, MSN: lincolnatiol@hotmail.com
Jabber: lincoln.lavoie@gmail.com

Ars sine scientia nihil est! -- Art without science is nothing.
Scientia sine ars est vacua! -- Science without art is empty.
**********************************************************************


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 14:06:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuYQi-00060m-58; Tue, 20 Nov 2007 14:06:40 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuYQh-00060a-2L
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:06:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYQg-00060R-OP
	for sip@ietf.org; Tue, 20 Nov 2007 14:06:38 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuYQd-0004x1-AZ
	for sip@ietf.org; Tue, 20 Nov 2007 14:06:38 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	BB3182050C; Tue, 20 Nov 2007 20:06:34 +0100 (CET)
X-AuditID: c1b4fb3c-b1f9bbb0000030cf-9c-4743303a2cac
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	90331203E2; Tue, 20 Nov 2007 20:06:34 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 20:06:34 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Tue, 20 Nov 2007 20:03:54 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: SDP in a 200OK when using 100rel
Thread-Index: AcgrlnemKGawUkJgQYKYzpf/pmfuFQAEaC5I
References: <8983EC086A9D954BA74D9763E853CF3E0437ED50@xmb-rtp-215.amer.cisco.com>	<6A10822E-CAC9-49DB-8DF5-200EFB342BF9@nostrum.com>
	<47422F2F.2080008@cisco.com> <474311D0.30409@cisco.com>
From: "Christer Holmberg" 
To: "Jonathan Rosenberg" ,
	"Paul Kyzivat" 
X-OriginalArrivalTime: 20 Nov 2007 19:06:34.0489 (UTC)
	FILETIME=[77D33690:01C82BA8]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,
=20
An implementation should keep offer/answer state and simply discard the =
SDP in the 200 OK.
=20
I don't think that is complicated :)
=20
Regards,
=20
Christer

________________________________

From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
Sent: Tue 20/11/2007 17:56
To: Paul Kyzivat
Cc: Sanjay Sinha (sanjsinh); sip List
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel



The intention was that, when reliable provisionals are used, the answer
would NOT appear in the 200 OK to the original INVITE. The paragraph in
RFC3261 is talking specifically about the case of an unreliable
provisional response.

The drawback of sending the answer in the reliable 18x and then
repeating it in the 200 OK, is what if they are not the same. It gets
really complicated if there are multiple O/A exchanges in UPDATE/PRACK
prior to the final 200 OK.

-Jonathan R.

Paul Kyzivat wrote:
>
>
> Robert Sparks wrote:
>> Yes, I did mean 200 INVITE.
>>
>> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
>>
>>> It is not clear from the call flow if the 200 OK is for PRACK or =
INVITE?
>>>
>>> I guess you meant 200 OK for Invite. If that is the case, I think =
the
>>> RFC is clear that the answer sdp is optional in it and if it does =
have
>>> an answer sdp, it MUST be idential to answer in 18x.
>>>
>>
>> Really? Point me to where you find this please.
>
> Mostly in 3261 sec 13.2.1. It says:
>
>       o  If the initial offer is in an INVITE, the answer MUST be in a
>          reliable non-failure message from UAS back to UAC which is
>          correlated to that INVITE.  For this specification, that is
>          only the final 2xx response to that INVITE.  That same exact
>          answer MAY also be placed in any provisional responses sent
>          prior to the answer.  The UAC MUST treat the first session
>          description it receives as the answer, and MUST ignore any
>          session descriptions in subsequent responses to the initial
>          INVITE.
>
> The first three sentences are the clearly normative part. When =
combined
> with RFC 3262 definition of reliable provisionals, they say that the
> reliable provisional contains the answer.
>
> The last sentence doesn't really say the UAS may include sdp in
> subsequent responses to the invite transaction, but neither does it =
say
> you can't. It does say the UAC should ignore them if present, which
> implies they can be present, but says nothing about what value they =
must
> have if they are present.
>
> AFAIK there is nothing that says the answer may be repeated in the =
200.
> However it is seemingly done a lot, so one had better beware.
>
>     Paul
>
>>> But I think the
>>> offer-answer draft has clarified it further that it should not have =
any
>>> answer sdp. This is probably harsh in case of one offer-answer =
exchange,
>>> but makes sense if there are multiple early dialog offer-answer
>>> exchanges in say Prack/200 OK or using UPDATE.
>
>
>
>>> Sanjay
>>>
>>>> -----Original Message-----
>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>>> Sent: Monday, November 19, 2007 4:14 PM
>>>> To: sip List
>>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>>>>
>>>> There was a lot of discussion and disagreement at SIPit21
>>>> about whether the following 200 OK is allowed (or should) have
>>>> SDP in it:
>>>>
>>>> INVITE (offer)
>>>> -------->
>>>> 18x (with 100rel) (answer)
>>>> <--------
>>>> PRACK
>>>> --------->
>>>> 200 OK (can this carry SDP?)
>>>> <---------
>>>> ACK
>>>> --------->
>>>>
>>>> I couldn't find anything definitive in RFC form. Paul's
>>>> offeranswer draft talks about this I think.
>>>>
>>>> If I understand things, the right answer here is that it's not
>>>> supposed to carry any SDP and that you should ignore it if it shows =
up.
>>>>
>>>> The question is, other than waste, what can go wrong if it is =
there?
>>>> When we end up with clear text around the requirement, will it
>>>> say SDP SHOULD NOT, or MUST NOT appear?
>>>>
>>>> Or do I have this wrong?
>>>>
>>>> RjS
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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
>

--
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                          =
 PHONE: (408) 902-3084
http://www.cisco.com =20


_______________________________________________
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




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 14:21:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuYeg-00005I-Cd; Tue, 20 Nov 2007 14:21:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuYee-00005D-GV
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:21:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYee-000050-5j
	for sip@ietf.org; Tue, 20 Nov 2007 14:21:04 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuYeb-0005mh-KB
	for sip@ietf.org; Tue, 20 Nov 2007 14:21:04 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Tue, 20 Nov 2007 14:20:59 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Tue, 20 Nov 2007 14:20:59 -0500
From: Hadriel Kaplan 
To: "Vijay K. Gurbani" 
Date: Tue, 20 Nov 2007 14:18:46 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Index: AcgriaoORW/6Iqd8SBWeEAFHOLu+RwAFtk5A
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<4742FC72.2090806@alcatel-lucent.com>
In-Reply-To: <4742FC72.2090806@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: IETF SIP List , Mahy ,
	Paul Kyzivat , Rohan, Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]
> Sent: Tuesday, November 20, 2007 10:26 AM
> To: Hadriel Kaplan
> Cc: Paul Kyzivat; IETF SIP List; Rohan Mahy; Brett Tate
> Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
>
> Trying to drill down to the mechanics of how this will work so the
> draft can be updated...
>
> Hadriel Kaplan wrote:
> > No, B does have a way of verifying it's talking to A.  B can digest
> > challenge A for the requests it got from A over that same connection
> > previously.
>
> What if A and B are proxies?  Digest will not work in that case.

True enough. (well... actually some proxies are digest challenged, but they=
 essentially act as UA's for that, and obviously it requires a shared secre=
t)
I was just responding to Paul when he said B has no way to authenticate A. =
 And B may well have local configuration which tells it that A is who it th=
inks it is.  For example this is sometimes the case for SIP-PBX connections=
 to providers.  The PBX is essentially a proxy (ie, "Proxy A"), and is some=
times behind a firewall, and the TCP connection from it to the provider's p=
roxy B needs to be reused for requests to the Enterprise due to that firewa=
ll.  Certain machinations occur to keep that TCP connection up and re-open =
it if it fails, but essentially the validity of using it for requests to th=
e Enterprise is provisioned or somehow known by Proxy B.  I'm not asking an=
y of that be specified, defined, etc.  I'm just using a real-world example,=
 to say there are cases where B knows (or thinks it knows) who Proxy A is.


> > I am not arguing this just for the sake of argument.  Today this
> > property of reusing the connection from A to B for requests back to A
> > is already deployed, and is essential for NAT traversal to work.  It
> > works, and is as secure as could be under the circumstances.  A
> > creates a TCP or client-TLS connection to B.  A sends a request, B
> > challenges it, A answers the challenge.  B can then knowingly send
> > requests over the connection to A, and there's no reason for A to
> > reject them.
>
> Problem is that this challenge-response mode in SIP is defined
> in HTTP Digest, and that is applicable only between a proxy/registrar
> and a UA.  What happens if A and B are proxies?  Or am I missing
> something?

I think the disconnect is you're trying to say proxy A should police the be=
havior of proxy B?  Proxy B may or may not have a legitimate reason for sen=
ding a request to proxy A on A's client TCP/TLS connection.  The draft shou=
ld and does say B shouldn't do this, but of course that can always be overr=
idden by B's local policy (ie, it may know better).  If it has such a polic=
y, there is really no reason A shouldn't allow it.  Even if it DOESN'T have=
 such a policy, there is really no reason A shouldn't allow it.  There is n=
othing damaging to A, nor A's domain, about accepting a request over that c=
onnection vs. its listen socket.

It's B's responsibility and fault if it sends requests to the wrong agent. =
 It's not A's role or fault for accepting them.  It's up to proxy B to figu=
re out who/where proxy A is.  It's not up to proxy A to second-guess what B=
 thinks it knows.  Proxy A knows who Proxy A is.

-hadriel
p.s., sorry for sticking on this point, it's just that when we get into deb=
ates with other vendors over interop issues in the field, RFCs are the tie-=
breakers; and these seemingly innocuous statements in RFCs often come back =
to bite us. :(



_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 14:32:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuYpy-00067z-BM; Tue, 20 Nov 2007 14:32:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuYpx-00066a-92
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:32:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYpw-00066S-VW
	for sip@ietf.org; Tue, 20 Nov 2007 14:32:44 -0500
Received: from n3.bullet.mail.tp2.yahoo.com ([203.188.202.79])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuYps-0006GF-5J
	for sip@ietf.org; Tue, 20 Nov 2007 14:32:44 -0500
Received: from [202.43.196.224] by n3.bullet.mail.tp2.yahoo.com with NNFMP;
	20 Nov 2007 19:32:38 -0000
Received: from [217.12.4.214] by t1.bullet.tpe.yahoo.com with NNFMP;
	20 Nov 2007 19:32:38 -0000
Received: from [216.252.122.219] by t1.bullet.ukl.yahoo.com with NNFMP;
	20 Nov 2007 19:32:38 -0000
Received: from [69.147.65.158] by t4.bullet.sp1.yahoo.com with NNFMP;
	20 Nov 2007 19:32:37 -0000
Received: from [127.0.0.1] by omp406.mail.sp1.yahoo.com with NNFMP;
	20 Nov 2007 19:32:37 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 800612.16026.bm@omp406.mail.sp1.yahoo.com
Received: (qmail 98341 invoked by uid 60001); 20 Nov 2007 18:46:30 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=Y3dHE3lXTVhWmahk5aY63faBXiQvtiM5d/rG0xQMIBhIBCc3gze07HngW6jjcT9nZXFDiC0XXHxttMaXJrrf7bmYue2fnQboQMr4WsFQN92xriMJ5Np/L/vkG/UWDFhXZe9Rn3aD4JYSWVcFdmQM/5VSntMC4sxm3nK7P0BzJJc=;
X-YMail-OSG: nwkSZ_0VM1lyE6gtGep4EfxIxPwX.gK9R3pdXq_U13u4GnmVPEIrYJFHoxfL6vkfWDTRbDIrPhU5ZTVZ.CsW4j4oPA--
Received: from [69.107.88.246] by web44905.mail.sp1.yahoo.com via HTTP;
	Tue, 20 Nov 2007 10:46:29 PST
X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157
Date: Tue, 20 Nov 2007 10:46:29 -0800 (PST)
From: Samir Srivastava 
To: sip@ietf.org
MIME-Version: 1.0
Message-ID: <114436.96155.qm@web44905.mail.sp1.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [Sip] Is Mike Hammer of Cisco Listening
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1773326499=="
Errors-To: sip-bounces@ietf.org

--===============1773326499==
Content-Type: multipart/alternative; boundary="0-1714326907-1195584389=:96155"

--0-1714326907-1195584389=:96155
Content-Type: text/plain; charset=us-ascii

Hi,

   Please contact me for the next version of draft.

Thx
Samir

PS: I check this email very irregularly.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
--0-1714326907-1195584389=:96155
Content-Type: text/html; charset=us-ascii


Hi,


 


   Please contact me for the next version of draft.


 


Thx


Samir


 


PS: I check this email very irregularly. 


      
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.
--0-1714326907-1195584389=:96155--




--===============1773326499==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1773326499==--






From sip-bounces@ietf.org Tue Nov 20 14:50:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuZ7E-0006UJ-2W; Tue, 20 Nov 2007 14:50:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuZ7C-0006Gk-5q
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:50:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZ7B-0006E5-OG
	for sip@ietf.org; Tue, 20 Nov 2007 14:50:33 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZ7B-0008L1-6k
	for sip@ietf.org; Tue, 20 Nov 2007 14:50:33 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lAKJnHPj004970
	for ; Tue, 20 Nov 2007 13:50:30 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 13:49:58 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 20:49:56 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 20 Nov 2007 20:49:56 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918001933A64@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Essential corrections
Thread-Index: AcgrrobfoYNP5KZJQfWREf3GGho6DQ==
From: "DRAGE, Keith \(Keith\)" 
To: "IETF SIP List" 
X-OriginalArrivalTime: 20 Nov 2007 19:49:56.0891 (UTC)
	FILETIME=[86FA3EB0:01C82BAE]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Subject: [Sip] Essential corrections
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

The following documents are currently those we have identified as
forming part of the essential corrections process for SIP. We intend to
start WGLC on at least some of these shortly after Vancouver.

http://www.ietf.org/internet-drafts/draft-gurbani-sip-ipv6-abnf-fix-00.t
xt
http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-01.t
xt
http://www.ietf.org/internet-drafts/draft-hilt-sip-correction-503-01.txt
http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-00.txt

And currently expired but to be reposted:

http://tools.ietf.org/html/draft-sparks-sip-invfix-00

Now would be a good time to identify if:

-	this is not a problem, or not an essential correction in the
current understanding of the term.
-	we have the wrong fix to the problem.
-	there is a lack of explanation of the problem.


At some point fairly shortly we are also going to see a revised version
of

http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-05.txt

Incorporating

http://www.ietf.org/internet-drafts/draft-sparks-sipping-max-breadth-01.
txt

Which will also be going for a renewed WGLC.

Regards

Keith


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 14:53:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuZAO-0000KI-MH; Tue, 20 Nov 2007 14:53:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuZAN-0000Bm-0G
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:53:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZAM-0000Bd-JU
	for sip@ietf.org; Tue, 20 Nov 2007 14:53:50 -0500
Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZAM-0008Vb-57
	for sip@ietf.org; Tue, 20 Nov 2007 14:53:50 -0500
Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44])
	by QMTA04.westchester.pa.mail.comcast.net with comcast
	id F6x41Y00C0xGWP80507500; Tue, 20 Nov 2007 19:53:49 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA12.westchester.pa.mail.comcast.net with comcast
	id F7to1Y00d0umElk0300000; Tue, 20 Nov 2007 19:53:49 +0000
X-Authority-Analysis: v=1.0 c=1 a=rBkLa1qTkTbGkcICx-gA:9
	a=0hZw17LWBQw-FKsyBq0A:7 a=npppZQgTZKC20D2UeDEjHeYuXI8A:4
	a=3FZX-ydVlcEA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAKJrmSV014753
	for ; Tue, 20 Nov 2007 14:53:48 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAKJrmA1014749;
	Tue, 20 Nov 2007 14:53:48 -0500
Date: Tue, 20 Nov 2007 14:53:48 -0500
Message-Id: <200711201953.lAKJrmA1014749@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <4741D47A.4020502@alcatel-lucent.com> (vkg@alcatel-lucent.com)
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
	
	<4741D47A.4020502@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Vijay K. Gurbani" 

   We could nail a line in the sand and make this more concrete (i.e.,
   use between proxies only.)  Or we could take a middle road and allow
   implementors who have reflective connectivity between a UA and a
   (proxy) server use connect-reuse.  So far, the draft has been taking
   the middle road.

It's clear that connection-reuse can be done between a UA and a proxy
(or two UA's for that matter).  It doesn't solve the problem that
outbound solves, namely what if connections can only be opened in one
direction.  (connection-reuse implicitly assumes that whoever wants to
send a request first can open a connection.)  What we need to make
sure is that the two mechanisms don't interfere with each other.  This
probably isn't hard, no more than saying "if you're using outbound to
communicate with a SIP agent, don't use connection-use to talk to that
agent".

Dale


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 15:30:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuZjY-00059A-L5; Tue, 20 Nov 2007 15:30:12 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuZjU-00056n-1Z
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 15:30:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZjT-00056I-M4
	for sip@ietf.org; Tue, 20 Nov 2007 15:30:07 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuZjS-0000tr-JB
	for sip@ietf.org; Tue, 20 Nov 2007 15:30:07 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAKKTpMF050182
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 20 Nov 2007 14:29:51 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <5D1A7985295922448D5550C94DE2918001933A64@DEEXC1U01.de.lucent.com>
References: <5D1A7985295922448D5550C94DE2918001933A64@DEEXC1U01.de.lucent.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <75D93870-A488-4FFE-BAAF-5E677DC24980@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] Essential corrections
Date: Tue, 20 Nov 2007 14:29:49 -0600
To: "DRAGE, Keith ((Keith))" 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4855/Tue Nov 20 03:49:20 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

????

I submitted fork-loop-fix-06 back at the beginning of the month using  
the online submission tool.

I don't see it in the repository though.

I'll see if I can figure out what happened.

You can get the draft at
http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-06.txt
for now.

RjS
On Nov 20, 2007, at 1:49 PM, DRAGE, Keith ((Keith)) wrote:

> The following documents are currently those we have identified as
> forming part of the essential corrections process for SIP. We  
> intend to
> start WGLC on at least some of these shortly after Vancouver.
>
> http://www.ietf.org/internet-drafts/draft-gurbani-sip-ipv6-abnf- 
> fix-00.t
> xt
> http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route- 
> fix-01.t
> xt
> http://www.ietf.org/internet-drafts/draft-hilt-sip- 
> correction-503-01.txt
> http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual- 
> auth-00.txt
>
> And currently expired but to be reposted:
>
> http://tools.ietf.org/html/draft-sparks-sip-invfix-00
>
> Now would be a good time to identify if:
>
> -	this is not a problem, or not an essential correction in the
> current understanding of the term.
> -	we have the wrong fix to the problem.
> -	there is a lack of explanation of the problem.
>
>
> At some point fairly shortly we are also going to see a revised  
> version
> of
>
> http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop- 
> fix-05.txt
>
> Incorporating
>
> http://www.ietf.org/internet-drafts/draft-sparks-sipping-max- 
> breadth-01.
> txt
>
> Which will also be going for a renewed WGLC.
>
> Regards
>
> Keith
>
>
> _______________________________________________
> 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



_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 16:06:20 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuaID-0005OT-Cq; Tue, 20 Nov 2007 16:06:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuaIB-0005OA-90
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 16:05:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaIA-0005O1-I2
	for sip@ietf.org; Tue, 20 Nov 2007 16:05:58 -0500
Received: from tpamail2.verizon.com ([192.76.82.136])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuaIA-0004AY-5h
	for sip@ietf.org; Tue, 20 Nov 2007 16:05:58 -0500
Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92])
	by tpamail2.verizon.com (8.13.3/8.13.3) with ESMTP id lAKL5s51018954
	for ; Tue, 20 Nov 2007 16:05:55 -0500 (EST)
Received: from ftwccout01.verizon.com (ftwccout01.verizon.com [138.83.131.134])
	by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id lAKL5sFK022369
	for ; Tue, 20 Nov 2007 16:05:54 -0500 (EST)
Received: from ftwccout01.verizon.com (unknown [127.0.0.1])
	by ftwccout01.verizon.com (Symantec Mail Security) with ESMTP id
	AAB71528002 for ; Tue, 20 Nov 2007 16:05:54 -0500 (EST)
X-AuditID: 8a538386-a4beabb000000945-c8-47434c32a1d9 
Received: from coregate2.verizon.com (unknown [138.83.34.48])
	by ftwccout01.verizon.com (EMF) with ESMTP id 78D5F4E4006
	for ; Tue, 20 Nov 2007 16:05:54 -0500 (EST)
Received: from dwsmtp03.core.verizon.com (dwsmtp03.verizon.com [138.83.35.63])
	by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id lAKL8AtV015021
	for ; Tue, 20 Nov 2007 15:08:11 -0600 (CST)
From: nabeel.2.cocker@verizon.com
To: sip@ietf.org
Message-ID: 
Date: Tue, 20 Nov 2007 16:05:51 -0500
X-MIMETrack: Serialize by Router on DWSMTP03/HSVR/Verizon(Release
	7.0.2FP2HF294 | September 14, 2007) at 11/20/2007 15:05:53
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Subject: [Sip] Nabeel 2. Cocker/EMPL/NY/Bell-Atl is out of the office.
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0810902534=="
Errors-To: sip-bounces@ietf.org

--===============0810902534==
Content-type: multipart/alternative; 
	Boundary="0__=0ABBF90ADFE0623C8f9e8a93df938690918c0ABBF90ADFE0623C"
Content-Disposition: inline

--0__=0ABBF90ADFE0623C8f9e8a93df938690918c0ABBF90ADFE0623C
Content-type: text/plain; charset=US-ASCII


I will be out of the office starting  11/19/2007 and will not return until
11/26/2007.

I will respond to your message when I return.

Regards,
Nabeel
--0__=0ABBF90ADFE0623C8f9e8a93df938690918c0ABBF90ADFE0623C
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline



I will be out of the office starting  11/19/2007 and will not return until 11/26/2007.



I will respond to your message when I return.



Regards,

Nabeel
--0__=0ABBF90ADFE0623C8f9e8a93df938690918c0ABBF90ADFE0623C--




--===============0810902534==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0810902534==--






From sip-bounces@ietf.org Tue Nov 20 16:38:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuanK-00048Q-2j; Tue, 20 Nov 2007 16:38:10 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuanI-00048F-7Q
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 16:38:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuanH-000487-QF
	for sip@ietf.org; Tue, 20 Nov 2007 16:38:07 -0500
Received: from smtp3.versatel.nl ([62.58.50.90])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuanH-0005Sp-1j
	for sip@ietf.org; Tue, 20 Nov 2007 16:38:07 -0500
Received: (qmail 29917 invoked by uid 0); 20 Nov 2007 21:37:32 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6])
	([87.212.11.198]) (envelope-sender )
	by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 20 Nov 2007 21:37:32 -0000
Message-ID: <474353B0.1050804@zonnet.nl>
Date: Tue, 20 Nov 2007 22:37:52 +0100
From: Jeroen van Bemmel 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IETF SIP List , Janet P Gunn 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: 
Subject: [Sip] RPH in responses : alternative GETS flow
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Janet,

Regarding 
http://www.ietf.org/internet-drafts/draft-gunn-sip-req-for-rph-in-responses-00.txt:

Thanks for writing this, it does help a lot to clarify the intended 
usage. However, I believe it does not resolve any of the concerns 
regarding the security issues.

As already identified in your document, an alternative solution is to 
send an UPDATE request in the opposite direction. A potential issue with 
this solution is that UPDATE cannot be sent until the dialog is 
established. So what if the B2BUA AS would simply send an empty 183 
response with 100rel back to the caller (as a status update), in 
parallel with forwarding the INVITE further upstream? Then the caller 
would send a PRACK to confirm, and after the PRACK is OK'ed the B2BUA 
would place SDP2 in an UPDATE request instead of a 183 response. Like so

    A                            GETS AS                             B
    |                                |                                |
    |-----------(1) INVITE SDP1----->|                                |
    |                    Look up in data base for                     |
    |                         priority level (=3)                     |
    |                                |                                |
    |<-(2a) 183 Ses Progress no SDP- |---(2b) INVITE SDP1 RPH wps.3-->|
    |-------------(3) PRACK--------->|                                |
    |<---------(4) 200 OK (PRACK)----|                                |
    |                                |<-(5) 183 Session Progress SDP2-|                      
    |<-(6a) UPDATE RPH wps.3 SDP2----|---(6b) PRACK RPH wps.3---***-->|
    |  ***                           |                          * *   |
    |  * *                           |                          * *   |
    |--*R*---------(7) OK----------->|<--(8) 200 OK (PRACK)-----* *---|
    |  *E*                           |                          *R*   |
    |  *S*                           |                          *E*   |
    |  *E*                           |                          *R*   |
    |  *R*                           |                          *E*   |
    |  *V*                           |                          *R*   |
    |  *A*                           |                          *V*   |
    |  *T*                           |                          *A*   |
    |  *I*                           |                          *T*   |
    |  *O*                           |                          *I*   |
    |  *N*                           |                          *O*   |
    |  ***                           |                          *N*   |
    |  ***                           |                          ***   |
    |  ***                           |                          ***   |
    |---(9) UPDATE SDP3------------->|                                |

It's 2 messages more than your proposed flow, but it allows to authenticate the source of the RPH 
(and provides earlier feedback to the caller, about the successful start of the GETS service) 

Regards,
Jeroen




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 17:22:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IubTh-0000q1-HZ; Tue, 20 Nov 2007 17:21:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IubTg-0000pq-DQ
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 17:21:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IubTg-0000pg-2G
	for sip@ietf.org; Tue, 20 Nov 2007 17:21:56 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IubTd-0005UW-Ly
	for sip@ietf.org; Tue, 20 Nov 2007 17:21:56 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAKMLlZt011382; 
	Tue, 20 Nov 2007 16:21:48 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAKMLhj22554; Tue, 20 Nov 2007 16:21:46 -0600 (CST)
Message-ID: <47435DF6.3040202@alcatel-lucent.com>
Date: Tue, 20 Nov 2007 16:21:42 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<4742FC72.2090806@alcatel-lucent.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: IETF SIP List , Rohan Mahy ,
	Paul Kyzivat , Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hadriel Kaplan wrote:
> True enough. (well... actually some proxies are digest challenged,
> but they essentially act as UA's for that, and obviously it requires
> a shared secret) I was just responding to Paul when he said B has no
> way to authenticate A.
[...]
> I think the disconnect is you're trying to say proxy A should police
> the behavior of proxy B?  Proxy B may or may not have a legitimate
> reason for sending a request to proxy A on A's client TCP/TLS
> connection.  

Hadriel: The bottom line of your reasoning boils down to this:

If A opens up a TCP connection to B, and it has some policy such
that it considers B to be trusted, it MAY insert an alias parameter
in the topmost Via of that request.  This will cause B to send
requests in the backwards direction over that connection.
Exactly what this policy is will be left up to each service
provider and implementation.

The draft can adequately warn implementations not to do so over
TCP due to various security reasons documented elsewhere in the
draft.  The normative strength of reusing a TCP connection in
this manner could be left as a SHOULD, with strong incentives
to perform connection reuse only over TLS.

Would this be a working solution that will strike a middle-
ground?  Is this agreeable to everyone else (Paul? others?)

> sorry for sticking on this point, it's just that when
> we get into debates with other vendors over interop issues in the
> field, RFCs are the tie-breakers; and these seemingly innocuous
> statements in RFCs often come back to bite us. :(

Funny -- so you have also been doing the frantic "RFC3261-dance-to-
support-my-argument (TM)" ;-)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 17:22:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IubTf-0000p8-OX; Tue, 20 Nov 2007 17:21:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IubTe-0000oy-FW
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 17:21:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IubTd-0000op-Lv
	for sip@ietf.org; Tue, 20 Nov 2007 17:21:53 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IubTb-0005UQ-Fh
	for sip@ietf.org; Tue, 20 Nov 2007 17:21:53 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAKMLoPp011425; 
	Tue, 20 Nov 2007 16:21:50 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAKMLoj22578; Tue, 20 Nov 2007 16:21:50 -0600 (CST)
Message-ID: <47435DFE.1020203@alcatel-lucent.com>
Date: Tue, 20 Nov 2007 16:21:50 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>		<4741D47A.4020502@alcatel-lucent.com>
	<200711201953.lAKJrmA1014749@dragon.ariadne.com>
In-Reply-To: <200711201953.lAKJrmA1014749@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dale.Worley@comcast.net wrote:
>    From: "Vijay K. Gurbani" 
> 
>    We could nail a line in the sand and make this more concrete (i.e.,
>    use between proxies only.)  Or we could take a middle road and allow
>    implementors who have reflective connectivity between a UA and a
>    (proxy) server use connect-reuse.  So far, the draft has been taking
>    the middle road.
> 
> It's clear that connection-reuse can be done between a UA and a proxy
> (or two UA's for that matter).  It doesn't solve the problem that
> outbound solves, namely what if connections can only be opened in one
> direction.  (connection-reuse implicitly assumes that whoever wants to
> send a request first can open a connection.)  What we need to make
> sure is that the two mechanisms don't interfere with each other.  This
> probably isn't hard, no more than saying "if you're using outbound to
> communicate with a SIP agent, don't use connection-use to talk to that
> agent".

Agreed -- sounds good.  A version of such a statement is already
given in S2:

    2. Applicability Statement

    The applicability of the mechanism described in this document is for
    two adjacent SIP entities to reuse connections when they are agnostic
    about the direction of the connection, i.e., either end can initiate
    the connection.  SIP entities that can only open a connection in a
    specific direction -- perhaps because of Network Address Translation
    (NAT) and firewall reasons -- reuse their connections using the
    mechanism described in [9].

I can reword this to make the outbound part more explicit; something
like:

    2. Applicability Statement

    The applicability of the mechanism described in this document is for
    two adjacent SIP entities to reuse connections when they are agnostic
    about the direction of the connection, i.e., either end can initiate
    the connection.  If connections can only be opened in one direction,
    perhaps due to the existence of firewalls and Network Address
    Translators (NATs), then the mechanism described by Jennings and
    Mahy [9] MUST be used instead.

Okay?

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 18:04:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuc9C-0007t3-VK; Tue, 20 Nov 2007 18:04:50 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuc9B-0007sw-MZ
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 18:04:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuc9B-0007so-Cm
	for sip@ietf.org; Tue, 20 Nov 2007 18:04:49 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Iuc96-0006hF-Vn for sip@ietf.org; Tue, 20 Nov 2007 18:04:49 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-3.cisco.com with ESMTP; 20 Nov 2007 15:04:44 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAKN4ilP006991; 
	Tue, 20 Nov 2007 15:04:44 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAKN4U46010145;
	Tue, 20 Nov 2007 23:04:35 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 18:04:31 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 18:04:30 -0500
Message-ID: <474367FD.4090800@cisco.com>
Date: Tue, 20 Nov 2007 18:04:29 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Nov 2007 23:04:30.0861 (UTC)
	FILETIME=[B534B3D0:01C82BC9]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5161; t=1195599884;
	x=1196463884; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20WGLC=3A=20draft-ietf-sip-connect-reuse-08.txt
	|Sender:=20; bh=EvX4ENtQXzbQf5Q3EPbrY7/2UVtdCTlALVxEcmCisCQ=;
	b=u4ipwKIjrbW8PiQW15RWhQ9JYfh/KUKLlKtvJ/3YVFx/lIHcQvuDHjAcI4q1totraCk2nGxN
	J2ithLYieQy09yLIsAKMl7B/lHoa7SGZSakU/KbC6/x9ClgLEIClFPpP;
Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Inline.

Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: Monday, November 19, 2007 3:25 PM
>> To: Vijay K. Gurbani
>> Cc: Hadriel Kaplan; IETF SIP List; Rohan Mahy; Brett Tate
>> Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
>>
>>
>>
>> Vijay K. Gurbani wrote:
>>> Hadriel Kaplan wrote:
>>>> I wouldn't. :)  It is no more "authenticated" than if the remote end
>>>> opened a connection using an ephemeral port to the local host's
>>>> listen port.  The local host client knows little about the validity
>>>> of the remote end.  Actually, the client knows slightly more about
>>>> the validity of a connection it opened to the far-end than the other
>>>> way-around, especially if it did single-sided TLS to the far-end, so
>>>> in that sense it makes more sense to accept requests over its client
>>>> socket than over the listen port.  It just doesn't make much sense
>>>> for the remote end to send them over it, unless it can authenticate
>>>> (e.g., using digest).  And that's the rub.  Today certain types of
>>>> devices fix NAT traversal for SIP/TCP or SIP/TLS without needing the
>>>> client to do sip-outbound, so long as the client can accept requests
>>>> over its persistent connection, because they can authenticate the
>>>> client.  It's worked so far, anyway.  But this new MUST would break
>>>> it.
>>> Hadriel: So essentially you are arguing for one of the following
>>> positions (assume A makes an active TCP connection to B to send a
>>> request downstream):
>>>
>>>   1) Allow B to send requests upstream (to A) as long as A can
>>>    authenticate B, possibly using HTTP Digest (although how we
>>>    will do so if A and B are proxies is an open question.)
>>>   2) Downgrade the strength of S8.1 to something like the following:
>>>    OLD:
>>>     It MUST only accept responses over this connection and MUST NOT
>>>     accept any requests over this connection.
>>>    NEW:
>>>     It accepts responses over this connection, but SHOULD NOT accept
>>>     any requests.
>> The above both seem like nonsense to me. Neither deals with the
>> essential issue that B has no way of verifying that it is talking to A.
>>
>>         Paul
> 
> No, B does have a way of verifying it's talking to A. 
> B can digest challenge A for the requests it got from A
> over that same connection previously. 

In general a digest challenge from B to A can't be correlated directly 
to the address of A. So a successful response to the challenge won't 
help with future reverse routing.

What is the digest challenging?

Lets take a case. Assume we have sip:alice@atlanta.com calling 
sip:bob@biloxi.com. But the call goes first to sip:edge.atlanta.com 
(based on some outbound "proxy" configured for alice) and then to 
sip:edge.biloxy.com (based on SRV lookup), and then to sip:bob@biloxy.com.

And lets just consider connection reuse between edge.atlanta.com and 
edge.biloxi.com. The connection is established in that direction. 
edge.biloxi.com *thinks* the name of the previous hop is 
edge.atlanta.com because of the Via header. But what digest challenge 
can edge.biloxi.com do to verify that the prior hop is who it thinks it is?

> As written in the draft,
> B has no way to verify it's talking to A when it creates a new
> TCP connection to A, other than to believe the TCP listener is A
> and SYN/ACK exchange is happening with A. 

The original connection was from A to B, and A had no better way to 
verify that it was talking to B.

> But we don't have to
> say anything about this.  Just remove the MUST statement in the
> draft that A must not accept requests from B over a TCP or
> single-sided TLS connection created by A to B.  You already say B
> must not reuse the connection to A because it's not authenticated. 
> Leave it at that.

I will agree that this isn't a concern of A's. It is B that has the 
concern, and lacks knowledge to reuse the connection. So it is B that we 
should be giving MUST NOT or SHOULD NOT instructions to.

I would be ok with saying that B MUST NOT reuse this connection for 
requests to the supposed party at the other end UNLESS it has some way 
of verifying the identity of that party to the same level of assurance 
as it would have by doing the DNS lookup and establishing its own 
connection. For instance, if a DNS lookup resolved to the same address 
and port as the source port of the inbound connection then that ought be 
be good enough.

	Thanks,
	Paul

> I am not arguing this just for the sake of argument.  Today this property of reusing the connection from A to B for requests back to A is already deployed, and is essential for NAT traversal to work.  It works, and is as secure as could be under the circumstances.  A creates a TCP or client-TLS connection to B.  A sends a request, B challenges it, A answers the challenge.  B can then knowingly send requests over the connection to A, and there's no reason for A to reject them.  This is in fact the premise for sip-outbound as well.
> 
> -hadriel
> 


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 18:34:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IucbV-00082y-J1; Tue, 20 Nov 2007 18:34:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IucbT-0007yU-IW
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 18:34:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IucbT-0007yK-8T
	for sip@ietf.org; Tue, 20 Nov 2007 18:34:03 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IucbQ-0008H5-JK
	for sip@ietf.org; Tue, 20 Nov 2007 18:34:03 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Tue, 20 Nov 2007 18:33:58 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Tue, 20 Nov 2007 18:33:58 -0500
From: Hadriel Kaplan 
To: Paul Kyzivat 
Date: Tue, 20 Nov 2007 18:31:44 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Index: Acgryb4YJpVAkb0nRgKekwbHiqf7zgAASaJQ
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
In-Reply-To: <474367FD.4090800@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, November 20, 2007 6:04 PM
> To: Hadriel Kaplan
> Cc: Vijay K. Gurbani; IETF SIP List; Rohan Mahy; Brett Tate
> Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
>
> In general a digest challenge from B to A can't be correlated directly
> to the address of A. So a successful response to the challenge won't
> help with future reverse routing.
>
> [snip]
> And lets just consider connection reuse between edge.atlanta.com and
> edge.biloxi.com. The connection is established in that direction.
> edge.biloxi.com *thinks* the name of the previous hop is
> edge.atlanta.com because of the Via header. But what digest challenge
> can edge.biloxi.com do to verify that the prior hop is who it thinks it
> is?

As I said in another email, I was referring to digest challenge for endpoin=
ts, not proxies.
People do digest-challenge proxies, but they do so in a weird way - for exa=
mple they digest challenge a Register from the proxy acting as a UA, where =
the proxy has a specific AoR that represents its "trunk". (this is basicall=
y the SIP-Forum's SIP-Connect optional PBX registration model - it's not we=
ll defined, and not clean from a SIP perspective)


> > But we don't have to
> > say anything about this.  Just remove the MUST statement in the
> > draft that A must not accept requests from B over a TCP or
> > single-sided TLS connection created by A to B.  You already say B
> > must not reuse the connection to A because it's not authenticated.
> > Leave it at that.
>
> I will agree that this isn't a concern of A's. It is B that has the
> concern, and lacks knowledge to reuse the connection. So it is B that we
> should be giving MUST NOT or SHOULD NOT instructions to.
>
> I would be ok with saying that B MUST NOT reuse this connection for
> requests to the supposed party at the other end UNLESS it has some way
> of verifying the identity of that party to the same level of assurance
> as it would have by doing the DNS lookup and establishing its own
> connection. For instance, if a DNS lookup resolved to the same address
> and port as the source port of the inbound connection then that ought be
> be good enough.

Awesome - that's all I'm saying as well.  B must not reuse the connection u=
nless it knows better.  If it sends the request to A over A's client connec=
tion, there's no reason to mandate A not accept it.  A has nothing to fear,=
 only B does.

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 19:23:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IudMj-0003s4-Tq; Tue, 20 Nov 2007 19:22:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IudMi-0003qX-Cf
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:22:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IudMi-0003qO-2y
	for sip@ietf.org; Tue, 20 Nov 2007 19:22:52 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IudMd-0001DP-B7
	for sip@ietf.org; Tue, 20 Nov 2007 19:22:52 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2007 19:22:47 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAL0MlOF006461; 
	Tue, 20 Nov 2007 19:22:47 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAL0MDxN021783; 
	Wed, 21 Nov 2007 00:22:38 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 19:22:33 -0500
Received: from [161.44.174.241] ([161.44.174.241]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 19:22:32 -0500
Message-ID: <47437A45.40409@cisco.com>
Date: Tue, 20 Nov 2007 19:22:29 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 00:22:32.0946 (UTC)
	FILETIME=[9BF22D20:01C82BD4]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3600; t=1195604567;
	x=1196468567; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20WGLC=3A=20draft-ietf-sip-connect-reuse-08.txt
	|Sender:=20 |To:=20Hadriel=20Kaplan=20;
	bh=+3GH+2Uf1/sz5oS2qqJAtXLHoycIudX8eV7P1UkQ+8k=;
	b=oZilEsOlUxK0vSH7fBggneaSTLlJDGbVlUFd/3QY5rIEBGBAKejjoc4jMJOJ5mLo4ldGJ1aW
	94KH6CvfZnt7avK/e+Peju3/MhHr8p620+29YMYJhZvGSkL+/KGLAIbL;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: Tuesday, November 20, 2007 6:04 PM
>> To: Hadriel Kaplan
>> Cc: Vijay K. Gurbani; IETF SIP List; Rohan Mahy; Brett Tate
>> Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
>>
>> In general a digest challenge from B to A can't be correlated directly
>> to the address of A. So a successful response to the challenge won't
>> help with future reverse routing.
>>
>> [snip]
>> And lets just consider connection reuse between edge.atlanta.com and
>> edge.biloxi.com. The connection is established in that direction.
>> edge.biloxi.com *thinks* the name of the previous hop is
>> edge.atlanta.com because of the Via header. But what digest challenge
>> can edge.biloxi.com do to verify that the prior hop is who it thinks it
>> is?
> 
> As I said in another email, I was referring to digest challenge for endpoints, not proxies.
> People do digest-challenge proxies, but they do so in a weird way - for example they digest challenge a Register from the proxy acting as a UA, where the proxy has a specific AoR that represents its "trunk". (this is basically the SIP-Forum's SIP-Connect optional PBX registration model - it's not well defined, and not clean from a SIP perspective)

Even with endpoints its not good enough in general.

If a request is From sip:alice@atlanta.com and you successfully digest 
challenge that, does it mean that you can send a request to 
sip:albert@atlanta.com on the same connection? Not unless you can 
actually tie the digest credentials to .

But I guess you were only using digest as an example, while you actually 
intend to use some other technique.

>>> But we don't have to
>>> say anything about this.  Just remove the MUST statement in the
>>> draft that A must not accept requests from B over a TCP or
>>> single-sided TLS connection created by A to B.  You already say B
>>> must not reuse the connection to A because it's not authenticated.
>>> Leave it at that.
>> I will agree that this isn't a concern of A's. It is B that has the
>> concern, and lacks knowledge to reuse the connection. So it is B that we
>> should be giving MUST NOT or SHOULD NOT instructions to.
>>
>> I would be ok with saying that B MUST NOT reuse this connection for
>> requests to the supposed party at the other end UNLESS it has some way
>> of verifying the identity of that party to the same level of assurance
>> as it would have by doing the DNS lookup and establishing its own
>> connection. For instance, if a DNS lookup resolved to the same address
>> and port as the source port of the inbound connection then that ought be
>> be good enough.
> 
> Awesome - that's all I'm saying as well.  B must not reuse the connection unless it knows better.  If it sends the request to A over A's client connection, there's no reason to mandate A not accept it.  A has nothing to fear, only B does.

Well, I really wasn't trying to "make your day". :-)

I fear leaving it that loose without at least some added words of 
wisdom. Perhaps some statements about typical means of decision that are 
not sufficient. (E.g. a successfully digest challenged registration of 
sip:alice@atlanta.com does not mean that the connection can be reused 
for anything addressed to sip:atlanta.com.

We have a lot of history of people taking carefully phrased things like 
this and using them to justify a lot of incorrect behavior. We don't 
want this to be misconstrued.

	Thanks,
	Paul


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 19:34:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IudXd-0006Lo-Ae; Tue, 20 Nov 2007 19:34:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IudXb-0006Co-JU
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:34:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IudXb-0006CV-9X
	for sip@ietf.org; Tue, 20 Nov 2007 19:34:07 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IudXU-0001Up-GE for sip@ietf.org; Tue, 20 Nov 2007 19:34:07 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-3.cisco.com with ESMTP; 20 Nov 2007 16:34:00 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAL0Y0Ii013715; 
	Tue, 20 Nov 2007 16:34:00 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAL0Xx40002038;
	Wed, 21 Nov 2007 00:33:59 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 16:33:59 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.148.187]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Nov 2007 16:33:59 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 20 Nov 2007 18:33:58 -0600
To: Daniel Grotti , IETF SIP List 
From: "James M. Polk" 
Subject: Re: [Sip] a question about IETF draft location conveyance 09 
In-Reply-To: <4742BDF5.9040302@unibo.it>
References: <4742BDF5.9040302@unibo.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 21 Nov 2007 00:33:59.0531 (UTC)
	FILETIME=[352EBBB0:01C82BD6]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2563; t=1195605240;
	x=1196469240; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20[Sip]=20a=20question=20about=20IETF=20draft=20locatio
	n=20conveyance=2009=20 |Sender:=20;
	bh=xXG2vbWlanvoo0CdbQ8/3NP+QI1n4MgT/+2Lt8q+RJQ=;
	b=e1go5d9OFsyeezWvYRiqTGpyNqgvNSQgg5qlnVz/agDe0XnRd6YP7u9r8/Sg4JaB73ZlbjLH
	3RwE9Z/9nHLr5sFXbrPaqsvLXRUPQe4dS7TRXhtf3SwzkWTFQpPmPIEl;
Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Daniel

wow... you nailed this one quickly.

Neither the SIP WG nor Geopriv WG have a position with regard to 
this.  I don't like the parameter at all, and have said so from its 
introduction into discussions about putting it in the draft.  I don't 
think it accomplishes much more than confusion or a false sense of 
security by implementors.

That said, a proxy has "ar" capabilities wrt the Geolocation 
according to Table 1. (on page 7), and associated text states this 
pretty clearly. There is no text (not even a hint) that a proxy 
cannot read a location because "recipient=endpoint", therefore it 
can.  I would take this "recipient=" parameter as a hint to each type 
of SIP entity that

         + if a UAS receives this parameter (meaning in a SIP request with
            a Geolocation header), and it is set to "recipient", the UAS
            shouldn't ignore the location in the request (like it otherwise
            might).

         + If a proxy receives this parameter (meaning in a SIP request with
            a Geolocation header), and it is set to "server", the proxy
            shouldn't ignore the location in the request (like it otherwise
            might).

I don't think either indication *ever* means the other SIP entity 
type cannot view the location, based on the parameter.  The only 
exception I can think of is a Location-by-value hidden by S/MIME 
means no one save who has the decryption key can view the contents of 
what's encrypted.

Does this make sense?

James

At 04:59 AM 11/20/2007, Daniel Grotti wrote:
>Hi all,
>I'd like to ask a question about "draft-ietf-sip-location-conveyance-09.txt".
>
>How does Proxy Server have to work when a Geolocation Header contain 
>"recipient=endpoint" parameter ?
>Does the Proxy server just have to forward the SIP message (without 
>do anything else) or can it read the information conveyed ?
>thanks,
>Regards
>daniel
>
>--
>
>---------------------------------------------------
>Daniel Grotti
>DEIS - University of Bologna
>Via Venezia, 52 - 47023 Cesena (FC) - ITALY
>
>Contacts
>e-mail : daniel.grotti@unibo.it
>Skype name : Daniel Grotti
>---------------------------------------------------
>
>
>
>_______________________________________________
>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


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 20 23:09:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuguB-0006Ri-B8; Tue, 20 Nov 2007 23:09:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iugu9-0006Rc-LJ
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 23:09:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iugu9-0006R2-BF
	for sip@ietf.org; Tue, 20 Nov 2007 23:09:37 -0500
Received: from py-out-1112.google.com ([64.233.166.180])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iugu5-00070U-El
	for sip@ietf.org; Tue, 20 Nov 2007 23:09:37 -0500
Received: by py-out-1112.google.com with SMTP id d32so12960255pye
	for ; Tue, 20 Nov 2007 20:09:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=j/1nh7Untl15UYc8jCflfqnJrsNNyVSYjYBzEXEw83A=;
	b=D9Rsd+vbN5QaLA5jTh+xEFeW+SS2SEjpT2ljaw/Y78xY3KrCua355sb3nlzc6nII5fO4EUqqDSX0ajGi5Rw0k87l7x/3uGdfuXCjBR7l+kNt2O9rmVCWj8yWjxBrvQaf0JePcADWp5dhtTtnmITmZpGtP5z7zsBBlXv9BpcOTqg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=YKX3rhg0Zisp5yQA6ruNEFecUkXaOLVQrDQN0kUxV4kXDsVUjVUFE+KuxbtlBZonmcBg+KEANXLNz8q3I5qYmxZVW+vubfD4HED067Epp9ufV0YLu6GX3gOoV1Tj+6ZFEuJROuK7nYKqIfPNSh3t/01pFN5MykRBoMcM7yFCmII=
Received: by 10.65.180.9 with SMTP id h9mr15844981qbp.1195618172436;
	Tue, 20 Nov 2007 20:09:32 -0800 (PST)
Received: by 10.64.84.19 with HTTP; Tue, 20 Nov 2007 20:09:32 -0800 (PST)
Message-ID: <66cd252f0711202009x11f42f35s445c25c4f12508a6@mail.gmail.com>
Date: Wed, 21 Nov 2007 15:09:32 +1100
From: "Hisham Khartabil" 
To: "Paul Kyzivat" 
Subject: Re: [Sip] SIPit 21: Question about offer answer
In-Reply-To: <4742ED6D.5030103@cisco.com>
MIME-Version: 1.0
References: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com>
	<4742359B.1060301@cisco.com>
	<200711200138.lAK1cmun008944@dragon.ariadne.com>
	
	<4742ED6D.5030103@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: sip@ietf.org, Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1125287509=="
Errors-To: sip-bounces@ietf.org

--===============1125287509==
Content-Type: multipart/alternative; 
	boundary="----=_Part_22283_24263160.1195618172427"

------=_Part_22283_24263160.1195618172427
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

My view on this is that if you don't want to send SDP but you have to when
sending a re-INVITE, then send UPDATE without the SDP. Can we update session
timer to say that?

Hisham


On 21/11/2007, Paul Kyzivat  wrote:
>
>
>
> Christer Holmberg wrote:
> > Hi,
> >
> > What if the offerer is not "prepared" to receive an updated answer (it
> > only included the "offer" because it had to)? How can it "reject" the
> > answer?
>
> It can't. At best it can make a counter offer after the fact, or
> terminate the call after the fact.
>
> But that clearly isn't a good policy. You should design your UA so that
> this isn't an issue. When you make an offer you must always be prepared
> for the answer be anything that is compatible with the offer.
>
> > I personally think that an unchanged o- line in the offer should not
> > allow the answer to change.
> >
> > One could of course change the o- line in the offer - even if the offer
> > itself hasn't changed - and that would then allow the answer to be
> > changed.
>
> Personally I think the o-line changing or not is just an extra
> complication that should never have been there as a factor. Whether the
> o-line changes or not isn't what matters. What matters is whether the
> rest of the SDP changes. At best the o-line is a hint about whether the
> rest changed or not, and simply introduces the potential error case
> where the SDP doesn't agree with what the o-line is hinting. (So what
> should you do if the o-line is unchanged but the SDP is changed?)
>
> But as things are written, you are expected to make the o-line the same
> if the rest of the SDP is the same. The o-line in the offer has
> *nothing* to do with what is in the answer.
>
>        Paul
>
> > Just some thinking...
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >> -----Original Message-----
> >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> >> Sent: 20. marraskuuta 2007 3:39
> >> To: sip@ietf.org
> >> Subject: Re: [Sip] SIPit 21: Question about offer answer
> >>
> >>    From: Paul Kyzivat 
> >>
> >>    A 3pcc controller doing a transfer may well send an
> >> offerless invite to
> >>    one UA and then send the offer it gets back to an entirely
> >> different UA
> >>    than had been in the session before. So of course the
> >> answer will be
> >>    entirely different.
> >>
> >> Hmmm, "my" music-on-hold proposal does that, too.
> >>
> >> Dale
> >>
> >>
> >> _______________________________________________
> >> 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
> >>
> >
> >
> > _______________________________________________
> > 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
> >
>
>
> _______________________________________________
> 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
>

------=_Part_22283_24263160.1195618172427
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


My view on this is that if you don't want to send SDP but you have to when sending a re-INVITE, then send UPDATE without the SDP. Can we update session timer to say that?


 


Hisham

 


On 21/11/2007, Paul Kyzivat <pkyzivat@cisco.com> wrote:



Christer Holmberg wrote:
> Hi,
>
> What if the offerer is not "prepared" to receive an updated answer (it

> only included the "offer" because it had to)? How can it "reject" the
> answer?

It can't. At best it can make a counter offer after the fact, or
terminate the call after the fact.


But that clearly isn't a good policy. You should design your UA so that
this isn't an issue. When you make an offer you must always be prepared
for the answer be anything that is compatible with the offer.


> I personally think that an unchanged o- line in the offer should not
> allow the answer to change.
>
> One could of course change the o- line in the offer - even if the offer
> itself hasn't changed - and that would then allow the answer to be

> changed.

Personally I think the o-line changing or not is just an extra
complication that should never have been there as a factor. Whether the
o-line changes or not isn't what matters. What matters is whether the

rest of the SDP changes. At best the o-line is a hint about whether the
rest changed or not, and simply introduces the potential error case
where the SDP doesn't agree with what the o-line is hinting. (So what

should you do if the o-line is unchanged but the SDP is changed?)

But as things are written, you are expected to make the o-line the same
if the rest of the SDP is the same. The o-line in the offer has
*nothing* to do with what is in the answer.


       Paul

> Just some thinking...
>
> Regards,
>
> Christer
>
>
>
>> -----Original Message-----
>> From: 
Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
>> Sent: 20. marraskuuta 2007 3:39
>> To: sip@ietf.org
>> Subject: Re: [Sip] SIPit 21: Question about offer answer

>>
>>    From: Paul Kyzivat <pkyzivat@cisco.com>
>>
>>    A 3pcc controller doing a transfer may well send an
>> offerless invite to

>>    one UA and then send the offer it gets back to an entirely
>> different UA
>>    than had been in the session before. So of course the
>> answer will be
>>    entirely different.

>>
>> Hmmm, "my" music-on-hold proposal does that, too.
>>
>> Dale
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________

> 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
>


_______________________________________________

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



------=_Part_22283_24263160.1195618172427--



--===============1125287509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1125287509==--





From sip-bounces@ietf.org Tue Nov 20 23:54:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuhbB-0007ua-RA; Tue, 20 Nov 2007 23:54:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuhb9-0007tg-G2
	for sip-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 23:54:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuhb9-0007tU-6H
	for sip@ietf.org; Tue, 20 Nov 2007 23:54:03 -0500
Received: from wa-out-1112.google.com ([209.85.146.182])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuhb6-0008Ga-DV
	for sip@ietf.org; Tue, 20 Nov 2007 23:54:03 -0500
Received: by wa-out-1112.google.com with SMTP id k40so3859000wah
	for ; Tue, 20 Nov 2007 20:53:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=x+GaK5p+0DndVZZeJtrxT8HPQeu9prUmJa0cCo1LFnA=;
	b=kmYHG9ET7AIy2mJwjAeL317mYcx3Q0+8Uu8B/AAkcemT+eyPRB0kE4dAGnpx6pwSHLCo2X1LS6tWkVtzxu6XZN9SC207lDMv5LHFQReHDu60DnhX3CmCoaqtco8V0sbcumQCnjAXWpyq4kqgy1XaNCm3y3il7VTklz4/Ejf0I2k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=gw6mEcdXu9MkzY2CxfMJ++S+2Ol+ucakJcbL5Mvl6LzRrX+mad00LCzkes4FMFuDeQoXVu4LLhSoEL48a5T6or+yyAaTZ1l8u42mzqAwA+5n5S4FzKWpulq9vGVoAFO1lLFRoMm1ULXmm8z22nTJXgsZiI5XzP2CA2AiF1L9Sr4=
Received: by 10.115.32.1 with SMTP id k1mr527359waj.1195620839592;
	Tue, 20 Nov 2007 20:53:59 -0800 (PST)
Received: by 10.64.84.19 with HTTP; Tue, 20 Nov 2007 20:53:58 -0800 (PST)
Message-ID: <66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>
Date: Wed, 21 Nov 2007 15:53:58 +1100
From: "Hisham Khartabil" 
To: "Robert Sparks" 
Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
In-Reply-To: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com>
MIME-Version: 1.0
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1715968899=="
Errors-To: sip-bounces@ietf.org

--===============1715968899==
Content-Type: multipart/alternative; 
	boundary="----=_Part_22391_11516042.1195620838651"

------=_Part_22391_11516042.1195620838651
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is a big change if we do adopt it. It will cause a lot of problem to
parsers that handle extenion headers today and is not backwards compatible.
Why isn't the extension header as is defined today not sufficient?

Hisham


On 20/11/2007, Robert Sparks  wrote:
>
> The BNF in 3261 says the following:
>
> extension-header  =  header-name HCOLON header-value
> header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)
>
> This is intended to be the catch-all field for all future extensions
> - older parsers working against this BNF shouldn't barf
> when we introduce a new header field.
>
> Now, we may have new fields in the future that look like:
>
> NewHeader = new-header-name HCOLON quoted-string
>
> And down inside quoted-string, we get:
>
>       quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
>       qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
>                         / UTF8-NONASCII
>       quoted-pair  =  "\" (%x00-09 / %x0B-0C
>                        / %x0E-7F)
>
> So, for instance, we could have inside a quoted string the 2 byte
> sequence \ NULL
>
> This does not parse against header-value above...
>
> Is this a problem? Some of the SIPit21 participants argued that it is.
>
> The projects I've been involved in don't parse unknown headers and
> the stacks will just hand up an unparsed bucket of bits (the only rules
> used are those necessary to identify the next header-field starting).
>
> Would it be worth the effort to make the BNF reflect that rather than
> continuing with the incongruity that we currently specify?
>
> RjS
>
>
> _______________________________________________
> 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
>

------=_Part_22391_11516042.1195620838651
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


This is a big change if we do adopt it. It will cause a lot of problem to parsers that handle extenion headers today and is not backwards compatible. Why isn't the extension header as is defined today not sufficient?



 


Hisham

 


On 20/11/2007, Robert Sparks <rjsparks@nostrum.com> wrote:

The BNF in 3261 says the following:

extension-header  =  header-name HCOLON header-value
header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)


This is intended to be the catch-all field for all future extensions
- older parsers working against this BNF shouldn't barf
when we introduce a new header field.

Now, we may have new fields in the future that look like:


NewHeader = new-header-name HCOLON quoted-string

And down inside quoted-string, we get:

      quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
      qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E

                        / UTF8-NONASCII
      quoted-pair  =  "\" (%x00-09 / %x0B-0C
                       / %x0E-7F)

So, for instance, we could have inside a quoted string the 2 byte
sequence \ NULL


This does not parse against header-value above...

Is this a problem? Some of the SIPit21 participants argued that it is.

The projects I've been involved in don't parse unknown headers and

the stacks will just hand up an unparsed bucket of bits (the only rules
used are those necessary to identify the next header-field starting).

Would it be worth the effort to make the BNF reflect that rather than

continuing with the incongruity that we currently specify?

RjS


_______________________________________________
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



------=_Part_22391_11516042.1195620838651--



--===============1715968899==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1715968899==--





From sip-bounces@ietf.org Wed Nov 21 00:29:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iui9h-0007s0-6N; Wed, 21 Nov 2007 00:29:45 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iui9e-0007ls-Vq
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 00:29:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iui9e-0007lk-MF
	for sip@ietf.org; Wed, 21 Nov 2007 00:29:42 -0500
Received: from py-out-1112.google.com ([64.233.166.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iui9c-0000l9-0e
	for sip@ietf.org; Wed, 21 Nov 2007 00:29:42 -0500
Received: by py-out-1112.google.com with SMTP id d32so13009724pye
	for ; Tue, 20 Nov 2007 21:29:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=d7AFAkPJCRgmmDhpCzz+BiFCimN0ujBe6yIGgHWVcr0=;
	b=s5aQL4WVxg2KTetv7jO2CIv+J7fsWC87DI6lNiF/PK6ljljAHBi8vpqkNI3FYqYNlXWqVGvNxPQwbTT/o6DNRO6lJKS0xe+pDTHrVxHKFESkTe3O5ljztnVKbaKOnlBBsyoMpbJSL/MyzTWewOJBpBduzephroJowVcMU9pqHGM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=WfRHPh6Uk1TLgRSjNk6bwPdB884+FWTCUjIfMz/8CwbKaHP+NZP7FAWIAfmvkJpJWzpVgsyaDpQuAKgpMoL+JH0SGd2TezCzkaJD2F6VR/erB4TVUmb5vIdk8is137wBamGiTIj9pQc2GczXxQDIMi74vCDSFwbKvwlnA0cb5jQ=
Received: by 10.65.74.9 with SMTP id b9mr16009453qbl.1195622979331;
	Tue, 20 Nov 2007 21:29:39 -0800 (PST)
Received: by 10.64.84.19 with HTTP; Tue, 20 Nov 2007 21:29:39 -0800 (PST)
Message-ID: <66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com>
Date: Wed, 21 Nov 2007 16:29:39 +1100
From: "Hisham Khartabil" 
To: "Robert Sparks" 
Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
In-Reply-To: <66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>
MIME-Version: 1.0
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com>
	<66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1389350888=="
Errors-To: sip-bounces@ietf.org

--===============1389350888==
Content-Type: multipart/alternative; 
	boundary="----=_Part_22499_29656504.1195622979329"

------=_Part_22499_29656504.1195622979329
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think I did misread Robert's original email. I thought header values
having quoted strings are currently not allowed and Robert wanted to change
RFC2822. Now I realise that you can have header field values with quoted
string. Therefore I support the correction that Robert is proposing.

Hisham


On 21/11/2007, Hisham Khartabil  wrote:
>
> This is a big change if we do adopt it. It will cause a lot of problem to
> parsers that handle extenion headers today and is not backwards compatible.
> Why isn't the extension header as is defined today not sufficient?
>
> Hisham
>
>
>  On 20/11/2007, Robert Sparks  wrote:
> >
> > The BNF in 3261 says the following:
> >
> > extension-header  =  header-name HCOLON header-value
> > header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)
> >
> > This is intended to be the catch-all field for all future extensions
> > - older parsers working against this BNF shouldn't barf
> > when we introduce a new header field.
> >
> > Now, we may have new fields in the future that look like:
> >
> > NewHeader = new-header-name HCOLON quoted-string
> >
> > And down inside quoted-string, we get:
> >
> >       quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
> >       qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
> >                         / UTF8-NONASCII
> >       quoted-pair  =  "\" (%x00-09 / %x0B-0C
> >                        / %x0E-7F)
> >
> > So, for instance, we could have inside a quoted string the 2 byte
> > sequence \ NULL
> >
> > This does not parse against header-value above...
> >
> > Is this a problem? Some of the SIPit21 participants argued that it is.
> >
> > The projects I've been involved in don't parse unknown headers and
> > the stacks will just hand up an unparsed bucket of bits (the only rules
> > used are those necessary to identify the next header-field starting).
> >
> > Would it be worth the effort to make the BNF reflect that rather than
> > continuing with the incongruity that we currently specify?
> >
> > RjS
> >
> >
> > _______________________________________________
> > 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
> >
>
>

------=_Part_22499_29656504.1195622979329
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


I think I did misread Robert's original email. I thought header values having quoted strings are currently not allowed and Robert wanted to change RFC2822. Now I realise that you can have header field values with quoted string. Therefore I support the correction that Robert is proposing.



 


Hisham 

 


On 21/11/2007, Hisham Khartabil <hisham.khartabil@gmail.com> wrote:



This is a big change if we do adopt it. It will cause a lot of problem to parsers that handle extenion headers today and is not backwards compatible. Why isn't the extension header as is defined today not sufficient? 



 


Hisham

 




On 20/11/2007, Robert Sparks <rjsparks@nostrum.com
> wrote: 

The BNF in 3261 says the following:

extension-header  =  header-name HCOLON header-value
header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS) 


This is intended to be the catch-all field for all future extensions
- older parsers working against this BNF shouldn't barf
when we introduce a new header field.

Now, we may have new fields in the future that look like: 


NewHeader = new-header-name HCOLON quoted-string

And down inside quoted-string, we get:

      quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
      qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E 

                        / UTF8-NONASCII
      quoted-pair  =  "\" (%x00-09 / %x0B-0C
                       / %x0E-7F)

So, for instance, we could have inside a quoted string the 2 byte
sequence \ NULL 


This does not parse against header-value above...

Is this a problem? Some of the SIPit21 participants argued that it is.

The projects I've been involved in don't parse unknown headers and

the stacks will just hand up an unparsed bucket of bits (the only rules
used are those necessary to identify the next header-field starting).

Would it be worth the effort to make the BNF reflect that rather than 

continuing with the incongruity that we currently specify?

RjS


_______________________________________________
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





------=_Part_22499_29656504.1195622979329--



--===============1389350888==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1389350888==--





From sip-bounces@ietf.org Wed Nov 21 02:08:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iujh4-00061i-IB; Wed, 21 Nov 2007 02:08:18 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iujh1-00061b-Mh
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 02:08:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iujh1-00061T-8u
	for sip@ietf.org; Wed, 21 Nov 2007 02:08:15 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iujgv-0002iZ-9q
	for sip@ietf.org; Wed, 21 Nov 2007 02:08:15 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	9AC5A20FE5; Wed, 21 Nov 2007 08:08:08 +0100 (CET)
X-AuditID: c1b4fb3e-afea1bb00000459d-d8-4743d9585ebc
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	7A21F206E7; Wed, 21 Nov 2007 08:08:08 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 08:08:08 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
Date: Wed, 21 Nov 2007 08:08:07 +0100
Message-ID: 
In-Reply-To: <66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: BNF future-proofing problem?
Thread-Index: Acgr/4//DVIj6RRdTiO11UE4RaClPAADYOiw
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>
	<66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com>
From: "Christer Holmberg" 
To: "Hisham Khartabil" ,
	"Robert Sparks" 
X-OriginalArrivalTime: 21 Nov 2007 07:08:08.0375 (UTC)
	FILETIME=[44FDF470:01C82C0D]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20
Hi,

I am still a little unclear what Robert is proposing, but is there
really a need to be able to use characters between x00 and x20 in SIP
messages? Characters between x21 and x7F, and between x80 and xBF, are
ok since they are covered by TEXT-UTF8char and UTF8-CONT.

Regards,

Christer


________________________________

	From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20
	Sent: 21. marraskuuta 2007 7:30
	To: Robert Sparks
	Cc: sip List
	Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
=09
=09
	I think I did misread Robert's original email. I thought header
values having quoted strings are currently not allowed and Robert wanted
to change RFC2822. Now I realise that you can have header field values
with quoted string. Therefore I support the correction that Robert is
proposing.=20
	=20
	Hisham=20
=09
	=20
	On 21/11/2007, Hisham Khartabil 
wrote:=20

		This is a big change if we do adopt it. It will cause a
lot of problem to parsers that handle extenion headers today and is not
backwards compatible. Why isn't the extension header as is defined today
not sufficient?=20
				=20
		Hisham
	=09
		=20
						On 20/11/2007, Robert
Sparks  wrote:=20

			The BNF in 3261 says the following:
		=09
			extension-header  =3D  header-name HCOLON
header-value
			header-value      =3D  *(TEXT-UTF8char / UTF8-CONT
/ LWS)=20
		=09
			This is intended to be the catch-all field for
all future extensions
			- older parsers working against this BNF
shouldn't barf
			when we introduce a new header field.
		=09
			Now, we may have new fields in the future that
look like:=20
		=09
			NewHeader =3D new-header-name HCOLON quoted-string
		=09
			And down inside quoted-string, we get:
		=09
			      quoted-string  =3D  SWS DQUOTE *(qdtext /
quoted-pair ) DQUOTE
			      qdtext         =3D  LWS / %x21 / %x23-5B /
%x5D-7E=20
			                        / UTF8-NONASCII
			      quoted-pair  =3D  "\" (%x00-09 / %x0B-0C
			                       / %x0E-7F)
		=09
			So, for instance, we could have inside a quoted
string the 2 byte
			sequence \ NULL=20
		=09
			This does not parse against header-value
above...
		=09
			Is this a problem? Some of the SIPit21
participants argued that it is.
		=09
			The projects I've been involved in don't parse
unknown headers and
			the stacks will just hand up an unparsed bucket
of bits (the only rules
			used are those necessary to identify the next
header-field starting).
		=09
			Would it be worth the effort to make the BNF
reflect that rather than=20
			continuing with the incongruity that we
currently specify?
		=09
			RjS
		=09
		=09
			_______________________________________________
			Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
=20
			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=20
		=09


	=09


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 02:20:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IujsR-00022W-P2; Wed, 21 Nov 2007 02:20:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IujsP-000220-Kh
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 02:20:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IujsP-00021s-4p
	for sip@ietf.org; Wed, 21 Nov 2007 02:20:01 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IujsM-0002we-PP
	for sip@ietf.org; Wed, 21 Nov 2007 02:20:01 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	308FF20F8D; Wed, 21 Nov 2007 08:19:58 +0100 (CET)
X-AuditID: c1b4fb3e-b1ea5bb00000459d-a5-4743dc1e3e13
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	03C3F207B6; Wed, 21 Nov 2007 08:19:58 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 08:19:57 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Wed, 21 Nov 2007 08:19:56 +0100
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: SDP in a 200OK when using 100rel
Thread-Index: Acgr8DHhD1WN6nTGT5Kx1i/l8MH5dQAHb1Bw
References: 
From: "Christer Holmberg" 
To: 
X-OriginalArrivalTime: 21 Nov 2007 07:19:57.0870 (UTC)
	FILETIME=[EBE24CE0:01C82C0E]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

I don't see any use case for this additional answer.

The text in chapter 13.2.1 says that the answer must be sent in "A" (it
doesn't say "only one") reliable response. The text also says that SDPs
in subsequent responses to the INVITE.

I DO agree life would be much easier if we from the beginning would have
said that an answer MUST only be sent ONCE - without "previews",
"re-sendings in additional responses" etc. But, no matter what the
intention of chapter 13.2.1 was, it does cover the case when additional
SDPs are received, so people just have to implement it correctly...

Regards,

Christer



________________________________

	From: prince.philip@aricent.com
[mailto:prince.philip@aricent.com]=20
	Sent: 21. marraskuuta 2007 5:40
	To: Christer Holmberg
	Cc: Jonathan Rosenberg; Paul Kyzivat; Sanjay Sinha (sanjsinh);
sip List
	Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
=09
=09
		Since in the UAC point of view the behaviour is defined
clearly, whats the issue?
	Does anybody see any use case for this additional answer, from
an UAS perspective?
	=20
	Prince.
=09


	-----"Christer Holmberg"  wrote:
-----
=09
=09

		To: "Jonathan Rosenberg" , "Paul
Kyzivat" 
		From: "Christer Holmberg"

		Date: 11/21/2007 12:33AM
		cc: "Sanjay Sinha \(sanjsinh\)" ,
sip List 
		Subject: RE: [Sip] SIPit21: SDP in a 200OK when using
100rel
	=09
		Hi,
	=09
		An implementation should keep offer/answer state and
simply discard the SDP in the 200 OK.
	=09
		I don't think that is complicated :)
	=09
		Regards,
	=09
		Christer
	=09
		________________________________
	=09
		From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
		Sent: Tue 20/11/2007 17:56
		To: Paul Kyzivat
		Cc: Sanjay Sinha (sanjsinh); sip List
		Subject: Re: [Sip] SIPit21: SDP in a 200OK when using
100rel
	=09
	=09
	=09
		The intention was that, when reliable provisionals are
used, the answer
		would NOT appear in the 200 OK to the original INVITE.
The paragraph in
		RFC3261 is talking specifically about the case of an
unreliable
		provisional response.
	=09
		The drawback of sending the answer in the reliable 18x
and then
		repeating it in the 200 OK, is what if they are not the
same. It gets
		really complicated if there are multiple O/A exchanges
in UPDATE/PRACK
		prior to the final 200 OK.
	=09
		-Jonathan R.
	=09
		Paul Kyzivat wrote:
		>
		>
		> Robert Sparks wrote:
		>> Yes, I did mean 200 INVITE.
		>>
		>> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh)
wrote:
		>>
		>>> It is not clear from the call flow if the 200 OK is
for PRACK or INVITE?
		>>>
		>>> I guess you meant 200 OK for Invite. If that is the
case, I think the
		>>> RFC is clear that the answer sdp is optional in it
and if it does have
		>>> an answer sdp, it MUST be idential to answer in 18x.
		>>>
		>>
		>> Really? Point me to where you find this please.
		>
		> Mostly in 3261 sec 13.2.1. It says:
		>
		>       o  If the initial offer is in an INVITE, the
answer MUST be in a
		>          reliable non-failure message from UAS back to
UAC which is
		>          correlated to that INVITE.  For this
specification, that is
		>          only the final 2xx response to that INVITE.
That same exact
		>          answer MAY also be placed in any provisional
responses sent
		>          prior to the answer.  The UAC MUST treat the
first session
		>          description it receives as the answer, and
MUST ignore any
		>          session descriptions in subsequent responses
to the initial
		>          INVITE.
		>
		> The first three sentences are the clearly normative
part. When combined
		> with RFC 3262 definition of reliable provisionals,
they say that the
		> reliable provisional contains the answer.
		>
		> The last sentence doesn't really say the UAS may
include sdp in
		> subsequent responses to the invite transaction, but
neither does it say
		> you can't. It does say the UAC should ignore them if
present, which
		> implies they can be present, but says nothing about
what value they must
		> have if they are present.
		>
		> AFAIK there is nothing that says the answer may be
repeated in the 200.
		> However it is seemingly done a lot, so one had better
beware.
		>
		>     Paul
		>
		>>> But I think the
		>>> offer-answer draft has clarified it further that it
should not have any
		>>> answer sdp. This is probably harsh in case of one
offer-answer exchange,
		>>> but makes sense if there are multiple early dialog
offer-answer
		>>> exchanges in say Prack/200 OK or using UPDATE.
		>
		>
		>
		>>> Sanjay
		>>>
		>>>> -----Original Message-----
		>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
		>>>> Sent: Monday, November 19, 2007 4:14 PM
		>>>> To: sip List
		>>>> Subject: [Sip] SIPit21: SDP in a 200OK when using
100rel
		>>>>
		>>>> There was a lot of discussion and disagreement at
SIPit21
		>>>> about whether the following 200 OK is allowed (or
should) have
		>>>> SDP in it:
		>>>>
		>>>> INVITE (offer)
		>>>> -------->
		>>>> 18x (with 100rel) (answer)
		>>>> <--------
		>>>> PRACK
		>>>> --------->
		>>>> 200 OK (can this carry SDP?)
		>>>> <---------
		>>>> ACK
		>>>> --------->
		>>>>
		>>>> I couldn't find anything definitive in RFC form.
Paul's
		>>>> offeranswer draft talks about this I think.
		>>>>
		>>>> If I understand things, the right answer here is
that it's not
		>>>> supposed to carry any SDP and that you should
ignore it if it shows up.
		>>>>
		>>>> The question is, other than waste, what can go
wrong if it is there?
		>>>> When we end up with clear text around the
requirement, will it
		>>>> say SDP SHOULD NOT, or MUST NOT appear?
		>>>>
		>>>> Or do I have this wrong?
		>>>>
		>>>> RjS
		>>>>
		>>>>
		>>>> _______________________________________________
		>>>> 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
		>>>>
		>>
		>>
		>>
		>> _______________________________________________
		>> 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
		>>
		>
		>
		> _______________________________________________
		> 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
		>
	=09
		--
		Jonathan D. Rosenberg, Ph.D.                   499
Thornall St.
		Cisco Fellow                                   Edison,
NJ 08837
		Cisco, Voice Technology Group
		jdrosen@cisco.com
		http://www.jdrosen.net 
http://www.jdrosen.net/>                          PHONE: (408) 902-3084
		http://www.cisco.com 
http://www.cisco.com/>=20
	=09
	=09
		_______________________________________________
		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
	=09
	=09
	=09
	=09
		_______________________________________________
		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
	=09


=09
	*****Aricent-Restricted *****=3D=20
		"DISCLAIMER: This message is proprietary to Aricent and
is intended solely for the use of=20
	the individual to whom it is addressed. It may contain
privileged or confidential information and should not be=20
	circulated or used for any purpose other than for what it is
intended. If you have received this message in error,=20
	please notify the originator immediately. If you are not the
intended recipient, you are notified that you are strictly
	prohibited from using, copying, altering, or disclosing the
contents of this message. Aricent accepts no responsibility for=20
	loss or damage arising from the use of the information
transmitted by this email including damage from virus."
=09
	=09



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 03:26:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IukuQ-0008F7-Og; Wed, 21 Nov 2007 03:26:10 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IukuN-0008Ey-J4
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 03:26:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IukuI-0008EY-2I
	for sip@ietf.org; Wed, 21 Nov 2007 03:26:02 -0500
Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IukuE-0004Z0-8V
	for sip@ietf.org; Wed, 21 Nov 2007 03:26:02 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
	lAL8PHt9009805; Wed, 21 Nov 2007 10:25:39 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 10:25:12 +0200
Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 10:25:12 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] Few comments to draft-ietf-sip-outbound-11
Date: Wed, 21 Nov 2007 10:25:10 +0200
Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F046D2838@esebe103.NOE.Nokia.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Few comments to draft-ietf-sip-outbound-11
thread-index: Acgqs0xxM/CIgATMQjSUOauakz7gUQBX23QA
References: 
From: 
To: , 
X-OriginalArrivalTime: 21 Nov 2007 08:25:12.0658 (UTC)
	FILETIME=[09478B20:01C82C18]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

First of all, in my opinion outbound-11 looks good.
It has improved a lot from the previous version and
properly addressed many comments given in August during
WGLC.

After reading the draft I found a few things for which
I would seek further clarification. Some of those were
already initially raised in WGLC and the other minor
issues are due to the new text appeared in version 11.

1. Why should the registrar store the time of updating
   the binding ?

Section 6. Registrar mechanisms tells the following:

   The registrar MUST store in the binding the Contact URI,
   all the Contact head field parameters, and any Path header field
   values and SHOULD also store the time at which the binding was last
   updated.=20

   If the registrar receives a re-registration for a specific
   combination of AOR, instance-id and reg-id values, the registrar MUST
   update any information that uniquely identifies the network flow over
   which the request arrived if that information has changed, and SHOULD
   update the time the binding was last updated.

To which purpose is this stored time used ? In my understanding
such a stored time is not needed for replacing older bindings and
I could not come up with any other reason either to store the time.

As the draft tells elsewhere "[when the] reg-id values [coming from
the UA within REGISTER request] will collide with the previously=20
used reg-id values [stored earlier along the binding] the registrar=20
can replace the older registrations". The time of any previous update
should not matter.


2. How to respond if UA requires Outbound but the proxy does=20
   not support it even if the registrar does ?

How should the registrar respond to a REGISTER request when:

- REGISTER contains Require: Outbound and reg-id in Contact

- Registrar itself supports Outbound

- Via header of REGISTER indicates that there is a proxy between
  the UA and registrar, but the proxy has not included either the
  Path header or 'ob' parameter to its URI within the Path ?


3. Completing the removal of TCP keepalive from the draft

As all the other references to TCP keepalive have now been removed=20
from the draft, then please remove also this one from section=20
Section 3.5. Keepalive Technique:

   transports such as TCP and SCTP, this specification describes a
   keepalive approach based on sending CRLFs, *and for TCP, a usage of
   TCP transport-layer keepalives*.=20


4. Ambiguous text in section 7

Section 7. Authoritative Proxy Mechanisms: Forwarding Requests tells:

   If the proxy doubles as a registrar and stored information about the
   flow that created the binding, then the proxy MUST send the request
   over the same 'logical flow' saved with the binding,

Sorry but I do not understand what is meant by: "If the proxy doubles=20
as a registrar and stored information about the flow that created the=20
binding"  Proxy 'doubling as a registrar' sounds odd (which might be due
to my poor skills of English ...) Could you please clarify this ?

Thanks,

Erkki Koivusalo


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 04:17:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iulhj-0007nv-4Z; Wed, 21 Nov 2007 04:17:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iulhg-0007dE-LB
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:17:04 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iulhg-0007Zo-6i
	for sip@ietf.org; Wed, 21 Nov 2007 04:17:04 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iulhf-00012S-MP
	for sip@ietf.org; Wed, 21 Nov 2007 04:17:03 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	A41D320FE2; Wed, 21 Nov 2007 10:17:02 +0100 (CET)
X-AuditID: c1b4fb3e-ae69ebb00000459d-2f-4743f78e37d3
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	8F5E1206E7; Wed, 21 Nov 2007 10:17:02 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 10:17:02 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 10:17:01 +0100
Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id AF4442461;
	Wed, 21 Nov 2007 11:17:01 +0200 (EET)
Message-ID: <4743F78D.4070705@ericsson.com>
Date: Wed, 21 Nov 2007 11:17:01 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: sip 
References: 
	<4743F62A.8040903@ericsson.com>
In-Reply-To: <4743F62A.8040903@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 09:17:01.0934 (UTC)
	FILETIME=[468D68E0:01C82C1F]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: Brett Tate 
Subject: [Sip] URI comparison rules - IPv6 addresses
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,

Brett brought this up in the SIP Implementors mailing list. The
following IPv6 addresses are supposed to be equivalent:

[::ffff:192.0.2.128] and [::ffff:c000:280]
[2001:db8::9:1] and [2001:db8::9:01]
[0:0:0:0:0:FFFF:129.144.52.38] and [::FFFF:129.144.52.38]

Now, let's say I need to compare sip:user1@[::ffff:192.0.2.128] and
sip:user1@[::ffff:c000:280]. Should we consider these URIs to be
equivalent or not?

My proposal is that we clarify that IPv6 address comparison happens at
the binary level, not at the textual level. We could log a bug against
RFC3261, and try and add such a clarification to the IPv6 transition
document (I will need to ask the ADs whether or not we can add this in
AUTH48).

Cheers,

Gonzalo


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 05:12:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IumZM-0002Mi-H2; Wed, 21 Nov 2007 05:12:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IumZK-0002Mc-NX
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 05:12:30 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IumZK-0002MU-89
	for sip@ietf.org; Wed, 21 Nov 2007 05:12:30 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IumZJ-0002eU-El
	for sip@ietf.org; Wed, 21 Nov 2007 05:12:29 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lALABvqV021665;
	Wed, 21 Nov 2007 04:12:23 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 04:12:03 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:12:00 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] URI comparison rules - IPv6 addresses
Date: Wed, 21 Nov 2007 11:11:59 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918001933BB9@DEEXC1U01.de.lucent.com>
In-Reply-To: <4743F78D.4070705@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] URI comparison rules - IPv6 addresses
Thread-Index: AcgsH1foTzcdIskQSH+wy86k0G0nYgABww3w
References: <4743F62A.8040903@ericsson.com>
	<4743F78D.4070705@ericsson.com>
From: "DRAGE, Keith \(Keith\)" 
To: "Gonzalo Camarillo" , "sip" 
X-OriginalArrivalTime: 21 Nov 2007 10:12:00.0340 (UTC)
	FILETIME=[F48E3940:01C82C26]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Whatever the merits of this, please do not suggest using a SIPPING =
document to change the SIP protocol. We are getting too many of these =
odd updates spread around in too many documents. If this really is a bug =
in RFC 3261, then use the essential corrections process we are working =
on to change this.

Regards

Keith

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20
> Sent: Wednesday, November 21, 2007 9:17 AM
> To: sip
> Cc: Brett Tate
> Subject: [Sip] URI comparison rules - IPv6 addresses
>=20
> Hi,
>=20
> Brett brought this up in the SIP Implementors mailing list.=20
> The following IPv6 addresses are supposed to be equivalent:
>=20
> [::ffff:192.0.2.128] and [::ffff:c000:280] [2001:db8::9:1]=20
> and [2001:db8::9:01] [0:0:0:0:0:FFFF:129.144.52.38] and=20
> [::FFFF:129.144.52.38]
>=20
> Now, let's say I need to compare=20
> sip:user1@[::ffff:192.0.2.128] and=20
> sip:user1@[::ffff:c000:280]. Should we consider these URIs to=20
> be equivalent or not?
>=20
> My proposal is that we clarify that IPv6 address comparison=20
> happens at the binary level, not at the textual level. We=20
> could log a bug against RFC3261, and try and add such a=20
> clarification to the IPv6 transition document (I will need to=20
> ask the ADs whether or not we can add this in AUTH48).
>=20
> Cheers,
>=20
> Gonzalo
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 05:54:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IunDP-0003AT-BQ; Wed, 21 Nov 2007 05:53:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IunDN-0003AN-O0
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 05:53:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IunDN-0003AE-7t
	for sip@ietf.org; Wed, 21 Nov 2007 05:53:53 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IunDM-0003nC-In
	for sip@ietf.org; Wed, 21 Nov 2007 05:53:53 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	F028D21077; Wed, 21 Nov 2007 11:53:51 +0100 (CET)
X-AuditID: c1b4fb3e-b1ea5bb00000459d-0c-47440e3ff191
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	DB38A200CE; Wed, 21 Nov 2007 11:53:51 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:53:51 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:53:50 +0100
Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id CA0882461;
	Wed, 21 Nov 2007 12:53:50 +0200 (EET)
Message-ID: <47440E3E.10206@ericsson.com>
Date: Wed, 21 Nov 2007 12:53:50 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "DRAGE, Keith \(Keith\)" 
Subject: Re: [Sip] URI comparison rules - IPv6 addresses
References: <4743F62A.8040903@ericsson.com>
	<4743F78D.4070705@ericsson.com>
	<5D1A7985295922448D5550C94DE2918001933BB9@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE2918001933BB9@DEEXC1U01.de.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 10:53:51.0494 (UTC)
	FILETIME=[CD51EA60:01C82C2C]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: sip , Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,

it is not really a bug. It is a clarification.

Cheers,

Gonzalo

DRAGE, Keith (Keith) wrote:
> Whatever the merits of this, please do not suggest using a SIPPING document to change the SIP protocol. We are getting too many of these odd updates spread around in too many documents. If this really is a bug in RFC 3261, then use the essential corrections process we are working on to change this.
> 
> Regards
> 
> Keith
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] 
>> Sent: Wednesday, November 21, 2007 9:17 AM
>> To: sip
>> Cc: Brett Tate
>> Subject: [Sip] URI comparison rules - IPv6 addresses
>>
>> Hi,
>>
>> Brett brought this up in the SIP Implementors mailing list. 
>> The following IPv6 addresses are supposed to be equivalent:
>>
>> [::ffff:192.0.2.128] and [::ffff:c000:280] [2001:db8::9:1] 
>> and [2001:db8::9:01] [0:0:0:0:0:FFFF:129.144.52.38] and 
>> [::FFFF:129.144.52.38]
>>
>> Now, let's say I need to compare 
>> sip:user1@[::ffff:192.0.2.128] and 
>> sip:user1@[::ffff:c000:280]. Should we consider these URIs to 
>> be equivalent or not?
>>
>> My proposal is that we clarify that IPv6 address comparison 
>> happens at the binary level, not at the textual level. We 
>> could log a bug against RFC3261, and try and add such a 
>> clarification to the IPv6 transition document (I will need to 
>> ask the ADs whether or not we can add this in AUTH48).
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> _______________________________________________
>> 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
>>



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 06:10:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IunSi-0003W3-Dg; Wed, 21 Nov 2007 06:09:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IunSg-0003Vs-Fd
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 06:09:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IunSg-0003Vf-20
	for sip@ietf.org; Wed, 21 Nov 2007 06:09:42 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IunSe-0004LL-Gf
	for sip@ietf.org; Wed, 21 Nov 2007 06:09:41 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	EF23A20B33; Wed, 21 Nov 2007 12:09:39 +0100 (CET)
X-AuditID: c1b4fb3c-aef95bb0000030cf-a1-474411f374b7
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	D3D4C20405; Wed, 21 Nov 2007 12:09:39 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 12:09:39 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Status of require headers in the re-INVITE request.
Date: Wed, 21 Nov 2007 12:09:38 +0100
Message-ID: 
In-Reply-To: <47423A7E.6020204@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Status of require headers in the re-INVITE request.
Thread-Index: AcgrFgR15L02LogYQIi1oWjW7rnJvABGEY5Q
References: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>	<473DDB80.8060507@cisco.com>	
	<4741FDDA.6000902@cisco.com> <47421D62.3040908@zonnet.nl>
	<47423A7E.6020204@cisco.com>
From: "Christer Holmberg" 
To: "Paul Kyzivat" ,
	"Jeroen van Bemmel" 
X-OriginalArrivalTime: 21 Nov 2007 11:09:39.0732 (UTC)
	FILETIME=[02838D40:01C82C2F]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,=20

>>RFC3261 is pretty clear on the intended scope:
>>=20
>>8.1.1.9 Supported and Require
>>=20
>>   If the UAC supports extensions to SIP that can be applied by the
>>   server *_to the response_*, the UAC SHOULD include a=20
>>   Supported header field in the request listing the option tags
(Section=20
>>   19.2) for those extensions.
>=20
>That seems to imply that you can change the Supported options from
request to request.=20

>But how do you reconcile that with the use of Supported in OPTIONS? For
the response to OPTIONS=20
>to mean anything at all it must imply that you will respond
affirmatively to a Require for the listed options at some=20
>time in the future. But when does that time end?

I think OPTIONS is a way to indicate what you are able to support - but
that doesn't mean you are going to accept it every time. You may not
support everything at once, but only certain combinations of features,
extensions, codecs etc.

>>Still, some drafts / RFC may have sneaked through that use a different

>>interpretation of scope. RFC3329 (sec-agree) came up with a "creative"
>>use, for example.
>=20
>I haven't done a survey, but I think there are probably a lot=20
>of creative interpretations of the scope.

Yes, and that is what causes interop problems :)

One alternative would be that when you define a new option-tag, you
should clearly specify what the "scope" of it is.

Regards,

Christer




> > Regards,
> > Jeroen
> >=20
> > Paul Kyzivat wrote:
> >>
> >>
> >> Christer Holmberg wrote:
> >>> Hi,
> >>> =20
> >>> I think this discussion touches on an issue, which I know=20
> has caused=20
> >>> some interop concerns:
> >>> =20
> >>> Is the Supported/Require header only transaction=20
> specific, or is it=20
> >>> dialog specific?
> >>> =20
> >>> If it is dialog specific, I would say that you don't need=20
> to include=20
> >>> anything in the re-INVITE, if it was already included in=20
> the INVITE.
> >>> But, then it would also mean that whatever you indicated in the=20
> >>> INVITE (e.g. 100rel) is also valid for the re-INVITE.
> >>
> >> For many usages it must have a scope longer than a single=20
> transaction.=20
> >> And dialog scope isn't always right either. (Some apply to=20
> non-dialog
> >> usages.) In practice, anything that seems to have dialog=20
> scope will=20
> >> be broken by 3pcc and so will at best have to be "from=20
> henceforth in=20
> >> the dialog until overridden". And overrides are themselves=20
> a problem=20
> >> because there is no Unrequired header.
> >>
> >> I haven't tried to do an exhaustive analysis of all the different=20
> >> options, but I have gut feeling that there is no single=20
> definition of=20
> >> scope that will work for all of them - that there will be examples=20
> >> that assume different scopes.
> >>
> >>     Paul
> >>
> >>> Regards,
> >>> =20
> >>> Christer
> >>>
> >>> ________________________________
> >>>
> >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>> Sent: Fri 16/11/2007 19:03
> >>> To: nataraju.basavaraju@wipro.com
> >>> Cc: sip@ietf.org
> >>> Subject: Re: [Sip] Status of require headers in the=20
> re-INVITE request.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> nataraju.basavaraju@wipro.com wrote:
> >>>> Paul,
> >>>>
> >>>> You are right, its not a mandatory that re-INVITE carry the same=20
> >>>> set of options which INVITE carried. It would vary from=20
> application=20
> >>>> to application.
> >>>
> >>> And the meaning when it changes may also vary from=20
> implementation to=20
> >>> implementation because it is not standardized.
> >>>
> >>>> To make the implementation simpler UAs might decide to send the=20
> >>>> same set of options negotiated during initial INVITE transaction.
> >>>
> >>> That would be a safe thing to do, but may not always be possible.
> >>>
> >>>> At least its
> >>>> not acceptable to add more options in re-INVITE, which were not=20
> >>>> negotiated during INTITE transaction.
> >>>
> >>> I would say that it might not be wise, or might be asking for=20
> >>> trouble, but its not banned by the specs. Whether it is=20
> acceptable=20
> >>> or not is something that will be judged by the recipient.
> >>>
> >>>> If so it might end up with a an
> >>>> issue with refresh (if remote guy does not support the=20
> new option).
> >>>
> >>> Yes you might. So if you do it you had better be prepared=20
> to get a=20
> >>> 420 error and recover.
> >>>
> >>> More difficult that adding options is taking them away, which is=20
> >>> what the original poster wanted to do. There is no=20
> Unrequire header,=20
> >>> and while there is an Unsupported header it may only be used in a=20
> >>> 420 response.
> >>>
> >>> Suppose Alice originally called Bob, specifying Supported:100rel,=20
> >>> and Bob answered with Require:100rel and used reliable=20
> provisionals.=20
> >>> Then Alice wants to send a reinvite but doesn't want to=20
> use 100rel=20
> >>> any longer. She can omit Supported:100rel from the reinvite, but=20
> >>> there is no guarantee that Bob won't remember it and again put=20
> >>> Require:100rel in the response and use reliable provisionals. (If=20
> >>> any provisionals are used at
> >>> all.) The best Alice can do is hope. If she gets a 1xx with=20
> >>> Require:100rel she has no real option except to send a PRACK.
> >>>
> >>> Note that Supported and Require are among the things that are=20
> >>> supposed to be included in an OPTIONS response. OPTIONS=20
> is typically=20
> >>> used outside a dialog. For the Supported and Require=20
> values in the=20
> >>> OPTIONS response to have any utility they must remain=20
> valid beyond=20
> >>> the transaction. One would expect that they are valid=20
> until further notice I suppose.
> >>>
> >>> Basically this is a mess.
> >>>
> >>>         Paul
> >>>
> >>>> As
> >>>> you said it has interoperability issue, because different people=20
> >>>> implement in different manner.
> >>>
> >>> Yes.
> >>>
> >>>> Regards,
> >>>> Nataraju A B
> >>>>
> >>>> -----Original Message-----
> >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>>> Sent: Friday, November 16, 2007 6:40 PM
> >>>> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility=20
> & Carrier
> >>>> Infrastructure)
> >>>> Cc: vineet.gupta@motorola.com; sip@ietf.org
> >>>> Subject: Re: [Sip] Status of require headers in the=20
> re-INVITE request.
> >>>>
> >>>> Nataraju,
> >>>>
> >>>> Why do you think this behavior is required?
> >>>>
> >>>> The scope of applicability of Supported, Require, etc.=20
> is not well=20
> >>>> defined. If you want to be certain, then you should=20
> repeat these in=20
> >>>> every request. But if you *don't* include them in every=20
> request it=20
> >>>> is still likely that some peers will remember a value you sent=20
> >>>> earlier and assume it still applies.
> >>>>
> >>>> This is a potential interoperability issue and should be=20
> fixed, but=20
> >>>> I think it will be difficult. To be useful these options=20
> generally=20
> >>>> need to have a scope longer than a single transaction,=20
> yet if you=20
> >>>> assume they should have longer scope then it becomes=20
> difficult to=20
> >>>> define when that scope ends.
> >>>>
> >>>> In your particular case, if you want to use PRACK for=20
> the initial=20
> >>>> INVITE but you don't want to use it for reINVITE, I=20
> guess you can=20
> >>>> try omitting the Require:100rel in the reINVITE and hope for the=20
> >>>> best. But don't get upset if somebody still sends you PRACKs.
> >>>>
> >>>>       Thanks,
> >>>>       Paul
> >>>>
> >>>> nataraju.basavaraju@wipro.com wrote:
> >>>>> Comments inline...
> >>>>>
> >>>>> *Regards,*
> >>>>> *Nataraju A B*
> >>>>>
> >>>>>=20
> ------------------------------------------------------------------
> >>>>> ----
> >>>>> --
> >>>>> *From:* Gupta Vineet-A18467 [mailto:vineet.gupta@motorola.com]
> >>>>> *Sent:* Friday, November 16, 2007 1:10 PM
> >>>>> *To:* sip@ietf.org
> >>>>> *Subject:* [Sip] Status of require headers in the=20
> re-INVITE request.
> >>>>>
> >>>>>     Hi,
> >>>>>         I have a doubt related to using Require:100rel in=20
> >>>>> re-INVITE
> >>>> requests.
> >>>>>         *If a Require header was used in the INVITE request=20
> >>>>> establishing
> >>>> the
> >>>>>     dialog, is it mandatory to include the same Require=20
> header in
> >>>>>     subsequent re-INVITE requests within the dialog?
> >>>>>     *[ABN] yes, its necessary that re-INVITE carry the=20
> same set of
> >>>>>     Require header values that of INVITE.
> >>>>>         To be specific, if INVITE request contained=20
> >>>>> Require:100rel, then
> >>>>>     inclusion of Require:100rel in re-INVITE would require the
> >>>>>     originator to handle Reliable provisional responses=20
> and respond
> >>>>>     accordingly. So, it would also imply that re-INVITE=20
> also takes
> >>>> same
> >>>>>     call establishment time (owing to multiple messages like 183
> >>>> session
> >>>>>     in Progress, PRACK, 180 ringing, PRACK etc.).
> >>>>>     [ABN] Yes, UA's should be ready to handle PRACK txn=20
> triggered by
> >>>>>     re-INVITE txn. Also sending 100rel in re-INVITE=20
> does not mean UAS
> >>>>>     has to generate 1xx. if UAS generates 1xx responses=20
> for re-INVITE,
> >>>>>     then yes, it lead to re-INV , 1xx(100rel), PRACK,=20
> 200-PRK, ...=20
> >>>>> it
> >>>> is
> >>>>>     not mandatory to send  1xx for re-INVITE, hence even if
> >>>>>     Require:100rel is in re-INVITE, re-INVITE txn could=20
> be completed
> >>>>>     with out PRACK transaction.
> >>>>>         I agree, that such delay in re-INVITE might be=20
> acceptable=20
> >>>>> given
> >>>> that
> >>>>>     re-INVITE requires the user-intervention, but it=20
> complicates makes
> >>>>>     the re-INVITE handling as complicated as the INVITE=20
> handling.
> >>>> Also,
> >>>>>     if the initial INVITE involved procedures such as=20
> QoS negotiation
> >>>>>     the re-INVITE state-machine complicates even further.
> >>>>>         [ABN] In most of the cases, re-INVITE is not=20
> expected to=20
> >>>>> undergo
> >>>>>     user-intervention. hence in most of the cases it=20
> would end up with
> >>>>>     re-INV, 200, ACK only...
> >>>>>         In general, re-INVITE is expected to perform subset of=20
> >>>>> what
> >>>> happened
> >>>>>     in INVITE transaction. it should not create any issues to=20
> >>>>> handle
> >>>> 1xx
> >>>>>     responses reliably.
> >>>>>         Hope this answers all your questions...
> >>>>>         Regards,
> >>>>>     Vineet.
> >>>>>         /"You're only given a little spark of madness.=20
> You mustn't=20
> >>>>> lose it."/
> >>>>>  =20
> >>>>>=20
> ------------------------------------------------------------------
> >>>>> ----
> >>>>> --
> >>>>>
> >>>>> _______________________________________________
> >>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>>>> This list is for NEW development of the core SIP Protocol Use=20
> >>>>> sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> >>>>> sipping@ietf.org for new developments on the application of sip
> >>>>
> >>>> The information contained in this electronic message and any=20
> >>>> attachments to this message are intended for the=20
> exclusive use of=20
> >>>> the addressee(s) and may contain proprietary, confidential or=20
> >>>> privileged information. If you are not the intended=20
> recipient, you=20
> >>>> should not disseminate, distribute or copy this e-mail. Please=20
> >>>> notify the sender immediately and destroy all copies of this=20
> >>>> message and any attachments.
> >>>>
> >>>> WARNING: Computer viruses can be transmitted via email. The=20
> >>>> recipient should check this email and any attachments for the=20
> >>>> presence of viruses. The company accepts no liability for any=20
> >>>> damage caused by any virus transmitted by this email.
> >>>>
> >>>> www.wipro.com
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the core SIP Protocol Use=20
> >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >>> sipping@ietf.org for new developments on the application of sip
> >>>
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use=20
> >> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >> sipping@ietf.org for new developments on the application of sip
> >>
> >=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 08:25:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IupZT-0005Db-3w; Wed, 21 Nov 2007 08:24:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IupZS-0005DW-4k
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 08:24:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IupZR-0005D1-Q3
	for sip@ietf.org; Wed, 21 Nov 2007 08:24:49 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IupZR-0000QH-Ba
	for sip@ietf.org; Wed, 21 Nov 2007 08:24:49 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	BCA55205A9; Wed, 21 Nov 2007 14:24:48 +0100 (CET)
X-AuditID: c1b4fb3e-b06a2bb00000459d-52-474431a04c0d
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	AF0902021E; Wed, 21 Nov 2007 14:24:48 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 14:24:48 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Wed, 21 Nov 2007 14:24:47 +0100
Message-ID: 
In-Reply-To: <4741FD6B.10507@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: Acgq8dfSeXVCa6emTvuo6GdJ3BVk/wBPWOGQ
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<20071111224707.68E5033C21@delta.rtfm.com><008701c824d4$096ca180$c4f0200a@cisco.com>
	<4741FD6B.10507@nostrum.com>
From: "Christer Holmberg" 
To: "Adam Roach" ,
	"Dan Wing" 
X-OriginalArrivalTime: 21 Nov 2007 13:24:48.0553 (UTC)
	FILETIME=[E3BF7190:01C82C41]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20
>>If 3GPP decides to use something other than DTLS-SRTP, we will have=20
>>two standards for SRTP keying -- the IETF standard and the non-IETF=20
>>standard.  I do not consider that desirable.
>>  =20
>=20
>Why should crypto be different than the underlying protocol?=20
>The bifurcation between "IETF SIP" and "3GPP SIP" already=20
>exists in the market.
>=20
>

I don't understand this "IETF SIP" versus "3GPP SIP" thing.

"3GPP SIP" is a SIP profile, including a number of SIP extensions, all
done in IETF. There is nothing which a non-3GPP entity can't use.

What is "IETF SIP"? What do I have to implement in order to be "IETF
SIP" compliant? RFC3261? RFC3261 plus each and every extension out
there?

Also, DTLS-SRTP is not the only mechanism defined in IETF for key
management. The 3GPP might come to a conclusion based on their
requirements that one of the other IETF mechanisms is better suited.
This would then also only be a profiling of IETF, and not diverge from
IETF. =20

Regards,

Christer


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 08:45:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuptd-0004O6-UB; Wed, 21 Nov 2007 08:45:41 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuptb-0004Nu-SU
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 08:45:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuptb-0004Nh-I7
	for sip@ietf.org; Wed, 21 Nov 2007 08:45:39 -0500
Received: from smtp.mitel.com ([216.191.234.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuptX-0005OQ-T8
	for sip@ietf.org; Wed, 21 Nov 2007 08:45:39 -0500
Received: from localhost (smtp.mitel.com [127.0.0.1])
	by smtp.mitel.com (Postfix) with ESMTP id ADD532C070;
	Wed, 21 Nov 2007 08:45:35 -0500 (EST)
X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com
Received: from smtp.mitel.com ([127.0.0.1])
	by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id TwKYrXVTwdoN; Wed, 21 Nov 2007 08:45:34 -0500 (EST)
Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58])
	by smtp.mitel.com (Postfix) with ESMTP id 9992F2C061;
	Wed, 21 Nov 2007 08:45:34 -0500 (EST)
In-Reply-To: <4743F78D.4070705@ericsson.com>
To: Gonzalo Camarillo 
Subject: Re: [Sip] URI comparison rules - IPv6 addresses
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: 
From: peter_blatherwick@mitel.com
Date: Wed, 21 Nov 2007 08:45:28 -0500
X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13,
	2003) at 11/21/2007 08:45:33 AM,
	Serialize complete at 11/21/2007 08:45:33 AM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Cc: sip , Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1926696935=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============1926696935==
Content-Type: multipart/alternative;
	boundary="=_alternative 004B924B8525739A_="

This is a multipart message in MIME format.
--=_alternative 004B924B8525739A_=
Content-Type: text/plain; charset="US-ASCII"

Hi, 
Yes, this seems like a very good clarification to make -- one of those 
"obvious" things that could easily get different interpretations or just 
lazy programming causing issues.  At minimum should be clarified for 
sipping-v6-transition.   If that could be done in RFC process, then it 
would obviously be better.  Likely a correction would also be warranted in 
base SIP; unsure.

And yes, those addresses are equivalent.  Saying it is done "at binary 
level" implies implementation, so I would not say that.  Some words like 
"expanded form" might be more appropriate.  But the comparison needs to 
account for all variations of notation on both IPv6 and IPv4 addresses 
(there are lots more than noted below of course). 

BTW, I notice this was not posted on SIPPING.  Even though most of us 
probably watch both, suggest it get put there also since it is the home of 
sipping-v6 ... perhaps aft this mini-debate settles. 

-- Peter






Gonzalo Camarillo 
21.11.07 04:17
 
        To:     sip 
        cc:     Brett Tate 
        Subject:        [Sip] URI comparison rules - IPv6 addresses


Hi,

Brett brought this up in the SIP Implementors mailing list. The
following IPv6 addresses are supposed to be equivalent:

[::ffff:192.0.2.128] and [::ffff:c000:280]
[2001:db8::9:1] and [2001:db8::9:01]
[0:0:0:0:0:FFFF:129.144.52.38] and [::FFFF:129.144.52.38]

Now, let's say I need to compare sip:user1@[::ffff:192.0.2.128] and
sip:user1@[::ffff:c000:280]. Should we consider these URIs to be
equivalent or not?

My proposal is that we clarify that IPv6 address comparison happens at
the binary level, not at the textual level. We could log a bug against
RFC3261, and try and add such a clarification to the IPv6 transition
document (I will need to ask the ADs whether or not we can add this in
AUTH48).

Cheers,

Gonzalo


_______________________________________________
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


--=_alternative 004B924B8525739A_=
Content-Type: text/html; charset="US-ASCII"



Hi, 

Yes, this seems like a very good clarification
to make -- one of those "obvious" things that could easily get
different interpretations or just lazy programming causing issues.  At
minimum should be clarified for sipping-v6-transition.   If that could
be done in RFC process, then it would obviously be better.  Likely
a correction would also be warranted in base SIP; unsure.



And yes, those addresses are equivalent.
 Saying it is done "at binary level" implies implementation,
so I would not say that.  Some words like "expanded form"
might be more appropriate.  But the comparison needs to account for
all variations of notation on both IPv6 and IPv4 addresses (there are lots
more than noted below of course).     



BTW, I notice this was not posted on
SIPPING.  Even though most of us probably watch both, suggest it get
put there also since it is the home of sipping-v6 ... perhaps aft this
mini-debate settles.  



-- Peter















Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

21.11.07 04:17

        

        To:
       sip <sip@ietf.org>

        cc:
       Brett Tate <brett@broadsoft.com>

        Subject:
       [Sip] URI comparison rules - IPv6 addresses






Hi,



Brett brought this up in the SIP Implementors mailing list. The

following IPv6 addresses are supposed to be equivalent:



[::ffff:192.0.2.128] and [::ffff:c000:280]

[2001:db8::9:1] and [2001:db8::9:01]

[0:0:0:0:0:FFFF:129.144.52.38] and [::FFFF:129.144.52.38]



Now, let's say I need to compare sip:user1@[::ffff:192.0.2.128] and

sip:user1@[::ffff:c000:280]. Should we consider these URIs to be

equivalent or not?



My proposal is that we clarify that IPv6 address comparison happens at

the binary level, not at the textual level. We could log a bug against

RFC3261, and try and add such a clarification to the IPv6 transition

document (I will need to ask the ADs whether or not we can add this in

AUTH48).



Cheers,



Gonzalo





_______________________________________________

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




--=_alternative 004B924B8525739A_=--



--===============1926696935==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1926696935==--





From sip-bounces@ietf.org Wed Nov 21 09:02:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuqA0-000872-Nc; Wed, 21 Nov 2007 09:02:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuq9y-0007xy-Gt
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:02:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuq9y-0007un-5k
	for sip@ietf.org; Wed, 21 Nov 2007 09:02:34 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuq9x-0001mM-OI
	for sip@ietf.org; Wed, 21 Nov 2007 09:02:33 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	1F4AA20BDF; Wed, 21 Nov 2007 15:02:33 +0100 (CET)
X-AuditID: c1b4fb3c-aff97bb0000030cf-eb-47443a79c65e
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	0639B20B07; Wed, 21 Nov 2007 15:02:33 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 15:02:32 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 21 Nov 2007 15:02:31 +0100
Message-ID: 
In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F046D2838@esebe103.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comment on draft-ietf-sip-outbound-11
Thread-Index: Acgqs0xxM/CIgATMQjSUOauakz7gUQBX23QAAA0JkmA=
References: 
	<8B1D53AEF7B03449A6D3771B3B7F850F046D2838@esebe103.NOE.Nokia.com>
From: "Christer Holmberg" 
To: ,
	,
	
X-OriginalArrivalTime: 21 Nov 2007 14:02:32.0910 (UTC)
	FILETIME=[2968E6E0:01C82C47]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: 
Subject: [Sip] Comment on draft-ietf-sip-outbound-11
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20
Hi,

One comment on the draft.

I think we should describe the usage of "ob" a little better. The usage
is a little unclear, I think.

Regards,

Christer


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 09:02:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuqA9-0000Kt-Py; Wed, 21 Nov 2007 09:02:45 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuqA8-0000IO-0h
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:02:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqA7-0000EY-HV
	for sip@ietf.org; Wed, 21 Nov 2007 09:02:43 -0500
Received: from syd-iport-1.cisco.com ([64.104.193.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqA2-0005x0-Kf
	for sip@ietf.org; Wed, 21 Nov 2007 09:02:43 -0500
Received: from syd-dkim-1.cisco.com ([64.104.193.116])
	by syd-iport-1.cisco.com with ESMTP; 22 Nov 2007 01:02:34 +1100
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALE2V2l004981; 
	Thu, 22 Nov 2007 01:02:32 +1100
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALE2809021406; 
	Wed, 21 Nov 2007 14:02:28 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 09:02:18 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] SIPit 21: Question about offer answer
Date: Wed, 21 Nov 2007 09:02:16 -0500
Message-ID: <8983EC086A9D954BA74D9763E853CF3E0437F38B@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <66cd252f0711202009x11f42f35s445c25c4f12508a6@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21: Question about offer answer
Thread-Index: Acgr9HjEnHJ79c2ITCuClxm4XItUBAAUhydg
From: "Sanjay Sinha (sanjsinh)" 
To: "Hisham Khartabil" ,
	"Paul Kyzivat (pkyzivat)" 
X-OriginalArrivalTime: 21 Nov 2007 14:02:18.0743 (UTC)
	FILETIME=[20F73070:01C82C47]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11589; t=1195653752;
	x=1196517752; c=relaxed/simple; s=syddkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20
	|Subject:=20RE=3A=20[Sip]=20SIPit=2021=3A=20Question=20about=20offer=20an
	swer |Sender:=20;
	bh=dVswZChr56BgKHCYkJuAM0jKxqgCaT8fh2h9Y2xoK0A=;
	b=SJLJqo88KGWLTl4Rbz7szMnzY4Sm9ltM4IkFJT2bBPuQ9xSVpXyfRZMMuXIa+VIeg1cVslXn
	Qv7JpEBSUdfr5Y6sDqNwv8LXi4ZLhrc+Gn0Pxn9wHEOT8RebEoKtfCU07r03CtuI6A48CECCCb
	xKnm33dgoYgX5prE1o0YWXgM8=;
Authentication-Results: syd-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/syddkim1002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad
Cc: sip@ietf.org, Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0813624248=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0813624248==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82C47.20CB7DAA"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82C47.20CB7DAA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

There is backward compatibility issues with it. There are some old UAs
which do not support UPDATE. But if they do,  and it can be figured out
from Allow header, then I agree that UPDATE is better than re-Invite for
session refresh.
=20
Sanjay


________________________________

	From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20
	Sent: Tuesday, November 20, 2007 11:10 PM
	To: Paul Kyzivat (pkyzivat)
	Cc: sip@ietf.org; Christer Holmberg
	Subject: Re: [Sip] SIPit 21: Question about offer answer
=09
=09
	My view on this is that if you don't want to send SDP but you
have to when sending a re-INVITE, then send UPDATE without the SDP. Can
we update session timer to say that?
	=20
	Hisham
=09
	=20
	On 21/11/2007, Paul Kyzivat  wrote:=20



		Christer Holmberg wrote:
		> Hi,
		>
		> What if the offerer is not "prepared" to receive an
updated answer (it=20
		> only included the "offer" because it had to)? How can
it "reject" the
		> answer?
	=09
		It can't. At best it can make a counter offer after the
fact, or
		terminate the call after the fact.=20
	=09
		But that clearly isn't a good policy. You should design
your UA so that
		this isn't an issue. When you make an offer you must
always be prepared
		for the answer be anything that is compatible with the
offer.=20
	=09
		> I personally think that an unchanged o- line in the
offer should not
		> allow the answer to change.
		>
		> One could of course change the o- line in the offer -
even if the offer
		> itself hasn't changed - and that would then allow the
answer to be=20
		> changed.
	=09
		Personally I think the o-line changing or not is just an
extra
		complication that should never have been there as a
factor. Whether the
		o-line changes or not isn't what matters. What matters
is whether the=20
		rest of the SDP changes. At best the o-line is a hint
about whether the
		rest changed or not, and simply introduces the potential
error case
		where the SDP doesn't agree with what the o-line is
hinting. (So what=20
		should you do if the o-line is unchanged but the SDP is
changed?)
	=09
		But as things are written, you are expected to make the
o-line the same
		if the rest of the SDP is the same. The o-line in the
offer has
		*nothing* to do with what is in the answer.=20
	=09
		       Paul
	=09
		> Just some thinking...
		>
		> Regards,
		>
		> Christer
		>
		>
		>
		>> -----Original Message-----
		>> From: Dale.Worley@comcast.net
[mailto:Dale.Worley@comcast.net]
		>> Sent: 20. marraskuuta 2007 3:39
		>> To: sip@ietf.org
		>> Subject: Re: [Sip] SIPit 21: Question about offer
answer=20
		>>
		>>    From: Paul Kyzivat 
		>>
		>>    A 3pcc controller doing a transfer may well send
an
		>> offerless invite to=20
		>>    one UA and then send the offer it gets back to an
entirely
		>> different UA
		>>    than had been in the session before. So of course
the
		>> answer will be
		>>    entirely different.=20
		>>
		>> Hmmm, "my" music-on-hold proposal does that, too.
		>>
		>> Dale
		>>
		>>
		>> _______________________________________________
		>> 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
		>>
		>
		>
		> _______________________________________________=20
		> 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
		>
	=09
	=09
		_______________________________________________=20
		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
	=09



------_=_NextPart_001_01C82C47.20CB7DAA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







There is backward compatibility issues with it. There are some =
old UAs=20
which do not support UPDATE. But if they do,  and it can be figured =
out=20
from Allow header, then I agree that UPDATE is better than =
re-Invite for=20
session refresh.


 


Sanjay



  

  

  From: Hisham Khartabil=20
  [mailto:hisham.khartabil@gmail.com] 
Sent: Tuesday, November =
20,=20
  2007 11:10 PM
To: Paul Kyzivat (pkyzivat)
Cc:=20
  sip@ietf.org; Christer Holmberg
Subject: Re: [Sip] SIPit 21: =

  Question about offer answer


  

  
My view on this is that if you don't want to send SDP but you =
have to=20
  when sending a re-INVITE, then send UPDATE without the SDP. Can we =
update=20
  session timer to say that?

  
 

  
Hisham

 

  
On 21/11/2007, Paul=20
  Kyzivat <pkyzivat@cisco.com>=20
  wrote:=20
  


Christer=20
    Holmberg wrote:
> Hi,
>
> What if the offerer is =
not=20
    "prepared" to receive an updated answer (it 
> only included =
the=20
    "offer" because it had to)? How can it "reject" the
>=20
    answer?

It can't. At best it can make a counter offer after =
the fact,=20
    or
terminate the call after the fact. 

But that clearly =
isn't a=20
    good policy. You should design your UA so that
this isn't an =
issue. When=20
    you make an offer you must always be prepared
for the answer be =
anything=20
    that is compatible with the offer. 

> I personally think =
that an=20
    unchanged o- line in the offer should not
> allow the answer =
to=20
    change.
>
> One could of course change the o- line in =
the offer=20
    - even if the offer
> itself hasn't changed - and that would =
then=20
    allow the answer to be 
> changed.

Personally I think =
the=20
    o-line changing or not is just an extra
complication that should =
never=20
    have been there as a factor. Whether the
o-line changes or not =
isn't what=20
    matters. What matters is whether the 
rest of the SDP changes. At =
best=20
    the o-line is a hint about whether the
rest changed or not, and =
simply=20
    introduces the potential error case
where the SDP doesn't agree =
with what=20
    the o-line is hinting. (So what 
should you do if the o-line is =
unchanged=20
    but the SDP is changed?)

But as things are written, you are =
expected=20
    to make the o-line the same
if the rest of the SDP is the same. =
The=20
    o-line in the offer has
*nothing* to do with what is in the =
answer.=20
    

       Paul

> Just =
some=20
    thinking...
>
> Regards,
>
>=20
    Christer
>
>
>
>> -----Original=20
    Message-----
>> From: Dale.Worley@comcast.net =
[mailto:Dale.Worley@comcast.net]
&=
gt;>=20
    Sent: 20. marraskuuta 2007 3:39
>> To: sip@ietf.org
>> Subject: =
Re: [Sip]=20
    SIPit 21: Question about offer answer=20
    
>>
>>    From: Paul Kyzivat =
<pkyzivat@cisco.com>
>>=

>>    A=20
    3pcc controller doing a transfer may well send an
>> =
offerless=20
    invite to 
>>    one UA and then send =
the offer=20
    it gets back to an entirely
>> different=20
    UA
>>    than had been in the session =
before.=20
    So of course the
>> answer will=20
    be
>>    entirely different.=20
    
>>
>> Hmmm, "my" music-on-hold proposal does =
that,=20
    too.
>>
>> =
Dale
>>
>>
>>=20
    _______________________________________________
>> Sip =
mailing=20
    list   https://www1.ietf.org=
/mailman/listinfo/sip
>>=20
    This list is for NEW development of the core SIP Protocol =
Use
>> sip-implementors@cs.colu=
mbia.edu=20
    for questions on current sip
>> Use sipping@ietf.org for new =
developments on=20
    the application of sip
>>
>
>
>=20
    _______________________________________________ 
> Sip mailing =

    list  https://www1.ietf.org=
/mailman/listinfo/sip
>=20
    This list is for NEW development of the core SIP Protocol
> =
Use sip-implementors@cs.colu=
mbia.edu=20
    for questions on current sip
> Use sipping@ietf.org for new =
developments on=20
    the application of=20
    =
sip
>


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



------_=_NextPart_001_01C82C47.20CB7DAA--



--===============0813624248==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0813624248==--





From sip-bounces@ietf.org Wed Nov 21 09:14:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuqL5-0003WP-VZ; Wed, 21 Nov 2007 09:14:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuqL4-0003Ss-9O
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:14:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqL3-0003Rw-Vc
	for sip@ietf.org; Wed, 21 Nov 2007 09:14:01 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqKy-0006Hf-99
	for sip@ietf.org; Wed, 21 Nov 2007 09:14:01 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	0D8B421105; Wed, 21 Nov 2007 15:13:14 +0100 (CET)
X-AuditID: c1b4fb3e-b0ea3bb00000459d-e4-47443cf9839e
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	B433021100; Wed, 21 Nov 2007 15:13:13 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 15:13:13 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] SIPit 21: Question about offer answer
Date: Wed, 21 Nov 2007 15:13:12 +0100
Message-ID: 
In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E0437F38B@xmb-rtp-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21: Question about offer answer
Thread-Index: Acgr9HjEnHJ79c2ITCuClxm4XItUBAAUhydgAAA6blA=
References: <66cd252f0711202009x11f42f35s445c25c4f12508a6@mail.gmail.com>
	<8983EC086A9D954BA74D9763E853CF3E0437F38B@xmb-rtp-215.amer.cisco.com>
From: "Christer Holmberg" 
To: "Sanjay Sinha (sanjsinh)" ,
	"Hisham Khartabil" ,
	"Paul Kyzivat (pkyzivat)" 
X-OriginalArrivalTime: 21 Nov 2007 14:13:13.0421 (UTC)
	FILETIME=[A72F1FD0:01C82C48]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0761699024=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0761699024==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82C48.A6F08B27"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82C48.A6F08B27
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
RFC4028 already allows the usage of UPDATE, so I guess the issue is more
to make sure one doesn't send an unchanged offer unless he is ready to
receive a modified answer.
=20
If I remember correctly the initial idea the session-timer was, that is
some entity in the path had lost state of the call, the re-INVITE would
re-initiate the call.
=20
However, that is not the case anymore. As far as I understand, the
session-timer is only used to indicate that the session is still active,
and if no re-INVITE/UPDATE is received the session can be released.
=20
You could do this even with...... INFO ;)
=20
Regards,
=20
Christer


________________________________

	From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20
	Sent: 21. marraskuuta 2007 16:02
	To: Hisham Khartabil; Paul Kyzivat (pkyzivat)
	Cc: sip@ietf.org; Christer Holmberg
	Subject: RE: [Sip] SIPit 21: Question about offer answer
=09
=09
	There is backward compatibility issues with it. There are some
old UAs which do not support UPDATE. But if they do,  and it can be
figured out from Allow header, then I agree that UPDATE is better than
re-Invite for session refresh.
	=20
	Sanjay


________________________________

		From: Hisham Khartabil
[mailto:hisham.khartabil@gmail.com]=20
		Sent: Tuesday, November 20, 2007 11:10 PM
		To: Paul Kyzivat (pkyzivat)
		Cc: sip@ietf.org; Christer Holmberg
		Subject: Re: [Sip] SIPit 21: Question about offer answer
	=09
	=09
		My view on this is that if you don't want to send SDP
but you have to when sending a re-INVITE, then send UPDATE without the
SDP. Can we update session timer to say that?
		=20
		Hisham
	=09
		=20
		On 21/11/2007, Paul Kyzivat  wrote:=20



			Christer Holmberg wrote:
			> Hi,
			>
			> What if the offerer is not "prepared" to
receive an updated answer (it=20
			> only included the "offer" because it had to)?
How can it "reject" the
			> answer?
		=09
			It can't. At best it can make a counter offer
after the fact, or
			terminate the call after the fact.=20
		=09
			But that clearly isn't a good policy. You should
design your UA so that
			this isn't an issue. When you make an offer you
must always be prepared
			for the answer be anything that is compatible
with the offer.=20
		=09
			> I personally think that an unchanged o- line
in the offer should not
			> allow the answer to change.
			>
			> One could of course change the o- line in the
offer - even if the offer
			> itself hasn't changed - and that would then
allow the answer to be=20
			> changed.
		=09
			Personally I think the o-line changing or not is
just an extra
			complication that should never have been there
as a factor. Whether the
			o-line changes or not isn't what matters. What
matters is whether the=20
			rest of the SDP changes. At best the o-line is a
hint about whether the
			rest changed or not, and simply introduces the
potential error case
			where the SDP doesn't agree with what the o-line
is hinting. (So what=20
			should you do if the o-line is unchanged but the
SDP is changed?)
		=09
			But as things are written, you are expected to
make the o-line the same
			if the rest of the SDP is the same. The o-line
in the offer has
			*nothing* to do with what is in the answer.=20
		=09
			       Paul
		=09
			> Just some thinking...
			>
			> Regards,
			>
			> Christer
			>
			>
			>
			>> -----Original Message-----
			>> From: Dale.Worley@comcast.net
[mailto:Dale.Worley@comcast.net]
			>> Sent: 20. marraskuuta 2007 3:39
			>> To: sip@ietf.org
			>> Subject: Re: [Sip] SIPit 21: Question about
offer answer=20
			>>
			>>    From: Paul Kyzivat 
			>>
			>>    A 3pcc controller doing a transfer may
well send an
			>> offerless invite to=20
			>>    one UA and then send the offer it gets
back to an entirely
			>> different UA
			>>    than had been in the session before. So of
course the
			>> answer will be
			>>    entirely different.=20
			>>
			>> Hmmm, "my" music-on-hold proposal does that,
too.
			>>
			>> Dale
			>>
			>>
			>>
_______________________________________________
			>> 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
			>>
			>
			>
			>
_______________________________________________=20
			> 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
			>
		=09
		=09
			_______________________________________________=20
			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
		=09



------_=_NextPart_001_01C82C48.A6F08B27
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi,


 


RFC4028 already allows the usage of UPDATE, so I guess the =
issue is more=20
to make sure one doesn't send an unchanged offer unless he is ready to =
receive a=20
modified answer.


 


If I=20
remember correctly the initial idea the session-timer was, =
that is=20
some entity in the path had lost state of the call, the re-INVITE would=20
re-initiate the call.


 


However, that is not the case anymore. As far as I understand, =
the=20
session-timer is only used to indicate that the session is still active, =
and if=20
no re-INVITE/UPDATE is received the session can be =
released.


 


You=20
could do this even with...... INFO ;)


 


Regards,


 


Christer




  

  

  From: Sanjay Sinha (sanjsinh)=20
  [mailto:sanjsinh@cisco.com] 
Sent: 21. marraskuuta 2007=20
  16:02
To: Hisham Khartabil; Paul Kyzivat =
(pkyzivat)
Cc:=20
  sip@ietf.org; Christer Holmberg
Subject: RE: [Sip] SIPit 21: =

  Question about offer answer


  

  
There is backward compatibility issues with it. There are =
some old UAs=20
  which do not support UPDATE. But if they do,  and it can be =
figured out=20
  from Allow header, then I agree that UPDATE is better than =
re-Invite for=20
  session refresh.

  
 

  
Sanjay


  
    

    

    From: Hisham Khartabil=20
    [mailto:hisham.khartabil@gmail.com] 
Sent: Tuesday, =
November 20,=20
    2007 11:10 PM
To: Paul Kyzivat (pkyzivat)
Cc:=20
    sip@ietf.org; Christer Holmberg
Subject: Re: [Sip] SIPit =
21:=20
    Question about offer answer


    

    
My view on this is that if you don't want to send SDP but you =
have to=20
    when sending a re-INVITE, then send UPDATE without the SDP. Can we =
update=20
    session timer to say that?

    
 

    
Hisham

 

    
On 21/11/2007, Paul=20
    Kyzivat <pkyzivat@cisco.com> =
wrote:=20
    


Christer=20
      Holmberg wrote:
> Hi,
>
> What if the offerer is =
not=20
      "prepared" to receive an updated answer (it 
> only included =
the=20
      "offer" because it had to)? How can it "reject" the
>=20
      answer?

It can't. At best it can make a counter offer after =
the=20
      fact, or
terminate the call after the fact. 

But that =
clearly=20
      isn't a good policy. You should design your UA so that
this =
isn't an=20
      issue. When you make an offer you must always be prepared
for =
the=20
      answer be anything that is compatible with the offer. 

> =
I=20
      personally think that an unchanged o- line in the offer should =
not
>=20
      allow the answer to change.
>
> One could of course =
change the=20
      o- line in the offer - even if the offer
> itself hasn't =
changed -=20
      and that would then allow the answer to be 
>=20
      changed.

Personally I think the o-line changing or not is =
just an=20
      extra
complication that should never have been there as a =
factor.=20
      Whether the
o-line changes or not isn't what matters. What =
matters is=20
      whether the 
rest of the SDP changes. At best the o-line is a =
hint=20
      about whether the
rest changed or not, and simply introduces =
the=20
      potential error case
where the SDP doesn't agree with what the =
o-line=20
      is hinting. (So what 
should you do if the o-line is unchanged =
but the=20
      SDP is changed?)

But as things are written, you are =
expected to=20
      make the o-line the same
if the rest of the SDP is the same. =
The o-line=20
      in the offer has
*nothing* to do with what is in the answer.=20
      

       Paul

> Just =
some=20
      thinking...
>
> Regards,
>
>=20
      Christer
>
>
>
>> -----Original=20
      Message-----
>> From: Dale.Worley@comcast.net=20
      [mailto:Dale.Worley@comcast.net]
&=
gt;>=20
      Sent: 20. marraskuuta 2007 3:39
>> To: sip@ietf.org
>> Subject: =
Re: [Sip]=20
      SIPit 21: Question about offer answer=20
      
>>
>>    From: Paul Kyzivat =
<pkyzivat@cisco.com>
>>=

>>    A=20
      3pcc controller doing a transfer may well send an
>> =
offerless=20
      invite to 
>>    one UA and then send =
the=20
      offer it gets back to an entirely
>> different=20
      UA
>>    than had been in the session =
before.=20
      So of course the
>> answer will=20
      be
>>    entirely different.=20
      
>>
>> Hmmm, "my" music-on-hold proposal does =
that,=20
      too.
>>
>> =
Dale
>>
>>
>>=20
      _______________________________________________
>> Sip =
mailing=20
      list   https://www1.ietf.org=
/mailman/listinfo/sip
>>=20
      This list is for NEW development of the core SIP Protocol =
Use
>>=20
      sip-implementors@cs.colu=
mbia.edu=20
      for questions on current sip
>> Use sipping@ietf.org for new =
developments=20
      on the application of sip
>>
>
>
>=20
      _______________________________________________ 
> Sip =
mailing=20
      list  https://www1.ietf.org=
/mailman/listinfo/sip
>=20
      This list is for NEW development of the core SIP Protocol
> =
Use sip-implementors@cs.colu=
mbia.edu=20
      for questions on current sip
> Use sipping@ietf.org for new =
developments=20
      on the application of=20
      =
sip
>


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



------_=_NextPart_001_01C82C48.A6F08B27--



--===============0761699024==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0761699024==--





From sip-bounces@ietf.org Wed Nov 21 09:18:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuqPR-0000zw-Re; Wed, 21 Nov 2007 09:18:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuqPP-0000zm-MX
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:18:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqPP-0000zd-Bu
	for sip@ietf.org; Wed, 21 Nov 2007 09:18:31 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqPO-0002EB-Vh
	for sip@ietf.org; Wed, 21 Nov 2007 09:18:31 -0500
Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net
	[70.242.127.246]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lALEIRfw004386
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Nov 2007 08:18:27 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <47443E2E.3020507@nostrum.com>
Date: Wed, 21 Nov 2007 08:18:22 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Christer Holmberg 
Subject: Re: [Sip] media-security-requirements and lawful intercept
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<20071111224707.68E5033C21@delta.rtfm.com><008701c824d4$096ca180$c4f0200a@cisco.com>
	<4741FD6B.10507@nostrum.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4872/Wed Nov 21 02:36:49 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: IETF SIP List , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Christer Holmberg wrote:
> I don't understand this "IETF SIP" versus "3GPP SIP" thing.
>
> "3GPP SIP" is a SIP profile, including a number of SIP extensions, all
> done in IETF. There is nothing which a non-3GPP entity can't use.
>   

I said the bifurcation exists _in_ _the_ _market_. Did you follow the 
link I included? It's extraordinarily relevant. If you need more 
context: these are screenshots from the SIP account configuration 
screens on the Nokia E61:



We can argue over whether the split is real on the technical level (and there are several reasons that it is -- for example, using SigComp without proper signaling of the intention to do so ahead of time), but it's all a moot point: products are already being designed with two distinct modes of operation.


> What is "IETF SIP"? What do I have to implement in order to be "IETF
> SIP" compliant? RFC3261? RFC3261 plus each and every extension out
> there?
>   

RFC 3261 plus proper negotiation of any extensions you choose to 
support. More emphatically: any behavior that is not in 3261 or its 
references needs to be explicitly negotiated before it is engaged. This 
applies to both clients and network servers.

Need something more clear-cut? Something you can apply empirically? 
Here's a litmus test for you: if the initial signaling between two 
network elements can't negotiate down to base SIP without any 
extensions, then it's no longer SIP.

/a


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 09:20:18 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuqR3-0003RC-BQ; Wed, 21 Nov 2007 09:20:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuqR2-0003R6-2P
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:20:12 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqR1-0003Qx-BY
	for sip@ietf.org; Wed, 21 Nov 2007 09:20:11 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqR0-0002Gg-Ot
	for sip@ietf.org; Wed, 21 Nov 2007 09:20:11 -0500
Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net
	[96.226.64.76]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lALEK6cG004536
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 21 Nov 2007 08:20:06 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: 
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>
	<66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
Date: Wed, 21 Nov 2007 08:20:04 -0600
To: "Christer Holmberg" 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4872/Wed Nov 21 02:36:49 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

So to restate the problem that was reported:

Right now, extension-header does not allow a new header that contains  
a quoted-string.

We have defined extensions (and are likely to define new ones) that  
use quoted-string (anything that uses name-addr for instance).

This inconsistency has caused interoperability problems in real  
implementations.

My original note was to suggest that we change extension-header to  
actually allow the headers we're going to define.

Christer's response could be read as a proposal to change quoted- 
string to achieve the same goal.

RjS

On Nov 21, 2007, at 1:08 AM, Christer Holmberg wrote:

>
> Hi,
>
> I am still a little unclear what Robert is proposing, but is there
> really a need to be able to use characters between x00 and x20 in SIP
> messages? Characters between x21 and x7F, and between x80 and xBF, are
> ok since they are covered by TEXT-UTF8char and UTF8-CONT.
>
> Regards,
>
> Christer
>
>
> ________________________________
>
> 	From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
> 	Sent: 21. marraskuuta 2007 7:30
> 	To: Robert Sparks
> 	Cc: sip List
> 	Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
> 	
> 	
> 	I think I did misread Robert's original email. I thought header
> values having quoted strings are currently not allowed and Robert  
> wanted
> to change RFC2822. Now I realise that you can have header field values
> with quoted string. Therefore I support the correction that Robert is
> proposing.
> 	
> 	Hisham
> 	
> 	
> 	On 21/11/2007, Hisham Khartabil 
> wrote:
>
> 		This is a big change if we do adopt it. It will cause a
> lot of problem to parsers that handle extenion headers today and is  
> not
> backwards compatible. Why isn't the extension header as is defined  
> today
> not sufficient?
> 				
> 		Hisham
> 		
> 		
> 						On 20/11/2007, Robert
> Sparks  wrote:
>
> 			The BNF in 3261 says the following:
> 			
> 			extension-header  =  header-name HCOLON
> header-value
> 			header-value      =  *(TEXT-UTF8char / UTF8-CONT
> / LWS)
> 			
> 			This is intended to be the catch-all field for
> all future extensions
> 			- older parsers working against this BNF
> shouldn't barf
> 			when we introduce a new header field.
> 			
> 			Now, we may have new fields in the future that
> look like:
> 			
> 			NewHeader = new-header-name HCOLON quoted-string
> 			
> 			And down inside quoted-string, we get:
> 			
> 			      quoted-string  =  SWS DQUOTE *(qdtext /
> quoted-pair ) DQUOTE
> 			      qdtext         =  LWS / %x21 / %x23-5B /
> %x5D-7E
> 			                        / UTF8-NONASCII
> 			      quoted-pair  =  "\" (%x00-09 / %x0B-0C
> 			                       / %x0E-7F)
> 			
> 			So, for instance, we could have inside a quoted
> string the 2 byte
> 			sequence \ NULL
> 			
> 			This does not parse against header-value
> above...
> 			
> 			Is this a problem? Some of the SIPit21
> participants argued that it is.
> 			
> 			The projects I've been involved in don't parse
> unknown headers and
> 			the stacks will just hand up an unparsed bucket
> of bits (the only rules
> 			used are those necessary to identify the next
> header-field starting).
> 			
> 			Would it be worth the effort to make the BNF
> reflect that rather than
> 			continuing with the incongruity that we
> currently specify?
> 			
> 			RjS
> 			
> 			
> 			_______________________________________________
> 			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
> 			
>
>
> 		



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 09:34:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuqeG-0008NU-Kj; Wed, 21 Nov 2007 09:33:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuqeF-0008If-AJ
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:33:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqeE-0008IW-VV
	for sip@ietf.org; Wed, 21 Nov 2007 09:33:51 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqeE-0002bD-5P
	for sip@ietf.org; Wed, 21 Nov 2007 09:33:50 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	8B786210AD; Wed, 21 Nov 2007 15:33:49 +0100 (CET)
X-AuditID: c1b4fb3e-b16a4bb00000459d-b9-474441cd0d11
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	7103621053; Wed, 21 Nov 2007 15:33:49 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 15:33:49 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
Date: Wed, 21 Nov 2007 15:33:48 +0100
Message-ID: 
In-Reply-To: <6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: BNF future-proofing problem?
Thread-Index: AcgsSaCFMdxh9wfFTeKGF2CITLPJSAAAZ63w
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>
	<66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com>
	
	<6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>
From: "Christer Holmberg" 
To: "Robert Sparks" 
X-OriginalArrivalTime: 21 Nov 2007 14:33:49.0351 (UTC)
	FILETIME=[87DB1370:01C82C4B]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,=20

>So to restate the problem that was reported:
>=20
>Right now, extension-header does not allow a new header that=20
>contains a quoted-string.
>=20
>We have defined extensions (and are likely to define new=20
>ones) that use quoted-string (anything that uses name-addr=20
>for instance).
>=20
>This inconsistency has caused interoperability problems in=20
>real implementations.
>=20
>My original note was to suggest that we change=20
>extension-header to actually allow the headers we're going to define.
>=20
>Christer's response could be read as a proposal to change=20
>quoted- string to achieve the same goal.

Yes.

Unless someone can show a use-case where the x00-x20 characters would be
needed, for backward compability reasons I think it's better to restrict
quoted-string than to extend extension-header.

Regards,

Christer




> > Hi,
> >
> > I am still a little unclear what Robert is proposing, but is there=20
> > really a need to be able to use characters between x00 and=20
> x20 in SIP=20
> > messages? Characters between x21 and x7F, and between x80=20
> and xBF, are=20
> > ok since they are covered by TEXT-UTF8char and UTF8-CONT.
> >
> > Regards,
> >
> > Christer
> >
> >
> > ________________________________
> >
> > 	From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
> > 	Sent: 21. marraskuuta 2007 7:30
> > 	To: Robert Sparks
> > 	Cc: sip List
> > 	Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
> > =09
> > =09
> > 	I think I did misread Robert's original email. I thought header=20
> > values having quoted strings are currently not allowed and Robert=20
> > wanted to change RFC2822. Now I realise that you can have=20
> header field=20
> > values with quoted string. Therefore I support the correction that=20
> > Robert is proposing.
> > =09
> > 	Hisham
> > =09
> > =09
> > 	On 21/11/2007, Hisham Khartabil 
> > wrote:
> >
> > 		This is a big change if we do adopt it. It will=20
> cause a lot of=20
> > problem to parsers that handle extenion headers today and is not=20
> > backwards compatible. Why isn't the extension header as is defined=20
> > today not sufficient?
> > 			=09
> > 		Hisham
> > 	=09
> > 	=09
> > 						On 20/11/2007, Robert
> > Sparks  wrote:
> >
> > 			The BNF in 3261 says the following:
> > 		=09
> > 			extension-header  =3D  header-name HCOLON=20
> header-value
> > 			header-value      =3D  *(TEXT-UTF8char / UTF8-CONT
> > / LWS)
> > 		=09
> > 			This is intended to be the catch-all=20
> field for all future=20
> > extensions
> > 			- older parsers working against this=20
> BNF shouldn't barf
> > 			when we introduce a new header field.
> > 		=09
> > 			Now, we may have new fields in the=20
> future that look like:
> > 		=09
> > 			NewHeader =3D new-header-name HCOLON quoted-string
> > 		=09
> > 			And down inside quoted-string, we get:
> > 		=09
> > 			      quoted-string  =3D  SWS DQUOTE=20
> *(qdtext / quoted-pair ) DQUOTE
> > 			      qdtext         =3D  LWS / %x21 / %x23-5B /
> > %x5D-7E
> > 			                        / UTF8-NONASCII
> > 			      quoted-pair  =3D  "\" (%x00-09 / %x0B-0C
> > 			                       / %x0E-7F)
> > 		=09
> > 			So, for instance, we could have inside=20
> a quoted string the 2 byte
> > 			sequence \ NULL
> > 		=09
> > 			This does not parse against=20
> header-value above...
> > 		=09
> > 			Is this a problem? Some of the SIPit21=20
> participants argued that it=20
> > is.
> > 		=09
> > 			The projects I've been involved in=20
> don't parse unknown headers and
> > 			the stacks will just hand up an=20
> unparsed bucket of bits (the only=20
> > rules
> > 			used are those necessary to identify=20
> the next header-field=20
> > starting).
> > 		=09
> > 			Would it be worth the effort to make=20
> the BNF reflect that rather=20
> > than
> > 			continuing with the incongruity that we=20
> currently specify?
> > 		=09
> > 			RjS
> > 		=09
> > 		=09
> > 			_______________________________________________
> > 			Sip mailing list
> > https://www1.ietf.org/mailman/listinfo/sip
> > 
> > 			This list is for NEW development of the=20
> core SIP Protocol
> > 			Use sip-implementors@cs.columbia.edu=20
> for questions on current sip
> > 			Use sipping@ietf.org for new=20
> developments on the application of sip
> > 		=09
> >
> >
> > 	=09
>=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 09:42:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuqme-0003Sn-IU; Wed, 21 Nov 2007 09:42:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuqmd-0003Si-4z
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:42:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuqmc-0003Sa-R9
	for sip@ietf.org; Wed, 21 Nov 2007 09:42:30 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuqmc-0002nO-I3
	for sip@ietf.org; Wed, 21 Nov 2007 09:42:30 -0500
Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net
	[70.242.127.246]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lALEgS29005775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Nov 2007 08:42:28 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <474443CF.8040306@nostrum.com>
Date: Wed, 21 Nov 2007 08:42:23 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Christer Holmberg 
Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>	<66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com>		<6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4872/Wed Nov 21 02:36:49 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Christer Holmberg wrote:
> Unless someone can show a use-case where the x00-x20 characters would be
> needed, for backward compability reasons I think it's better to restrict
> quoted-string than to extend extension-header.
>   

Certainly you mean 0x00-0x19, right? I'd like to be able to use spaces 
inside quoted strings.

/a


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 09:44:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuqoY-0007Ix-EK; Wed, 21 Nov 2007 09:44:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuqoX-0007IK-3Q
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:44:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqoW-0007IC-QA
	for sip@ietf.org; Wed, 21 Nov 2007 09:44:28 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqoW-00074d-D0
	for sip@ietf.org; Wed, 21 Nov 2007 09:44:28 -0500
Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net
	[70.242.127.246]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lALEiPbw005915
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Nov 2007 08:44:25 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <47444444.9040700@nostrum.com>
Date: Wed, 21 Nov 2007 08:44:20 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Christer Holmberg 
Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>	<66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com>		<6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>	
	<474443CF.8040306@nostrum.com>
In-Reply-To: <474443CF.8040306@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4872/Wed Nov 21 02:36:49 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Adam Roach wrote:
> Christer Holmberg wrote:
>> Unless someone can show a use-case where the x00-x20 characters would be
>> needed, for backward compability reasons I think it's better to restrict
>> quoted-string than to extend extension-header.
>>   
>
> Certainly you mean 0x00-0x19, right? I'd like to be able to use spaces 
> inside quoted strings.

Erm... make that 0x00 - 0x1F (oops).

/a


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 10:37:44 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iurdz-00060h-Eb; Wed, 21 Nov 2007 10:37:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iurdy-00060c-3J
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:37:38 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iurdx-00060R-9T
	for sip@ietf.org; Wed, 21 Nov 2007 10:37:37 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iurdw-0004xI-Qq
	for sip@ietf.org; Wed, 21 Nov 2007 10:37:37 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lALFbMfV003261; 
	Wed, 21 Nov 2007 09:37:23 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lALFbMj21870; Wed, 21 Nov 2007 09:37:23 -0600 (CST)
Message-ID: <474450B2.1020907@alcatel-lucent.com>
Date: Wed, 21 Nov 2007 09:37:22 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Gonzalo Camarillo 
References: 
	<4743F62A.8040903@ericsson.com> <4743F78D.4070705@ericsson.com>
In-Reply-To: <4743F78D.4070705@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: sip , Brett Tate 
Subject: [Sip] Re: URI comparison rules - IPv6 addresses
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Gonzalo Camarillo wrote:
> Hi,
> 
> Brett brought this up in the SIP Implementors mailing list. The
> following IPv6 addresses are supposed to be equivalent:
> 
> [::ffff:192.0.2.128] and [::ffff:c000:280]
> [2001:db8::9:1] and [2001:db8::9:01]
> [0:0:0:0:0:FFFF:129.144.52.38] and [::FFFF:129.144.52.38]
> 
> Now, let's say I need to compare sip:user1@[::ffff:192.0.2.128] and
> sip:user1@[::ffff:c000:280]. Should we consider these URIs to be
> equivalent or not?
> 
> My proposal is that we clarify that IPv6 address comparison happens at
> the binary level, not at the textual level. We could log a bug against
> RFC3261, and try and add such a clarification to the IPv6 transition
> document (I will need to ask the ADs whether or not we can add this in
> AUTH48).

Gonzalo: My only concern that I had mentioned to Brett as
well was that this should not be construed as endorsing the
notion of multiple representations of the IPv6 address in
SIP signaling.  This may cause problems in normal SIP operations.

Consider a proxy that uses the sent-by address in a loop detection
mechanism.  If it gets a looped request but the upstream proxy
had now put a different representation of the IP address, then
the proxy will not recognize that as a loop.  Admittedly, the
upstream proxy should not be inserting different representations
of the same IP address in each request (unless, of course it is
malicious; but then if it is malicious, it could probably do
damage by other means.)

Now, regarding where to put it: in v6-transition or in a SIP
essential fix, here are some thoughts.  Insofar as we are talking
about URI comparison, this clarification is probably best put
in S19.1.4 (URI Comparison) of rfc3261.  We already have a
SIP essential fix document that fixes the IPv6 ABNF in rfc3261
(http://tools.ietf.org/html/draft-gurbani-sip-ipv6-abnf-fix-00);
this clarification could be tacked on in that draft if the WG
agrees.  Thoughts?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 11:20:05 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IusIl-0000ws-Ct; Wed, 21 Nov 2007 11:19:47 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IusIj-0000w8-Dh
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:19:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IusIi-0000vo-7N
	for sip@ietf.org; Wed, 21 Nov 2007 11:19:44 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IusIh-0006sx-7b
	for sip@ietf.org; Wed, 21 Nov 2007 11:19:44 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 21 Nov 2007 11:19:33 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALGJWoE023368; 
	Wed, 21 Nov 2007 11:19:32 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALGJ109011523; 
	Wed, 21 Nov 2007 16:19:32 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:19:21 -0500
Received: from [10.82.210.128] ([10.82.210.128]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:19:21 -0500
Message-ID: <47445A89.8090002@cisco.com>
Date: Wed, 21 Nov 2007 11:19:21 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: prince.philip@aricent.com
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 16:19:21.0788 (UTC)
	FILETIME=[464847C0:01C82C5A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9317; t=1195661973;
	x=1196525973; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20 |To:=20prince.philip@aricent.com;
	bh=h2WeOmZwFrfP7j6YNAOEcUJ5akOtNhSAu05n3cpp5Po=;
	b=TF6lR7oOqKCS1xhjw2cq4GDs5mhra09Zy2LjYecympSAnPuxb796WnNw9dhf61O38YO5AbjZ
	wWOnmVZROMguHKZH+bVgAkFCOSxzig2Tukt9GhfITulAF9DktBL6I866;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



prince.philip@aricent.com wrote:
> Since in the UAC point of view the behaviour is defined clearly, whats 
> the issue?
> Does anybody see any use case for this additional answer, from an UAS 
> perspective?

 From a practical perspective I think that there have been a lot of 
implementors that implemented what they *thought* the spec said, but got 
it wrong. Then others have done what they thought they had to do to 
interoperate.

So there may be some use for this added answer for interoperation with 
certain broken implementations. (But I speak hypothetically - I don't 
have a specific implementation to point to.)

But for those just trying to follow the specs there is no use for this 
added SDP. Nobody should be *using* it. If they are, they need to change.

	Paul

> Prince.
> 
> 
> -----"Christer Holmberg"  wrote: -----
> 
>     To: "Jonathan Rosenberg" , "Paul Kyzivat"
>     
>     From: "Christer Holmberg" 
>     Date: 11/21/2007 12:33AM
>     cc: "Sanjay Sinha \(sanjsinh\)" , sip List
>     
>     Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
> 
>     Hi,
> 
>     An implementation should keep offer/answer state and simply discard
>     the SDP in the 200 OK.
> 
>     I don't think that is complicated :)
> 
>     Regards,
> 
>     Christer
> 
>     ________________________________
> 
>     From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
>     Sent: Tue 20/11/2007 17:56
>     To: Paul Kyzivat
>     Cc: Sanjay Sinha (sanjsinh); sip List
>     Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
> 
> 
> 
>     The intention was that, when reliable provisionals are used, the answer
>     would NOT appear in the 200 OK to the original INVITE. The paragraph in
>     RFC3261 is talking specifically about the case of an unreliable
>     provisional response.
> 
>     The drawback of sending the answer in the reliable 18x and then
>     repeating it in the 200 OK, is what if they are not the same. It gets
>     really complicated if there are multiple O/A exchanges in UPDATE/PRACK
>     prior to the final 200 OK.
> 
>     -Jonathan R.
> 
>     Paul Kyzivat wrote:
>      >
>      >
>      > Robert Sparks wrote:
>      >> Yes, I did mean 200 INVITE.
>      >>
>      >> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
>      >>
>      >>> It is not clear from the call flow if the 200 OK is for PRACK
>     or INVITE?
>      >>>
>      >>> I guess you meant 200 OK for Invite. If that is the case, I
>     think the
>      >>> RFC is clear that the answer sdp is optional in it and if it
>     does have
>      >>> an answer sdp, it MUST be idential to answer in 18x.
>      >>>
>      >>
>      >> Really? Point me to where you find this please.
>      >
>      > Mostly in 3261 sec 13.2.1. It says:
>      >
>      >       o  If the initial offer is in an INVITE, the answer MUST be
>     in a
>      >          reliable non-failure message from UAS back to UAC which is
>      >          correlated to that INVITE.  For this specification, that is
>      >          only the final 2xx response to that INVITE.  That same exact
>      >          answer MAY also be placed in any provisional responses sent
>      >          prior to the answer.  The UAC MUST treat the first session
>      >          description it receives as the answer, and MUST ignore any
>      >          session descriptions in subsequent responses to the initial
>      >          INVITE.
>      >
>      > The first three sentences are the clearly normative part. When
>     combined
>      > with RFC 3262 definition of reliable provisionals, they say that the
>      > reliable provisional contains the answer.
>      >
>      > The last sentence doesn't really say the UAS may include sdp in
>      > subsequent responses to the invite transaction, but neither does
>     it say
>      > you can't. It does say the UAC should ignore them if present, which
>      > implies they can be present, but says nothing about what value
>     they must
>      > have if they are present.
>      >
>      > AFAIK there is nothing that says the answer may be repeated in
>     the 200.
>      > However it is seemingly done a lot, so one had better beware.
>      >
>      >     Paul
>      >
>      >>> But I think the
>      >>> offer-answer draft has clarified it further that it should not
>     have any
>      >>> answer sdp. This is probably harsh in case of one offer-answer
>     exchange,
>      >>> but makes sense if there are multiple early dialog offer-answer
>      >>> exchanges in say Prack/200 OK or using UPDATE.
>      >
>      >
>      >
>      >>> Sanjay
>      >>>
>      >>>> -----Original Message-----
>      >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>      >>>> Sent: Monday, November 19, 2007 4:14 PM
>      >>>> To: sip List
>      >>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
>      >>>>
>      >>>> There was a lot of discussion and disagreement at SIPit21
>      >>>> about whether the following 200 OK is allowed (or should) have
>      >>>> SDP in it:
>      >>>>
>      >>>> INVITE (offer)
>      >>>> -------->
>      >>>> 18x (with 100rel) (answer)
>      >>>> <--------
>      >>>> PRACK
>      >>>> --------->
>      >>>> 200 OK (can this carry SDP?)
>      >>>> <---------
>      >>>> ACK
>      >>>> --------->
>      >>>>
>      >>>> I couldn't find anything definitive in RFC form. Paul's
>      >>>> offeranswer draft talks about this I think.
>      >>>>
>      >>>> If I understand things, the right answer here is that it's not
>      >>>> supposed to carry any SDP and that you should ignore it if it
>     shows up.
>      >>>>
>      >>>> The question is, other than waste, what can go wrong if it is
>     there?
>      >>>> When we end up with clear text around the requirement, will it
>      >>>> say SDP SHOULD NOT, or MUST NOT appear?
>      >>>>
>      >>>> Or do I have this wrong?
>      >>>>
>      >>>> RjS
>      >>>>
>      >>>>
>      >>>> _______________________________________________
>      >>>> 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
>      >>>>
>      >>
>      >>
>      >>
>      >> _______________________________________________
>      >> 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
>      >>
>      >
>      >
>      > _______________________________________________
>      > 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
>      >
> 
>     --
>     Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
>     Cisco Fellow                                   Edison, NJ 08837
>     Cisco, Voice Technology Group
>     jdrosen@cisco.com
>     http://www.jdrosen.net
>     http://www.jdrosen.net/>                  
>            PHONE: (408) 902-3084
>     http://www.cisco.com http://www.cisco.com/>
> 
> 
>     _______________________________________________
>     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
> 
> 
> 
> 
>     _______________________________________________
>     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
> 
> 
> 
> *****Aricent-Restricted *****=
> 
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
> the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
> circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
> please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
> loss or damage arising from the use of the information transmitted by this email including damage from virus."
> 


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 11:20:18 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IusJG-0001iN-EE; Wed, 21 Nov 2007 11:20:18 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IusJE-0001i7-Tc
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:20:16 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IusJE-0001ht-Is
	for sip@ietf.org; Wed, 21 Nov 2007 11:20:16 -0500
Received: from figas.ekabal.com ([204.61.215.10])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IusJB-0006tx-O6
	for sip@ietf.org; Wed, 21 Nov 2007 11:20:14 -0500
Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lALGJkU31048;
	Wed, 21 Nov 2007 08:19:47 -0800
In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F046D2838@esebe103.NOE.Nokia.com>
References: 
	<8B1D53AEF7B03449A6D3771B3B7F850F046D2838@esebe103.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Rohan Mahy 
Subject: Re: [Sip] Few comments to draft-ietf-sip-outbound-11
Date: Wed, 21 Nov 2007 08:19:37 -0800
To: 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 21, 2007, at 12:25 AM,  wrote:

>
> Hi,
>
> First of all, in my opinion outbound-11 looks good.
> It has improved a lot from the previous version and
> properly addressed many comments given in August during
> WGLC.
>
> After reading the draft I found a few things for which
> I would seek further clarification. Some of those were
> already initially raised in WGLC and the other minor
> issues are due to the new text appeared in version 11.
>
> 1. Why should the registrar store the time of updating
>    the binding ?
>
> Section 6. Registrar mechanisms tells the following:
>
>    The registrar MUST store in the binding the Contact URI,
>    all the Contact head field parameters, and any Path header field
>    values and SHOULD also store the time at which the binding was last
>    updated.
>
>    If the registrar receives a re-registration for a specific
>    combination of AOR, instance-id and reg-id values, the registrar  
> MUST
>    update any information that uniquely identifies the network flow  
> over
>    which the request arrived if that information has changed, and  
> SHOULD
>    update the time the binding was last updated.
>
> To which purpose is this stored time used ? In my understanding
> such a stored time is not needed for replacing older bindings and
> I could not come up with any other reason either to store the time.
>
> As the draft tells elsewhere "[when the] reg-id values [coming from
> the UA within REGISTER request] will collide with the previously
> used reg-id values [stored earlier along the binding] the registrar
> can replace the older registrations". The time of any previous update
> should not matter.

There are three reasons, but all of them are a bit dubious.
a) RFC 3261 recommends keeping this information, but does not say why
b) This was needed in a previous version of outbound
c) GRUU uses this in the temporary GRUU invalidation procedure.   
However, this is an open issue for GRUU and outbound.  I will send  
mail about this soon.

The short answer is that it can probably be removed.

> 2. How to respond if UA requires Outbound but the proxy does
>    not support it even if the registrar does ?
>
> How should the registrar respond to a REGISTER request when:
>
> - REGISTER contains Require: Outbound and reg-id in Contact
>
> - Registrar itself supports Outbound
>
> - Via header of REGISTER indicates that there is a proxy between
>   the UA and registrar, but the proxy has not included either the
>   Path header or 'ob' parameter to its URI within the Path ?

I looked for an appropriate error message for this and it was quite a  
puzzler.  420 is clearly not appropriate. I was planning to  
investigate if 488 Not Acceptable Here or 580 Precondition Failed  
could be reused for this purpose.  I am not really keen on adding a  
new response code though. A 400 Bad Request would be appropriate but  
not especially helpful.

> 3. Completing the removal of TCP keepalive from the draft
>
> As all the other references to TCP keepalive have now been removed
> from the draft, then please remove also this one from section
> Section 3.5. Keepalive Technique:
>
>    transports such as TCP and SCTP, this specification describes a
>    keepalive approach based on sending CRLFs, *and for TCP, a usage of
>    TCP transport-layer keepalives*.

Thanks

> 4. Ambiguous text in section 7
>
> Section 7. Authoritative Proxy Mechanisms: Forwarding Requests tells:
>
>    If the proxy doubles as a registrar and stored information about  
> the
>    flow that created the binding, then the proxy MUST send the request
>    over the same 'logical flow' saved with the binding,
>
> Sorry but I do not understand what is meant by: "If the proxy doubles
> as a registrar and stored information about the flow that created the
> binding"  Proxy 'doubling as a registrar' sounds odd (which might  
> be due
> to my poor skills of English ...) Could you please clarify this ?

Sure.  This is the case where the authoritative proxy and registrar  
roles are implemented in the same SIP implementation.  The flow was  
stored by the "registrar" but the "authoritative proxy" performs the  
lookup function and routes to the registered UA over the saved flow.

This was actually a suggestion from Byron Cambell which seemed much  
less cumbersome from the previous text, but clearly it could use some  
additional rewording.  Feel free to propose something.

thanks,
-rohan



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 11:23:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IusLm-00049E-SK; Wed, 21 Nov 2007 11:22:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IusLl-00048M-M0
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:22:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IusLl-00048E-CV
	for sip@ietf.org; Wed, 21 Nov 2007 11:22:53 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IusLi-0002Kr-5g
	for sip@ietf.org; Wed, 21 Nov 2007 11:22:53 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 21 Nov 2007 11:22:50 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALGMo3F025835; 
	Wed, 21 Nov 2007 11:22:50 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALGMnKH025340; 
	Wed, 21 Nov 2007 16:22:49 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:22:23 -0500
Received: from [10.82.210.128] ([10.82.210.128]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:22:22 -0500
Message-ID: <47445B3E.2070509@cisco.com>
Date: Wed, 21 Nov 2007 11:22:22 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Hisham Khartabil 
Subject: Re: [Sip] SIPit 21: Question about offer answer
References: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com>	
	<4742359B.1060301@cisco.com>	
	<200711200138.lAK1cmun008944@dragon.ariadne.com>	
		
	<4742ED6D.5030103@cisco.com>
	<66cd252f0711202009x11f42f35s445c25c4f12508a6@mail.gmail.com>
In-Reply-To: <66cd252f0711202009x11f42f35s445c25c4f12508a6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 16:22:22.0872 (UTC)
	FILETIME=[B2378180:01C82C5A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4740; t=1195662170;
	x=1196526170; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit=2021=3A=20Question=20about=20offer=20an
	swer |Sender:=20
	|To:=20Hisham=20Khartabil=20;
	bh=p4zzOPBfl6hGODuHMLWtluFmwG/Lq96km5/kMh2lkVo=;
	b=GZHKe1W77qi2RtVUzlda+sDkOysGy+a9CLsSd2VrxFnepmRahxtuLFaKt3IBNitIh4KDt7fQ
	QjCZlgDAiMw1Q4gnEF4Kt8O0Swi0ikQ7pa8kRHO50iyO4Y+E6cCrkNc2;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: sip@ietf.org, Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Hisham Khartabil wrote:
> My view on this is that if you don't want to send SDP but you have to 
> when sending a re-INVITE, then send UPDATE without the SDP. Can we 
> update session timer to say that?

I suppose we could, but you can only do that if both sides support 
UPDATE. Since its optional, those who implement session timer must be 
prepared to do it with reINVITE.

I really don't understand the issue here. If you send a reINVITE with 
unchanged SDP and you get back an answer that is changed, just deal with 
it. Why is this a problem?

	Paul

> Hisham
> 
>  
> On 21/11/2007, *Paul Kyzivat*  > wrote:
> 
> 
> 
>     Christer Holmberg wrote:
>      > Hi,
>      >
>      > What if the offerer is not "prepared" to receive an updated
>     answer (it
>      > only included the "offer" because it had to)? How can it "reject" the
>      > answer?
> 
>     It can't. At best it can make a counter offer after the fact, or
>     terminate the call after the fact.
> 
>     But that clearly isn't a good policy. You should design your UA so that
>     this isn't an issue. When you make an offer you must always be prepared
>     for the answer be anything that is compatible with the offer.
> 
>      > I personally think that an unchanged o- line in the offer should not
>      > allow the answer to change.
>      >
>      > One could of course change the o- line in the offer - even if the
>     offer
>      > itself hasn't changed - and that would then allow the answer to be
>      > changed.
> 
>     Personally I think the o-line changing or not is just an extra
>     complication that should never have been there as a factor. Whether the
>     o-line changes or not isn't what matters. What matters is whether the
>     rest of the SDP changes. At best the o-line is a hint about whether the
>     rest changed or not, and simply introduces the potential error case
>     where the SDP doesn't agree with what the o-line is hinting. (So what
>     should you do if the o-line is unchanged but the SDP is changed?)
> 
>     But as things are written, you are expected to make the o-line the same
>     if the rest of the SDP is the same. The o-line in the offer has
>     *nothing* to do with what is in the answer.
> 
>            Paul
> 
>      > Just some thinking...
>      >
>      > Regards,
>      >
>      > Christer
>      >
>      >
>      >
>      >> -----Original Message-----
>      >> From: Dale.Worley@comcast.net 
>     [mailto:Dale.Worley@comcast.net ]
>      >> Sent: 20. marraskuuta 2007 3:39
>      >> To: sip@ietf.org 
>      >> Subject: Re: [Sip] SIPit 21: Question about offer answer
>      >>
>      >>    From: Paul Kyzivat      >
>      >>
>      >>    A 3pcc controller doing a transfer may well send an
>      >> offerless invite to
>      >>    one UA and then send the offer it gets back to an entirely
>      >> different UA
>      >>    than had been in the session before. So of course the
>      >> answer will be
>      >>    entirely different.
>      >>
>      >> Hmmm, "my" music-on-hold proposal does that, too.
>      >>
>      >> Dale
>      >>
>      >>
>      >> _______________________________________________
>      >> 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
>      >>
>      >
>      >
>      > _______________________________________________
>      > 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
>      >
> 
> 
>     _______________________________________________
>     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
> 
> 


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 11:23:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IusLy-0004Q7-QE; Wed, 21 Nov 2007 11:23:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IusLw-0004Nn-LQ
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:23:04 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IusLw-0004Ll-5T
	for sip@ietf.org; Wed, 21 Nov 2007 11:23:04 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IusLv-0006z9-Cf
	for sip@ietf.org; Wed, 21 Nov 2007 11:23:04 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	B0D382111B; Wed, 21 Nov 2007 17:23:02 +0100 (CET)
X-AuditID: c1b4fb3e-b0ea3bb00000459d-98-47445b66bade
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	A0C3F2109B; Wed, 21 Nov 2007 17:23:02 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 17:23:02 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 17:23:02 +0100
Received: from [131.160.126.193] (rvi2-126-193.lmf.ericsson.se
	[131.160.126.193])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 10044234E;
	Wed, 21 Nov 2007 18:23:02 +0200 (EET)
Message-ID: <47445B65.7010608@ericsson.com>
Date: Wed, 21 Nov 2007 18:23:01 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
References: 
	<4743F62A.8040903@ericsson.com> <4743F78D.4070705@ericsson.com>
	<474450B2.1020907@alcatel-lucent.com>
In-Reply-To: <474450B2.1020907@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 16:23:02.0415 (UTC)
	FILETIME=[C9C949F0:01C82C5A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: sip , Brett Tate 
Subject: [Sip] Re: URI comparison rules - IPv6 addresses
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi Vijay,

if this document becomes a WG item, I agree it would be the perfect 
place to document this issue.

Cheers,

Gonzalo


Vijay K. Gurbani wrote:
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> Brett brought this up in the SIP Implementors mailing list. The
>> following IPv6 addresses are supposed to be equivalent:
>>
>> [::ffff:192.0.2.128] and [::ffff:c000:280]
>> [2001:db8::9:1] and [2001:db8::9:01]
>> [0:0:0:0:0:FFFF:129.144.52.38] and [::FFFF:129.144.52.38]
>>
>> Now, let's say I need to compare sip:user1@[::ffff:192.0.2.128] and
>> sip:user1@[::ffff:c000:280]. Should we consider these URIs to be
>> equivalent or not?
>>
>> My proposal is that we clarify that IPv6 address comparison happens at
>> the binary level, not at the textual level. We could log a bug against
>> RFC3261, and try and add such a clarification to the IPv6 transition
>> document (I will need to ask the ADs whether or not we can add this in
>> AUTH48).
> 
> Gonzalo: My only concern that I had mentioned to Brett as
> well was that this should not be construed as endorsing the
> notion of multiple representations of the IPv6 address in
> SIP signaling.  This may cause problems in normal SIP operations.
> 
> Consider a proxy that uses the sent-by address in a loop detection
> mechanism.  If it gets a looped request but the upstream proxy
> had now put a different representation of the IP address, then
> the proxy will not recognize that as a loop.  Admittedly, the
> upstream proxy should not be inserting different representations
> of the same IP address in each request (unless, of course it is
> malicious; but then if it is malicious, it could probably do
> damage by other means.)
> 
> Now, regarding where to put it: in v6-transition or in a SIP
> essential fix, here are some thoughts.  Insofar as we are talking
> about URI comparison, this clarification is probably best put
> in S19.1.4 (URI Comparison) of rfc3261.  We already have a
> SIP essential fix document that fixes the IPv6 ABNF in rfc3261
> (http://tools.ietf.org/html/draft-gurbani-sip-ipv6-abnf-fix-00);
> this clarification could be tacked on in that draft if the WG
> agrees.  Thoughts?
> 
> Thanks,
> 
> - vijay



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 11:25:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IusOK-0007zO-Qb; Wed, 21 Nov 2007 11:25:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IusOJ-0007z9-4s
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:25:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IusOI-0007xu-Q0
	for sip@ietf.org; Wed, 21 Nov 2007 11:25:30 -0500
Received: from figas.ekabal.com ([204.61.215.10])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IusOI-00073M-6e
	for sip@ietf.org; Wed, 21 Nov 2007 11:25:30 -0500
Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lALGPJU31273;
	Wed, 21 Nov 2007 08:25:19 -0800
In-Reply-To: 
References: 
	<8B1D53AEF7B03449A6D3771B3B7F850F046D2838@esebe103.NOE.Nokia.com>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2084781E-13D4-4E25-863E-17B7B860BE69@ekabal.com>
Content-Transfer-Encoding: 7bit
From: Rohan Mahy 
Date: Wed, 21 Nov 2007 08:25:09 -0800
To: "Christer Holmberg" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip@ietf.org, Rohan Mahy , fluffy@cisco.com
Subject: [Sip] Re: Comment on draft-ietf-sip-outbound-11
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Christer,

I could add to the Overview something like this:

"The 'ob' parameter has two uses.  In a REGISTER request it is placed  
in the Path header by the first edge proxy to indicate that the edge  
proxy understood outbound and added a flow token there.  Secondly, it  
is placed by a User Agent in its dialog-forming requests, when the UA  
wants the first hop proxy to Record-Route subsequent requests in this  
dialog over the same flow."

Would that help?

thanks,
-rohan

On Nov 21, 2007, at 6:02 AM, Christer Holmberg wrote:
> Hi,
>
> One comment on the draft.
>
> I think we should describe the usage of "ob" a little better. The  
> usage
> is a little unclear, I think.
>
> Regards,
>
> Christer



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 11:40:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuscX-0000QB-Bd; Wed, 21 Nov 2007 11:40:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuscV-0000IJ-K9
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:40:11 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuscV-0000Hj-96
	for sip@ietf.org; Wed, 21 Nov 2007 11:40:11 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuscV-0007SA-00
	for sip@ietf.org; Wed, 21 Nov 2007 11:40:11 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 21 Nov 2007 11:40:11 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALGeAm5014354; 
	Wed, 21 Nov 2007 11:40:10 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALGeAKH002117; 
	Wed, 21 Nov 2007 16:40:10 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:40:10 -0500
Received: from [10.82.210.128] ([10.82.210.128]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 11:40:09 -0500
Message-ID: <47445F69.2090702@cisco.com>
Date: Wed, 21 Nov 2007 11:40:09 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Christer Holmberg 
Subject: Re: [Sip] Status of require headers in the re-INVITE request.
References: <01949ABCDD38EF4A95B8C347C399D1CE05B7EB96@BLR-EC-MBX02.wipro.com>	<473DDB80.8060507@cisco.com>	
	<4741FDDA.6000902@cisco.com> <47421D62.3040908@zonnet.nl>
	<47423A7E.6020204@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 16:40:09.0633 (UTC)
	FILETIME=[2E0E5110:01C82C5D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=623; t=1195663210;
	x=1196527210; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20Status=20of=20require=20headers=20in=20the=20
	re-INVITE=20request. |Sender:=20
	|To:=20Christer=20Holmberg=20;
	bh=c5yjkumEfoNXGlKZA4qVu70l6JbgrH5l8Na528YZ7nM=;
	b=Dxnyi3WgGATm64gB/H4y1msmDXXM+Nj6Qst2pfBfrqhn6Wuv7eVYMkLmbKgXaBeNh7DG96Fx
	zcPitw1QMjdtmxzPuF3gW1M2lGjGyDcJTSDfBmZMMDHE5pn5ljsP8caY;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Christer Holmberg wrote:

>>> Still, some drafts / RFC may have sneaked through that use a different
>>> interpretation of scope. RFC3329 (sec-agree) came up with a "creative"
>>> use, for example.
>> I haven't done a survey, but I think there are probably a lot 
>> of creative interpretations of the scope.
> 
> Yes, and that is what causes interop problems :)
> 
> One alternative would be that when you define a new option-tag, you
> should clearly specify what the "scope" of it is.

Yes, that is probably the only practical way forward. It needs to be 
done for all the existing tags too.

	Paul


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 12:34:44 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IutT0-00018H-8r; Wed, 21 Nov 2007 12:34:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IutSy-00013B-KF
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:34:24 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IutSy-000130-8O
	for sip@ietf.org; Wed, 21 Nov 2007 12:34:24 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IutSx-0000zt-EE
	for sip@ietf.org; Wed, 21 Nov 2007 12:34:24 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	E5AEB20864; Wed, 21 Nov 2007 18:34:22 +0100 (CET)
X-AuditID: c1b4fb3c-b0798bb0000030cf-47-47446c1e7a0e
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	BF57E20487; Wed, 21 Nov 2007 18:34:22 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 18:34:22 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21: Question about offer answer
Date: Wed, 21 Nov 2007 18:29:38 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21: Question about offer answer
Thread-Index: AcgsWuBvJ4FdnQxGQZuf2MjTJN14XwACTc75
References: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com>	
	<4742359B.1060301@cisco.com>	
	<200711200138.lAK1cmun008944@dragon.ariadne.com>	
		
	<4742ED6D.5030103@cisco.com>
	<66cd252f0711202009x11f42f35s445c25c4f12508a6@mail.gmail.com>
	<47445B3E.2070509@cisco.com>
From: "Christer Holmberg" 
To: "Paul Kyzivat" ,
	"Hisham Khartabil" 
X-OriginalArrivalTime: 21 Nov 2007 17:34:22.0668 (UTC)
	FILETIME=[C10410C0:01C82C64]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,
=20
>> My view on this is that if you don't want to send SDP but you have to
>> when sending a re-INVITE, then send UPDATE without the SDP. Can we
>> update session timer to say that?
>
>I suppose we could, but you can only do that if both sides support
>UPDATE. Since its optional, those who implement session timer must be
>prepared to do it with reINVITE.
>
>I really don't understand the issue here. If you send a reINVITE with
>unchanged SDP and you get back an answer that is changed, just deal =
with
>it. Why is this a problem?

The problem is when you - for whatever reason - can't deal with it.

Regards,

Christer

=20

=20

=20

> On 21/11/2007, *Paul Kyzivat*  > wrote:
>
>
>
>     Christer Holmberg wrote:
>      > Hi,
>      >
>      > What if the offerer is not "prepared" to receive an updated
>     answer (it
>      > only included the "offer" because it had to)? How can it =
"reject" the
>      > answer?
>
>     It can't. At best it can make a counter offer after the fact, or
>     terminate the call after the fact.
>
>     But that clearly isn't a good policy. You should design your UA so =
that
>     this isn't an issue. When you make an offer you must always be =
prepared
>     for the answer be anything that is compatible with the offer.
>
>      > I personally think that an unchanged o- line in the offer =
should not
>      > allow the answer to change.
>      >
>      > One could of course change the o- line in the offer - even if =
the
>     offer
>      > itself hasn't changed - and that would then allow the answer to =
be
>      > changed.
>
>     Personally I think the o-line changing or not is just an extra
>     complication that should never have been there as a factor. =
Whether the
>     o-line changes or not isn't what matters. What matters is whether =
the
>     rest of the SDP changes. At best the o-line is a hint about =
whether the
>     rest changed or not, and simply introduces the potential error =
case
>     where the SDP doesn't agree with what the o-line is hinting. (So =
what
>     should you do if the o-line is unchanged but the SDP is changed?)
>
>     But as things are written, you are expected to make the o-line the =
same
>     if the rest of the SDP is the same. The o-line in the offer has
>     *nothing* to do with what is in the answer.
>
>            Paul
>
>      > Just some thinking...
>      >
>      > Regards,
>      >
>      > Christer
>      >
>      >
>      >
>      >> -----Original Message-----
>      >> From: Dale.Worley@comcast.net 
>     [mailto:Dale.Worley@comcast.net ]
>      >> Sent: 20. marraskuuta 2007 3:39
>      >> To: sip@ietf.org 
>      >> Subject: Re: [Sip] SIPit 21: Question about offer answer
>      >>
>      >>    From: Paul Kyzivat      >
>      >>
>      >>    A 3pcc controller doing a transfer may well send an
>      >> offerless invite to
>      >>    one UA and then send the offer it gets back to an entirely
>      >> different UA
>      >>    than had been in the session before. So of course the
>      >> answer will be
>      >>    entirely different.
>      >>
>      >> Hmmm, "my" music-on-hold proposal does that, too.
>      >>
>      >> Dale
>      >>
>      >>
>      >> _______________________________________________
>      >> 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
>      >>
>      >
>      >
>      > _______________________________________________
>      > 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
>      >
>
>
>     _______________________________________________
>     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
>
>




_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 12:42:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iutae-0001Ov-0M; Wed, 21 Nov 2007 12:42:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iutac-0001Oe-HA
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:42:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iutac-0001OT-7b
	for sip@ietf.org; Wed, 21 Nov 2007 12:42:18 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IutaZ-0005JD-Qh
	for sip@ietf.org; Wed, 21 Nov 2007 12:42:18 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	29BCC20A98; Wed, 21 Nov 2007 18:42:13 +0100 (CET)
X-AuditID: c1b4fb3c-b0798bb0000030cf-c5-47446df56ebc
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	1681520A44; Wed, 21 Nov 2007 18:42:13 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 18:42:12 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
Date: Wed, 21 Nov 2007 18:42:12 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: BNF future-proofing problem?
Thread-Index: AcgsTMNy4xQSFy5zTSCLX9+s6dfHiAAGDsX5
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com>	<66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com>		<6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>
	
	<474443CF.8040306@nostrum.com>
From: "Christer Holmberg" 
To: "Adam Roach" 
X-OriginalArrivalTime: 21 Nov 2007 17:42:12.0978 (UTC)
	FILETIME=[D957AD20:01C82C65]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,
=20
>>Unless someone can show a use-case where the x00-x20 characters would =
be
>>needed, for backward compability reasons I think it's better to =
restrict
>>quoted-string than to extend extension-header.
> =20
>
>Certainly you mean 0x00-0x19, right? I'd like to be able to use spaces
>inside quoted strings.

The ABNF (see below) acutally doesn't allow 0x20 as such. BUT, you are =
also allowed to use LWS, which can contain spaces :)

header-value      =3D  *(TEXT-UTF8char / UTF8-CONT / LWS)

TEXT-UTF8-TRIM  =3D  1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
TEXT-UTF8char   =3D   %x21-7E / UTF8-NONASCII
UTF8-NONASCII   =3D  %xC0-DF 1UTF8-CONT
                                    /  %xE0-EF 2UTF8-CONT
                                    /  %xF0-F7 3UTF8-CONT
                                    /  %xF8-Fb 4UTF8-CONT
                                    /  %xFC-FD 5UTF8-CONT
UTF8-CONT       =3D  %x80-BF


Regards,

Christer

=20



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 12:44:16 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IutcR-0000yb-O7; Wed, 21 Nov 2007 12:44:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IutcP-0000yU-VT
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:44:09 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IutcP-0000wj-JF
	for sip@ietf.org; Wed, 21 Nov 2007 12:44:09 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IutcO-0001eQ-NS
	for sip@ietf.org; Wed, 21 Nov 2007 12:44:09 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	13B91200BE; Wed, 21 Nov 2007 18:44:08 +0100 (CET)
X-AuditID: c1b4fb3e-afea1bb00000459d-47-47446e6737f5
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	E419C2007A; Wed, 21 Nov 2007 18:44:07 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 18:44:07 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
Date: Wed, 21 Nov 2007 18:42:53 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: BNF future-proofing problem?
Thread-Index: AcgsSaCFMdxh9wfFTeKGF2CITLPJSAAAZ63wAAashzg=
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com><66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com><6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>
	
From: "Christer Holmberg" 
To: "Christer Holmberg" ,
	"Robert Sparks" 
X-OriginalArrivalTime: 21 Nov 2007 17:44:07.0836 (UTC)
	FILETIME=[1DCD9DC0:01C82C66]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,
=20
Another alternative would be to define an escaping mechanism for =
quoted-strings in SIP messages, and require all characters not allowed =
by the header-value ABNF to be escaped.
=20
Regards,
=20
Christer=20

________________________________

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Wed 21/11/2007 15:33
To: Robert Sparks
Cc: sip List
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?




Hi,

>So to restate the problem that was reported:
>
>Right now, extension-header does not allow a new header that
>contains a quoted-string.
>
>We have defined extensions (and are likely to define new
>ones) that use quoted-string (anything that uses name-addr
>for instance).
>
>This inconsistency has caused interoperability problems in
>real implementations.
>
>My original note was to suggest that we change
>extension-header to actually allow the headers we're going to define.
>
>Christer's response could be read as a proposal to change
>quoted- string to achieve the same goal.

Yes.

Unless someone can show a use-case where the x00-x20 characters would be
needed, for backward compability reasons I think it's better to restrict
quoted-string than to extend extension-header.

Regards,

Christer




> > Hi,
> >
> > I am still a little unclear what Robert is proposing, but is there
> > really a need to be able to use characters between x00 and
> x20 in SIP
> > messages? Characters between x21 and x7F, and between x80
> and xBF, are
> > ok since they are covered by TEXT-UTF8char and UTF8-CONT.
> >
> > Regards,
> >
> > Christer
> >
> >
> > ________________________________
> >
> >     From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
> >     Sent: 21. marraskuuta 2007 7:30
> >     To: Robert Sparks
> >     Cc: sip List
> >     Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
> >   =20
> >   =20
> >     I think I did misread Robert's original email. I thought header
> > values having quoted strings are currently not allowed and Robert
> > wanted to change RFC2822. Now I realise that you can have
> header field
> > values with quoted string. Therefore I support the correction that
> > Robert is proposing.
> >   =20
> >     Hisham
> >   =20
> >   =20
> >     On 21/11/2007, Hisham Khartabil 
> > wrote:
> >
> >             This is a big change if we do adopt it. It will
> cause a lot of
> > problem to parsers that handle extenion headers today and is not
> > backwards compatible. Why isn't the extension header as is defined
> > today not sufficient?
> >                           =20
> >             Hisham
> >           =20
> >           =20
> >                                             On 20/11/2007, Robert
> > Sparks  wrote:
> >
> >                     The BNF in 3261 says the following:
> >                   =20
> >                     extension-header  =3D  header-name HCOLON
> header-value
> >                     header-value      =3D  *(TEXT-UTF8char / =
UTF8-CONT
> > / LWS)
> >                   =20
> >                     This is intended to be the catch-all
> field for all future
> > extensions
> >                     - older parsers working against this
> BNF shouldn't barf
> >                     when we introduce a new header field.
> >                   =20
> >                     Now, we may have new fields in the
> future that look like:
> >                   =20
> >                     NewHeader =3D new-header-name HCOLON =
quoted-string
> >                   =20
> >                     And down inside quoted-string, we get:
> >                   =20
> >                           quoted-string  =3D  SWS DQUOTE
> *(qdtext / quoted-pair ) DQUOTE
> >                           qdtext         =3D  LWS / %x21 / %x23-5B /
> > %x5D-7E
> >                                             / UTF8-NONASCII
> >                           quoted-pair  =3D  "\" (%x00-09 / %x0B-0C
> >                                            / %x0E-7F)
> >                   =20
> >                     So, for instance, we could have inside
> a quoted string the 2 byte
> >                     sequence \ NULL
> >                   =20
> >                     This does not parse against
> header-value above...
> >                   =20
> >                     Is this a problem? Some of the SIPit21
> participants argued that it
> > is.
> >                   =20
> >                     The projects I've been involved in
> don't parse unknown headers and
> >                     the stacks will just hand up an
> unparsed bucket of bits (the only
> > rules
> >                     used are those necessary to identify
> the next header-field
> > starting).
> >                   =20
> >                     Would it be worth the effort to make
> the BNF reflect that rather
> > than
> >                     continuing with the incongruity that we
> currently specify?
> >                   =20
> >                     RjS
> >                   =20
> >                   =20
> >                     _______________________________________________
> >                     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
> >                   =20
> >
> >
> >           =20
>
>


_______________________________________________
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




_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 12:46:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iutf5-0004VU-GK; Wed, 21 Nov 2007 12:46:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iutf4-0004VO-0L
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:46:54 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iutf3-0004VF-I8
	for sip@ietf.org; Wed, 21 Nov 2007 12:46:53 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iutez-0001im-5o
	for sip@ietf.org; Wed, 21 Nov 2007 12:46:53 -0500
Received: from rly27f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly27f.srv.mailcontrol.com (MailControl) with ESMTP id
	lALHkbqf002005 for ; Wed, 21 Nov 2007 17:46:48 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly27f.srv.mailcontrol.com (MailControl) id lALHjdMu026300
	for sip@ietf.org; Wed, 21 Nov 2007 17:45:39 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12])
	by rly27f-eth0.srv.mailcontrol.com (envelope-sender
	attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id
	lALHjUID024310; Wed, 21 Nov 2007 17:45:39 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by
	exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 17:45:08 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Can atransactionstatelessproxysupportOutbounddraft?Ifyes,
	how will the responsebe sentback theUAbehind NAT
Date: Wed, 21 Nov 2007 17:44:26 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60AE76EC@EXVS02.nasstar-t1.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Can atransactionstatelessproxysupportOutbounddraft?Ifyes,
	how will the responsebe sentback theUAbehind NAT
Thread-Index: AcgroXKXKmqwJ/hzSsCC4V3n2FFMRwADka/z
References: <680808427CF931459462C3D78CB5EC60AE6AF9@EXVS02.nasstar-t1.net>
	<20071120201414.rlay7fshwkssoo0w@horde-intra.tml.hut.fi>
From: "Attila Sipos" 
To: 
X-OriginalArrivalTime: 21 Nov 2007 17:45:08.0761 (UTC)
	FILETIME=[421E0890:01C82C66]
X-Scanned-By: MailControl A-08-00-01 (www.mailcontrol.com) on 10.70.1.137
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03c3fc09de985df221a4ba6d13d99161
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1347361603=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1347361603==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82C66.420C4535"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82C66.420C4535
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>>  I don't know how to answer where the flow token should be stored in=20
>>the UA. I did not studied about the UA details.

rfc 3327 talks about the Path header as a way for REGISTRARs to work out
the path
back to a UA. It also says that the UA can check the Path header to make
sure that undesirable proxies don't insert themselves in the route.
The Path, like Record-Route, is reflected back so this can be stored by
the UA.
There is nowhere I know which says the UA must store it but it would
seem
useful to do so.
=20
=20
>>>> So, I'm a bit confused.  Is there a problem with using the
>>>> flow token in the Via or not?  I think the answer is no.
>>
>>  I think that NO if we do as we propose.
>>
>>  And Yes, it is a problem if we limit only to the draft because the=20
>>draft does not say anything explicitly about
>>1) In the UA: storing the flow-token in the UA
>>2) In the UA: putting the flow token in the Route header if the flow=20
>>is used for outgoing requests
>>3) In the Ed.proxy : copying the flow token to the Via header.

=20
I agree, you need to do extra things (more than what the
draft specified) but this is fine.
All the proposed actions are transparent to the UA's below and
transparent to the proxies above.  So it cannot break anything.
=20
=20
=20
>>  One problem that I see generating the flow token at any time is=20
>>about the proxy rebooting; it will generate a flow token for a non=20
>>existent flow (although this issue is for discussing hours, because=20
>>depending on the implementation and protocols one can argue that if=20
>>the edge proxy rebooted, the UAC can no longer use the flow because it

>>disappeared.).=20
=20
I don't think there's much you can do.  Except realise that the flow
token
is stale since the proxy rebooted.  One would have to wait
for the flow to get re-established to get successful routing.
=20
>>Anyway the most important characteristic of our=20
>>approach is that the edge proxy can know that what arrives comes from=20
>>an outbound flow and then have a criteria to determine that the Via=20
>>header must have a flow token. Nevertheless I recognize that the=20
>>discussion is not complete. The edge proxy must have some kind of=20
>>mapping between the flow-tokens and socket descriptors that we did not

>>discuss..
=20
I thought we did discuss that the mapping is effectively stored in the
flow token.
=20

>>  After all these discussions we should remember that in fact the=20
>>draft does not discusses about using a flow for outbound requests; and

>>that a UAC can always avoid using the flow for outgoing requests just=20
>>by using the traditional approach (the UAC is behind the NAT and is=20
>>free to form any number of connections independent of outbound flows)

=20
Yes.  The UAC could send a request without using the flow.  I wonder
how often this happens.
=20
This discussion has certainly raised lots of questions.
=20
Regards,
Attila
=20


________________________________

From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
Sent: Tue 20/11/2007 18:14
To: Attila Sipos
Cc: sip@ietf.org
Subject: RE: [Sip] Can
atransactionstatelessproxysupportOutbounddraft?Ifyes, how will the
responsebe sentback theUAbehind NAT







>>>   Our approach tries to use the flow token also in responses: we
just
>>> put the flow token in the Via. As mentioned before:
>>>   -the UA stores the flow token when it receives a 200 OK after
> REGISTER;
>
> So the flow token is stored in the UA's route set?


  I don't know how to answer where the flow token should be stored in=20
the UA. I did not studied about the UA details.
  We consider that the Edge Proxy is stateless but UACs are stateful.
  We assume that in an UAC  every flow will be associated to a=20
transaction and the transaction can store the flow token.
  We did not research about the UAC storing the flow token; so any=20
comments about  feasibility are welcome.

>
>>>   -then it puts it into every SIP request that is sent over a flow;
>
> So it goes into the Route headers.

Yes


> But you challenged that with this problem:
>>> Here is the issue : From were you get the flow token?
>>> (In my previous email I mentioned 2 options... )
>
> So, I'm a bit confused.  Is there a problem with using the
> flow token in the Via or not?  I think the answer is no.



  I think that NO if we do as we propose.

  And Yes, it is a problem if we limit only to the draft because the=20
draft does not say anything explicitly about
1) In the UA: storing the flow-token in the UA
2) In the UA: putting the flow token in the Route header if the flow=20
is used for outgoing requests
3) In the Ed.proxy : copying the flow token to the Via header.

  This is the approach we propose.


  It could be suggested that since the origin IP and port and so on=20
are known in the Edge Proxy, the flow token can be generated at any=20
time when request arrives.

  I don't know way we did not discuss this option before (our approach=20
was storing the flow token in the UA and your approach was retrieving=20
it from the registrar).

  One problem that I see generating the flow token at any time is=20
about the proxy rebooting; it will generate a flow token for a non=20
existent flow (although this issue is for discussing hours, because=20
depending on the implementation and protocols one can argue that if=20
the edge proxy rebooted, the UAC can no longer use the flow because it=20
disappeared.). Anyway the most important characteristic of our=20
approach is that the edge proxy can know that what arrives comes from=20
an outbound flow and then have a criteria to determine that the Via=20
header must have a flow token. Nevertheless I recognize that the=20
discussion is not complete. The edge proxy must have some kind of=20
mapping between the flow-tokens and socket descriptors that we did not=20
discuss... we sent to publish an abstract proposing a solution at=20
application level about this issue.

  After all these discussions we should remember that in fact the=20
draft does not discusses about using a flow for outbound requests; and=20
that a UAC can always avoid using the flow for outgoing requests just=20
by using the traditional approach (the UAC is behind the NAT and is=20
free to form any number of connections independent of outbound flows)

Sergio



Quoting Attila Sipos :

>>>   Our approach tries to use the flow token also in responses: we
just
>>> put the flow token in the Via. As mentioned before:
>>>   -the UA stores the flow token when it receives a 200 OK after
> REGISTER;
>
> So the flow token is stored in the UA's route set?
>
>>>   -then it puts it into every SIP request that is sent over a flow;
>
> So it goes into the Route headers.
>
>>>   -then the edge proxy copies the flow token to the URI part of the
> Via
>>> when it composes the Via before to forward the message.
> ok
>
>>>   -Later, when the response arrives at the edge proxy, it tries to
>>> decode the flow token in the Via, if it succeeds, it  forwards the
>>> response over the flow indicated in the flow token.
>
> yes, looks good to me.
>
>>>   At what moment you generate the "branch flow token"
>>> (for example, when the Via is created?)
>
> yes, that was the idea.
>
>>>   I can not understand completely the idea, from my point of view
>>> it is easier to use the same flow token. Considering that the flow
>>> token considers the reboot, why it could be an advantage to use the
>>> "branch flow token" instead of the flow-token ?
>
> Well that's what I had thought originally (that it is
> easier to use the same flow token).
>
> In an earlier e-mail, I had said:
>>> 3.
>>>> In the Via header's branch parameter, it would encode the required
>>>> flow token.
>>>
>
> But you challenged that with this problem:
>>> Here is the issue : From were you get the flow token?
>>> (In my previous email I mentioned 2 options... )
>
> So, I'm a bit confused.  Is there a problem with using the
> flow token in the Via or not?  I think the answer is no.
>
> Anyway, the conclusion is this:
>  "Yes, it is possible for a transaction-stateless proxy
>  to support the outbound draft".
>
> Regards,
>
> Attila
>
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: 19 November 2007 22:02
> To: Attila Sipos
> Cc: sip@ietf.org
> Subject: RE: [Sip] Can a
> transactionstatelessproxysupportOutbounddraft?Ifyes, how will the
> response be sentback theUAbehind NAT
>
>
>
> Hi,
>
>
>> I feel this would not be a problem for a stateless proxy providing
>> that it is not just a raw socket descriptor id that is passed to the
>> registrar.  The branch parameter in the Via would need some kind of
>> hashed/encrypted "reboot count" parameter as well as the socket id.
>> Then if the edge-proxy rebooted, it would know that the response
>> coming back is stale.  There are many ways to do the
>> hashing/encryption - you could use a method similar to that used in
>> the gruu draft Appendix A.2.
>>
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-
>> 15
>> .txt
>
>    In outbound 10, 5.2.  Generating Flow Tokens :
>
> "When the proxy boots it selects a 20-octet crypto
>         random key called K that only the Edge Proxy knows."
>
>
>    Instead to using the 'reboot count', the approach mentioned in the
> draft already considers the case of old flow tokens that can remain
> stored in the registrar by using a different key every time the proxy
> reboots.
>
>
>
>> So the Via header's branch parameter would contain encoded
information
>
>> about:
>> 1. the flow back to the UA (socket id, IP, port) 2. the reboot count
>
>    Our approach tries to use the flow token also in responses: we just
> put the flow token in the Via. As mentioned before:
>    -the UA stores the flow token when it receives a 200 OK after
> REGISTER;
>    -then it puts it into every SIP request that is sent over a flow;
>    -then the edge proxy copies the flow token to the URI part of the
Via
> when it composes the Via before to forward the message.
>    -Later, when the response arrives at the edge proxy, it tries to
> decode the flow token in the Via, if it succeeds, it  forwards the
> response over the flow indicated in the flow token.
>
>
>> So my proposal is generating some kind of flow token (but not THE
same
>
>> "flow token"as used in the REGISTER).  So there is the "flow token"
as
> described in
>> theoutbound draft and now there is also a "branch flow token" that I
>> am
> ?proposing.
>
>    Perhaps can be a possible solution but seems complex.
>    At what moment you generate the "branch flow token" (for example,
> when the Via is created?)
>    I can not understand completely the idea, from my point of view it
is
> easier to use the same flow token. Considering that the flow token
> considers the reboot, why it could be an advantage to use the "branch
> flow token" instead of the flow-token ?
>
>
> Regards,
>
> Sergio
>
> Quoting Attila Sipos :
>
>>
>>>>  The problem with the above (separated elements) is that there is
>>>> not synchronization about the state of the socket descriptors. As
>> mentioned
>>>> before, if the edge proxy crashes the socket descriptors used
>> immediately
>>>> after reboot could result in delivering messages to different
flows.
>>>>
>>>>  In my opinion the randomness included in the flow token avoids
that
>> to
>>>> happen, since after reboot the flowtoken can not be decoded and/or
>> find an
>>>> existing flow and that cause the return a error response.
>>
>>
>> Yes, absolutely.  And this is a problem with stateful proxies too.
>>
>> I have agreed with everything you've said.
>> However, I still think there is a way to do an outbound-compatible
>> edge proxy with a transaction-stateless/call-stateless proxy.
>>
>> So I now go back to say something similar to what I said before.
>> But first, I will refer to something you said in an earlier mail:
>>
>>>>  Furthermore my registrar should not store socket descriptors due
>>>> that if the edge proxy crashes, the registrar could have a number
of
>
>>>> descriptor that after the crash belong to other flows.
>>
>> I feel this would not be a problem for a stateless proxy providing
>> that it is not just a raw socket descriptor id that is passed to the
>> registrar.  The branch parameter in the Via would need some kind of
>> hashed/encrypted "reboot count" parameter as well as the socket id.
>> Then if the edge-proxy rebooted, it would know that the response
>> coming back is stale.  There are many ways to do the
>> hashing/encryption - you could use a method similar to that used in
>> the gruu draft Appendix A.2.
>>
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-
>> 15
>> .txt
>>
>> So the Via header's branch parameter would contain encoded
information
>
>> about:
>> 1. the flow back to the UA (socket id, IP, port) 2. the reboot count
>>
>> So now I go back to something else you said:
>>>> 2) generate again the flow token for every request (very bad from
>>>> security point of views) and destroys the consistency of the system
>>>> since you can send requests for non existing flows. Note that the
>>>> draft mentions that the flow and the flow token is only created
with
>> REGISTERs.
>>
>> So my proposal is generating some kind of flow token (but not THE
same
>
>> "flow token"
>> as used in the REGISTER).  So there is the "flow token" as described
>> in the outbound draft and now there is also a "branch flow token"
that
>
>> I am proposing.
>> And, as explained before, the information in the "branch flow token"
>> is used to route responses back to the UA.  But the original "flow
>> token" is never changed.
>> The original "flow token" would still be used when forwarding
requests
>
>> to the UA because the Edge Proxy (in your diagram) would've added it
>> to the Path.  So requests to the UA would still work.
>>
>> Now I'm not sure about the security aspects.
>> What security problems could there be with "branch flow token" idea?
>>
>> Regards,
>> Attila
>>
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: 16 November 2007 15:53
>> To: Attila Sipos
>> Subject: RE: [Sip] Can a transaction
>> statelessproxysupportOutbounddraft?Ifyes, how will the response be
>> sent back theUAbehind NAT
>>
>>
>>
>>> I am starting to see the problems.
>>>
>>> If I understand correctly, your scenario is this...
>>>
>>> REGISTRAR--------PROXY----------NAT---------SIP UA
>>>
>>> Can you confirm?
>>
>> more specifically my scenario is
>>
>> REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA
>>
>>
>> where PROXY is a traditional SIP proxy
>>
>>
>>> And, since you were talking about scalability, you might also have
>>> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>>>
>>> is this right?
>>
>>
>>   About scalability I was thinking about
>>
>>
>>                         /EDGEPROXY1\
>> REGISTRAR/PROXY--------            ----------NAT---------SIP UA
>>                         \EDGEPROXY2/
>>
>>
>>   So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.
>>
>>
>>   I have no experience with registrars, I guess that in your case you
>> have a REGISTRAR/EDGEPROXY in the same process (or group of
processes)
>
>> and not REGISTRAR--------EDGEPROXY (linked by other means).
>>
>>   The problem with the above (separated elements) is that there is
not
>
>> synchronization about the state of the socket descriptors. As
>> mentioned before, if the edge proxy crashes the socket descriptors
>> used immediately after reboot could result in delivering messages to
>> different flows.
>>
>>   In my opinion the randomness included in the flow token avoids that
>> to happen, since after reboot the flowtoken can not be decoded and/or
>> find an existing flow and that cause the return a error response.
>>   Then another entry in the registrar binding will be used, i.e.
other
>
>> flow token. If you have a second edge proxy (that does not crashed at
>> the same time that the first one :) and the flow token belongs to the
>> second edge proxy, the message will reach the UA over a flow
>> previously established to the second edge proxy.
>>
>>
>>
>> BR
>>
>> Sergio
>>
>>
>> Quoting Attila Sipos :
>>
>>>
>>>
>>>>>>>> 3.
>>>>>>>>> In the Via header's branch parameter, it would encode the
>>> required
>>>>>>>>> flow token.
>>>>>>>>
>>>>>>>> Here is the issue : From were you get the flow token?
>>>>>>>> (In my previous email I mentioned 2 options... )
>>>>>>>>
>>>>>>
>>>>>> OK I'm starting to see your problem.
>>>>>>
>>>>>> The registration record stores the flow token (obviously)
>>>>>
>>>>> It seems that you are integrating the edge proxy and registrar in
>>>>> the
>>> same code, right?
>>>
>>> yes, that's it.
>>>
>>>
>>>>>> And the socket id for the flow would be stored as well (for
>>>>>
>>>>> Can you confirm that you call socket id to the socket/file
>>>>> descriptor
>>> of the connection?
>>>
>>> yes.
>>>
>>>>>> connection-oriented
>>>>>> protocols). So if you received a request on that socket, you
could
>
>>>>>> match that up to one of the registration records and hence, one
of
>>> the
>>>>>> flow tokens.
>>>>>>
>>>>>
>>>>>  Good approach. I assume that you have available the socket
>>> descriptor
>>>>> in the registrar, so basically you consider storing the socket
>>> descriptor
>>>>> (number) in the registrar tables. Then perhaps using a flow token
>>>>> it
>>> is not
>>>>> necessary since you have available in the socket descriptor all
the
>>> information
>>>>> that describes a flow (TCP case).
>>>
>>> That's true.  I might not need the flow tokens.
>>>
>>>
>>>>>> I hope I have explained how the flow token might be mapped to the
>>>>>> socket.
>>>>>
>>>>>  Yes if my comments above make sense..
>>>>>
>>>>>> I can now see that my idea wouldn't work for UDP.
>>>>>
>>>>>  Now for UDP perhaps you can consider storing the socket
descriptor
>>> for
>>>>> UDP and the IP and port for the flow from the NAT.
>>>
>>> yes, that would work I think.
>>>
>>>
>>>>>  Furthermore my registrar should not store socket descriptors due
>>> that
>>>>> if the edge proxy crashes, the registrar could have a number of
>>> descriptor
>>>>> that after the crash belong to other flows.
>>>>>
>>>>>  I generate the flow token with REGISTER and send it to the
>>>>> registrar (other node). The approach works as the draft says for
>>>>> incoming
>>> requests
>>>>> (to the Calle). Now when the Callee  sends requests, and the
>>>>> requests
>>> are
>>>>> sent over the flow, the responses of that request reach first the
>>>>> edge
>>> proxy
>>>>> and it can not forward them to the Callee over the flow, because
>>>>> these responses don't have the flow token (and the flow token is
>>>>> not
>>
>>>>> stored
>>> in
>>>>> the edge proxy)...
>>>
>>> I am starting to see the problems.
>>>
>>> If I understand correctly, your scenario is this...
>>>
>>> REGISTRAR--------PROXY----------NAT---------SIP UA
>>>
>>> Can you confirm?
>>>
>>> And, since you were talking about scalability, you might also have
>>> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>>>
>>> is this right?
>>>
>>>
>>>>>> But what if you used the gruu in the contact to match up with the
>>> gruu
>>>>>> of a registration?  Then the registration record tells tells you
>>> about
>>>>>> the flow token.  That would work wouldn't it?
>>>>>
>>>>>  I have not background with gruu. Could you recommend what could I
>>> read about it?
>>>
>>> Sorry, I didn't mean gruu, I was mixing up my drafts!
>>> I was just looking for a unique identifier for the UA which is the
>>> sip.instance from the outbound draft (not gruu).
>>>
>>>
>>> Regards,
>>> Attila
>>>
>>
>>
>>
>
>
>
>






------_=_NextPart_001_01C82C66.420C4535
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


RE: [Sip] Can =
atransactionstatelessproxysupportOutbounddraft?Ifyes, how will the =
responsebe sentback theUAbehind NAT






>> =20
I don't know how to answer where the flow token should be stored=20
in 
>>the UA. I did not studied about the UA=20
details.


rfc 3327 talks=20
about the Path header as a way for REGISTRARs to work out the=20
path


back to a UA. It also says that the UA can =
check the=20
Path header to make


sure that undesirable proxies don't insert =
themselves=20
in the route.


The Path, like Record-Route, is reflected =
back so=20
this can be stored by the=20
UA.


There is nowhere I know which says the UA =
must store=20
it but it would seem


useful to do so.


 


 


>>>> So, I'm a bit confused.  =
Is there a=20
problem with using the
>>>> flow token in the Via or =
not?  I=20
think the answer is no.
>>


>> =20
I think that NO if we do as we propose.
>>
>>  =
And Yes,=20
it is a problem if we limit only to the draft because =
the 
>>draft=20
does not say anything explicitly about
>>1) In the UA: storing =
the=20
flow-token in the UA
>>2) In the UA: putting the flow token in =
the=20
Route header if the flow 
>>is used for outgoing=20
requests
>>3) In the Ed.proxy : copying the flow token to the =
Via=20
header.


 


I agree, you=20
need to do extra things (more than what the


draft=20
specified) but this is fine.


All the proposed actions are =
transparent to=20
the UA's below and


transparent to the =
proxies=20
above.  So it cannot break=20
anything.


 


 


 


>>  One problem that I see =
generating=20
the flow token at any time is 
>>about the proxy rebooting; it =
will=20
generate a flow token for a non 
>>existent flow (although this =
issue is=20
for discussing hours, because 
>>depending on the =
implementation and=20
protocols one can argue that if 
>>the edge proxy rebooted, the =
UAC can no=20
longer use the flow because it 
>>disappeared.).=20



 


I don't =
think there's=20
much you can do.  Except realise that the flow =
token


is stale =
since the=20
proxy rebooted.  One would have to wait


for =
the flow to get re-established to get =
successful=20
routing.


 


>>Anyway the most important characteristic =
of=20
our 
>>approach is that the edge proxy can know =
that what=20
arrives comes from 
>>an outbound flow and then have a criteria =
to=20
determine that the Via 
>>header must have a flow token. =
Nevertheless I=20
recognize that the 
>>discussion is not complete. The edge =
proxy must=20
have some kind of 
>>mapping between the flow-tokens and =
socket=20
descriptors that we did not 
>>discuss..


 


I=20
thought we did discuss that the mapping is effectively stored in the =
flow=20
token.


 



>>  After all these =
discussions we=20
should remember that in fact the 
>>draft does not discusses about =
using a=20
flow for outbound requests; and 
>>that a UAC can always avoid =
using the=20
flow for outgoing requests just 
>>by using the traditional =
approach (the=20
UAC is behind the NAT and is 
>>free to form any number of =
connections=20
independent of outbound flows)


 


Yes. =20
The UAC could send a request without using the flow.  I=20
wonder


how often=20
this happens.


 


This=20
discussion has certainly raised lots of questions.


 


Regards,


Attila


 






From: sergiole@tml.hut.fi=20
[mailto:sergiole@tml.hut.fi]
Sent: Tue 20/11/2007 =
18:14
To:=20
Attila Sipos
Cc: sip@ietf.org
Subject: RE: [Sip] Can =

atransactionstatelessproxysupportOutbounddraft?Ifyes, how will the =
responsebe=20
sentback theUAbehind NAT








>>>   Our approach tries to use the =
flow=20
token also in responses: we just
>>> put the flow token in =
the Via.=20
As mentioned before:
>>>   -the UA stores the flow =
token=20
when it receives a 200 OK after
> REGISTER;
>
> So the =
flow=20
token is stored in the UA's route set?


  I don't know =
how to=20
answer where the flow token should be stored in 
the UA. I did =
not=20
studied about the UA details.
  We consider that the Edge Proxy =
is=20
stateless but UACs are stateful.
  We assume that in an =
UAC  every=20
flow will be associated to a 
transaction and the transaction =
can store=20
the flow token.
  We did not research about the UAC storing the =
flow=20
token; so any 
comments about  feasibility are=20
welcome.

>
>>>   -then it puts it into =
every SIP=20
request that is sent over a flow;
>
> So it goes into the =
Route=20
headers.

Yes


> But you challenged that with this=20
problem:
>>> Here is the issue : From were you get the flow=20
token?
>>> (In my previous email I mentioned 2 options...=20
)
>
> So, I'm a bit confused.  Is there a problem with =
using=20
the
> flow token in the Via or not?  I think the answer is=20
no.



  I think that NO if we do as we =
propose.

 =20
And Yes, it is a problem if we limit only to the draft because=20
the 
draft does not say anything explicitly about
1) In the =
UA:=20
storing the flow-token in the UA
2) In the UA: putting the flow token =
in the=20
Route header if the flow 
is used for outgoing requests
3) In =
the=20
Ed.proxy : copying the flow token to the Via header.

  This =
is the=20
approach we propose.


  It could be suggested that since =
the=20
origin IP and port and so on 
are known in the Edge Proxy, the =
flow=20
token can be generated at any 
time when request =
arrives.

 =20
I don't know way we did not discuss this option before (our=20
approach 
was storing the flow token in the UA and your approach =
was=20
retrieving 
it from the registrar).

  One problem =
that I see=20
generating the flow token at any time is 
about the proxy =
rebooting; it=20
will generate a flow token for a non 
existent flow (although =
this issue=20
is for discussing hours, because 
depending on the =
implementation and=20
protocols one can argue that if 
the edge proxy rebooted, the =
UAC can no=20
longer use the flow because it 
disappeared.). Anyway the most =
important=20
characteristic of our 
approach is that the edge proxy can know =
that=20
what arrives comes from 
an outbound flow and then have a =
criteria to=20
determine that the Via 
header must have a flow token. =
Nevertheless I=20
recognize that the 
discussion is not complete. The edge proxy =
must have=20
some kind of 
mapping between the flow-tokens and socket =
descriptors=20
that we did not 
discuss... we sent to publish an abstract =
proposing a=20
solution at 
application level about this issue.

  =
After all=20
these discussions we should remember that in fact the 
draft =
does not=20
discusses about using a flow for outbound requests; and 
that a =
UAC can=20
always avoid using the flow for outgoing requests just 
by using =
the=20
traditional approach (the UAC is behind the NAT and is 
free to =
form any=20
number of connections independent of outbound=20
flows)

Sergio



Quoting Attila Sipos=20
<attila.sipos@vegastream.com>:

>>>   Our =

approach tries to use the flow token also in responses: we =
just
>>>=20
put the flow token in the Via. As mentioned =
before:
>>>  =20
-the UA stores the flow token when it receives a 200 OK after
>=20
REGISTER;
>
> So the flow token is stored in the UA's route=20
set?
>
>>>   -then it puts it into every SIP =
request=20
that is sent over a flow;
>
> So it goes into the Route=20
headers.
>
>>>   -then the edge proxy copies =
the=20
flow token to the URI part of the
> Via
>>> when it =
composes=20
the Via before to forward the message.
>=20
ok
>
>>>   -Later, when the response arrives =
at the=20
edge proxy, it tries to
>>> decode the flow token in the =
Via, if it=20
succeeds, it  forwards the
>>> response over the flow =
indicated=20
in the flow token.
>
> yes, looks good to=20
me.
>
>>>   At what moment you generate the =
"branch=20
flow token"
>>> (for example, when the Via is=20
created?)
>
> yes, that was the=20
idea.
>
>>>   I can not understand =
completely the=20
idea, from my point of view
>>> it is easier to use the same =
flow=20
token. Considering that the flow
>>> token considers the =
reboot, why=20
it could be an advantage to use the
>>> "branch flow token" =
instead=20
of the flow-token ?
>
> Well that's what I had thought =
originally=20
(that it is
> easier to use the same flow token).
>
> =
In an=20
earlier e-mail, I had said:
>>> 3.
>>>> In =
the Via=20
header's branch parameter, it would encode the =
required
>>>> flow=20
token.
>>>
>
> But you challenged that with this =

problem:
>>> Here is the issue : From were you get the flow=20
token?
>>> (In my previous email I mentioned 2 options...=20
)
>
> So, I'm a bit confused.  Is there a problem with =
using=20
the
> flow token in the Via or not?  I think the answer is=20
no.
>
> Anyway, the conclusion is this:
>  "Yes, =
it is=20
possible for a transaction-stateless proxy
>  to support the =
outbound=20
draft".
>
> Regards,
>
> =
Attila
>
>
>=20
-----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
&g=
t; Sent:=20
19 November 2007 22:02
> To: Attila Sipos
> Cc: =
sip@ietf.org
>=20
Subject: RE: [Sip] Can a
>=20
transactionstatelessproxysupportOutbounddraft?Ifyes, how will =
the
>=20
response be sentback theUAbehind NAT
>
>
>
>=20
Hi,
>
>
>> I feel this would not be a problem for a =

stateless proxy providing
>> that it is not just a raw socket=20
descriptor id that is passed to the
>> registrar.  The =
branch=20
parameter in the Via would need some kind of
>> =
hashed/encrypted=20
"reboot count" parameter as well as the socket id.
>> Then if =
the=20
edge-proxy rebooted, it would know that the response
>> coming =
back is=20
stale.  There are many ways to do the
>> =
hashing/encryption - you=20
could use a method similar to that used in
>> the gruu draft =
Appendix=20
A.2.
>> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-g=
ruu-
>>=20
15
>> .txt
>
>    In outbound 10, =
5.2. =20
Generating Flow Tokens :
>
> "When the proxy boots it =
selects a=20
20-octet crypto
>         =
random=20
key called K that only the Edge Proxy=20
knows."
>
>
>    Instead to using the =
'reboot=20
count', the approach mentioned in the
> draft already considers =
the case=20
of old flow tokens that can remain
> stored in the registrar by =
using a=20
different key every time the proxy
>=20
reboots.
>
>
>
>> So the Via header's branch=20
parameter would contain encoded information
>
>>=20
about:
>> 1. the flow back to the UA (socket id, IP, port) 2. =
the=20
reboot count
>
>    Our approach tries to use =
the=20
flow token also in responses: we just
> put the flow token in the =
Via. As=20
mentioned before:
>    -the UA stores the flow =
token when=20
it receives a 200 OK after
> REGISTER;
>    =
-then it=20
puts it into every SIP request that is sent over a=20
flow;
>    -then the edge proxy copies the flow =
token to=20
the URI part of the Via
> when it composes the Via before to =
forward the=20
message.
>    -Later, when the response arrives at =
the edge=20
proxy, it tries to
> decode the flow token in the Via, if it =
succeeds,=20
it  forwards the
> response over the flow indicated in the =
flow=20
token.
>
>
>> So my proposal is generating some =
kind of=20
flow token (but not THE same
>
>> "flow token"as used in =
the=20
REGISTER).  So there is the "flow token" as
> described=20
in
>> theoutbound draft and now there is also a "branch flow =
token"=20
that I
>> am
> =
?proposing.
>
>   =20
Perhaps can be a possible solution but seems =
complex.
>   =20
At what moment you generate the "branch flow token" (for =
example,
> when=20
the Via is created?)
>    I can not understand =
completely=20
the idea, from my point of view it is
> easier to use the same =
flow token.=20
Considering that the flow token
> considers the reboot, why it =
could be an=20
advantage to use the "branch
> flow token" instead of the =
flow-token=20
?
>
>
> Regards,
>
> =
Sergio
>
>=20
Quoting Attila Sipos=20
<attila.sipos@vegastream.com>:
>
>>
>>>&=
gt; =20
The problem with the above (separated elements) is that there=20
is
>>>> not synchronization about the state of the socket =

descriptors. As
>> mentioned
>>>> before, if the =
edge=20
proxy crashes the socket descriptors used
>>=20
immediately
>>>> after reboot could result in delivering =
messages=20
to different flows.
>>>>
>>>>  In my =
opinion=20
the randomness included in the flow token avoids that
>>=20
to
>>>> happen, since after reboot the flowtoken can not =
be=20
decoded and/or
>> find an
>>>> existing flow and =
that=20
cause the return a error response.
>>
>>
>> =
Yes,=20
absolutely.  And this is a problem with stateful proxies=20
too.
>>
>> I have agreed with everything you've=20
said.
>> However, I still think there is a way to do an=20
outbound-compatible
>> edge proxy with a=20
transaction-stateless/call-stateless proxy.
>>
>> So I =
now go=20
back to say something similar to what I said before.
>> But =
first, I=20
will refer to something you said in an earlier=20
mail:
>>
>>>>  Furthermore my registrar =
should not=20
store socket descriptors due
>>>> that if the edge proxy =
crashes,=20
the registrar could have a number of
>
>>>> =
descriptor that=20
after the crash belong to other flows.
>>
>> I feel =
this would=20
not be a problem for a stateless proxy providing
>> that it is =
not just=20
a raw socket descriptor id that is passed to the
>> =
registrar. =20
The branch parameter in the Via would need some kind of
>>=20
hashed/encrypted "reboot count" parameter as well as the socket =
id.
>>=20
Then if the edge-proxy rebooted, it would know that the =
response
>>=20
coming back is stale.  There are many ways to do the
>>=20
hashing/encryption - you could use a method similar to that used =
in
>>=20
the gruu draft Appendix A.2.
>> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-g=
ruu-
>>=20
15
>> .txt
>>
>> So the Via header's branch =
parameter=20
would contain encoded information
>
>> about:
>> =
1. the=20
flow back to the UA (socket id, IP, port) 2. the reboot=20
count
>>
>> So now I go back to something else you=20
said:
>>>> 2) generate again the flow token for every =
request=20
(very bad from
>>>> security point of views) and destroys =
the=20
consistency of the system
>>>> since you can send =
requests for=20
non existing flows. Note that the
>>>> draft mentions =
that the=20
flow and the flow token is only created with
>>=20
REGISTERs.
>>
>> So my proposal is generating some =
kind of=20
flow token (but not THE same
>
>> "flow =
token"
>> as=20
used in the REGISTER).  So there is the "flow token" as=20
described
>> in the outbound draft and now there is also a =
"branch flow=20
token" that
>
>> I am proposing.
>> And, as =
explained=20
before, the information in the "branch flow token"
>> is used =
to route=20
responses back to the UA.  But the original "flow
>> =
token" is=20
never changed.
>> The original "flow token" would still be used =
when=20
forwarding requests
>
>> to the UA because the Edge Proxy =
(in=20
your diagram) would've added it
>> to the Path.  So =
requests to=20
the UA would still work.
>>
>> Now I'm not sure about =
the=20
security aspects.
>> What security problems could there be with =
"branch=20
flow token" idea?
>>
>> Regards,
>>=20
Attila
>>
>>
>> -----Original=20
Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
&g=
t;>=20
Sent: 16 November 2007 15:53
>> To: Attila Sipos
>> =
Subject:=20
RE: [Sip] Can a transaction
>>=20
statelessproxysupportOutbounddraft?Ifyes, how will the response =
be
>>=20
sent back theUAbehind =
NAT
>>
>>
>>
>>> I=20
am starting to see the problems.
>>>
>>> If I =
understand=20
correctly, your scenario is this...
>>>
>>>=20
REGISTRAR--------PROXY----------NAT---------SIP=20
UA
>>>
>>> Can you =
confirm?
>>
>> more=20
specifically my scenario is
>>
>>=20
REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP=20
UA
>>
>>
>> where PROXY is a traditional SIP=20
proxy
>>
>>
>>> And, since you were =
talking about=20
scalability, you might also have
>>>=20
REGISTRAR--------PROXY--------PROXY----------NAT---------SIP=20
UA
>>>
>>> is this=20
right?
>>
>>
>>   About scalability =
I was=20
thinking=20
about
>>
>>
>>     &n=
bsp;           &nb=
sp;      =20
/EDGEPROXY1\
>>=20
REGISTRAR/PROXY--------        &n=
bsp;  =20
----------NAT---------SIP=20
UA
>>          =
;            =
  =20
\EDGEPROXY2/
>>
>>
>>   So that the =
UA has=20
flows to EDGEPROXY1 and=20
EDGEPROXY2.
>>
>>
>>   I have no =
experience=20
with registrars, I guess that in your case you
>> have a=20
REGISTRAR/EDGEPROXY in the same process (or group of=20
processes)
>
>> and not REGISTRAR--------EDGEPROXY =
(linked by=20
other means).
>>
>>   The problem with the =
above=20
(separated elements) is that there is not
>
>> =
synchronization=20
about the state of the socket descriptors. As
>> mentioned =
before, if=20
the edge proxy crashes the socket descriptors
>> used =
immediately after=20
reboot could result in delivering messages to
>> different=20
flows.
>>
>>   In my opinion the randomness =
included=20
in the flow token avoids that
>> to happen, since after reboot =
the=20
flowtoken can not be decoded and/or
>> find an existing flow =
and that=20
cause the return a error response.
>>   Then another =
entry in=20
the registrar binding will be used, i.e. other
>
>> flow =
token.=20
If you have a second edge proxy (that does not crashed at
>> =
the same=20
time that the first one :) and the flow token belongs to the
>> =
second=20
edge proxy, the message will reach the UA over a flow
>> =
previously=20
established to the second edge=20
proxy.
>>
>>
>>
>>=20
BR
>>
>> Sergio
>>
>>
>> =
Quoting=20
Attila Sipos=20
<attila.sipos@vegastream.com>:
>>
>>>
>&=
gt;>
>>>>>>>>=20
3.
>>>>>>>>> In the Via header's branch =
parameter,=20
it would encode the
>>>=20
required
>>>>>>>>> flow=20
token.
>>>>>>>>
>>>>>>>=
;>=20
Here is the issue : From were you get the flow=20
token?
>>>>>>>> (In my previous email I =
mentioned 2=20
options...=20
)
>>>>>>>>
>>>>>>
>=
>>>>>=20
OK I'm starting to see your=20
problem.
>>>>>>
>>>>>> The=20
registration record stores the flow token=20
(obviously)
>>>>>
>>>>> It seems =
that you=20
are integrating the edge proxy and registrar in
>>>>>=20
the
>>> same code, right?
>>>
>>> =
yes,=20
that's it.
>>>
>>>
>>>>>> =
And the=20
socket id for the flow would be stored as well=20
(for
>>>>>
>>>>> Can you confirm =
that you=20
call socket id to the socket/file
>>>>>=20
descriptor
>>> of the =
connection?
>>>
>>>=20
yes.
>>>
>>>>>>=20
connection-oriented
>>>>>> protocols). So if you =
received a=20
request on that socket, you could
>
>>>>>> =
match that=20
up to one of the registration records and hence, one of
>>>=20
the
>>>>>> flow=20
tokens.
>>>>>>
>>>>>
>>&g=
t;>> =20
Good approach. I assume that you have available the =
socket
>>>=20
descriptor
>>>>> in the registrar, so basically you =
consider=20
storing the socket
>>> descriptor
>>>>> =
(number)=20
in the registrar tables. Then perhaps using a flow =
token
>>>>>=20
it
>>> is not
>>>>> necessary since you =
have=20
available in the socket descriptor all the
>>>=20
information
>>>>> that describes a flow (TCP=20
case).
>>>
>>> That's true.  I might not =
need the=20
flow tokens.
>>>
>>>
>>>>>> =
I hope=20
I have explained how the flow token might be mapped to=20
the
>>>>>>=20
socket.
>>>>>
>>>>>  Yes if my =
comments=20
above make sense..
>>>>>
>>>>>> I =
can now=20
see that my idea wouldn't work for=20
UDP.
>>>>>
>>>>>  Now for UDP =
perhaps=20
you can consider storing the socket descriptor
>>>=20
for
>>>>> UDP and the IP and port for the flow from =
the=20
NAT.
>>>
>>> yes, that would work I=20
think.
>>>
>>>
>>>>>  =
Furthermore=20
my registrar should not store socket descriptors due
>>>=20
that
>>>>> if the edge proxy crashes, the registrar =
could have=20
a number of
>>> descriptor
>>>>> that =
after the=20
crash belong to other=20
flows.
>>>>>
>>>>>  I generate =
the flow=20
token with REGISTER and send it to the
>>>>> registrar =
(other=20
node). The approach works as the draft says for
>>>>>=20
incoming
>>> requests
>>>>> (to the =
Calle). Now=20
when the Callee  sends requests, and the
>>>>>=20
requests
>>> are
>>>>> sent over the flow, =
the=20
responses of that request reach first the
>>>>>=20
edge
>>> proxy
>>>>> and it can not =
forward them=20
to the Callee over the flow, because
>>>>> these =
responses=20
don't have the flow token (and the flow token is
>>>>> =

not
>>
>>>>> stored
>>>=20
in
>>>>> the edge =
proxy)...
>>>
>>> I=20
am starting to see the problems.
>>>
>>> If I =
understand=20
correctly, your scenario is this...
>>>
>>>=20
REGISTRAR--------PROXY----------NAT---------SIP=20
UA
>>>
>>> Can you=20
confirm?
>>>
>>> And, since you were talking =
about=20
scalability, you might also have
>>>=20
REGISTRAR--------PROXY--------PROXY----------NAT---------SIP=20
UA
>>>
>>> is this=20
right?
>>>
>>>
>>>>>> But =
what if=20
you used the gruu in the contact to match up with the
>>>=20
gruu
>>>>>> of a registration?  Then the =
registration=20
record tells tells you
>>> about
>>>>>> =
the=20
flow token.  That would work wouldn't=20
it?
>>>>>
>>>>>  I have not =
background=20
with gruu. Could you recommend what could I
>>> read about=20
it?
>>>
>>> Sorry, I didn't mean gruu, I was =
mixing up=20
my drafts!
>>> I was just looking for a unique identifier =
for the UA=20
which is the
>>> sip.instance from the outbound draft (not=20
gruu).
>>>
>>>
>>> =
Regards,
>>>=20
Attila
>>>
>>
>>
>>
>
>=
;
>
>





------_=_NextPart_001_01C82C66.420C4535--



--===============1347361603==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1347361603==--





From sip-bounces@ietf.org Wed Nov 21 13:14:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuu69-00063O-SK; Wed, 21 Nov 2007 13:14:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuu67-00061F-Vi
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 13:14:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuu67-000615-Lp
	for sip@ietf.org; Wed, 21 Nov 2007 13:14:51 -0500
Received: from jes-fe1.zx.nl ([194.187.76.132])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuu62-0006MN-Gc
	for sip@ietf.org; Wed, 21 Nov 2007 13:14:51 -0500
Received: from Inbox ([89.205.252.72])
	by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep
	5
	2006)) with ESMTP id <0JRV00ABLC050460@jes-fe1.zx.nl> for sip@ietf.org;
	Wed, 21 Nov 2007 19:14:45 +0100 (CET)
Date: Wed, 21 Nov 2007 19:17:38 +0100
From: Jeroen van Bemmel 
Subject: RE: [Sip] Re: URI comparison rules - IPv6 addresses
To: "Vijay K. Gurbani" ,
	Gonzalo Camarillo 
Message-id: <0JRV00ABOC070460@jes-fe1.zx.nl>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
Importance: normal
X-Priority: 3
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: sip , Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Vijay,
It's not only IPv6: what about 127.0.0.1 versus 127.000.000.1?

Regards,
Jeroen

-----Oorspronkelijk bericht -----
Van: "Vijay K. Gurbani" 
Aan: "Gonzalo Camarillo" 
CC: "sip" ; "Brett Tate" 
Verzonden: 21-11-07 16:37
Onderwerp: [Sip] Re: URI comparison rules - IPv6 addresses

Gonzalo Camarillo wrote:
> Hi,
>=20
> Brett brought this up in the SIP Implementors mailing list. The
> following IPv6 addresses are supposed to be equivalent:
>=20
> [::ffff:192.0.2.128] and [::ffff:c000:280]
> [2001:db8::9:1] and [2001:db8::9:01]
> [0:0:0:0:0:FFFF:129.144.52.38] and [::FFFF:129.144.52.38]
>=20
> Now, let's say I need to compare sip:user1@[::ffff:192.0.2.128] and
> sip:user1@[::ffff:c000:280]. Should we consider these URIs to be
> equivalent or not?
>=20
> My proposal is that we clarify that IPv6 address comparison happens at
> the binary level, not at the textual level. We could log a bug against
> RFC3261, and try and add such a clarification to the IPv6 transition
> document (I will need to ask the ADs whether or not we can add this in
> AUTH48).

Gonzalo: My only concern that I had mentioned to Brett as
well was that this should not be construed as endorsing the
notion of multiple representations of the IPv6 address in
SIP signaling.  This may cause problems in normal SIP operations.

Consider a proxy that uses the sent-by address in a loop detection



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 13:20:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuuBK-0001ow-On; Wed, 21 Nov 2007 13:20:14 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuuBI-0001oh-HK
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 13:20:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuBI-0001oZ-7h
	for sip@ietf.org; Wed, 21 Nov 2007 13:20:12 -0500
Received: from rn-out-0910.google.com ([64.233.170.190]
	helo=rn-out-0102.google.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuuBF-0006Xg-19
	for sip@ietf.org; Wed, 21 Nov 2007 13:20:12 -0500
Received: by rn-out-0102.google.com with SMTP id a46so1698666rne
	for ; Wed, 21 Nov 2007 10:20:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type;
	bh=oDSmySHkUOcbCg3GPDWU8664zrgecho1NN0WaYfKDVw=;
	b=ByXKpMR2yT4eSkKEbx27l+pdEz+vvOguhjrGIlwGZ4EdFrolVzhPmXHEFU6Vdmlb33mrnutK757iJqkA3q60u4ERTa9a/4i9xdSYfJTYUJH4YY8Pxx3ibc9nzVpXpxfzAZ6QYZ2FlhAylCUqF6yIhjmSYjuSnOhS8PKN0oA7/uU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=CDJf9OSVteIPafEwI7q5Aavj0clrxGLWZzMQHIwre+Y6r/voEV6QXQKvD7v14isyvEa5vg3zeEtx6imb0pW7sYdl5is9xFTgDGRnGIO71TjPHcagC9a5fvcSwoIe8Vk0TefAXJxYEvUR0yBxcMBxrppKJ1gEVfLOb3LSgT9PEc8=
Received: by 10.150.202.17 with SMTP id z17mr1391399ybf.1195669208584;
	Wed, 21 Nov 2007 10:20:08 -0800 (PST)
Received: by 10.150.137.19 with HTTP; Wed, 21 Nov 2007 10:20:08 -0800 (PST)
Message-ID: <9d6632e0711211020t15344ca7i11022838e505cdc2@mail.gmail.com>
Date: Wed, 21 Nov 2007 12:20:08 -0600
From: Joe 
To: sip@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [Sip] Errant Proxy Behavior?
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1858520414=="
Errors-To: sip-bounces@ietf.org

--===============1858520414==
Content-Type: multipart/alternative; 
	boundary="----=_Part_5311_27984172.1195669208566"

------=_Part_5311_27984172.1195669208566
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello all,

If a proxy receives a message containing a SIP URI in a Route header that
has "%24" in the user portion (used as part of a token) is it allowed to
modify this to "$", leave the rest untouched, and forward it?

This seems like incorrect behavior.

Thanks!
Joe

------=_Part_5311_27984172.1195669208566
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello all,

If a proxy receives a message containing a SIP URI in a Route header that has "%24" in the user portion (used as part of a token) is it allowed to modify this to "$", leave the rest untouched, and forward it?


This seems like incorrect behavior.

Thanks!
Joe


------=_Part_5311_27984172.1195669208566--



--===============1858520414==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1858520414==--





From sip-bounces@ietf.org Wed Nov 21 14:09:30 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuuwl-0003k6-W4; Wed, 21 Nov 2007 14:09:15 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuuwl-0003jw-6f
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:09:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuuwk-0003jo-TF
	for sip@ietf.org; Wed, 21 Nov 2007 14:09:14 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuuwi-00080N-FK
	for sip@ietf.org; Wed, 21 Nov 2007 14:09:14 -0500
Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net
	[96.226.64.76]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lALJ97Vr020450
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 21 Nov 2007 13:09:08 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <9d6632e0711211020t15344ca7i11022838e505cdc2@mail.gmail.com>
References: <9d6632e0711211020t15344ca7i11022838e505cdc2@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <04F6CAAC-A1DD-4F42-A343-E36D2B7D1477@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] Errant Proxy Behavior?
Date: Wed, 21 Nov 2007 13:09:06 -0600
To: Joe 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4872/Wed Nov 21 02:36:49 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

There are several things to comment on here.

I assume you're talking about a Route header value that's not the  
topmost one (which would in most circumstances be consumed before  
being forwarded).

Making any modification to those values while proxying is unwise,  
even when its legal. The best way to achieve interoperability is to  
give a proxy back EXACTLY the set of bits it record-routed with.

Now, for the particular transformation you're describing - it's not  
legal. Replacing a %41 with an 'A' or vice-versa would be legal (but  
unwise). "$", on the other hand, is special.

The text in section 19.1.4 (URI Comparison) says:
...
   SIP and SIPS URIs are compared for equality
    according to the following rules:
...
       o  Characters other than those in the "reserved" set (see RFC  
2396
          [5]) are equivalent to their ""%" HEX HEX" encoding.

But

       reserved    =  ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
                      / "$" / ","

Hope that helps,

RjS

On Nov 21, 2007, at 12:20 PM, Joe wrote:

> Hello all,
>
> If a proxy receives a message containing a SIP URI in a Route  
> header that has "%24" in the user portion (used as part of a token)  
> is it allowed to modify this to "$", leave the rest untouched, and  
> forward it?
>
> This seems like incorrect behavior.
>
> Thanks!
> Joe
> _______________________________________________
> 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



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 14:51:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuvbF-0006jt-Od; Wed, 21 Nov 2007 14:51:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuvbD-0006jd-JX
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:51:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvbD-0006jP-8t
	for sip@ietf.org; Wed, 21 Nov 2007 14:51:03 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuvb9-000170-RR
	for sip@ietf.org; Wed, 21 Nov 2007 14:51:03 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lALJonY2019790; 
	Wed, 21 Nov 2007 13:50:50 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lALJonj22353; Wed, 21 Nov 2007 13:50:49 -0600 (CST)
Message-ID: <47448C19.20100@alcatel-lucent.com>
Date: Wed, 21 Nov 2007 13:50:49 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Gonzalo Camarillo 
References: 
	<4743F62A.8040903@ericsson.com> <4743F78D.4070705@ericsson.com>
	<474450B2.1020907@alcatel-lucent.com>
	<47445B65.7010608@ericsson.com>
In-Reply-To: <47445B65.7010608@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: sip , Brett Tate 
Subject: [Sip] Re: URI comparison rules - IPv6 addresses
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Gonzalo Camarillo wrote:
> Hi Vijay,
> 
> if this document becomes a WG item, I agree it would be the perfect 
> place to document this issue.

OK; good.  draft-gurbani-sip-ipv6-abnf-fix has been reviewed
and okayed by at least one member of the SIP WG on the list.  Things
will be much clearer after the Vancouver IETF.  Then, if the chips
fall in place, Brett and I will ensure that the text for URI
comparison gets in.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 14:51:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuvbF-0006jj-54; Wed, 21 Nov 2007 14:51:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuvbD-0006jK-2l
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:51:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvbC-0006jC-On
	for sip@ietf.org; Wed, 21 Nov 2007 14:51:02 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuvbC-0005p6-Dq
	for sip@ietf.org; Wed, 21 Nov 2007 14:51:02 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lALJoq7r019815; 
	Wed, 21 Nov 2007 13:50:52 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lALJoqj22368; Wed, 21 Nov 2007 13:50:52 -0600 (CST)
Message-ID: <47448C1B.7000603@alcatel-lucent.com>
Date: Wed, 21 Nov 2007 13:50:51 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Jeroen van Bemmel 
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>
In-Reply-To: <0JRV00ABOC070460@jes-fe1.zx.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: sip , Gonzalo Camarillo ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Jeroen van Bemmel wrote:
> Vijay,
> It's not only IPv6: what about 127.0.0.1 versus 127.000.000.1?

Jeroen: Pedantically speaking, you are probably right.  But
in practice we do not generally see leading zeros in an IPv4
octet.

IPv6, with its compressed notation and the need to represent
hybrid addresses (like IPv4-mapped IPv6 addresses) makes the
representation issue more acute.  For instance, the low-order
32 bits of an IPv4-mapped IPv6 address can be represented using
the familiar dotted-decimal notation, or they can be represented
using the IPv6 colon-separated notation.

But your point is well taken: if we put some text about the
binary equivalence of different textual representations of an
IPv6 address, I guess we should do so for IPv4 as well.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 14:51:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuvc0-0007Y4-IP; Wed, 21 Nov 2007 14:51:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuvby-0007XG-Ro
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:51:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuvby-0007Wg-Eq
	for sip@ietf.org; Wed, 21 Nov 2007 14:51:50 -0500
Received: from numenor.qualcomm.com ([129.46.51.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuvbx-0005rN-Md
	for sip@ietf.org; Wed, 21 Nov 2007 14:51:50 -0500
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lALJplXR032732
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 21 Nov 2007 11:51:48 -0800
Received: from [67.169.50.136] (carbuncle.qualcomm.com [129.46.226.27])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	lALJpkeS019569; Wed, 21 Nov 2007 11:51:47 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>
	
Date: Wed, 21 Nov 2007 11:51:44 -0800
To: "James M. Polk" , Daniel Grotti ,
	IETF SIP List 
From: Ted Hardie 
Subject: Re: [Sip] a question about IETF draft location conveyance 09
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 6:33 PM -0600 11/20/07, James M. Polk wrote:
>Daniel
>
>wow... you nailed this one quickly.
>
>Neither the SIP WG nor Geopriv WG have a position with regard to this.  I don't like the parameter at all, and have said so from its introduction into discussions about putting it in the draft.  I don't think it accomplishes much more than confusion or a false sense of security by implementors.

Well, I think the Geopriv working group discussed this a great deal, and that
there was reasonable (albeit rough) consensus that it be included.  Anyone
interested can certainly see a lively debate on the Geopriv list.

The current text is:
A locationValue has the following independent header parameters,

(snip of other parameters)

the "recipient=" parameter to allow recipients to infer what SIP
      element type this locationValue was intended to be for.  The
      types are

         o "endpoint" - meaning the ultimate destination UAS;

         o "routing-entity" - meaning SIP servers that route messages
                    based on the location contents of requests; and

         o "both" - meaning this locationValue is to be viewed by both
                    types of SIP entities. 

      Not all SIP entities have to read the locationValue within a
      Geolocation header, therefore a parameter value of "both" does
      not mean "every" SIP element receiving this request, it means all
      that care to pay attention to a locationValue.  The default
      behavior of SIP entities reading the locationValue is that if
      this header parameter is NOT present, the intended recipient is
      the destination UAS.

A proxy seeing a locationValue with a recipient= tag of
routing-entity or both MAY do location based routing using
the location (as the draft says, it does not have to).  A proxy
seeing a locationValue with a recipient=endpoint should understand
that the locationValue was not intended to be used for
location-based routing.    The draft is pretty clear that the
privacy rules in RFC 4119; in Section 5 it says pretty bluntly:
  
   Location Recipients MUST obey the privacy and security rules in the
   PIDF-LO as described in RFC 4119 regarding retransmission and
   retention.

If a proxy is not the intended recipient, as given in this parameter,
it shouldn't be storing or acting on this data, just sending it along.


>That said, a proxy has "ar" capabilities wrt the Geolocation according to Table 1. (on page 7), and associated text states this pretty clearly. There is no text (not even a hint) that a proxy cannot read a location because "recipient=endpoint", therefore it can.  I would take this "recipient=" parameter as a hint to each type of SIP entity that
>
>        + if a UAS receives this parameter (meaning in a SIP request with
>           a Geolocation header), and it is set to "recipient", the UAS
>           shouldn't ignore the location in the request (like it otherwise
>           might).
>
>        + If a proxy receives this parameter (meaning in a SIP request with
>           a Geolocation header), and it is set to "server", the proxy
>           shouldn't ignore the location in the request (like it otherwise
>           might).
>
>I don't think either indication *ever* means the other SIP entity type cannot view the location, based on the parameter. 

I don't understand what you mean by "view" here.  A proxy putting this to memory
in order to send it along is doing fine; someone doing location-based-routing when
recipient=endpoint is not doing the right thing (except in the Emergency Services
case, where all bets are off).

			


>The only exception I can think of is a Location-by-value hidden by S/MIME means no one save who has the decryption key can view the contents of what's encrypted.
>
>Does this make sense?

I suggest we continue the conversation in GeoPRIV if we have further discussion
on this particular point.
				Ted



>James
>
>At 04:59 AM 11/20/2007, Daniel Grotti wrote:
>>Hi all,
>>I'd like to ask a question about "draft-ietf-sip-location-conveyance-09.txt".
>>
>>How does Proxy Server have to work when a Geolocation Header contain "recipient=endpoint" parameter ?
>>Does the Proxy server just have to forward the SIP message (without do anything else) or can it read the information conveyed ?
>>thanks,
>>Regards
>>daniel
>>
>>--
>>
>>---------------------------------------------------
>>Daniel Grotti
>>DEIS - University of Bologna
>>Via Venezia, 52 - 47023 Cesena (FC) - ITALY
>>
>>Contacts
>>e-mail : daniel.grotti@unibo.it
>>Skype name : Daniel Grotti
>>---------------------------------------------------
>>
>>
>>
>>_______________________________________________
>>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
>
>
>_______________________________________________
>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



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 15:14:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuvxz-0003dJ-1r; Wed, 21 Nov 2007 15:14:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuvxx-0003cv-I9
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:14:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuvxx-0003cm-5s
	for sip@ietf.org; Wed, 21 Nov 2007 15:14:33 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuvxw-0006zL-FD
	for sip@ietf.org; Wed, 21 Nov 2007 15:14:33 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lALKETQu003914
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for ; Wed, 21 Nov 2007 14:14:31 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: 
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF SIP List 
From: Dean Willis 
Date: Wed, 21 Nov 2007 14:14:24 -0600
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Subject: [Sip] draft-gunn-sip-req-for-rph-in-responses-00: What is impact on
	response?
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


I'm still struggling with the rph-in-response question. I was hoping  
to get some insight from draft-gunn-sip-req-for-rph-in-responses-00,  
but I'm still left unclear on a few points.

For the record, this draft adds supporting rationale for draft-polk- 
sip-rph-in-responses-00.txt.

I understand from this draft that a node making a call that would  
need RPH information might not know what RPH value would apply at the  
time the call is launched by sending INVITE. This is because the  
priority granted will depend on external factors, including  
potentially the priority status of the call target. So we need a way  
to inform the network elements along the path (including the UAC) as  
to what priority they should grant the call.

Now for the questions:

1) RFC 4412 (which defines RPH) is not clear to me on the  
relationship between priorities, requests, responses, and dialogs.  
Specifically, does an RPH value expressed in an INVITE transaction  
apply to a dialog, or does it apply only to the request in which it  
appears? This has implications for what happens should an RPH value  
change mid-dialog, which is what the rph-responses work is proposing.  
The only way I can see that this works is for RPH values to apply  
only to the request (or perhaps request or response) in which they  
occur. Supporting UAs would then have to remember the RPH value and  
include it in all further requests (and perhaps responses). If the  
RPH value is not resent, then the RPH value would cease to apply. Now  
here's the problem: The RPH value seems to impact the processing of  
the SIP messages themselves, and the priority of the media flow  
established in a dialog. So what happens to the priority of a media  
flow when subsequent transactions within the dialog experience  
changes in RPH values?


2) What is the impact of RPH in a response? Does this value get  
interpreted and used to prioritize the response (which has some  
substantial implications for overload processing) or is it simply  
informative, such that the UAC learns the RPH value and can include  
it in future requests? Otherwise worded, are we suggesting that the  
responses to requests be treated with different prioritization than  
the request itself?

3) What is the authentication/authorization model? This has two sub- 
problems.

3A) First, we cannot (in SIP) challenge a response. There are no  
"responses to responses" -- they can either be transmitted or  
dropped.  In some cases, responses can be modified by proxies. This  
lead us to the model of connected-identity we currently have, where  
identity is asserted by sending a request in the opposing direction  
of flow. So, let's say a UAS receiving a low-priority request sends a  
high-priority response. What information in this response is used by  
the proxy layer to decide whether or not the UAS is authorized to  
assert this level of priority? It can't be "identity" (because in the  
absence of an outbound-style last-hop persistent TLS connection, we  
can only do assert identity on requests). What happens if a UAS  
asserts an RPH value it is not authorized to use? Do the proxies  
simply mark it back down, or does the request get dropped? And how  
can any of this work in a stateless element?

3B) Assume the original UAC learns in a response from the UAS of a  
new RPH value, and then uses it in future requests within the dialog.  
How does the proxy layer decide the UAS is authorized to use this new  
RPH? The UAS's identity hasn't changed, and that identity was not  
originally authorized for the higher RPH level. There was no crypto- 
token in the response that can be evaluated. Dialog-stateful proxies  
that saw the response might be able to track this as authorization to  
the UAC, but stateless proxies will have no clue.

As a consequence of the two aspects of problem 3, all a stateless  
proxy can do is either ignore RPH entirely or blindly assume that the  
RPH value in a request is valid and act on it to the best of its  
ability. This raises some very interesting security questions in an  
environment that is rich with stateless proxies.

I think for this to really work, we need to make a couple of  
enhancements.

First, we need to understand whether the RPH value of a request  
applies to any response to that request -- that is, whether the  
applied value cannot change between request and response. I think  
that the response priority is the same as the request priority, as  
doing otherwise either requires changing the fundamental  
authentication model of SIP, or it requires stateful proxies combined  
with draft-ietf-sip-outbound and thereby making this extension so  
narrow as to arguably be in the "P-header" domain.

Second, we need to understand that RPH can change with each new  
request, whether in a dialog or not, and we'll need to clarify the  
interaction between the changing of RPH within a dialog and the  
priority of any media session associated with that dialog.

Thirdly, we need some way for the UAC to be granted the right to use  
an RPH by a response. This could either be some sort of token sent by  
the UAS to the UAC, or it could be a requirement that the admitting  
proxy (the one to which the UAC directly connects) be dialog stateful.

---
Dean, the priority-confused.









_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 15:20:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuw3y-0000bz-Ok; Wed, 21 Nov 2007 15:20:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuw3w-0000ba-KN
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:20:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuw3w-0000bS-Ar
	for sip@ietf.org; Wed, 21 Nov 2007 15:20:44 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuw3s-0002RS-TZ
	for sip@ietf.org; Wed, 21 Nov 2007 15:20:44 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lALKKXTl003984
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 21 Nov 2007 14:20:35 -0600
In-Reply-To: 
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Wed, 21 Nov 2007 14:20:28 -0600
To: Robert Sparks 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 20, 2007, at 8:54 AM, Robert Sparks wrote:

> Yeah - that's not it - it doesn't match your assertion even.
> That text says that _if_ SDP shows up in the 200, you have to  
> ignore it.
> It doesn't say anything about it matching the 18x, and it doesn't  
> say anything about whether the UAS is allowed to put it in the 200  
> in the first place.
>
> Btw - that passage _IS BEING USED_ to argue that it's ok, and even  
> _right_, to put SDP in the 200 OK since things MUST ignore it.

Apply Postel's maxim here.

Broken UAs might (and from what I hear, frequently do) ignore the  
answer in the 18x, instead taking the answer from the 200. If these  
answers are identical, then it works. If they aren't, then it doesn't.

Is it better to have a clearly described irrecoverable failure or a  
working call?

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 15:28:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuwBU-0004Pd-Po; Wed, 21 Nov 2007 15:28:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuwBT-0004Kq-T9
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:28:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwBT-0004HM-D4
	for sip@ietf.org; Wed, 21 Nov 2007 15:28:31 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuwBS-0007fx-8W
	for sip@ietf.org; Wed, 21 Nov 2007 15:28:31 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-1.cisco.com with ESMTP; 21 Nov 2007 12:28:29 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALKSTeq015743; 
	Wed, 21 Nov 2007 12:28:29 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lALKST0W017363;
	Wed, 21 Nov 2007 20:28:29 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 12:28:29 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.92.162]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 12:28:28 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 21 Nov 2007 14:28:27 -0600
To: Ted Hardie , Daniel Grotti , 
	IETF SIP List 
From: "James M. Polk" 
Subject: Re: [Sip] a question about IETF draft location conveyance 09
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>
	
	
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 21 Nov 2007 20:28:28.0971 (UTC)
	FILETIME=[137F67B0:01C82C7D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7670; t=1195676909;
	x=1196540909; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20[Sip]=20a=20question=20about=20IETF=20draft=20locatio
	n=20conveyance=2009 |Sender:=20;
	bh=uWTWnW5bzcjqUYX9SvatVGRcRXGGDYIyeSfo8oAgyfg=;
	b=imGk1/DX9reIIGmtypk8MEfHkrtGlHtM+dNPBO+dsl6tJOYM2HyxErfFYWNGLShaS8H3ohxL
	smb432SHKEMWZqon7v7XErZT4zuBf1VhTF2PW8tcU9VifEwmP+3dYQOIoMcWPPHv9LXoDxdpco
	v4zPV9qDEWsuM6gk6RGvARzwM=;
Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Ted

The "recipient=" within the Geolocation header is a SIP parameter, in 
a SIP document.  Everything discussed in Geopriv regarding this 
document needs to be approved in SIP too.  The SIP WG hasn't heard 
this part of the discussion because most members of SIP aren't 
subscribed to the Geopriv list.

I'm on the agenda right now to present in SIP in Vancouver, and this 
is one issue I'd like the SIP WG to comment on, so I'll be asking it there.

the rest of my reply is in-line

At 01:51 PM 11/21/2007, Ted Hardie wrote:
>At 6:33 PM -0600 11/20/07, James M. Polk wrote:
> >Daniel
> >
> >wow... you nailed this one quickly.
> >
> >Neither the SIP WG nor Geopriv WG have a position with regard to 
> this.  I don't like the parameter at all, and have said so from its 
> introduction into discussions about putting it in the draft.  I 
> don't think it accomplishes much more than confusion or a false 
> sense of security by implementors.
>
>Well, I think the Geopriv working group discussed this a great deal, and that
>there was reasonable (albeit rough) consensus that it be included.  Anyone
>interested can certainly see a lively debate on the Geopriv list.

and where was the SIP WG discussion on a SIP header parameter?  Since 
this parameter, from what you state below,  has a UA understanding 
the topology of a request - all the way to the endpoint - which is 
not part of the Geopriv charter to know or make decisions on, where's 
that discussion, at least as confirmation that SIP UAC's can know the 
full topology of a network enough to make this decision (that can't 
be changed)?

For example, Alice calls PizzaHut.com, and Pizza Hut routes her call 
to the Pizza Hut store most local to wherever she is to take her 
order.  Does her UAC understand this type of call well enough to have 
"recipient=both"?  Or would it just enter "recipient=endpoint", thus 
preventing her SIP request from being retargetted?

How does her UAC understand the different from this type of call to 
Pizza Hut from merely a complaint to Pizza Hut corporate?

I still can't seem to get over this simple example of a limitation 
and assumption created by this header parameter that the caller 
doesn't control.


>The current text is:
>A locationValue has the following independent header parameters,
>
>(snip of other parameters)
>
>the "recipient=" parameter to allow recipients to infer what SIP
>       element type this locationValue was intended to be for.  The
>       types are
>
>          o "endpoint" - meaning the ultimate destination UAS;
>
>          o "routing-entity" - meaning SIP servers that route messages
>                     based on the location contents of requests; and
>
>          o "both" - meaning this locationValue is to be viewed by both
>                     types of SIP entities.
>
>       Not all SIP entities have to read the locationValue within a
>       Geolocation header, therefore a parameter value of "both" does
>       not mean "every" SIP element receiving this request, it means all
>       that care to pay attention to a locationValue.  The default
>       behavior of SIP entities reading the locationValue is that if
>       this header parameter is NOT present, the intended recipient is
>       the destination UAS.
>
>A proxy seeing a locationValue with a recipient= tag of
>routing-entity or both MAY do location based routing using
>the location (as the draft says, it does not have to).  A proxy
>seeing a locationValue with a recipient=endpoint should understand
>that the locationValue was not intended to be used for
>location-based routing.    The draft is pretty clear that the
>privacy rules in RFC 4119; in Section 5 it says pretty bluntly:
>
>    Location Recipients MUST obey the privacy and security rules in the
>    PIDF-LO as described in RFC 4119 regarding retransmission and
>    retention.
>
>If a proxy is not the intended recipient, as given in this parameter,
>it shouldn't be storing or acting on this data, just sending it along.
>
>
> >That said, a proxy has "ar" capabilities wrt the Geolocation 
> according to Table 1. (on page 7), and associated text states this 
> pretty clearly. There is no text (not even a hint) that a proxy 
> cannot read a location because "recipient=endpoint", therefore it 
> can.  I would take this "recipient=" parameter as a hint to each 
> type of SIP entity that
> >
> >        + if a UAS receives this parameter (meaning in a SIP request with
> >           a Geolocation header), and it is set to "recipient", the UAS
> >           shouldn't ignore the location in the request (like it otherwise
> >           might).
> >
> >        + If a proxy receives this parameter (meaning in a SIP request with
> >           a Geolocation header), and it is set to "server", the proxy
> >           shouldn't ignore the location in the request (like it otherwise
> >           might).
> >
> >I don't think either indication *ever* means the other SIP entity 
> type cannot view the location, based on the parameter.
>
>I don't understand what you mean by "view" here.  A proxy putting 
>this to memory
>in order to send it along is doing fine; someone doing 
>location-based-routing when
>recipient=endpoint is not doing the right thing (except in the 
>Emergency Services
>case, where all bets are off).

RFC3261 says proxies can view message bodies that aren't encrypted.

I don't see the text giving an exemption in the emergency case, not 
at least in this doc.


> >The only exception I can think of is a Location-by-value hidden by 
> S/MIME means no one save who has the decryption key can view the 
> contents of what's encrypted.
> >
> >Does this make sense?
>
>I suggest we continue the conversation in GeoPRIV if we have further 
>discussion
>on this particular point.

But this is a SIP parameter, and a SIP document.  Everything 
discussed in Geopriv needs to be approved in SIP too.  The SIP WG 
hasn't heard this part of the discussion because most members of SIP 
aren't subscribed to the Geopriv list.

>                                 Ted
>
>
>
> >James
> >
> >At 04:59 AM 11/20/2007, Daniel Grotti wrote:
> >>Hi all,
> >>I'd like to ask a question about 
> "draft-ietf-sip-location-conveyance-09.txt".
> >>
> >>How does Proxy Server have to work when a Geolocation Header 
> contain "recipient=endpoint" parameter ?
> >>Does the Proxy server just have to forward the SIP message 
> (without do anything else) or can it read the information conveyed ?
> >>thanks,
> >>Regards
> >>daniel
> >>
> >>--
> >>
> >>---------------------------------------------------
> >>Daniel Grotti
> >>DEIS - University of Bologna
> >>Via Venezia, 52 - 47023 Cesena (FC) - ITALY
> >>
> >>Contacts
> >>e-mail : daniel.grotti@unibo.it
> >>Skype name : Daniel Grotti
> >>---------------------------------------------------
> >>
> >>
> >>
> >>_______________________________________________
> >>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
> >
> >
> >_______________________________________________
> >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


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 15:56:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuwcW-0002Jh-D8; Wed, 21 Nov 2007 15:56:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuwcV-0002Jc-LU
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:56:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwcV-0002JU-BV
	for sip@ietf.org; Wed, 21 Nov 2007 15:56:27 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuwcR-00049j-QA
	for sip@ietf.org; Wed, 21 Nov 2007 15:56:27 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 12:56:23 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lALKuNJf016146
	for ; Wed, 21 Nov 2007 12:56:23 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lALKu4ss016319
	for ; Wed, 21 Nov 2007 20:56:23 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 12:56:13 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.92.162]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 12:56:13 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 21 Nov 2007 14:56:11 -0600
To: sip@ietf.org
From: "James M. Polk" 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 21 Nov 2007 20:56:13.0230 (UTC)
	FILETIME=[F3792CE0:01C82C80]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1898; t=1195678583;
	x=1196542583; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20SIP=20Location=20Conveyance=20revved=20(-09)
	|Sender:=20; bh=xELUxAQY/X5LTZArI2ooKGX57rYCiagdYs06TKEx638=;
	b=CrrO2xRnFVxeU+s9V2QTSHgUmumlKc2GuG8igRLdTx8mBKMWz+A+0SgF0AvoMQF2DuQt2KFb
	h3FFMhsFAJb1npF05q32QQbEHBMuLK4Fqcbcs6HTJxqitnMP5zMLkTHk;
Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: [Sip] SIP Location Conveyance revved (-09)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I've submitted a new version of SIP Location Conveyance
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-09.txt

This version has the following changes:

- clarified that the "inserted-by=", "used-for-routing" and 
"recipient=" parameters within the Geolocation header are independent 
of each other, and not replacements (i.e., that only one can be in the header)

- made "inserted-by=" a mandatory header parameter.  This is because 
there is a comparable header for errors that needs this parameter's 
value. I'll mention that in a bit.

- With Robert Spark's help, changed the ABNF of the Geolocation-Error header.

- Geolocation-Error header now includes an "inserter=" header, which 
is copied from the "inserted-by=" header from the Geolocation header 
in a request.  This identifies which location inserter (because there 
can be more than one) inserted a location the Location Recipient 
concluded had bad location information.

- Also added the ability for a Geolocation-Error header to contain a 
list of civic CAtypes (that were in the PIDF-LO location) that the 
Location Recipient considered bad.  State that the CAtype values MUST 
NOT be included, just the CAtypes.  This, coupled with the redone 
Error codes, tells the location "inserter=" what specifically was 
wrong with the location it put into the SIP request.

- fixed all the examples of the Geolocation-Errors

- split out an error handling subsection within each of UAC Behavior, 
UAS Behavior and Proxy Behavior sections, for clarity.

I believe there is one remaining open issue, and that is the 
"recipient=" parameter, of which - there is an active thread of this 
on the SIP list right now.  I believe it is flawed as is, some don't, 
and I'm looking for input into this Geolocation header parameter.

comments are welcome and encouraged

James & Brian



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 15:56:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuwcR-0002Ce-It; Wed, 21 Nov 2007 15:56:23 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuwcP-00024i-SY
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:56:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwcP-00024a-Id
	for sip@ietf.org; Wed, 21 Nov 2007 15:56:21 -0500
Received: from dnsmx1pya.telcordia.com ([128.96.20.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuwcJ-00049F-8Q
	for sip@ietf.org; Wed, 21 Nov 2007 15:56:21 -0500
Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com
	[128.96.20.21])
	by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id lALKuCD04764
	for ; Wed, 21 Nov 2007 15:56:12 -0500 (EST)
Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31])
	by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id
	M2007112115560915794
	for ; Wed, 21 Nov 2007 15:56:09 -0500
Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by
	rrc-dte-exbh01.dte.telcordia.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 15:56:10 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 21 Nov 2007 15:56:09 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Need for RPH in SIP Responses
thread-index: AcgsgPFAQ9r3KFNvRbGMwEjTuLtQag==
From: "Sandesara, Niranjan B" 
To: 
X-OriginalArrivalTime: 21 Nov 2007 20:56:10.0248 (UTC)
	FILETIME=[F1B22880:01C82C80]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f
Subject: [Sip] Need for RPH in SIP Responses
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1109480351=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1109480351==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82C80.F17D4E7A"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82C80.F17D4E7A
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi!

=20

The SIP Resource Priority Header (RPH), in its current form, is not
allowed in SIP responses.  This was a design choice during RFC 4412's
development. This is not a good choice in certain scenarios. The
Internet Draft, "Allowing SIP Resource Priority Header in SIP Responses"
(draft-polk-sip-rph-in-responses-00) describes a modification to RFC4412
to permit RPH in responses. The Internet Draft, "Requirements for SIP
Resource Priority Header in SIP Responses"
(draft-gunn-sip-req-for-rph-in-responses-00), describes one of the
requirements associated with systems using RPH, that could be easily met
by the modification of RFC 4412 to permit RPH in responses, and can not
be easily met by other methods. Additional scenarios and requirement are
described below that can be easily met if RPH is permitted in responses
per draft-polk-sip-rph-in-responses-00.

=20

All aspects of a GETS/WPS call require priority treatment in order to
ensure that it is successfully established with priority, maintained
with adequate quality and priority, and released with priority.  RFC
3261 permits stateless servers. There are scenarios involving stateless
servers that require such servers to provide priority treatment to
GETS/WPS calls. Three scenarios are described below where inclusion of
RPH in SIP responses would enable a stateless server to provide priority
treatment.

1.	If there is congestion at a SIP server, it is important that SIP
messages (requests as well as responses) related to a GETS/WPS call are
processed with priority, and discarded last in comparison with normal
calls. Presence of RPH in SIP responses would enable a stateless server
to provide such capability.
2.	A network can mark IP packets that carry SIP messages related to
GETS/WPS calls with a specific DiffServ Code Point (DSCP). This could be
used as one mechanism to ensure that such packets receive priority
treatment in transport through an IP network. A stateless server can
mark IP packets that carry SIP responses in this manner only if it
recognizes the responses that are related to GETS/WPS calls. Presence of
RPH in SIP responses would enable a stateless server to mark packets
carrying SIP responses in this manner or other priority transport
mechanisms (e.g. MPLS path selection).=20
3.	On receipt of a SIP response related to a GETS/WPS call, if a
stateless server needs to invoke other services and interact with other
servers with priority, it needs to be aware of the GETS/WPS call.
Presence of RPH in SIP responses would enable a stateless server to
provide such capability.

=20

As described in the internet draft, "Requirements for SIP Resource
Priority Header in SIP Responses"
(draft-gunn-sip-req-for-rph-in-responses-00), GETS/WPS paradigm is
different from the MLPP paradigm. One important difference between the
two is that a GETS/WPS call request from the calling party may not
include an RPH. It is possible that SIP servers (whether stateful or
stateless) preceding the server that authenticates and authorizes a
GETS/WPS call request have RPH capability but do not have the capability
to identify the request as a GETS/WPS call request. After successful
authorization, the authenticating server will insert an RPH in all
requests it sends. In this scenario, the servers preceding the
authenticating servers would not become aware of the priority nature of
the call and would not provide any priority treatment until they receive
a SIP request with an RPH from the authenticating server.  This is not
desirable. This situation can be easily remedied if RPH is permitted in
SIP responses.

=20

As has been pointed out earlier, possible security risk of permitting
RPH in SIP responses is minimal in managed IP networks where this
capability is generally expected to be used.=20

=20

Regards,

=20

Niranjan Sandesara


------_=_NextPart_001_01C82C80.F17D4E7A
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
















Hi!



 



The SIP Resource Priority Header (RPH), in its =
current form,
is not allowed in SIP responses.  This was a design choice during =
RFC 4412's
development. This is not a good choice in certain scenarios. The =
Internet Draft,
"Allowing SIP Resource Priority Header in SIP Responses" =
(draft-polk-sip-rph-in-responses-00)
describes a modification to RFC4412 to permit RPH in responses. The =
Internet
Draft, “Requirements for SIP Resource Priority Header in SIP =
Responses”
(draft-gunn-sip-req-for-rph-in-responses-00), describes one of the =
requirements
associated with systems using RPH, that could be easily met by the =
modification
of RFC 4412 to permit RPH in responses, and can not be easily met by =
other
methods. Additional scenarios and requirement are described below that =
can be
easily met if RPH is permitted in responses per
draft-polk-sip-rph-in-responses-00.



 



All aspects of a GETS/WPS call require priority =
treatment in
order to ensure that it is successfully established with priority, =
maintained
with adequate quality and priority, and released with priority. =
 RFC 3261
permits stateless servers. There are scenarios involving stateless =
servers that
require such servers to provide priority treatment to GETS/WPS calls. =
Three scenarios
are described below where inclusion of RPH in SIP responses would enable =
a
stateless server to provide priority =
treatment.



    
 
  1. If there is congestion =
at a SIP
     server, it is important that SIP messages (requests as well as =
responses) related
     to a GETS/WPS call are processed with priority, and discarded last =
in
     comparison with normal calls. Presence of RPH in SIP responses =
would
     enable a stateless server to provide such =
capability.
    2. 
 
  2. A network can mark IP =
packets
     that carry SIP messages related to GETS/WPS calls with a specific =
DiffServ
     Code Point (DSCP). This could be used as one mechanism to ensure =
that such
     packets receive priority treatment in transport through an IP =
network. A
     stateless server can mark IP packets that carry SIP responses in =
this
     manner only if it recognizes the responses that are related to =
GETS/WPS
     calls. Presence of RPH in SIP responses would enable a stateless =
server to
     mark packets carrying SIP responses in this manner or other =
priority
     transport mechanisms (e.g. MPLS path selection). =

    3. 
 
  3. On receipt of a SIP =
response
     related to a GETS/WPS call, if a stateless server needs to invoke =
other
     services and interact with other servers with priority, it needs to =
be
     aware of the GETS/WPS call. Presence of RPH in SIP responses would =
enable
     a stateless server to provide such =
capability.
    4. 




 



As described in the internet draft, =
“Requirements for
SIP Resource Priority Header in SIP Responses”
(draft-gunn-sip-req-for-rph-in-responses-00), GETS/WPS paradigm is =
different
from the MLPP paradigm. One important difference between the two is that =
a
GETS/WPS call request from the calling party may not include an RPH. It =
is
possible that SIP servers (whether stateful or stateless) preceding the =
server
that authenticates and authorizes a GETS/WPS call request have RPH =
capability
but do not have the capability to identify the request as a GETS/WPS =
call
request. After successful authorization, the authenticating server will =
insert
an RPH in all requests it sends. In this scenario, the servers preceding =
the
authenticating servers would not become aware of the priority nature of =
the
call and would not provide any priority treatment until they receive a =
SIP
request with an RPH from the authenticating server.  This is not =
desirable.
This situation can be easily remedied if RPH is permitted in SIP =
responses.



 



As has been pointed out earlier, possible security =
risk of
permitting RPH in SIP responses is minimal in managed IP networks where =
this
capability is generally expected to be used. =




 



Regards,



 



Niranjan Sandesara









------_=_NextPart_001_01C82C80.F17D4E7A--



--===============1109480351==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1109480351==--





From sip-bounces@ietf.org Wed Nov 21 16:02:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuwiJ-00080f-UL; Wed, 21 Nov 2007 16:02:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuwiH-00080S-TO
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwiH-0007yt-Hf
	for sip@ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuwiD-0004S4-0d
	for sip@ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lALL2JUM008483
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 21 Nov 2007 13:02:19 -0800
Received: from [67.169.50.136] (carbuncle.qualcomm.com [129.46.226.27])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	lALL2InA005852; Wed, 21 Nov 2007 13:02:19 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>
	
	
	
Date: Wed, 21 Nov 2007 13:02:16 -0800
To: "James M. Polk" , Daniel Grotti ,
	IETF SIP List 
From: Ted Hardie 
Subject: Re: [Sip] a question about IETF draft location conveyance 09
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 2:28 PM -0600 11/21/07, James M. Polk wrote:
>Ted
>
>The "recipient=" within the Geolocation header is a SIP parameter, in a SIP document.  Everything discussed in Geopriv regarding this document needs to be approved in SIP too.  The SIP WG hasn't heard this part of the discussion because most members of SIP aren't subscribed to the Geopriv list.

That SIP parameter in a SIP document relates to a PIDF-LO object carried by
SIP; in that context, SIP is a using protocol of the GEOPRIV framework.  SIP
folks should certainly understand the work they're reusing, or the implementations
won't do the right thing.  But re-starting the conversation in SIP without
reference to the discussions that have already occurred in GeoPRIV is a
recipe for conflict at IETF Last Call.  We might as well start getting people
on the same page now.  From my  perspective, the right way to do that is
to start the discussion from where it last left off, even if that wasn't in
the same group.  That tells people where the consensus of that group was
and informs the rest of the discussion.

>
>I'm on the agenda right now to present in SIP in Vancouver, and this is one issue I'd like the SIP WG to comment on, so I'll be asking it there.

I look forward to your presentation.

Further commments inline.



>the rest of my reply is in-line
>
>At 01:51 PM 11/21/2007, Ted Hardie wrote:
>>At 6:33 PM -0600 11/20/07, James M. Polk wrote:
>>>Daniel
>>>
>>>wow... you nailed this one quickly.
>>>
>>>Neither the SIP WG nor Geopriv WG have a position with regard to this.  I don't like the parameter at all, and have said so from its introduction into discussions about putting it in the draft.  I don't think it accomplishes much more than confusion or a false sense of security by implementors.
>>
>>Well, I think the Geopriv working group discussed this a great deal, and that
>>there was reasonable (albeit rough) consensus that it be included.  Anyone
>>interested can certainly see a lively debate on the Geopriv list.
>
>and where was the SIP WG discussion on a SIP header parameter?  Since this parameter, from what you state below,  has a UA understanding the topology of a request - all the way to the endpoint - which is not part of the Geopriv charter to know or make decisions on, where's that discussion, at least as confirmation that SIP UAC's can know the full topology of a network enough to make this decision (that can't be changed)?

You are making a big leap here.  It doesn't have a UA understanding of the topology;
it has User control over private information.  The user gets to say by whom his or
her location gets used; that's a core aspect of RFC 4119 and friends, and you don't
get to reuse that work without getting that assumption built in.  We've had
exceptions for emergency services (discussed in the ECRIT BCPs), but they're
not general.  If a user does not want that private information used by the
SIP routing system but is willing to give it to the SIP entity receiving the call,
the system has to provide a way of making that clear.  We discussed several
ways to achieve that (including changes to 4119), and there was pretty
clear consensus on this way forward.  The version with retransmission-allowed
or routing-query-allowed did not see support, nor did redefining "retransmission=no"
to mean "except for SIP".

Yes, this does mean that a UA that sends a location object with recipient=end-point
may have a call fail if location-based routing is absolutely required; so will any
call not containing location, though, and the UA will have to be able to handle
that case.  It may very well be what is wanted, as we discussed in relation to
taxi services at some length (I may be willing to send my location to a local
taxi service so it can send the taxi, but not willing to send my location to
the sip-routing system so it can pick a taxi-service local to me).

>For example, Alice calls PizzaHut.com, and Pizza Hut routes her call to the Pizza Hut store most local to wherever she is to take her order.  Does her UAC understand this type of call well enough to have "recipient=both"?  Or would it just enter "recipient=endpoint", thus preventing her SIP request from being retargetted?
>
>How does her UAC understand the different from this type of call to Pizza Hut from merely a complaint to Pizza Hut corporate?
>
>I still can't seem to get over this simple example of a limitation and assumption created by this header parameter that the caller doesn't control.

Perhaps I don't see what you mean by "caller doesn't control" here.  Can you
elaborate?



>
>>The current text is:
>>A locationValue has the following independent header parameters,
>>
>>(snip of other parameters)
>>
>>the "recipient=" parameter to allow recipients to infer what SIP
>>      element type this locationValue was intended to be for.  The
>>      types are
>>
>>         o "endpoint" - meaning the ultimate destination UAS;
>>
>>         o "routing-entity" - meaning SIP servers that route messages
>>                    based on the location contents of requests; and
>>
>>         o "both" - meaning this locationValue is to be viewed by both
>>                    types of SIP entities.
>>
>>      Not all SIP entities have to read the locationValue within a
>>      Geolocation header, therefore a parameter value of "both" does
>>      not mean "every" SIP element receiving this request, it means all
>>      that care to pay attention to a locationValue.  The default
>>      behavior of SIP entities reading the locationValue is that if
>>      this header parameter is NOT present, the intended recipient is
>>      the destination UAS.
>>
>>A proxy seeing a locationValue with a recipient= tag of
>>routing-entity or both MAY do location based routing using
>>the location (as the draft says, it does not have to).  A proxy
>>seeing a locationValue with a recipient=endpoint should understand
>>that the locationValue was not intended to be used for
>>location-based routing.    The draft is pretty clear that the
>>privacy rules in RFC 4119; in Section 5 it says pretty bluntly:
>>
>>   Location Recipients MUST obey the privacy and security rules in the
>>   PIDF-LO as described in RFC 4119 regarding retransmission and
>>   retention.
>>
>>If a proxy is not the intended recipient, as given in this parameter,
>>it shouldn't be storing or acting on this data, just sending it along.
>>
>>
>>>That said, a proxy has "ar" capabilities wrt the Geolocation according to Table 1. (on page 7), and associated text states this pretty clearly. There is no text (not even a hint) that a proxy cannot read a location because "recipient=endpoint", therefore it can.  I would take this "recipient=" parameter as a hint to each type of SIP entity that
>>>
>>>        + if a UAS receives this parameter (meaning in a SIP request with
>>>           a Geolocation header), and it is set to "recipient", the UAS
>>>           shouldn't ignore the location in the request (like it otherwise
>>>           might).
>>>
>>>        + If a proxy receives this parameter (meaning in a SIP request with
>>>           a Geolocation header), and it is set to "server", the proxy
>>>           shouldn't ignore the location in the request (like it otherwise
>>>           might).
>>>
>>>I don't think either indication *ever* means the other SIP entity type cannot view the location, based on the parameter.
>>
>>I don't understand what you mean by "view" here.  A proxy putting this to memory
>>in order to send it along is doing fine; someone doing location-based-routing when
>>recipient=endpoint is not doing the right thing (except in the Emergency Services
>>case, where all bets are off).
>
>RFC3261 says proxies can view message bodies that aren't encrypted.

And what does "view" mean here?  If it understands it enough to know
how to use a pidf-lo object for location-based routing, it pretty much has
to understand it enough to know that it is not an intended recipient of
such a body, based on the header here and the pidf-lo internal rules.
If it doesn't understand pidf-lo, then "viewing" it means something like
"copying", "forwarding", or similar, no?

>I don't see the text giving an exemption in the emergency case, not at least in this doc.

The exception is in the ECRIT documents, or was the last I checked (sorry that I
have no time to confirm now).

>
>> >The only exception I can think of is a Location-by-value hidden by S/MIME means no one save who has the decryption key can view the contents of what's encrypted.
>>>
>>>Does this make sense?
>>
>>I suggest we continue the conversation in GeoPRIV if we have further discussion
>>on this particular point.
>
>But this is a SIP parameter, and a SIP document.  Everything discussed in Geopriv needs to be approved in SIP too.  The SIP WG hasn't heard this part of the discussion because most members of SIP aren't subscribed to the Geopriv list.

I'm reluctant to suggest cross-posting, but I do believe that folks commenting on
this should be aware of the discussion in the Geopriv group prior to this.  I continue
to recommend that folks review the geopriv archive, searching for the document
name, in order to get that context.

Note that deciding to ignore the privacy implications of geopriv's framework is
simply going to create "confusion and delay", as my son's favorite railroad
director says, and if we actually hope to see this work we need to work within
the framework as much as we can.

			regards,
				Ted Hardie






>>                                Ted
>>
>>
>>
>>>James
>>>
>>>At 04:59 AM 11/20/2007, Daniel Grotti wrote:
>>>>Hi all,
>>>>I'd like to ask a question about "draft-ietf-sip-location-conveyance-09.txt".
>>>>
>>>>How does Proxy Server have to work when a Geolocation Header contain "recipient=endpoint" parameter ?
>>>>Does the Proxy server just have to forward the SIP message (without do anything else) or can it read the information conveyed ?
>>>>thanks,
>>>>Regards
>>>>daniel
>>>>
>>>>--
>>>>
>>>>---------------------------------------------------
>>>>Daniel Grotti
>>>>DEIS - University of Bologna
>>>>Via Venezia, 52 - 47023 Cesena (FC) - ITALY
>>>>
>>>>Contacts
>>>>e-mail : daniel.grotti@unibo.it
>>>>Skype name : Daniel Grotti
>>>>---------------------------------------------------
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>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
>>>
>>>
>>>_______________________________________________
>>>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



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 16:14:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuwtu-0003bL-7P; Wed, 21 Nov 2007 16:14:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuwtr-0003Cw-Fq
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:14:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuwtq-00038b-Vp
	for sip@ietf.org; Wed, 21 Nov 2007 16:14:23 -0500
Received: from smtp1.versatel.nl ([62.58.50.88])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuwtq-0001Ot-Hq
	for sip@ietf.org; Wed, 21 Nov 2007 16:14:22 -0500
Received: (qmail 23613 invoked by uid 0); 21 Nov 2007 21:15:23 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6])
	([87.212.11.198]) (envelope-sender )
	by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 21 Nov 2007 21:15:23 -0000
Message-ID: <47449FA0.6050904@zonnet.nl>
Date: Wed, 21 Nov 2007 22:14:08 +0100
From: Jeroen van Bemmel 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Sandesara, Niranjan B" 
Subject: Re: [Sip] Need for RPH in SIP Responses
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Niranjan,

> As has been pointed out earlier, possible security risk of permitting 
> RPH in SIP responses is minimal in managed IP networks where this 
> capability is generally expected to be used.
>
For this argument to apply, the element sending the RPH header in a 
response and the element acting on it should both be in the same domain. 
In other words you are talking about a closed system, a very specific 
environment. The use of this header in this way then clearly does not 
apply to the Internet; the proper way to standardize this is as a 
P-header (instead of taking a header which is already defined in a 
"approved-for-the-Internet" RFC, and modifying its allowed use to 
accommodate for a non-Internet use)

Regards,
Jeroen


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 16:22:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iux23-0006Dx-K9; Wed, 21 Nov 2007 16:22:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iux22-00069M-5N
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:22:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iux21-00066a-NB
	for sip@ietf.org; Wed, 21 Nov 2007 16:22:49 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iux21-0001yw-0k
	for sip@ietf.org; Wed, 21 Nov 2007 16:22:49 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 13:22:48 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lALLMmML002122; 
	Wed, 21 Nov 2007 13:22:48 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALLMVbE026144;
	Wed, 21 Nov 2007 21:22:40 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 13:22:36 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.92.162]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 13:22:36 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 21 Nov 2007 15:22:35 -0600
To: Dean Willis , IETF SIP List 
From: "James M. Polk" 
Subject: Re: [Sip] draft-gunn-sip-req-for-rph-in-responses-00: What is
	impact on response?
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 21 Nov 2007 21:22:36.0440 (UTC)
	FILETIME=[A323D980:01C82C84]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3957; t=1195680168;
	x=1196544168; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20[Sip]=20draft-gunn-sip-req-for-rph-in-responses-00=3A
	=20What=20is=0A=20=20impact=20on=20response? |Sender:=20;
	bh=qCo5WWVpisKysIMwQMcsnNw1mK1AYDd5EW3mDmNAL2Y=;
	b=gGy3pIs+fOu5Q8NGiwwM+aQAeS2hfnKfCcHdZWrb5xN3nkDz+xFHzQxfMmjULXWOp7/h13Mt
	QTgX6adbNx47tC51q14RJzrKAXQieK1ytkMWG4OwW3MXM+5OhlZYvrGH;
Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I'll answer part of your long questionnaire  ;-)

At 02:14 PM 11/21/2007, Dean Willis wrote:
>Now for the questions:
>
>1) RFC 4412 (which defines RPH) is not clear to me on the
>relationship between priorities, requests, responses, and dialogs.

RFC 4412 explicitly creates a priority for requests and dialogs 
within UAs and Proxies that allow a priority to be assigned within a 
namespace.  I agree it isn't so clear about responses; though it has 
text stated proxies should be wary of changing priorities within a 
response by "colluding UAs."

In stateful proxies, responses were supposed to be afforded the same 
priority as their request partner message within a transaction.  This 
is to give all messages within a transaction a priority for special 
handling in processing queues, and rejections if a proxy knew a lower 
priority request wouldn't get through to the destination (perhaps 
because it knew the UAS was already engaged in a higher priority dialog).

RFC 4412 was not clear what to do with responses in stateless 
proxies. This is what draft-polk- sip-rph-in-responses-00 currently addresses.

>Specifically, does an RPH value expressed in an INVITE transaction
>apply to a dialog, or does it apply only to the request in which it
>appears?

see above (it applies to everything (requests and dialogs) except for 
in responses in stateless proxies)

>This has implications for what happens should an RPH value
>change mid-dialog,

obviously the transaction occurs before dialog changes, so the dialog 
would maintain the priority it currently has until successful 
acceptance of the new transaction about the dialog changes the 
priority of the dialog.

>which is what the rph-responses work is proposing.

...which draft-polk- sip-rph-in-responses-00 currently is not yet

>The only way I can see that this works is for RPH values to apply
>only to the request (or perhaps request or response) in which they
>occur.

see my reply, and I think this works everywhere the namespace is 
accepted.  In other words, RPH applies to a transaction involving 
stateful proxies until the dialog starts, which takes on that 
priority within the dialog. If a new transaction occurs within that 
Call-ID, the new priority affects that transaction until it is 
successful, then the dialog takes on that new priority.

>Supporting UAs would then have to remember the RPH value

of course they would, per dialog

>and
>include it in all further requests (and perhaps responses).

yes, unless the request includes a change in priorities within an 
acceptable namespace

>If the
>RPH value is not resent, then the RPH value would cease to apply.

This isn't stated, but I think once a priority is established within 
a dialog, it doesn't cease because a new transaction within that 
dialog didn't contain the same namespace.priority-value.  But I do 
expect any new transaction to contain at least the same RPH values as 
the existing dialog.

>Now
>here's the problem: The RPH value seems to impact the processing of
>the SIP messages themselves, and the priority of the media flow
>established in a dialog.

This isn't a problem, since this is the intent

>So what happens to the priority of a media flow when subsequent 
>transactions within the dialog experience changes in RPH values?

The priority of the media flow changes to match that of the new 
transaction within the established dialog.

If the media established a priority in the first place, it shouldn't 
be hard to change the priority mid-stream, should it?

If this changes the DSCP value, then there needs to be a mechanism to 
change the DSCP.  I didn't rev this ID for this meeting, but I will 
very soon (taking out all mention of servers from the ID to satisfy 
resistance I got within the MMUSIC WG in Chicago)
http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-attribute-01.txt


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 16:26:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iux5d-00008i-Hm; Wed, 21 Nov 2007 16:26:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iux5c-00008T-0m
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:26:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iux5b-00008D-NC
	for sip@ietf.org; Wed, 21 Nov 2007 16:26:31 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iux5Z-0005ja-Cl
	for sip@ietf.org; Wed, 21 Nov 2007 16:26:31 -0500
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 13:26:28 -0800
Received: from crabapple.local ([10.21.67.122])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id lALJxQ54015508;
	Wed, 21 Nov 2007 11:59:26 -0800
Message-ID: <4744A284.9040009@cisco.com>
Date: Wed, 21 Nov 2007 13:26:28 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>
	<47448C1B.7000603@alcatel-lucent.com>
In-Reply-To: <47448C1B.7000603@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1482; t=1195675167;
	x=1196539167; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20
	|Subject:=20Re=3A=20[Sip]=20Re=3A=20URI=20comparison=20rules=20-=20IPv6=2
	0addresses |Sender:=20
	|To:=20=22Vijay=20K.=20Gurbani=22=20;
	bh=HwRfPWaO49tLWed6YmBvjLObQUZed7TIIRO+sjr8374=;
	b=oQRdp1A9Ou4DX3f4hbkniYabFTTOj63bKE9gTj80VViBaN3+qgH78DpsDeKfrYKPrJBTvxPp
	m3UEaO+h527kxiaDbe6vADXyZfQqqK9rs/rhZkJE438SHchBwsew6FfC;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: sip , Brett Tate ,
	Gonzalo Camarillo 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Vijay K. Gurbani wrote:
> Jeroen van Bemmel wrote:
>> Vijay,
>> It's not only IPv6: what about 127.0.0.1 versus 127.000.000.1?
>
> Jeroen: Pedantically speaking, you are probably right.  But
> in practice we do not generally see leading zeros in an IPv4
> octet.
>
> IPv6, with its compressed notation and the need to represent
> hybrid addresses (like IPv4-mapped IPv6 addresses) makes the
> representation issue more acute.  For instance, the low-order
> 32 bits of an IPv4-mapped IPv6 address can be represented using
> the familiar dotted-decimal notation, or they can be represented
> using the IPv6 colon-separated notation.
>
> But your point is well taken: if we put some text about the
> binary equivalence of different textual representations of an
> IPv6 address, I guess we should do so for IPv4 as well.

Doesn't this sort of slide down the slippery slope of understanding
the semantics of the URI for comparison? For example, why can't
you make the same kind of argument for www.example.com and
example.com since they're pretty much synonymous these days?
And for that matter what about comparing example.com and, oh
say, its A(AAA) record? They're the "same", FSVO "same".

Maybe I missed the first post, but is it realistic that something(s)
producing URI's for the same target would create their name in
different manners? And if it is, why wouldn't it be as much of a
problem with the IP address name and a real fqdn?

       Mike


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 16:36:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuxF5-0006tJ-QY; Wed, 21 Nov 2007 16:36:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuxF4-0006rh-7A
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:36:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxF3-0006rY-Tb
	for sip@ietf.org; Wed, 21 Nov 2007 16:36:17 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuxF3-0006G7-D4
	for sip@ietf.org; Wed, 21 Nov 2007 16:36:17 -0500
Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net
	[96.226.64.76]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lALLaBYD027971
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 21 Nov 2007 15:36:11 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>
	
	<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Wed, 21 Nov 2007 15:36:10 -0600
To: Dean Willis 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4873/Wed Nov 21 12:51:49 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

That's an improper dichotomy for the question at hand.

Nobody's arguing against ignoring the SDP if it shows up.

The question to be addressed is the ambiguity the spec currently  
suffers around whether things should put something there.
The danger in leaving the "its ok to put something there because  
things are supposed to ignore it" is the slippery slope that
leads to people _requiring_ it be there, then _requiring_ that it  
mean something (which somebody must already be doing or
people wouldn't be so uptight about it being there) and then we have  
a deployed de-facto standard that does not match the documentation.

Is that what you're arguing for?

RjS

On Nov 21, 2007, at 2:20 PM, Dean Willis wrote:

>
> On Nov 20, 2007, at 8:54 AM, Robert Sparks wrote:
>
>> Yeah - that's not it - it doesn't match your assertion even.
>> That text says that _if_ SDP shows up in the 200, you have to  
>> ignore it.
>> It doesn't say anything about it matching the 18x, and it doesn't  
>> say anything about whether the UAS is allowed to put it in the 200  
>> in the first place.
>>
>> Btw - that passage _IS BEING USED_ to argue that it's ok, and even  
>> _right_, to put SDP in the 200 OK since things MUST ignore it.
>
> Apply Postel's maxim here.
>
> Broken UAs might (and from what I hear, frequently do) ignore the  
> answer in the 18x, instead taking the answer from the 200. If these  
> answers are identical, then it works. If they aren't, then it doesn't.
>
> Is it better to have a clearly described irrecoverable failure or a  
> working call?
>
> --
> Dean



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 16:42:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuxLT-0000BV-Hd; Wed, 21 Nov 2007 16:42:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuxLR-0000BP-NF
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:42:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxLR-0000BH-CZ
	for sip@ietf.org; Wed, 21 Nov 2007 16:42:53 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuxLQ-0002xL-MR
	for sip@ietf.org; Wed, 21 Nov 2007 16:42:53 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lALLggV2020212; 
	Wed, 21 Nov 2007 15:42:42 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lALLgfj07418; Wed, 21 Nov 2007 15:42:41 -0600 (CST)
Message-ID: <4744A651.9010306@alcatel-lucent.com>
Date: Wed, 21 Nov 2007 15:42:41 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Michael Thomas 
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>
	<47448C1B.7000603@alcatel-lucent.com> <4744A284.9040009@cisco.com>
In-Reply-To: <4744A284.9040009@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: sip , Brett Tate ,
	Gonzalo Camarillo 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Michael Thomas wrote:
> Doesn't this sort of slide down the slippery slope of understanding 
> the semantics of the URI for comparison? For example, why can't you
> make the same kind of argument for www.example.com and example.com
> since they're pretty much synonymous these days? And for that matter
> what about comparing example.com and, oh say, its A(AAA) record?
> They're the "same", FSVO "same".

Mike: Our domain is restricted to SIP URIs.  In other words,
while DNS-wise, www.example.com = example.com, this does not carry
into SIP; i.e., sip:user@sip.example.com != sip:user@example.com.

I suppose the rules for SIP URI comparisons are a bit more stringent
than DNS equivalence of names, aliases, and their resulting addresses.

> Maybe I missed the first post, but is it realistic that something(s) 
> producing URI's for the same target would create their name in 
> different manners?

No, not realistic, but entirely probable.

> And if it is, why wouldn't it be as much of a problem with the IP
> address name and a real fqdn?

Because, SIP URI wise, sip:user@example.com != sip:user@192.0.2.128
even though DNS_lookup("example.com") = "192.0.2.128".

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 16:44:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuxN4-00014J-LD; Wed, 21 Nov 2007 16:44:34 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuxN2-00013s-Nc
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:44:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxN2-00013k-Dl
	for sip@ietf.org; Wed, 21 Nov 2007 16:44:32 -0500
Received: from mail146.messagelabs.com ([216.82.245.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuxMy-0006cz-00
	for sip@ietf.org; Wed, 21 Nov 2007 16:44:32 -0500
X-VirusChecked: Checked
X-Env-Sender: mdolly@att.com
X-Msg-Ref: server-13.tower-146.messagelabs.com!1195681467!19025209!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 29524 invoked from network); 21 Nov 2007 21:44:27 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com)
	(144.160.20.54)
	by server-13.tower-146.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2007 21:44:27 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	lALLiQgg011997 for ; Wed, 21 Nov 2007 16:44:26 -0500
Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	lALLiNsL011978 for ; Wed, 21 Nov 2007 16:44:24 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Need for RPH in SIP Responses
Date: Wed, 21 Nov 2007 16:44:23 -0500
Message-ID: <28F05913385EAC43AF019413F674A0171246E6B9@OCCLUST04EVS1.ugd.att.com>
In-Reply-To: <47449FA0.6050904@zonnet.nl>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Need for RPH in SIP Responses
thread-index: Acgsg4XhK7I40DUQS/+kKYPQ5DSu1gAAyWEg
References: 
	<47449FA0.6050904@zonnet.nl>
From: "DOLLY, MARTIN C, ATTLABS" 
To: "Jeroen van Bemmel" ,
	"Sandesara, Niranjan B" 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Jeroen,

It does apply to a concatenation of managed networks, lets say
UE-AT&T-Verizon-UE...Oh, this is the same concatenation for what you are
referring to as the "internet"..right? Only difference is a different
portion of our IP backbones.

More important here (please just don't cut/paste the above without
this), for wireless access the user's priority level may change based on
call processing, including authentication, and this needs to be relayed
back to the wireless access.

Cheers,

Martin=20

-----Original Message-----
From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20
Sent: Wednesday, November 21, 2007 4:14 PM
To: Sandesara, Niranjan B
Cc: sip@ietf.org
Subject: Re: [Sip] Need for RPH in SIP Responses

Niranjan,

> As has been pointed out earlier, possible security risk of permitting=20
> RPH in SIP responses is minimal in managed IP networks where this=20
> capability is generally expected to be used.
>
For this argument to apply, the element sending the RPH header in a=20
response and the element acting on it should both be in the same domain.

In other words you are talking about a closed system, a very specific=20
environment. The use of this header in this way then clearly does not=20
apply to the Internet; the proper way to standardize this is as a=20
P-header (instead of taking a header which is already defined in a=20
"approved-for-the-Internet" RFC, and modifying its allowed use to=20
accommodate for a non-Internet use)

Regards,
Jeroen


_______________________________________________
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


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 16:58:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuxa5-0001RX-TL; Wed, 21 Nov 2007 16:58:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuxa4-0001RE-DQ
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:58:00 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuxa4-0001R1-2J
	for sip@ietf.org; Wed, 21 Nov 2007 16:58:00 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuxa3-0003cx-KS
	for sip@ietf.org; Wed, 21 Nov 2007 16:57:59 -0500
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-3.cisco.com with ESMTP; 21 Nov 2007 13:57:59 -0800
Received: from crabapple.local ([10.21.67.122])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id lALKUvwH016811;
	Wed, 21 Nov 2007 12:30:57 -0800
Message-ID: <4744A9E7.40306@cisco.com>
Date: Wed, 21 Nov 2007 13:57:59 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>
	<47448C1B.7000603@alcatel-lucent.com> <4744A284.9040009@cisco.com>
	<4744A651.9010306@alcatel-lucent.com>
In-Reply-To: <4744A651.9010306@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1910; t=1195677058;
	x=1196541058; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20
	|Subject:=20Re=3A=20[Sip]=20Re=3A=20URI=20comparison=20rules=20-=20IPv6=2
	0addresses |Sender:=20
	|To:=20=22Vijay=20K.=20Gurbani=22=20;
	bh=KCKCKsuvFrr0M2vaguUHmzn8R8TSSpRKBhIl8DcVK3c=;
	b=HyT/Q3oqjTUdLcetv0UWPzsxjQpZQMm9ozrKxakqtLG1y7/gFYyfArQAgRktp71/naLB1oNN
	iIlziUXst0MJkNT6zpYNk/0g3PE0++H/RsQL5laeS9ernx8ypYqKWIeS;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: sip , Brett Tate ,
	Gonzalo Camarillo 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Vijay K. Gurbani wrote:
> Michael Thomas wrote:
>> Doesn't this sort of slide down the slippery slope of understanding 
>> the semantics of the URI for comparison? For example, why can't you
>> make the same kind of argument for www.example.com and example.com
>> since they're pretty much synonymous these days? And for that matter
>> what about comparing example.com and, oh say, its A(AAA) record?
>> They're the "same", FSVO "same".
>
> Mike: Our domain is restricted to SIP URIs.  In other words,
> while DNS-wise, www.example.com = example.com, this does not carry
> into SIP; i.e., sip:user@sip.example.com != sip:user@example.com.
>
> I suppose the rules for SIP URI comparisons are a bit more stringent
> than DNS equivalence of names, aliases, and their resulting addresses.
>

This of course leads us into the mysterious rat hole of what constitutes
"same", but...
>> Maybe I missed the first post, but is it realistic that something(s) 
>> producing URI's for the same target would create their name in 
>> different manners?
>
> No, not realistic, but entirely probable.
>
>> And if it is, why wouldn't it be as much of a problem with the IP
>> address name and a real fqdn?
>
> Because, SIP URI wise, sip:user@example.com != sip:user@192.0.2.128
> even though DNS_lookup("example.com") = "192.0.2.128".

Well, that's sort of my point: if you have something(s) writing URI's
for the same entity in different ways, it seems just as likely that they
might write them as sip:user@example.com and 192.0.2.128 as
they would by writing different representations of IPv6 addresses.
Here's another corner case: try multi-homed servers.

Let me put it another way: if there is something dire that happens if
two different representations of the same identity can't be compared
as equal, then your problem runs much deeper than the special IPv6
case.

       Mike


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:05:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuxhP-0005xq-FB; Wed, 21 Nov 2007 17:05:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuxhO-0005xl-Qd
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:05:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxhO-0005xd-07
	for sip@ietf.org; Wed, 21 Nov 2007 17:05:34 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuxhJ-0007Rm-OR
	for sip@ietf.org; Wed, 21 Nov 2007 17:05:33 -0500
Received: (qmail invoked by alias); 21 Nov 2007 22:05:28 -0000
Received: from p54985C5A.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.92.90]
	by mail.gmx.net (mp010) with SMTP; 21 Nov 2007 23:05:28 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+oZaoHp+WoScToHux+oDHWkw7GMJ9S6vWtH1dgtH
	T3xEL7tOTDg+5b
Message-ID: <4744ABA5.2090501@gmx.net>
Date: Wed, 21 Nov 2007 23:05:25 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Robert Sparks 
References: <753B4BA1-2934-4A88-A6F0-5B55801E0A76@nostrum.com>
In-Reply-To: <753B4BA1-2934-4A88-A6F0-5B55801E0A76@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: sip List 
Subject: [Sip] SIPit 21 summary & Security
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi Robert,

I have a question regarding a few sub-items:

> Implementations using each transport for SIP messages:
>   UDP    100%
>   TCP     82%
>   TLS     49% (server auth only)
>   TLS      6% (mutual auth)
>   SCTP      3%
>   DTLS      0%
>
> 36% of the implementations supported SIP over IPv6 (up from 25% at 
> SIPit20)
> 18% supported SIP over IPSec
What does it mean when someone supports SIP over IPsec?
 IPsec is independent of SIP. Is this referring to the 3GPP IPsec 
security between the UA and the P-CSCF?

> Support for various items:
>   61% rport
>   15% sigcomp
>   22% enum
>   21% sending multiplexing STUN and SIP
>   28% receiving multiplexed STUN and SIP
>   22% RFC4320 fixes
>   12% identity
>   70% session-timer
>
What type of SIP Identity support is this?
Is this support at the proxy for creating the SIP Identity header?
Is this support at the end host for creating the SIP Identity header?
Is this support at proxies that verify SIP identity?
Is this support by UAs verifying SIP identity?

> Support for various things in the endpoints:
>   10%   ICE (but there was no interoperability - see below)
>    0%   ICE-TCP
>   13%    STUNbis
>   17%    TURN (again, there was no interoperability)
>   75%    symmetric RTP
>   25%    SRTP
>    0%    RTP over DTLS
RTP over DTLS was an idea in an old draft for media security. The 
document was dumped. Hence, the 0% is not surprising.

Ciao
Hannes



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:11:15 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuxml-0006zK-02; Wed, 21 Nov 2007 17:11:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuxmh-0006vc-Jh
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:11:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuxmh-0006vT-5G
	for sip@ietf.org; Wed, 21 Nov 2007 17:11:03 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuxmg-00048V-QP
	for sip@ietf.org; Wed, 21 Nov 2007 17:11:03 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lALMAxLE004847
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 21 Nov 2007 16:11:01 -0600
In-Reply-To: 
References: 
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5A8C011C-2D22-44F7-B98A-47CC81C97F8E@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] draft-gunn-sip-req-for-rph-in-responses-00: What is impact
	on response?
Date: Wed, 21 Nov 2007 16:10:53 -0600
To: "James M. Polk" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 21, 2007, at 3:22 PM, James M. Polk wrote:
>> If the
>> RPH value is not resent, then the RPH value would cease to apply.
>
> This isn't stated, but I think once a priority is established  
> within a dialog, it doesn't cease because a new transaction within  
> that dialog didn't contain the same namespace.priority-value.  But  
> I do expect any new transaction to contain at least the same RPH  
> values as the existing dialog.

If RPH can change on a per-message cycle within a dialog, is the  
transmission of a message without an RPH header within the dialog the  
same as explicitly sending an RPH that conveys no priority? This  
needs to be clear in the documentation.

--
dean


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:18:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuxu7-0002A8-KQ; Wed, 21 Nov 2007 17:18:43 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuxu5-0002A2-GZ
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:18:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuxu5-00029p-6f
	for sip@ietf.org; Wed, 21 Nov 2007 17:18:41 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuxu0-0007uF-MP
	for sip@ietf.org; Wed, 21 Nov 2007 17:18:41 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 14:18:36 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALMIaTe030585; 
	Wed, 21 Nov 2007 14:18:36 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lALMHeBT002284;
	Wed, 21 Nov 2007 22:18:36 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 14:18:32 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.92.162]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 14:18:32 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 21 Nov 2007 16:18:30 -0600
To: Ted Hardie , Daniel Grotti , 
	IETF SIP List 
From: "James M. Polk" 
Subject: Re: [Sip] a question about IETF draft location conveyance 09
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>
	
	
	
	
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 21 Nov 2007 22:18:32.0164 (UTC)
	FILETIME=[734EB240:01C82C8C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12759; t=1195683516;
	x=1196547516; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20[Sip]=20a=20question=20about=20IETF=20draft=20locatio
	n=20conveyance=2009 |Sender:=20;
	bh=EqfvWYhJ20h4SjEoeaVHdtfXqxg1Mg1iQrJkYfedfdc=;
	b=YHe7Y9TA9ru456MuEGF9hDSAXIu5jMP+lpD+bJSHURlhtHdTSAb+qERZT5SvZj0lBA4V8Tar
	Q1qBLqEUd1EfdRauj2x7t0bIADkFq9ygR/btD49cFU/EX07zS/b3x9+Upj3EHCE281eUI49kh8
	8FxwvA4/SUvxWtTfWORdIZ+6A=;
Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 03:02 PM 11/21/2007, Ted Hardie wrote:
>At 2:28 PM -0600 11/21/07, James M. Polk wrote:
> >Ted
> >
> >The "recipient=" within the Geolocation header is a SIP parameter, 
> in a SIP document.  Everything discussed in Geopriv regarding this 
> document needs to be approved in SIP too.  The SIP WG hasn't heard 
> this part of the discussion because most members of SIP aren't 
> subscribed to the Geopriv list.
>
>That SIP parameter in a SIP document relates to a PIDF-LO object carried by
>SIP; in that context, SIP is a using protocol of the GEOPRIV framework.  SIP
>folks should certainly understand the work they're reusing, or the 
>implementations
>won't do the right thing.  But re-starting the conversation in SIP without
>reference to the discussions that have already occurred in GeoPRIV is a
>recipe for conflict at IETF Last Call.  We might as well start getting people
>on the same page now.  From my  perspective, the right way to do that is
>to start the discussion from where it last left off, even if that wasn't in
>the same group.  That tells people where the consensus of that group was
>and informs the rest of the discussion.

Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains 
to the SIP WG's expertise in knowing and agreeing with SIP's ability 
to foresee the type of topology from UAC to UAS, and each server 
(whether there even is one) in between.  I'm not so sure the SIP WG 
agrees that a UAC can make this determination, and am soliciting 
their input here in a broad way.

Can a UAC understand enough about the topology of the Internet to 
understand where it is sending a request, including how SIP servers 
may or may not act upon that request?

I believe, if the answer is no, the the "recipient=" parameter is a 
flawed SIP header parameter.

If the answer is yes, then it stays with no further arguments from me.


> >
> >I'm on the agenda right now to present in SIP in Vancouver, and 
> this is one issue I'd like the SIP WG to comment on, so I'll be 
> asking it there.
>
>I look forward to your presentation.

The above question is what I'll propose to the SIP WG, nothing 
more.  If they ask for an example, I'll give them the Pizza Hut 
example I did on this thread a few messages ago.


>Further commments inline.
>
>
>
> >the rest of my reply is in-line
> >
> >At 01:51 PM 11/21/2007, Ted Hardie wrote:
> >>At 6:33 PM -0600 11/20/07, James M. Polk wrote:
> >>>Daniel
> >>>
> >>>wow... you nailed this one quickly.
> >>>
> >>>Neither the SIP WG nor Geopriv WG have a position with regard to 
> this.  I don't like the parameter at all, and have said so from its 
> introduction into discussions about putting it in the draft.  I 
> don't think it accomplishes much more than confusion or a false 
> sense of security by implementors.
> >>
> >>Well, I think the Geopriv working group discussed this a great 
> deal, and that
> >>there was reasonable (albeit rough) consensus that it be included.  Anyone
> >>interested can certainly see a lively debate on the Geopriv list.
> >
> >and where was the SIP WG discussion on a SIP header 
> parameter?  Since this parameter, from what you state below,  has a 
> UA understanding the topology of a request - all the way to the 
> endpoint - which is not part of the Geopriv charter to know or make 
> decisions on, where's that discussion, at least as confirmation 
> that SIP UAC's can know the full topology of a network enough to 
> make this decision (that can't be changed)?
>
>You are making a big leap here.  It doesn't have a UA understanding 
>of the topology;
>it has User control over private information.  The user gets to say 
>by whom his or
>her location gets used; that's a core aspect of RFC 4119 and 
>friends, and you don't
>get to reuse that work without getting that assumption built in.  We've had
>exceptions for emergency services (discussed in the ECRIT BCPs), but they're
>not general.  If a user does not want that private information used by the
>SIP routing system but is willing to give it to the SIP entity 
>receiving the call,
>the system has to provide a way of making that clear.  We discussed several
>ways to achieve that (including changes to 4119), and there was pretty
>clear consensus on this way forward.  The version with retransmission-allowed
>or routing-query-allowed did not see support, nor did redefining 
>"retransmission=no"
>to mean "except for SIP".
>
>Yes, this does mean that a UA that sends a location object with 
>recipient=end-point
>may have a call fail if location-based routing is absolutely 
>required; so will any
>call not containing location, though, and the UA will have to be 
>able to handle
>that case.  It may very well be what is wanted, as we discussed in relation to
>taxi services at some length (I may be willing to send my location to a local
>taxi service so it can send the taxi, but not willing to send my location to
>the sip-routing system so it can pick a taxi-service local to me).
>
> >For example, Alice calls PizzaHut.com, and Pizza Hut routes her 
> call to the Pizza Hut store most local to wherever she is to take 
> her order.  Does her UAC understand this type of call well enough 
> to have "recipient=both"?  Or would it just enter 
> "recipient=endpoint", thus preventing her SIP request from being retargetted?
> >
> >How does her UAC understand the different from this type of call 
> to Pizza Hut from merely a complaint to Pizza Hut corporate?
> >
> >I still can't seem to get over this simple example of a limitation 
> and assumption created by this header parameter that the caller 
> doesn't control.
>
>Perhaps I don't see what you mean by "caller doesn't control" here.  Can you
>elaborate?
>
>
>
> >
> >>The current text is:
> >>A locationValue has the following independent header parameters,
> >>
> >>(snip of other parameters)
> >>
> >>the "recipient=" parameter to allow recipients to infer what SIP
> >>      element type this locationValue was intended to be for.  The
> >>      types are
> >>
> >>         o "endpoint" - meaning the ultimate destination UAS;
> >>
> >>         o "routing-entity" - meaning SIP servers that route messages
> >>                    based on the location contents of requests; and
> >>
> >>         o "both" - meaning this locationValue is to be viewed by both
> >>                    types of SIP entities.
> >>
> >>      Not all SIP entities have to read the locationValue within a
> >>      Geolocation header, therefore a parameter value of "both" does
> >>      not mean "every" SIP element receiving this request, it means all
> >>      that care to pay attention to a locationValue.  The default
> >>      behavior of SIP entities reading the locationValue is that if
> >>      this header parameter is NOT present, the intended recipient is
> >>      the destination UAS.
> >>
> >>A proxy seeing a locationValue with a recipient= tag of
> >>routing-entity or both MAY do location based routing using
> >>the location (as the draft says, it does not have to).  A proxy
> >>seeing a locationValue with a recipient=endpoint should understand
> >>that the locationValue was not intended to be used for
> >>location-based routing.    The draft is pretty clear that the
> >>privacy rules in RFC 4119; in Section 5 it says pretty bluntly:
> >>
> >>   Location Recipients MUST obey the privacy and security rules in the
> >>   PIDF-LO as described in RFC 4119 regarding retransmission and
> >>   retention.
> >>
> >>If a proxy is not the intended recipient, as given in this parameter,
> >>it shouldn't be storing or acting on this data, just sending it along.
> >>
> >>
> >>>That said, a proxy has "ar" capabilities wrt the Geolocation 
> according to Table 1. (on page 7), and associated text states this 
> pretty clearly. There is no text (not even a hint) that a proxy 
> cannot read a location because "recipient=endpoint", therefore it 
> can.  I would take this "recipient=" parameter as a hint to each 
> type of SIP entity that
> >>>
> >>>        + if a UAS receives this parameter (meaning in a SIP request with
> >>>           a Geolocation header), and it is set to "recipient", the UAS
> >>>           shouldn't ignore the location in the request (like it otherwise
> >>>           might).
> >>>
> >>>        + If a proxy receives this parameter (meaning in a SIP 
> request with
> >>>           a Geolocation header), and it is set to "server", the proxy
> >>>           shouldn't ignore the location in the request (like it otherwise
> >>>           might).
> >>>
> >>>I don't think either indication *ever* means the other SIP 
> entity type cannot view the location, based on the parameter.
> >>
> >>I don't understand what you mean by "view" here.  A proxy putting 
> this to memory
> >>in order to send it along is doing fine; someone doing 
> location-based-routing when
> >>recipient=endpoint is not doing the right thing (except in the 
> Emergency Services
> >>case, where all bets are off).
> >
> >RFC3261 says proxies can view message bodies that aren't encrypted.
>
>And what does "view" mean here?  If it understands it enough to know
>how to use a pidf-lo object for location-based routing, it pretty much has
>to understand it enough to know that it is not an intended recipient of
>such a body, based on the header here and the pidf-lo internal rules.
>If it doesn't understand pidf-lo, then "viewing" it means something like
>"copying", "forwarding", or similar, no?
>
> >I don't see the text giving an exemption in the emergency case, 
> not at least in this doc.
>
>The exception is in the ECRIT documents, or was the last I checked 
>(sorry that I
>have no time to confirm now).
>
> >
> >> >The only exception I can think of is a Location-by-value hidden 
> by S/MIME means no one save who has the decryption key can view the 
> contents of what's encrypted.
> >>>
> >>>Does this make sense?
> >>
> >>I suggest we continue the conversation in GeoPRIV if we have 
> further discussion
> >>on this particular point.
> >
> >But this is a SIP parameter, and a SIP document.  Everything 
> discussed in Geopriv needs to be approved in SIP too.  The SIP WG 
> hasn't heard this part of the discussion because most members of 
> SIP aren't subscribed to the Geopriv list.
>
>I'm reluctant to suggest cross-posting, but I do believe that folks 
>commenting on
>this should be aware of the discussion in the Geopriv group prior to 
>this.  I continue
>to recommend that folks review the geopriv archive, searching for the document
>name, in order to get that context.
>
>Note that deciding to ignore the privacy implications of geopriv's 
>framework is
>simply going to create "confusion and delay", as my son's favorite railroad
>director says, and if we actually hope to see this work we need to work within
>the framework as much as we can.
>
>                         regards,
>                                 Ted Hardie
>
>
>
>
>
>
> >>                                Ted
> >>
> >>
> >>
> >>>James
> >>>
> >>>At 04:59 AM 11/20/2007, Daniel Grotti wrote:
> >>>>Hi all,
> >>>>I'd like to ask a question about 
> "draft-ietf-sip-location-conveyance-09.txt".
> >>>>
> >>>>How does Proxy Server have to work when a Geolocation Header 
> contain "recipient=endpoint" parameter ?
> >>>>Does the Proxy server just have to forward the SIP message 
> (without do anything else) or can it read the information conveyed ?
> >>>>thanks,
> >>>>Regards
> >>>>daniel
> >>>>
> >>>>--
> >>>>
> >>>>---------------------------------------------------
> >>>>Daniel Grotti
> >>>>DEIS - University of Bologna
> >>>>Via Venezia, 52 - 47023 Cesena (FC) - ITALY
> >>>>
> >>>>Contacts
> >>>>e-mail : daniel.grotti@unibo.it
> >>>>Skype name : Daniel Grotti
> >>>>---------------------------------------------------
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>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
> >>>
> >>>
> >>>_______________________________________________
> >>>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


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:23:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuxyD-0003Kk-Fm; Wed, 21 Nov 2007 17:22:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuxyB-0003KQ-Lk
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:22:55 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxyB-0003KD-Ao
	for sip@ietf.org; Wed, 21 Nov 2007 17:22:55 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuxyA-0004hr-PY
	for sip@ietf.org; Wed, 21 Nov 2007 17:22:55 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lALMMpPw004947
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 21 Nov 2007 16:22:53 -0600
In-Reply-To: <650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>
	
	<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>
	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Wed, 21 Nov 2007 16:22:45 -0600
To: Robert Sparks 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 21, 2007, at 3:36 PM, Robert Sparks wrote:

> That's an improper dichotomy for the question at hand.

Why? The question at hand is, if I have it "If we send an answer in a  
reliable provisional response, should we include a copy of that  
answer in the final 200 OK response?"

We agree that IF we send the answer in both places, then it MUST be  
the same answer, because if it isn't then all sorts of things get  
confusing. Right? The only question is whether or not to include it.

> Nobody's arguing against ignoring the SDP if it shows up.
>
> The question to be addressed is the ambiguity the spec currently  
> suffers around whether things should put something there.
> The danger in leaving the "its ok to put something there because  
> things are supposed to ignore it" is the slippery slope that
> leads to people _requiring_ it be there, then _requiring_ that it  
> mean something (which somebody must already be doing or
> people wouldn't be so uptight about it being there) and then we  
> have a deployed de-facto standard that does not match the  
> documentation.
>
> Is that what you're arguing for?

Well, I hope I'm not arguing in favor of ambiguity.

I'm trying to argue for stating in section 2.1 of draft-ietf-sipping- 
sip-offeranswer-04.txt (pattern 3) that the final 200 OK  either MAY  
or SHOULD contain a copy of the offer sent in the reliable  
provisional response, as this approach offers less backward  
compatibility headache than not including a copy of the answer. It's  
also consistent with the "preview" model of sending an answer in a  
non-reliable provisional response as discussed in section 3.1 of that  
draft.

--
Dean


--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:23:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuxyU-0003lx-H2; Wed, 21 Nov 2007 17:23:14 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuxyS-0003ll-Ol
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:23:12 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxyS-0003ld-E5
	for sip@ietf.org; Wed, 21 Nov 2007 17:23:12 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuxyS-0004ig-1X
	for sip@ietf.org; Wed, 21 Nov 2007 17:23:12 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lALMMtsn028981; 
	Wed, 21 Nov 2007 16:22:56 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lALMMmj21161; Wed, 21 Nov 2007 16:22:48 -0600 (CST)
Message-ID: <4744AFB8.7030801@lucent.com>
Date: Wed, 21 Nov 2007 16:22:48 -0600
From: "Vijay K. Gurbani" 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Paul Kyzivat , Hadriel Kaplan 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com>
In-Reply-To: <47437A45.40409@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:
> We have a lot of history of people taking carefully phrased things like 
> this and using them to justify a lot of incorrect behavior. We don't 
> want this to be misconstrued.

Paul, Hadriel: So ... where do we stand on this?  It appears that
Digest challenge for proxies is a non-starter.  Yesterday, I
had suggested something along these lines:

   If A opens up a TCP connection to B, and it has some policy such
   that it considers B to be trusted, it MAY insert an alias parameter
   in the topmost Via of that request.  This will cause B to send
   requests in the backwards direction over that connection.
   Exactly what this policy is will be left up to each service
   provider and implementation.

   The draft can adequately warn implementations not to do so over
   TCP due to various security reasons documented elsewhere in the
   draft.  The normative strength of reusing a TCP connection in
   this manner could be left as a SHOULD, with strong incentives
   to perform connection reuse only over TLS.

This, of course, means that there is connection reuse in TCP
as well (i.e., using one TCP stream), but is not encouraged by
the draft, and implementations doing so will have adequately
weighed in the associated risks before doing so.

Would this be a working solution that will strike a middle-
ground?  Is this agreeable?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:30:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuy5u-0000B3-OY; Wed, 21 Nov 2007 17:30:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuy5s-0000Ag-Jz
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:30:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuy5s-0000AM-9e
	for sip@ietf.org; Wed, 21 Nov 2007 17:30:52 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuy5n-0008Ps-52
	for sip@ietf.org; Wed, 21 Nov 2007 17:30:52 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lALMUfpO006411; 
	Wed, 21 Nov 2007 16:30:41 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lALMUdj23482; Wed, 21 Nov 2007 16:30:39 -0600 (CST)
Message-ID: <4744B18F.5080609@alcatel-lucent.com>
Date: Wed, 21 Nov 2007 16:30:39 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Michael Thomas 
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>
	<47448C1B.7000603@alcatel-lucent.com> <4744A284.9040009@cisco.com>
	<4744A651.9010306@alcatel-lucent.com> <4744A9E7.40306@cisco.com>
In-Reply-To: <4744A9E7.40306@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: sip , Brett Tate ,
	Gonzalo Camarillo 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Michael Thomas wrote:
> Well, that's sort of my point: if you have something(s) writing URI's
> for the same entity in different ways, it seems just as likely that they
> might write them as sip:user@example.com and 192.0.2.128 as
> they would by writing different representations of IPv6 addresses.
> Here's another corner case: try multi-homed servers.

Michael: Insofar as these URIs are used purely for routing purposes,
I don't think it matters what the representation is.  But if they
are used for identification purposes or for any other purpose (like
including them in a hash for loop detection), then it matters what
their representation is.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:44:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuyIY-0007SG-LZ; Wed, 21 Nov 2007 17:43:58 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuyIX-0007Rx-2y
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:43:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyIW-0007Ro-OS
	for sip@ietf.org; Wed, 21 Nov 2007 17:43:56 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuyIW-0005ZA-7Y
	for sip@ietf.org; Wed, 21 Nov 2007 17:43:56 -0500
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-3.cisco.com with ESMTP; 21 Nov 2007 14:43:55 -0800
Received: from crabapple.local ([10.21.67.122])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id lALLGsMx018649;
	Wed, 21 Nov 2007 13:16:54 -0800
Message-ID: <4744B4AB.1040403@cisco.com>
Date: Wed, 21 Nov 2007 14:43:55 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>
	<47448C1B.7000603@alcatel-lucent.com> <4744A284.9040009@cisco.com>
	<4744A651.9010306@alcatel-lucent.com> <4744A9E7.40306@cisco.com>
	<4744B18F.5080609@alcatel-lucent.com>
In-Reply-To: <4744B18F.5080609@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1438; t=1195679815;
	x=1196543815; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20
	|Subject:=20Re=3A=20[Sip]=20Re=3A=20URI=20comparison=20rules=20-=20IPv6=2
	0addresses |Sender:=20
	|To:=20=22Vijay=20K.=20Gurbani=22=20;
	bh=BlBlGrnDbGIro28FNanZER0EpkyMftpejpF1KAjStSk=;
	b=LqECLtfhd3GZ6klO/kcwnP/Zcw82osbiDuljxurIe+aoCCCyIDwTGtBSrMUr9dBDp2Tf2bqn
	RZxAfFvfsA4mAAUfZyhRXf1+MSRDDcABxG5DNoGWdTvqTwlqD4VhByJW;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip , Brett Tate ,
	Gonzalo Camarillo 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Vijay K. Gurbani wrote:
> Michael Thomas wrote:
>> Well, that's sort of my point: if you have something(s) writing URI's
>> for the same entity in different ways, it seems just as likely that they
>> might write them as sip:user@example.com and 192.0.2.128 as
>> they would by writing different representations of IPv6 addresses.
>> Here's another corner case: try multi-homed servers.
>
> Michael: Insofar as these URIs are used purely for routing purposes,
> I don't think it matters what the representation is.  But if they
> are used for identification purposes or for any other purpose (like
> including them in a hash for loop detection), then it matters what
> their representation is.

Sorry if I'm belaboring this Vijay. I definitely agree if that you're using
them as a locator, it doesn't matter. But for loop detection, wouldn't that
require that the same entity that wrote the via to write it in different 
ways
to foil the loop detector? It seems to me that either this is pathological
(ie, example.com and 192.0.2.128) or it's a non-problem because the
(same) entity shouldn't be writing it in different ways in the first place.


Put another way: If I want loop detection to work with things under my
control, I better make certain that the names are stringwise-identical, not
just route to the same identity. Which is not specific to IPv6, and thus
we shouldn't special case it.

       Mike


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:49:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuyO8-0008UQ-V9; Wed, 21 Nov 2007 17:49:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuyO6-0008Qs-Lo
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:49:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyO5-0008Qb-Sr
	for sip@ietf.org; Wed, 21 Nov 2007 17:49:41 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuyO5-0005oO-Gz
	for sip@ietf.org; Wed, 21 Nov 2007 17:49:41 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lALMnXeO014547; 
	Wed, 21 Nov 2007 16:49:33 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lALMnXj29765; Wed, 21 Nov 2007 16:49:33 -0600 (CST)
Message-ID: <4744B5FC.6030408@alcatel-lucent.com>
Date: Wed, 21 Nov 2007 16:49:32 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Michael Thomas 
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>
	<47448C1B.7000603@alcatel-lucent.com> <4744A284.9040009@cisco.com>
	<4744A651.9010306@alcatel-lucent.com> <4744A9E7.40306@cisco.com>
	<4744B18F.5080609@alcatel-lucent.com> <4744B4AB.1040403@cisco.com>
In-Reply-To: <4744B4AB.1040403@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip , Brett Tate ,
	Gonzalo Camarillo 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Michael Thomas wrote:
> Sorry if I'm belaboring this Vijay. I definitely agree if that you're
> using them as a locator, it doesn't matter. But for loop detection,
> wouldn't that require that the same entity that wrote the via to
> write it in different ways to foil the loop detector? It seems to me
> that either this is pathological (ie, example.com and 192.0.2.128) or
> it's a non-problem because the (same) entity shouldn't be writing it
> in different ways in the first place.

Right, precisely what I wrote in an earlier email in this thread:

   Admittedly, the upstream proxy should not be inserting different
   representations of the same IP address in each request (unless, of
   course it is malicious; but then if it is malicious, it could
   probably do damage by other means.)

> Put another way: If I want loop detection to work with things under
> my control, I better make certain that the names are
> stringwise-identical, not just route to the same identity. Which is
> not specific to IPv6, and thus we shouldn't special case it.

Agreed.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 17:59:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuyXn-0007YH-FJ; Wed, 21 Nov 2007 17:59:43 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuyXl-0007Qw-IT
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:59:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyXl-0007OJ-5e
	for sip@ietf.org; Wed, 21 Nov 2007 17:59:41 -0500
Received: from smtp3.versatel.nl ([62.58.50.90])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyXi-0001MY-Du
	for sip@ietf.org; Wed, 21 Nov 2007 17:59:41 -0500
Received: (qmail 5526 invoked by uid 0); 21 Nov 2007 22:59:13 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6])
	([87.212.11.198]) (envelope-sender )
	by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 21 Nov 2007 22:59:13 -0000
Message-ID: <4744B854.1040605@zonnet.nl>
Date: Wed, 21 Nov 2007 23:59:32 +0100
From: Jeroen van Bemmel 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "DOLLY, MARTIN C, ATTLABS" 
Subject: Re: [Sip] Need for RPH in SIP Responses
References: 
	<47449FA0.6050904@zonnet.nl>
	<28F05913385EAC43AF019413F674A0171246E6B9@OCCLUST04EVS1.ugd.att.com>
In-Reply-To: <28F05913385EAC43AF019413F674A0171246E6B9@OCCLUST04EVS1.ugd.att.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: sip@ietf.org, "Sandesara, Niranjan B" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Martin,

It appears we have a different view on what constitutes the Internet - 
perhaps because I am not from the US. In any case, I was referring to 
the Internet as a whole, exactly as in RFC3455:

The SIP extensions specified in this document make certain
   assumptions regarding network topology, linkage between SIP and lower
   layers, and the availability of transitive trust.  These assumptions
   are generally NOT APPLICABLE in the Internet as a whole.

The proposed mechanism is only secure under assumptions that do not hold 
in the Internet as a whole. It is not only a minor change from the 
current RPH usage, as draft-polk-sip-rph-in-responses-00 tries to say 
("The only new security threat...")

To me, there are 3 things that could happen:
1. ignore/accept it and generate an RFC
2. define additional security measures to mitigate
3. consider a different solution

Regards,
Jeroen

DOLLY, MARTIN C, ATTLABS wrote:
> Jeroen,
>
> It does apply to a concatenation of managed networks, lets say
> UE-AT&T-Verizon-UE...Oh, this is the same concatenation for what you are
> referring to as the "internet"..right? Only difference is a different
> portion of our IP backbones.
>
> More important here (please just don't cut/paste the above without
> this), for wireless access the user's priority level may change based on
> call processing, including authentication, and this needs to be relayed
> back to the wireless access.
>
> Cheers,
>
> Martin 
>
> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] 
> Sent: Wednesday, November 21, 2007 4:14 PM
> To: Sandesara, Niranjan B
> Cc: sip@ietf.org
> Subject: Re: [Sip] Need for RPH in SIP Responses
>
> Niranjan,
>
>   
>> As has been pointed out earlier, possible security risk of permitting 
>> RPH in SIP responses is minimal in managed IP networks where this 
>> capability is generally expected to be used.
>>
>>     
> For this argument to apply, the element sending the RPH header in a 
> response and the element acting on it should both be in the same domain.
>
> In other words you are talking about a closed system, a very specific 
> environment. The use of this header in this way then clearly does not 
> apply to the Internet; the proper way to standardize this is as a 
> P-header (instead of taking a header which is already defined in a 
> "approved-for-the-Internet" RFC, and modifying its allowed use to 
> accommodate for a non-Internet use)
>
> Regards,
> Jeroen
>
>
> _______________________________________________
> 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
>
>   


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 18:16:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuynY-0004RL-Om; Wed, 21 Nov 2007 18:16:00 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuynW-0004R4-EM
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:15:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuynW-0004Qq-4W
	for sip@ietf.org; Wed, 21 Nov 2007 18:15:58 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuynQ-00027t-3Q
	for sip@ietf.org; Wed, 21 Nov 2007 18:15:58 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 21 Nov 2007 18:15:52 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALNFpOJ005411; 
	Wed, 21 Nov 2007 18:15:51 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALNFTKj004371; 
	Wed, 21 Nov 2007 23:15:51 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 18:15:29 -0500
Received: from [10.82.210.128] ([10.82.210.128]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 18:15:28 -0500
Message-ID: <4744BC10.40301@cisco.com>
Date: Wed, 21 Nov 2007 18:15:28 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
In-Reply-To: <48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 23:15:28.0915 (UTC)
	FILETIME=[67D98630:01C82C94]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2792; t=1195686951;
	x=1196550951; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20
	|To:=20Dean=20Willis=20;
	bh=XXem+USxvhEiWv8NPjg3Xiu80yd+tQehC1FF45a+/6U=;
	b=msn0NEQsYEZattHS9lXHJYTDE4tKqwWyaxRr40ktlGFECI0981F7aJAgoujbokKezCm0WJon
	a3QCkP92Kt7bh+n9zxKyKSfzGOSNov5tVRkxyZUyisik7qej6KA1zn5T;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> 
> On Nov 21, 2007, at 3:36 PM, Robert Sparks wrote:
> 
>> That's an improper dichotomy for the question at hand.
> 
> Why? The question at hand is, if I have it "If we send an answer in a 
> reliable provisional response, should we include a copy of that answer 
> in the final 200 OK response?"
> 
> We agree that IF we send the answer in both places, then it MUST be the 
> same answer, because if it isn't then all sorts of things get confusing. 
> Right? The only question is whether or not to include it.
> 
>> Nobody's arguing against ignoring the SDP if it shows up.
>>
>> The question to be addressed is the ambiguity the spec currently 
>> suffers around whether things should put something there.
>> The danger in leaving the "its ok to put something there because 
>> things are supposed to ignore it" is the slippery slope that
>> leads to people _requiring_ it be there, then _requiring_ that it mean 
>> something (which somebody must already be doing or
>> people wouldn't be so uptight about it being there) and then we have a 
>> deployed de-facto standard that does not match the documentation.
>>
>> Is that what you're arguing for?
> 
> Well, I hope I'm not arguing in favor of ambiguity.
> 
> I'm trying to argue for stating in section 2.1 of 
> draft-ietf-sipping-sip-offeranswer-04.txt (pattern 3) that the final 200 
> OK  either MAY or SHOULD contain a copy of the offer sent in the 
> reliable provisional response, as this approach offers less backward 
> compatibility headache than not including a copy of the answer.

That may seem simple and harmless. But it gets ugly when additional 
offer/answers happen:

   Alice               Bob
     |  INVITE offer1   |
     |----------------->|
     |  183 answer1     |
     |<-----------------|
     |  PRACK           |
     |----------------->|
     |  200 PRACK       |
     |<-----------------|
     |  UPDATE offer2   |
     |<-----------------|
     |  200 UP answer2  |
     |<-----------------|
     |  200 IN SDP?     |
     |<-----------------|

Now what should be in the 200 for the invite?

Its better to do what is already required - send no SDP in the 200 for 
the invite.

	Paul

> It's 
> also consistent with the "preview" model of sending an answer in a 
> non-reliable provisional response as discussed in section 3.1 of that 
> draft.
> 
> -- 
> Dean
> 
> 
> -- 
> Dean
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 18:29:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuz0v-00049A-3V; Wed, 21 Nov 2007 18:29:49 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuz0s-00048u-SD
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:29:46 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuz0s-00048m-HI
	for sip@ietf.org; Wed, 21 Nov 2007 18:29:46 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuz0s-0007ne-3i
	for sip@ietf.org; Wed, 21 Nov 2007 18:29:46 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 21 Nov 2007 18:29:45 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALNTjkv008969; 
	Wed, 21 Nov 2007 18:29:45 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALNTeKH007643; 
	Wed, 21 Nov 2007 23:29:40 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 18:29:40 -0500
Received: from [10.82.210.128] ([10.82.210.128]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Nov 2007 18:29:38 -0500
Message-ID: <4744BF62.3040806@cisco.com>
Date: Wed, 21 Nov 2007 18:29:38 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
In-Reply-To: <4744AFB8.7030801@lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2007 23:29:39.0045 (UTC)
	FILETIME=[62911150:01C82C96]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2357; t=1195687785;
	x=1196551785; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20WGLC=3A=20draft-ietf-sip-connect-reuse-08.txt
	|Sender:=20
	|To:=20=22Vijay=20K.=20Gurbani=22=20;
	bh=D1xEk3HrCAbnDWX5sDgd4igsdLgUdfYpE3/VlpIPVjg=;
	b=NHtoOplSqanR4QAmyjCWrnFhLqkKgG8xD7XN1JM30KWqr6jHxlnaJloFscunq0m+CvX5upIj
	Sec0MrjcLbiBwyGchKB671WBvig+koZlVzylBbu16FYFXLh8tOvJ1f2N;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I think much less should be said.

Don't say that A must reject requests sent to it over the connection. 
But also don't specify, or even imply, a mechanism by which B might 
decide it is ok to send requests on this connection. And I think the 
Alias is bad because it implies such a mechanism.

Vijay K. Gurbani wrote:
> Paul Kyzivat wrote:
>> We have a lot of history of people taking carefully phrased things 
>> like this and using them to justify a lot of incorrect behavior. We 
>> don't want this to be misconstrued.
> 
> Paul, Hadriel: So ... where do we stand on this?  It appears that
> Digest challenge for proxies is a non-starter.  Yesterday, I
> had suggested something along these lines:
> 
>   If A opens up a TCP connection to B, and it has some policy such
>   that it considers B to be trusted, it MAY insert an alias parameter
>   in the topmost Via of that request.  This will cause B to send
>   requests in the backwards direction over that connection.
>   Exactly what this policy is will be left up to each service
>   provider and implementation.

As Hadriel pointed out, there is no issue of trust on the part of A. 
(Were A to get a request over this connection that was addressed to A it 
would have no more reason to distrust it than if it got the same request 
over some other connection.) So the above is a sort of red herring.

The issue of trust is with B. A passing an alias parameter doesn't give 
B any reason to believe the connection is really with A.

>   The draft can adequately warn implementations not to do so over
>   TCP due to various security reasons documented elsewhere in the
>   draft.  The normative strength of reusing a TCP connection in
>   this manner could be left as a SHOULD, with strong incentives
>   to perform connection reuse only over TLS.

The above seems ok to me.

> This, of course, means that there is connection reuse in TCP
> as well (i.e., using one TCP stream), but is not encouraged by
> the draft, and implementations doing so will have adequately
> weighed in the associated risks before doing so.

I can almost buy not *banning* it. But that is not the same as actually 
having it in the draft.

	Paul

> Would this be a working solution that will strike a middle-
> ground?  Is this agreeable?
> 
> Thanks,
> 
> - vijay


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 18:36:30 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuz7M-0005sN-4L; Wed, 21 Nov 2007 18:36:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iuz7K-0005sB-Qd
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:36:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuz7K-0005s3-HC
	for sip@ietf.org; Wed, 21 Nov 2007 18:36:26 -0500
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuz7G-000367-UM
	for sip@ietf.org; Wed, 21 Nov 2007 18:36:26 -0500
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lALNaLR1023301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 21 Nov 2007 15:36:21 -0800
Received: from [67.169.50.136] (carbuncle.qualcomm.com [129.46.226.27])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lALNaK3X010787;
	Wed, 21 Nov 2007 15:36:20 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>
	
	
	
	
	
Date: Wed, 21 Nov 2007 15:36:18 -0800
To: "James M. Polk" , Daniel Grotti ,
	IETF SIP List 
From: Ted Hardie 
Subject: Re: [Sip] a question about IETF draft location conveyance 09
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>\
>Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains to the SIP WG's expertise in knowing and agreeing with SIP's ability to foresee the type of topology from UAC to UAS, and each server (whether there even is one) in between.  I'm not so sure the SIP WG agrees that a UAC can make this determination, and am soliciting their input here in a broad way.
>
>Can a UAC understand enough about the topology of the Internet to understand where it is sending a request, including how SIP servers may or may not act upon that request?
>
>I believe, if the answer is no, the the "recipient=" parameter is a flawed SIP header parameter.
>
>If the answer is yes, then it stays with no further arguments from me.


I think we have fundamentally different ideas of how much understanding of the
topology this implies.  My view is that the header as currently specified says
either "This is meant for the person answering the call/taking the session" or
"This is meant to help get the call through/get the session to the right responder".
Within the latter case, it requires no knowledge at all of topology; it does
not distinguish among the many different routing elements which might be
trying to make that happen. 

A UA that does not care whether it is used for routing can enter "both"
and all is well.  A UA that *wants* it to be used this way can enter "routing-entity".
The availability of "endpoint" as a separate possibility makes sure that
an endpoint can indicate that use by the routing system is not intended. 
If the SIP community believes "routing-entity" is too vague
and needs to be broken out, I do not see how the GeoPRIV could object or
why it would want to; certainly this working group should have the final word
on that.  But collapsing things so that entering "endpoint" is
not an indicator to the routing entities that they should just pass things along
would find opposition (at the very least from me).  That would break a pretty
fundamental assumption that users are in control of the pidf-lo distributions.

Hope you have a great Thanksgiving,
				Ted


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 18:43:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuzDn-0004rJ-3P; Wed, 21 Nov 2007 18:43:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuzDl-0004qy-Cp
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:43:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzDl-0004qk-2k
	for sip@ietf.org; Wed, 21 Nov 2007 18:43:05 -0500
Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuzDh-0003M0-UT
	for sip@ietf.org; Wed, 21 Nov 2007 18:43:05 -0500
Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43])
	by QMTA01.westchester.pa.mail.comcast.net with comcast
	id Fbiy1Y0020vyq2s0500100; Wed, 21 Nov 2007 23:43:01 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA05.westchester.pa.mail.comcast.net with comcast
	id Fbj11Y0050umElk0300000; Wed, 21 Nov 2007 23:43:01 +0000
X-Authority-Analysis: v=1.0 c=1 a=a641SQi2628A:10 a=3JPcM4IzsFwy4_BOV3wA:9
	a=eVKkyKUIdOYYdu1NV_0A:7 a=RExMb4gvKHjsakjjPmdLtlCaRkcA:4
	a=3FZX-ydVlcEA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lALNh1SV006915
	for ; Wed, 21 Nov 2007 18:43:01 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lALNh17e006911;
	Wed, 21 Nov 2007 18:43:01 -0500
Date: Wed, 21 Nov 2007 18:43:01 -0500
Message-Id: <200711212343.lALNh17e006911@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <47448C1B.7000603@alcatel-lucent.com> (vkg@alcatel-lucent.com)
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>
	<47448C1B.7000603@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Vijay K. Gurbani" 

   Jeroen van Bemmel wrote:
   > Vijay,
   > It's not only IPv6: what about 127.0.0.1 versus 127.000.000.1?

   Jeroen: Pedantically speaking, you are probably right.  But
   in practice we do not generally see leading zeros in an IPv4
   octet.

Even worse, in some places, including some early RFCs, the leading
zero is used to indicate that the octet is represented in octal!

But I think Jeroen's point is actually well-taken, when comparing
representations of IP addresses (not DNS names), the comparison is
implicitly of the address represented, not the textual
representation.  And this applies in IPv4 as well as IPv6.

In regard to loop detection, there are two approaches:  (1) Whatever
attempts to detect loops can canonicalize the addresses before
comparing them or whatever.  (2) Since there are a limited number of
likely representations of any address, having different entities use
different representations will only delay loop detection, not prevent
it.  And loops will be detected even if address comparisons have
occasional false negatives.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 18:58:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuzSf-0001W5-4s; Wed, 21 Nov 2007 18:58:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IuzSe-0001VB-DV
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:58:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzSe-0001V3-2a
	for sip@ietf.org; Wed, 21 Nov 2007 18:58:28 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuzSd-0000pK-LJ
	for sip@ietf.org; Wed, 21 Nov 2007 18:58:27 -0500
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-3.cisco.com with ESMTP; 21 Nov 2007 15:58:27 -0800
Received: from crabapple.local ([10.21.67.122])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id lALMVObu021648;
	Wed, 21 Nov 2007 14:31:24 -0800
Message-ID: <4744C622.300@cisco.com>
Date: Wed, 21 Nov 2007 15:58:26 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>	<47448C1B.7000603@alcatel-lucent.com>
	<200711212343.lALNh17e006911@dragon.ariadne.com>
In-Reply-To: <200711212343.lALNh17e006911@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1954; t=1195684285;
	x=1196548285; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20
	|Subject:=20Re=3A=20[Sip]=20Re=3A=20URI=20comparison=20rules=20-=20IPv6=2
	0addresses |Sender:=20 |To:=20Dale.Worley@comcast.net;
	bh=vV9IEAqKglIGeu9Nsk6Tv6vGwSHFScyDtdehjzScfBI=;
	b=rQWj/N2GPmBt2EcAnZGPPVWQVEtaahthBsoBLK0Onzs4OAp39XbgR41YOKhHe75GJYqVbyBt
	4Lpg8pKmBQS0yUBsyDEZaFTTeCw9NF1TIfAQom+0aIjAlFcWBtHo+O56;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dale.Worley@comcast.net wrote:
>    From: "Vijay K. Gurbani" 
>
>    Jeroen van Bemmel wrote:
>    > Vijay,
>    > It's not only IPv6: what about 127.0.0.1 versus 127.000.000.1?
>
>    Jeroen: Pedantically speaking, you are probably right.  But
>    in practice we do not generally see leading zeros in an IPv4
>    octet.
>
> Even worse, in some places, including some early RFCs, the leading
> zero is used to indicate that the octet is represented in octal!
>
> But I think Jeroen's point is actually well-taken, when comparing
> representations of IP addresses (not DNS names), the comparison is
> implicitly of the address represented, not the textual
> representation.  And this applies in IPv4 as well as IPv6.
>
> In regard to loop detection, there are two approaches:  (1) Whatever
> attempts to detect loops can canonicalize the addresses before
> comparing them or whatever.  (2) Since there are a limited number of
> likely representations of any address, having different entities use
> different representations will only delay loop detection, not prevent
> it.  And loops will be detected even if address comparisons have
> occasional false negatives.
>   
Given that a particular IP address might serve many, many different
URI's (think about the outsourced case), I doesn't seem to me that this
would be a very good assumption. It might be perfectly reasonable for
a method to traverse from IP address A and then back through IP address
A again without being a loop since it might be outsource1.com through
outsource2.com which is legal, right? This case certainly comes up with
email and is actually really common(*).

It seems that the conclusion of Vijay and my violent agreement is that
the entity inserting the URI better keep things consistent as the loop
detector ought to just consider these things as opaque blobs.

       Mike

(*) modulo DNSBL considerations.


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 20:03:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv0Sz-0003LD-CN; Wed, 21 Nov 2007 20:02:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv0Sy-0003L2-G6
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 20:02:52 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv0Sy-0003Ku-32
	for sip@ietf.org; Wed, 21 Nov 2007 20:02:52 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv0Sx-00040E-MT
	for sip@ietf.org; Wed, 21 Nov 2007 20:02:52 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAM12m9n006592
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 21 Nov 2007 19:02:50 -0600
In-Reply-To: <4744BC10.40301@cisco.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Wed, 21 Nov 2007 19:02:40 -0600
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 21, 2007, at 5:15 PM, Paul Kyzivat wrote:
>
> That may seem simple and harmless. But it gets ugly when additional  
> offer/answers happen:
>
>   Alice               Bob
>     |  INVITE offer1   |
>     |----------------->|
>     |  183 answer1     |
>     |<-----------------|
>     |  PRACK           |
>     |----------------->|
>     |  200 PRACK       |
>     |<-----------------|
>     |  UPDATE offer2   |
>     |<-----------------|
>     |  200 UP answer2  |
>     |<-----------------|
>     |  200 IN SDP?     |
>     |<-----------------|
>
> Now what should be in the 200 for the invite?
>
> Its better to do what is already required - send no SDP in the 200  
> for the invite.

Huh. Is it actually ok to send a 200 OK for the UPDATE before sending  
the 200 OK for the INVITE? That seems like a race condition from hell.

If it's OK only because you can claim the INVITE's O/A sequence  
completed before the UPDATE was sent, then we're making the SIP state  
machine dependent on the O/A model, and that's just wrong.

--
Dean




_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 20:10:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv0aE-0007l1-Uk; Wed, 21 Nov 2007 20:10:22 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv0aD-0007kq-Mu
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 20:10:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv0aD-0007ia-5a
	for sip@ietf.org; Wed, 21 Nov 2007 20:10:21 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv0aA-0007ik-OF
	for sip@ietf.org; Wed, 21 Nov 2007 20:10:21 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAM1AFuX006665
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 21 Nov 2007 19:10:17 -0600
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>
	
	
	
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] a question about IETF draft location conveyance 09
Date: Wed, 21 Nov 2007 19:10:09 -0600
To: Ted Hardie , "James M. Polk" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 21, 2007, at 3:02 PM, Ted Hardie wrote:

> At 2:28 PM -0600 11/21/07, James M. Polk wrote:
>>
>> The "recipient=" within the Geolocation header is a SIP parameter,  
>> in a SIP document.  Everything discussed in Geopriv regarding this  
>> document needs to be approved in SIP too.  The SIP WG hasn't heard  
>> this part of the discussion because most members of SIP aren't  
>> subscribed to the Geopriv list.
>
> That SIP parameter in a SIP document relates to a PIDF-LO object  
> carried by
> SIP; in that context, SIP is a using protocol of the GEOPRIV  
> framework.  SIP
> folks should certainly understand the work they're reusing, or the  
> implementations
> won't do the right thing.  But re-starting the conversation in SIP  
> without
> reference to the discussions that have already occurred in GeoPRIV  
> is a
> recipe for conflict at IETF Last Call.  We might as well start  
> getting people
> on the same page now.  From my  perspective, the right way to do  
> that is
> to start the discussion from where it last left off, even if that  
> wasn't in
> the same group.  That tells people where the consensus of that  
> group was
> and informs the rest of the discussion.

Supposedly, the discussion in GEOPRIV was a joint SIP/GEOPRIV effort.

A brief recap of the conclusion in GEOPRIV might be reasonable, but  
I'd much rather not revisit the thousands of emails on the topic in  
GEOPRIV. If we notice now that it is broken in some horrible way we  
didn't, before, that might change the situation, but we shouldn't  
rehash the entire design rationale.

--
Dean 


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 23:09:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv3Me-0008WC-A3; Wed, 21 Nov 2007 23:08:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv3Mc-0008W5-ML
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 23:08:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv3Mc-0008Vx-CU
	for sip@ietf.org; Wed, 21 Nov 2007 23:08:30 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv3MZ-0006XX-Rh
	for sip@ietf.org; Wed, 21 Nov 2007 23:08:30 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAM48BWW029912; 
	Wed, 21 Nov 2007 22:08:11 -0600 (CST)
Received: from [135.244.0.86] (vkg.lra.lucent.com [135.244.0.86])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAM489j13706; Wed, 21 Nov 2007 22:08:09 -0600 (CST)
Message-ID: <474500A5.5040605@alcatel-lucent.com>
Date: Wed, 21 Nov 2007 22:08:05 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Paul Kyzivat 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com>
In-Reply-To: <4744BF62.3040806@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:
> I think much less should be said.
> 
> Don't say that A must reject requests sent to it over the connection. 
> But also don't specify, or even imply, a mechanism by which B might 
> decide it is ok to send requests on this connection.

Any way you cut, slice, and dice this thing, TCP connection reuse
in the backwards direction is bad.  Note that it does not work with
virtual servers at all.

Unfortunately, people are using it and as such something ought to
be said about it in the draft.  I agree that as the less said, the
better.  I also agree that putting the "alias" parameter in the
Via request for TCP.

Going back to our scenario of A opening a connection to B, it
probably suffices to massage the text you proposed in an earlier
email of this thread:

    B MUST NOT reuse this connection for requests to the
    supposed party at the other end UNLESS it has some way
    of verifying the identity of that party to the same level
    of assurance as it would have by doing the DNS lookup and
    establishing its own connection. For instance, if a DNS
    lookup resolved to the same address and port as the source
    port of the inbound connection then that ought be be good
    enough.

This still does not solve the problem of reusing TCP connections
for virtual servers; i.e., B does not know that that A's physical
IP address is being used by multiple virtual domains.  Again, I
can just point this out for the TCP and SCTP transport in
the virtual server section more emphatically and leave it at that.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 21 23:48:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv3z3-0008Vs-4r; Wed, 21 Nov 2007 23:48:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv3z0-0008Up-TM
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 23:48:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv3z0-0008Uh-Jg
	for sip@ietf.org; Wed, 21 Nov 2007 23:48:10 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv3yx-0007xI-KD
	for sip@ietf.org; Wed, 21 Nov 2007 23:48:10 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAM4m4UC007719
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for ; Wed, 21 Nov 2007 22:48:06 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
To: IETF SIP List 
Message-Id: <182DCB20-647C-411F-B226-554474E726E5@softarmor.com>
From: Dean Willis 
Date: Wed, 21 Nov 2007 22:47:57 -0600
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e
Subject: [Sip] Revised SIP Agenda, IETF 70 -- many changes
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1945334287=="
Errors-To: sip-bounces@ietf.org


--===============1945334287==
Content-Type: multipart/alternative; boundary=Apple-Mail-2-503829639


--Apple-Mail-2-503829639
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Note that the following has changed a lot. Many people will be  
surprised by a need to get their slides in earlier, because a lot of  
stuff moved to Monday. Rationale: The chairs and ADs wanted some  
hallway time to discuss Outbound, so it moved to Wednesday.

Session 1, Monday December 3, 1740-1950 Salon A/B
Start Time
Topic
Discussion Lead
Reading List
1740
Agenda Bash and Status
Chairs
This document
1800
Location Conveyance
Brian Rosen
James Polk
draft-ietf-sip-location-conveyance-08
1830
INFO Harmful
Eric Burger
draft-burger-sip-info-02
1900
INFO Events
Hadriel Kaplan
draft-kaplan-sip-info-events-00
1930
Connection Reuse (MAYBE)
Vijay Gurbani
draft-ietf-sip-connect-reuse-08
1950
End



Session 2, Wednesday December 5, 0900-1130, Salon A/B
Start Time
Topic
Discussion Lead
Reading List
0900
Agenda Bash
Chairs
This Document
0910
Outbound
Rohan Mahy
draft-ietf-sip-outbound-10
1000
RPH In Responses
James Polk
Janet Gunn
draft-polk-sip-rph-in-responses-00
draft-gunn-sip-req-for-rph-in-responses-00.txt

1020
Media Identity
Dan Wing
draft-wing-sip-identity-media-01
1050
DTLS Framework
Eric Rescorla
Jason Fischl
draft-ietf-sip-dtls-srtp-framework-00
1130
End



--Apple-Mail-2-503829639
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1


Note that the following has changed =
a lot. Many people will be surprised by a need to get their slides in =
earlier, because a lot of stuff moved to Monday. Rationale: The chairs =
and ADs wanted some hallway time to discuss Outbound, so it moved to =
Wednesday.

Session 1, Monday December 3, 1740-1950 Salon =
A/B
  =
 =
 =
 =

  
 
Start Time
 		 
Topic
 		 
Discussion Lead
 		 
Reading List
 		 
 
 
1740
 		 
Agenda Bash and Status
 =
 
Chairs
 		 
This document
 		 
 
1800
 		 
Location Conveyance
 
Brian Rosen
James Polk
 		  =
 
 
 
1830
 		 
INFO =
Harmful
 		 
Eric =
Burger
 		   
 
 
1900
 		 
INFO Events
 		 
Hadriel Kaplan
 		  =
 
 
 
1930
 		 
Connection Reuse (MAYBE)
 		 
Vijay Gurbani
 		   
 
1950
 		 
End
 		 

 		 

 		 
 

Session 2, Wednesday December 5, 0900-1130, Salon =
A/B
  =
 =
 =

  
 
Start Time
 		 
Topic
 		 
Discussion Lead
 		 
Reading List
 		 
 
 
0900
 		 
Agenda Bash
 		 
Chairs
 		 
This Document
 		 
 
0910
 		 
Outbound
 		 
Rohan Mahy
 		   
 
 
1000
 		 
RPH In Responses
 
James Polk
Janet Gunn
 		 
draft-gunn-sip-req-for-rph-in-responses-00.txt
 		 
 
 
1020
 		 
Media =
Identity
 		 
Dan =
Wing
 		  =
 
 
 
1050
 		 
DTLS =
Framework
 		 
Eric =
Rescorla
Jason =
Fischl
 		  =
 
 
 
1130
 		 
End
 		 

 =
 

 		 
 

=

--Apple-Mail-2-503829639--



--===============1945334287==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1945334287==--





From sip-bounces@ietf.org Wed Nov 21 23:58:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv48Y-0006gm-G1; Wed, 21 Nov 2007 23:58:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv48W-0006gh-Mx
	for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 23:58:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv48W-0006gZ-9w
	for sip@ietf.org; Wed, 21 Nov 2007 23:58:00 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv48V-0008Eq-Q5
	for sip@ietf.org; Wed, 21 Nov 2007 23:58:00 -0500
Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net
	[96.226.64.76]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAM4vpEB048399
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 21 Nov 2007 22:57:51 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Wed, 21 Nov 2007 22:57:51 -0600
To: Dean Willis 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4882/Wed Nov 21 22:15:37 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

There can be several UPDATEs with their associated 200-UPDATES before  
the 200-INVITE.
Remember that UPDATE is a nonINVITE transaction and there may be a  
_long_ time between the UPDATE and the 200-INVITE.

Paul drew the arrow backwards for the 200-UPDATE though - did that  
mislead you?

RjS

On Nov 21, 2007, at 7:02 PM, Dean Willis wrote:

>
> On Nov 21, 2007, at 5:15 PM, Paul Kyzivat wrote:
>>
>> That may seem simple and harmless. But it gets ugly when  
>> additional offer/answers happen:
>>
>>   Alice               Bob
>>     |  INVITE offer1   |
>>     |----------------->|
>>     |  183 answer1     |
>>     |<-----------------|
>>     |  PRACK           |
>>     |----------------->|
>>     |  200 PRACK       |
>>     |<-----------------|
>>     |  UPDATE offer2   |
>>     |<-----------------|
>>     |  200 UP answer2  |
>>     |<-----------------|
>>     |  200 IN SDP?     |
>>     |<-----------------|
>>
>> Now what should be in the 200 for the invite?
>>
>> Its better to do what is already required - send no SDP in the 200  
>> for the invite.
>
> Huh. Is it actually ok to send a 200 OK for the UPDATE before  
> sending the 200 OK for the INVITE? That seems like a race condition  
> from hell.
>
> If it's OK only because you can claim the INVITE's O/A sequence  
> completed before the UPDATE was sent, then we're making the SIP  
> state machine dependent on the O/A model, and that's just wrong.
>
> --
> Dean
>
>



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 00:21:20 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv4Ug-0003Le-Rz; Thu, 22 Nov 2007 00:20:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv4Uf-0003K3-34
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 00:20:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv4Ue-0003GV-9Q
	for sip@ietf.org; Thu, 22 Nov 2007 00:20:52 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv4Ua-0000RG-SN
	for sip@ietf.org; Thu, 22 Nov 2007 00:20:52 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAM5KkVf007934
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 21 Nov 2007 23:20:47 -0600
In-Reply-To: <1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
	<1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Wed, 21 Nov 2007 23:20:39 -0600
To: Robert Sparks 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 21, 2007, at 10:57 PM, Robert Sparks wrote:

> There can be several UPDATEs with their associated 200-UPDATES  
> before the 200-INVITE.
> Remember that UPDATE is a nonINVITE transaction and there may be a  
> _long_ time between the UPDATE and the 200-INVITE.
>
> Paul drew the arrow backwards for the 200-UPDATE though - did that  
> mislead you?
>

Ah, yes, I read that Alice had sent a second conflicting offer in  
UPDATE.

However, even with this directionality, the answer in the INVITE-200,  
if present, would have to be a copy of the answer in the 183. This  
doesn't create any error I can see, it just illustrates the UPDATE  
race condition that would have existed even had there not been an  
answer in the 183. Early media, early session, and UPDATE were all  
bad ideas (probably all because of forking and PSTN interactions)  
IMHO, and I'm pretty sure reliable provisionals are on that list too.


>>>
>>>   Alice               Bob
>>>     |  INVITE offer1   |
>>>     |----------------->|
>>>     |  183 answer1     |
>>>     |<-----------------|
>>>     |  PRACK           |
>>>     |----------------->|
>>>     |  200 PRACK       |
>>>     |<-----------------|
>>>     |  UPDATE offer2   |
>>>     |<-----------------|
>>>     |  200 UP answer2  |
>>>     |<-----------------|
>>>     |  200 IN SDP?     |
>>>     |<-----------------|
>>>
>>> Now what should be in the 200 for the invite?
>>>
>>> Its better to do what is already required - send no SDP in the  
>>> 200 for the invite.
>>

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 00:52:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv4ym-0003Sb-Us; Thu, 22 Nov 2007 00:52:00 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv4yl-0003Hd-6P
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 00:51:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv4yk-0003Fy-HS
	for sip@ietf.org; Thu, 22 Nov 2007 00:51:58 -0500
Received: from mail119.messagelabs.com ([216.82.241.179])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iv4yj-0006PI-RA
	for sip@ietf.org; Thu, 22 Nov 2007 00:51:58 -0500
X-VirusChecked: Checked
X-Env-Sender: satyanarayana.t@motorola.com
X-Msg-Ref: server-2.tower-119.messagelabs.com!1195710717!18801814!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 18024 invoked from network); 22 Nov 2007 05:51:57 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-2.tower-119.messagelabs.com with SMTP;
	22 Nov 2007 05:51:57 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAM5ps7O008372
	for ; Wed, 21 Nov 2007 22:51:54 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143])
	by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lAM5prJa019690
	for ; Wed, 21 Nov 2007 23:51:54 -0600 (CST)
Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27])
	by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lAM5pqwj019678
	for ; Wed, 21 Nov 2007 23:51:53 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
Date: Thu, 22 Nov 2007 13:51:42 +0800
Message-ID: <3100473D52017B48B9068E079BE2A6E6029AC63D@ZMY16EXM67.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: BNF future-proofing problem?
Thread-Index: AcgsSaCFMdxh9wfFTeKGF2CITLPJSAAAZ63wAAashzgAGJzNMAAA1Aeg
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com><66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com><6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>
	
From: "T Satyanarayana-A12694" 
To: "Christer Holmberg" ,
	"Robert Sparks" 
X-CFilter-Loop: Reflected
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

This would mean a large change to existing parsers and formatters. And
also, the "escaping" and "unescaping" overheads.

Changing the header-value BNF may be more acceptable?

Regards
Satya T

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Wednesday, November 21, 2007 11:13 PM
To: Christer Holmberg; Robert Sparks
Cc: sip List
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?

Hi,
=20
Another alternative would be to define an escaping mechanism for
quoted-strings in SIP messages, and require all characters not allowed
by the header-value ABNF to be escaped.
=20
Regards,
=20
Christer=20

________________________________

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Wed 21/11/2007 15:33
To: Robert Sparks
Cc: sip List
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?




Hi,

>So to restate the problem that was reported:
>
>Right now, extension-header does not allow a new header that contains a

>quoted-string.
>
>We have defined extensions (and are likely to define new
>ones) that use quoted-string (anything that uses name-addr for=20
>instance).
>
>This inconsistency has caused interoperability problems in real=20
>implementations.
>
>My original note was to suggest that we change extension-header to=20
>actually allow the headers we're going to define.
>
>Christer's response could be read as a proposal to change
>quoted- string to achieve the same goal.

Yes.

Unless someone can show a use-case where the x00-x20 characters would be
needed, for backward compability reasons I think it's better to restrict
quoted-string than to extend extension-header.

Regards,

Christer




> > Hi,
> >
> > I am still a little unclear what Robert is proposing, but is there=20
> > really a need to be able to use characters between x00 and
> x20 in SIP
> > messages? Characters between x21 and x7F, and between x80
> and xBF, are
> > ok since they are covered by TEXT-UTF8char and UTF8-CONT.
> >
> > Regards,
> >
> > Christer
> >
> >
> > ________________________________
> >
> >     From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
> >     Sent: 21. marraskuuta 2007 7:30
> >     To: Robert Sparks
> >     Cc: sip List
> >     Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
> >   =20
> >   =20
> >     I think I did misread Robert's original email. I thought header=20
> > values having quoted strings are currently not allowed and Robert=20
> > wanted to change RFC2822. Now I realise that you can have
> header field
> > values with quoted string. Therefore I support the correction that=20
> > Robert is proposing.
> >   =20
> >     Hisham
> >   =20
> >   =20
> >     On 21/11/2007, Hisham Khartabil 
> > wrote:
> >
> >             This is a big change if we do adopt it. It will
> cause a lot of
> > problem to parsers that handle extenion headers today and is not=20
> > backwards compatible. Why isn't the extension header as is defined=20
> > today not sufficient?
> >                           =20
> >             Hisham
> >           =20
> >           =20
> >                                             On 20/11/2007, Robert=20
> > Sparks  wrote:
> >
> >                     The BNF in 3261 says the following:
> >                   =20
> >                     extension-header  =3D  header-name HCOLON
> header-value
> >                     header-value      =3D  *(TEXT-UTF8char / =
UTF8-CONT
> > / LWS)
> >                   =20
> >                     This is intended to be the catch-all
> field for all future
> > extensions
> >                     - older parsers working against this
> BNF shouldn't barf
> >                     when we introduce a new header field.
> >                   =20
> >                     Now, we may have new fields in the
> future that look like:
> >                   =20
> >                     NewHeader =3D new-header-name HCOLON =
quoted-string
> >                   =20
> >                     And down inside quoted-string, we get:
> >                   =20
> >                           quoted-string  =3D  SWS DQUOTE
> *(qdtext / quoted-pair ) DQUOTE
> >                           qdtext         =3D  LWS / %x21 / %x23-5B /
> > %x5D-7E
> >                                             / UTF8-NONASCII
> >                           quoted-pair  =3D  "\" (%x00-09 / %x0B-0C
> >                                            / %x0E-7F)
> >                   =20
> >                     So, for instance, we could have inside
> a quoted string the 2 byte
> >                     sequence \ NULL
> >                   =20
> >                     This does not parse against
> header-value above...
> >                   =20
> >                     Is this a problem? Some of the SIPit21
> participants argued that it
> > is.
> >                   =20
> >                     The projects I've been involved in
> don't parse unknown headers and
> >                     the stacks will just hand up an
> unparsed bucket of bits (the only
> > rules
> >                     used are those necessary to identify
> the next header-field
> > starting).
> >                   =20
> >                     Would it be worth the effort to make
> the BNF reflect that rather
> > than
> >                     continuing with the incongruity that we
> currently specify?
> >                   =20
> >                     RjS
> >                   =20
> >                   =20
> >                     _______________________________________________
> >                     Sip mailing list=20
> > 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
> >                   =20
> >
> >
> >           =20
>
>


_______________________________________________
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




_______________________________________________
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


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 02:16:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv6I9-0007JD-RN; Thu, 22 Nov 2007 02:16:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv6I7-0007J7-VI
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 02:16:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv6I7-0007Iy-HH
	for sip@ietf.org; Thu, 22 Nov 2007 02:16:03 -0500
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv6I3-0004JZ-TA
	for sip@ietf.org; Thu, 22 Nov 2007 02:16:03 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	lAM7FJ59026641; Thu, 22 Nov 2007 09:15:45 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 09:15:43 +0200
Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 09:15:43 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Few comments to draft-ietf-sip-outbound-11
Date: Thu, 22 Nov 2007 09:15:41 +0200
Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F046FD43F@esebe103.NOE.Nokia.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Few comments to draft-ietf-sip-outbound-11
thread-index: AcgsWm9qffDkZsovSb6jCXAnzNib7wAd4y1w
References: 
	<8B1D53AEF7B03449A6D3771B3B7F850F046D2838@esebe103.NOE.Nokia.com>
	
From: 
To: 
X-OriginalArrivalTime: 22 Nov 2007 07:15:43.0155 (UTC)
	FILETIME=[7E79A030:01C82CD7]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: fluffy@cisco.com, sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20
Hi Rohan,

Thanks for your answers. Please find my proposal for section 7 below:

>> Sorry but I do not understand what is meant by: "If the proxy doubles
>> as a registrar and stored information about the flow that created the
>> binding"  Proxy 'doubling as a registrar' sounds odd (which might =20
>> be due
>> to my poor skills of English ...) Could you please clarify this ?
>
>Sure.  This is the case where the authoritative proxy and registrar =20
>roles are implemented in the same SIP implementation.  The flow was =20
>stored by the "registrar" but the "authoritative proxy" performs the =20
>lookup function and routes to the registered UA over the saved flow.
>
>This was actually a suggestion from Byron Cambell which seemed much =20
>less cumbersome from the previous text, but clearly it could use some =20
>additional rewording.  Feel free to propose something.

So this case is when all the roles of registrar, authoritative proxy
and edge proxy are colocated, right ?

If so, then I propose the text to be written like this:

   If the proxy is colocated with the registrar which stored in=20
   the binding the information about its direct flow to the UA,
   then the proxy MUST send the request over the same 'logical=20
   flow' saved with the binding ...

How would that sound ?

Regards,

Erkki

>-----Original Message-----
>From: ext Rohan Mahy [mailto:rohan@ekabal.com]=20
>Sent: 21.November.2007 18:20
>To: Koivusalo Erkki (Nokia-BI/Espoo)
>Cc: Rohan Mahy; fluffy@cisco.com; sip@ietf.org
>Subject: Re: [Sip] Few comments to draft-ietf-sip-outbound-11
>
>
>On Nov 21, 2007, at 12:25 AM,  wrote:
>
>>
>> Hi,
>>
>> First of all, in my opinion outbound-11 looks good.
>> It has improved a lot from the previous version and
>> properly addressed many comments given in August during
>> WGLC.
>>
>> After reading the draft I found a few things for which
>> I would seek further clarification. Some of those were
>> already initially raised in WGLC and the other minor
>> issues are due to the new text appeared in version 11.
>>
>> 1. Why should the registrar store the time of updating
>>    the binding ?
>>
>> Section 6. Registrar mechanisms tells the following:
>>
>>    The registrar MUST store in the binding the Contact URI,
>>    all the Contact head field parameters, and any Path header field
>>    values and SHOULD also store the time at which the=20
>binding was last
>>    updated.
>>
>>    If the registrar receives a re-registration for a specific
>>    combination of AOR, instance-id and reg-id values, the registrar =20
>> MUST
>>    update any information that uniquely identifies the network flow =20
>> over
>>    which the request arrived if that information has changed, and =20
>> SHOULD
>>    update the time the binding was last updated.
>>
>> To which purpose is this stored time used ? In my understanding
>> such a stored time is not needed for replacing older bindings and
>> I could not come up with any other reason either to store the time.
>>
>> As the draft tells elsewhere "[when the] reg-id values [coming from
>> the UA within REGISTER request] will collide with the previously
>> used reg-id values [stored earlier along the binding] the registrar
>> can replace the older registrations". The time of any previous update
>> should not matter.
>
>There are three reasons, but all of them are a bit dubious.
>a) RFC 3261 recommends keeping this information, but does not say why
>b) This was needed in a previous version of outbound
>c) GRUU uses this in the temporary GRUU invalidation procedure.  =20
>However, this is an open issue for GRUU and outbound.  I will send =20
>mail about this soon.
>
>The short answer is that it can probably be removed.
>
>> 2. How to respond if UA requires Outbound but the proxy does
>>    not support it even if the registrar does ?
>>
>> How should the registrar respond to a REGISTER request when:
>>
>> - REGISTER contains Require: Outbound and reg-id in Contact
>>
>> - Registrar itself supports Outbound
>>
>> - Via header of REGISTER indicates that there is a proxy between
>>   the UA and registrar, but the proxy has not included either the
>>   Path header or 'ob' parameter to its URI within the Path ?
>
>I looked for an appropriate error message for this and it was quite a =20
>puzzler.  420 is clearly not appropriate. I was planning to =20
>investigate if 488 Not Acceptable Here or 580 Precondition Failed =20
>could be reused for this purpose.  I am not really keen on adding a =20
>new response code though. A 400 Bad Request would be appropriate but =20
>not especially helpful.
>
>> 3. Completing the removal of TCP keepalive from the draft
>>
>> As all the other references to TCP keepalive have now been removed
>> from the draft, then please remove also this one from section
>> Section 3.5. Keepalive Technique:
>>
>>    transports such as TCP and SCTP, this specification describes a
>>    keepalive approach based on sending CRLFs, *and for TCP,=20
>a usage of
>>    TCP transport-layer keepalives*.
>
>Thanks
>
>> 4. Ambiguous text in section 7
>>
>> Section 7. Authoritative Proxy Mechanisms: Forwarding Requests tells:
>>
>>    If the proxy doubles as a registrar and stored information about =20
>> the
>>    flow that created the binding, then the proxy MUST send=20
>the request
>>    over the same 'logical flow' saved with the binding,
>>
>> Sorry but I do not understand what is meant by: "If the proxy doubles
>> as a registrar and stored information about the flow that created the
>> binding"  Proxy 'doubling as a registrar' sounds odd (which might =20
>> be due
>> to my poor skills of English ...) Could you please clarify this ?
>
>Sure.  This is the case where the authoritative proxy and registrar =20
>roles are implemented in the same SIP implementation.  The flow was =20
>stored by the "registrar" but the "authoritative proxy" performs the =20
>lookup function and routes to the registered UA over the saved flow.
>
>This was actually a suggestion from Byron Cambell which seemed much =20
>less cumbersome from the previous text, but clearly it could use some =20
>additional rewording.  Feel free to propose something.
>
>thanks,
>-rohan
>
>


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 03:02:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv70u-0002e0-1F; Thu, 22 Nov 2007 03:02:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv70r-0002do-Aj
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 03:02:17 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv70q-0002dg-TP
	for sip@ietf.org; Thu, 22 Nov 2007 03:02:16 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv70q-0002Le-BJ
	for sip@ietf.org; Thu, 22 Nov 2007 03:02:16 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x11 #31430)
	with ESMTP id <0JRW0057VEBR8X@siemenscomms.co.uk> for sip@ietf.org; Thu,
	22 Nov 2007 08:02:15 +0000 (GMT)
Date: Thu, 22 Nov 2007 08:02:14 +0000
From: "Elwell, John" 
Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel
In-reply-to: <65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
To: Dean Willis ,
	Robert Sparks 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441623@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] SIPit21: SDP in a 200OK when using 100rel
Thread-Index: Acgsx5tYOvK5fRg5QxC5cbpJHtoQ3QAFQURA
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>
	
	<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>
	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
	<1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
	<65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I don't see it as an "UPDATE race condition". There are legitimate
sequences (arising from 100rel, UPDATE, pre-conditions, early session
disposition etc.) in which, following conclusion of the original
offer-answer exchange when the answer is sent in a reliable provisional
response, further offer-answer exchanges can occur (using PRACK or
UPDATE). These can occur before the 200 response to INVITE. Thus
repeating the original SDP answer in the 200 response to INVITE is
history - it has been overtaken by subsequent offers and answers. At
best it will be ignored, but at worst it will lead to confusion, e.g.,
the UAC and UAS getting out of step with which SDP version from the UAS
is to be used. And why should the UAS even have to store the original
SDP answer it sent, if it has been overtaken by subsequent SDPs?

Of course, one can question the wisdom behind some of these mechanisms,
some of which have not seen much deployment. But they are there, and
unless we deprecate them, we change the offer-answer rules at our peril.

John

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com] 
> Sent: 22 November 2007 05:21
> To: Robert Sparks
> Cc: Sanjay Sinha (sanjsinh); sip List; Paul Kyzivat
> Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
> 
> 
> On Nov 21, 2007, at 10:57 PM, Robert Sparks wrote:
> 
> > There can be several UPDATEs with their associated 200-UPDATES  
> > before the 200-INVITE.
> > Remember that UPDATE is a nonINVITE transaction and there may be a  
> > _long_ time between the UPDATE and the 200-INVITE.
> >
> > Paul drew the arrow backwards for the 200-UPDATE though - did that  
> > mislead you?
> >
> 
> Ah, yes, I read that Alice had sent a second conflicting offer in  
> UPDATE.
> 
> However, even with this directionality, the answer in the 
> INVITE-200,  
> if present, would have to be a copy of the answer in the 183. This  
> doesn't create any error I can see, it just illustrates the UPDATE  
> race condition that would have existed even had there not been an  
> answer in the 183. Early media, early session, and UPDATE were all  
> bad ideas (probably all because of forking and PSTN interactions)  
> IMHO, and I'm pretty sure reliable provisionals are on that list too.
> 
> 
> >>>
> >>>   Alice               Bob
> >>>     |  INVITE offer1   |
> >>>     |----------------->|
> >>>     |  183 answer1     |
> >>>     |<-----------------|
> >>>     |  PRACK           |
> >>>     |----------------->|
> >>>     |  200 PRACK       |
> >>>     |<-----------------|
> >>>     |  UPDATE offer2   |
> >>>     |<-----------------|
> >>>     |  200 UP answer2  |
> >>>     |<-----------------|
> >>>     |  200 IN SDP?     |
> >>>     |<-----------------|
> >>>
> >>> Now what should be in the 200 for the invite?
> >>>
> >>> Its better to do what is already required - send no SDP in the  
> >>> 200 for the invite.
> >>
> 
> --
> Dean
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 03:22:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv7KN-0004H8-Bo; Thu, 22 Nov 2007 03:22:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv7KL-00048H-QR
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 03:22:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv7KL-00045e-CZ
	for sip@ietf.org; Thu, 22 Nov 2007 03:22:25 -0500
Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv7KH-0006dB-8J
	for sip@ietf.org; Thu, 22 Nov 2007 03:22:25 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
	lAM8Le4o016898; Thu, 22 Nov 2007 10:22:17 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 10:22:14 +0200
Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 10:22:13 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] What is SIP ? (was RE: [Sip] media-security-requirements and
	lawful intercept)
Date: Thu, 22 Nov 2007 10:22:12 +0200
Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F046FD533@esebe103.NOE.Nokia.com>
In-Reply-To: <47443E2E.3020507@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] What is SIP ? (was RE: [Sip] media-security-requirements
	and lawful intercept)
thread-index: AcgsSWvWPNnVtQjfToiTC2gJuX1JRAAj6ATg
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<20071111224707.68E5033C21@delta.rtfm.com><008701c824d4$096ca180$c4f0200a@cisco.com><4741FD6B.10507@nostrum.com>
	<47443E2E.3020507@nostrum.com>
From: 
To: , 
X-OriginalArrivalTime: 22 Nov 2007 08:22:13.0706 (UTC)
	FILETIME=[C90762A0:01C82CE0]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: sip@ietf.org, dwing@cisco.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20
Hi,

Perhaps this thread is not worth continuing for long, so=20
please feel free to cut it down, but there are a few
remarks that I would like to make:

>Need something more clear-cut? Something you can apply empirically?=20
>Here's a litmus test for you: if the initial signaling between two=20
>network elements can't negotiate down to base SIP without any=20
>extensions, then it's no longer SIP.

What you say above implies that if there is a NAT between those two
network elements so that the communication between those can only
be established with help of rport extension, then the result is
no longer SIP.

Well ... you could start arguing that there are extensions and
extensions ... but the bottom line is that the simplicity of
the test is lost with any exceptions. Unfortunately the world
is a bit complex to fit simple rules.

>> What is "IETF SIP"? What do I have to implement in order to be "IETF
>> SIP" compliant? RFC3261? RFC3261 plus each and every extension out
>> there?
>>  =20
>RFC 3261 plus proper negotiation of any extensions you choose to=20
>support. More emphatically: any behavior that is not in 3261 or its=20
>references needs to be explicitly negotiated before it is=20
>engaged. This applies to both clients and network servers.

Concept of dynamic negotiation is architecturally nice, but
unfortunately often undesirable in practical deployments.
The registration procedure between a full-fledged UA and a
typical SIP network deployment would look like this:

1. UA sends DHCPINFORM for SIP Option to find local SIP proxy
2. DCHP server answers that it has no value for SIP Option
3. UA sends OPTIONS request to SIP proxy resolved from the
   host part of the AOR
4. Proxy responds to OPTIONS and tells e.g. that it does not
   support sigcomp or sec-agree
5. UA sends REGISTER request without compression or requiring
   sec-agree, containing Require: outbound
6. Registrar responds with 420 Bad extension, Unsupported: Outbound
7. UA sends REGISTER again after removing extensions which
   the registrar did not support
8. Registrar responds with 401
9. UA sends REGISTER again with proper credentials
10. Reistrar responds with 200 OK
11. UA sends SUBCRIBE for reg-event
12. Network responds with 489 Bad Event (or in worst case loops
    the SUBSCRIBE back to the UA as it contains the AOR of the
    user as its Request-URI)

In practice the service provides most often do not want all=20
this to happen but instead would like to configure the UAs
to suppress any extensions which the deployment does not support.

>I said the bifurcation exists _in_ _the_ _market_. Did you follow the=20
>link I included? It's extraordinarily relevant. If you need more=20
>context: these are screenshots from the SIP account configuration=20
>screens on the Nokia E61:
>
>
>
>We can argue over whether the split is real on the technical=20
>level (and there are several reasons that it is -- for=20
>example, using SigComp without proper signaling of the=20
>intention to do so ahead of time), but it's all a moot point:=20
>products are already being designed with two distinct modes of=20
>operation.

Having working at Nokia I can give some perspective to the
design of this UI. Even if the E61 product is relatively new
the concept of the split was created a few years ago when the
world looked polarized like this:

3GPP was promoting IMS as a SIP profile, mandating extensions
like RFC 3310 (HTTP Digest AKA), RFC 3327 (Path) RFC 3329 (sec-agree),
RFC 3455 (P-headers), RFC 3489 (Compressing SIP), RFC 3608 (service
route)
and RFC 3680 (reg-event). This is a whole bunch of things to be
implemented, but the behaviour of the environment was supposed
to be quite deterministic.

IETF was promoting a toolbox approach for SIP so that service
providers were able to deploy any combination of extensions.
In practice however most of the deployments supported minimum
amount of extensions and there was a requirement for the UA
to cope with such deployments with minimal amount of config
settings and minimum amount of dynamic negotiation.

Thus the design team ended up with two modes, one for each
environment to control whether or not certain extensions
would be applied. The modes mostly defined some default
values, which thereafter could be separately changed with
the UI, but usage of a few extensions was hardcoded by the
mode.
----

Whether that design was good or bad is another subject of
discussion but with the knowledge of today it is clear that
the "SIP" world is not polarized between IETF and 3GPP but
fragmented to a number of different environments like:

- Every SIP service provider tends to define their own SIP
  profile which they wish the UAs to comply as close as possible
- Some providers even create their own proprietary extensions
  (like Yahoo for authentication)
- "Cellular IMS" like the original 3GPP IMS
- "CableLabs IMS" promoting new NAT traveral techniques to IMS
- "Fixed Broadband IMS" of ETSI TISPAN style
- "Early IMS" implementations supporting just a subset
   of extensions defined for 3GPP IMS
- and so on ...

Thus all this means that design of an SIP UA aiming to worldwide
coverage of different SIP-based deployments is an enormously
complex task. Autoconfiguration solutions would be highly
desirable to manage the complexity, but unfortunately for
that there is no unified solution: many VoIP providers
use TFTP or manual configuration while cellular IMS operators=20
may rely on factory settings, OMA Device Management or OMA Client=20
Provisioning and in IETF the SIP Configuration Framework is=20
still on drawing board ...

Having a world with one unified "SIP" approach is a nice
dream, but unfortunately the reality is already far from
that and there are only some weak signs of convergence :(

Regards,

Erkki





_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 03:25:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv7NC-0007h5-R8; Thu, 22 Nov 2007 03:25:22 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv7NB-0007gz-Fo
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 03:25:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv7NB-0007gr-5k
	for sip@ietf.org; Thu, 22 Nov 2007 03:25:21 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv7NA-0006k3-BD
	for sip@ietf.org; Thu, 22 Nov 2007 03:25:21 -0500
Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net
	[96.226.64.76]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAM8PG8S057899
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 22 Nov 2007 02:25:16 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
	<1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
	<65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Thu, 22 Nov 2007 02:25:16 -0600
To: Dean Willis 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4882/Wed Nov 21 22:15:37 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I'm still not sure what you originally objected to. Just to be point  
out that the UPDATE can come from either side, I'm copying figure 1  
from the UPDATE RFC here.

Tell me what SDP you think is safe to put in message 9.
I _think_ you're saying it should be answer 1 from message 2. How  
could that help anybody? The session described by offer1/answer1 is  
long long gone.
If you repeat offer 3 from message 7, again - how could that help  
anybody?

I'll accept that you don't like the whole idea of early dialogs and  
early media. But that cat's so far out of the bag its forgotten what  
the bag smells like.
Given that this stuff is now _deployed_, what's the best answer to my  
original question?

What Paul points out causes me to champion making a much clearer MUST  
NOT put SDP in the 200-INVITE if you're using 100-rel.

And my questions about how the repeat of either of those SDPs is  
earnest, not rhetorical. I really don't see how its helping something  
work.
Can you diagram the scenario where not repeating the SDP you want to  
repeat leads to abject failure?

RjS


                 Caller                        Callee
                    |                             |
                    |                             |
                    |(1) INVITE with offer 1      |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |(2) 180 with answer 1        |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(3) PRACK                    |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |(4) 200 PRACK                |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(5) UPDATE with offer 2      |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |(6) 200 UPDATE with answer 2 |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(7) UPDATE with offer 3      |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(8) 200 UPDATE with answer 3 |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |(9) 200 INVITE               |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(10) ACK                     |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |                             |
                    |                             |

                      Figure 1: UPDATE Call Flow

On Nov 21, 2007, at 11:20 PM, Dean Willis wrote:

>
> On Nov 21, 2007, at 10:57 PM, Robert Sparks wrote:
>
>> There can be several UPDATEs with their associated 200-UPDATES  
>> before the 200-INVITE.
>> Remember that UPDATE is a nonINVITE transaction and there may be a  
>> _long_ time between the UPDATE and the 200-INVITE.
>>
>> Paul drew the arrow backwards for the 200-UPDATE though - did that  
>> mislead you?
>>
>
> Ah, yes, I read that Alice had sent a second conflicting offer in  
> UPDATE.
>
> However, even with this directionality, the answer in the  
> INVITE-200, if present, would have to be a copy of the answer in  
> the 183. This doesn't create any error I can see, it just  
> illustrates the UPDATE race condition that would have existed even  
> had there not been an answer in the 183. Early media, early  
> session, and UPDATE were all bad ideas (probably all because of  
> forking and PSTN interactions) IMHO, and I'm pretty sure reliable  
> provisionals are on that list too.
>
>
>>>>
>>>>   Alice               Bob
>>>>     |  INVITE offer1   |
>>>>     |----------------->|
>>>>     |  183 answer1     |
>>>>     |<-----------------|
>>>>     |  PRACK           |
>>>>     |----------------->|
>>>>     |  200 PRACK       |
>>>>     |<-----------------|
>>>>     |  UPDATE offer2   |
>>>>     |<-----------------|
>>>>     |  200 UP answer2  |
>>>>     |<-----------------|
>>>>     |  200 IN SDP?     |
>>>>     |<-----------------|
>>>>
>>>> Now what should be in the 200 for the invite?
>>>>
>>>> Its better to do what is already required - send no SDP in the  
>>>> 200 for the invite.
>>>
>
> --
> Dean



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 03:34:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv7VT-0005nb-Gn; Thu, 22 Nov 2007 03:33:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv7VS-0005nL-0T
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 03:33:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv7VR-0005nC-JM
	for sip@ietf.org; Thu, 22 Nov 2007 03:33:53 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv7VR-000706-1m
	for sip@ietf.org; Thu, 22 Nov 2007 03:33:53 -0500
Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net
	[96.226.64.76]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAM8Xm8A058370
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 22 Nov 2007 02:33:48 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <4744ABA5.2090501@gmx.net>
References: <753B4BA1-2934-4A88-A6F0-5B55801E0A76@nostrum.com>
	<4744ABA5.2090501@gmx.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <635BE5EA-27B6-4354-AB8C-7D1013E0D55C@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Date: Thu, 22 Nov 2007 02:33:48 -0600
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4882/Wed Nov 21 22:15:37 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: sip List 
Subject: [Sip] Re: SIPit 21 summary & Security
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 21, 2007, at 4:05 PM, Hannes Tschofenig wrote:

> Hi Robert,
>
> I have a question regarding a few sub-items:
>
>> Implementations using each transport for SIP messages:
>>   UDP    100%
>>   TCP     82%
>>   TLS     49% (server auth only)
>>   TLS      6% (mutual auth)
>>   SCTP      3%
>>   DTLS      0%
>>
>> 36% of the implementations supported SIP over IPv6 (up from 25% at  
>> SIPit20)
>> 18% supported SIP over IPSec
> What does it mean when someone supports SIP over IPsec?
> IPsec is independent of SIP. Is this referring to the 3GPP IPsec  
> security between the UA and the P-CSCF?

TLS and SCTP are independent of SIP too.
Most of the implementations supporting IPSec were doing it to support  
the 3GPP call flows, yes.
Some were there were embedded products that could just be set up to  
use IPSec. Take that for what it is.

>
>> Support for various items:
>>   61% rport
>>   15% sigcomp
>>   22% enum
>>   21% sending multiplexing STUN and SIP
>>   28% receiving multiplexed STUN and SIP
>>   22% RFC4320 fixes
>>   12% identity
>>   70% session-timer
>>
> What type of SIP Identity support is this?
> Is this support at the proxy for creating the SIP Identity header?
This is most of what was there.
> Is this support at the end host for creating the SIP Identity header?
I didn't see anyone doing this at SIPit 21.
> Is this support at proxies that verify SIP identity?
Not at SIPit 21, but two proxies plan to have it at SIPit 22
> Is this support by UAs verifying SIP identity?
I didn't see any of this yet.

>
>> Support for various things in the endpoints:
>>   10%   ICE (but there was no interoperability - see below)
>>    0%   ICE-TCP
>>   13%    STUNbis
>>   17%    TURN (again, there was no interoperability)
>>   75%    symmetric RTP
>>   25%    SRTP
>>    0%    RTP over DTLS
> RTP over DTLS was an idea in an old draft for media security. The  
> document was dumped. Hence, the 0% is not surprising.
>
> Ciao
> Hannes
>



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 05:25:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv9F0-000281-SM; Thu, 22 Nov 2007 05:25:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv9Ez-00027q-Aj
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 05:25:01 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9Ey-00027h-W4
	for sip@ietf.org; Thu, 22 Nov 2007 05:25:01 -0500
Received: from wip-cdc-wd.wipro.com ([203.91.201.26])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv9Ex-00086D-Tk
	for sip@ietf.org; Thu, 22 Nov 2007 05:25:00 -0500
Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1])
	by localhost (Postfix) with ESMTP id 59C1418062
	for ; Thu, 22 Nov 2007 15:54:57 +0530 (IST)
Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92])
	by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 47D2F18059
	for ; Thu, 22 Nov 2007 15:54:57 +0530 (IST)
Received: from BLR-EC-MBX04.wipro.com ([10.201.50.168]) by
	blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 22 Nov 2007 15:54:57 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 15:54:58 +0530
Message-ID: <2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
In-Reply-To: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQ
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com>
From: 
To: ,
	
X-OriginalArrivalTime: 22 Nov 2007 10:24:57.0788 (UTC)
	FILETIME=[EE5D1FC0:01C82CF1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I was surprised to find=20

> * There were implementations that offered an m-line with codecs A, B,
> and C, got an answer with C, then got upset when they got RTP with A
> (which is quite legal).

On the list (like others who argued about it I think).

I had some offline discussions with some of the members on this.
While I agree this seems legal, this seems very counter-intuitive and
may result in wasted resources, would it not?

For example, if the offerer is a conference bridge or a transcoder, and
has a limited number of codecs of each type he offers, why should it
hold on to one codec of each type for the duration of the session, even
though the answerer has not supported it?

Any particular reason why this should be continued as a legal scenario?
Would it not be possible change it to say that the Offerer needs to
expect only those codecs which answerer has explicitly supported in the
answer?

Regards,
Ravi.

--
=20
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
=20
ravishankar.shiroor@wipro.com
--

> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: Tuesday, November 20, 2007 2:38 AM
> To: sip List
> Subject: [Sip] SIPit 21 : Topics that attendees argued about
>=20
> Digging through my notes:
>=20
> Here are some of the topics where people were arguing. I'm capturing
> the smaller topics here. Larger arguments will get their own message.
>=20
> * There were arguments about the dynamic payload map from numbers to
> codecs (identified in the SDP and sent in the RTP) being the same in
> the offer and the answer . The spec says they SHOULD. Some
> implementations were insisting they MUST.
> * There were arguments around preserving the relative order of codecs
> on an m-line between the offer and the answer. The specs say SHOULD.
> * There were implementations that offered an m-line with codecs A, B,
> and C, got an answer with C, then got upset when they got RTP with A
> (which is quite legal).
> * There were arguments about deleting rejected m-lines on re-invites
> (which you cannot do), and on reusing the slot they occupy in re-
> invites (which you can do).
> * There were implementations that didn't add the refresher tag in a
> session-refresh message when they were the refresher and there were
> arguments about whether that meant the other side could take the role.
> * Several implementations handled a=3Dsendonly as a session attribute,
> but not a media attribute - it can appear in either place.
>=20
>=20
>=20
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 05:30:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv9Jz-0001zD-Ne; Thu, 22 Nov 2007 05:30:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv9Jy-0001tp-J2
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 05:30:10 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9Jx-0001re-Ul
	for sip@ietf.org; Thu, 22 Nov 2007 05:30:10 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv9Jw-0008JS-Sv
	for sip@ietf.org; Thu, 22 Nov 2007 05:30:09 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	011282124F; Thu, 22 Nov 2007 11:28:40 +0100 (CET)
X-AuditID: c1b4fb3e-af6a0bb00000459d-49-474559d8376f
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	D74AA2124C; Thu, 22 Nov 2007 11:28:40 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 11:28:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] media-security-requirements and lawful intercept
Date: Thu, 22 Nov 2007 11:28:39 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] media-security-requirements and lawful intercept
Thread-Index: AcgsSWeha+ZrgAPbTKGIfZRpk1fvjAAKXnos
References: <06c101c8209d$8d543700$c4f0200a@cisco.com>	<20071111224707.68E5033C21@delta.rtfm.com><008701c824d4$096ca180$c4f0200a@cisco.com>
	<4741FD6B.10507@nostrum.com>
	
	<47443E2E.3020507@nostrum.com>
From: "Christer Holmberg" 
To: "Adam Roach" 
X-OriginalArrivalTime: 22 Nov 2007 10:28:40.0686 (UTC)
	FILETIME=[7338A8E0:01C82CF2]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1
Cc: IETF SIP List , Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1209744952=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1209744952==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82CF2.73124527"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82CF2.73124527
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

>> I don't understand this "IETF SIP" versus "3GPP SIP" thing.
>>
>> "3GPP SIP" is a SIP profile, including a number of SIP extensions,
all
>> done in IETF. There is nothing which a non-3GPP entity can't use.
> =20
>
>I said the bifurcation exists _in_ _the_ _market_. Did you follow the
>link I included? It's extraordinarily relevant. If you need more
>context: these are screenshots from the SIP account configuration
>screens on the Nokia E61:
>
>

I did follow the link. My question was not directly towards you. It was
a more generic question, because this IETF SIP versus 3GPP SIP thing
comes up quite often.

>We can argue over whether the split is real on the technical level (and
there are several reasons that it is -- for example, using SigComp
without proper signaling of the intention to do so ahead of time), but
it's all a moot point:=20
>products are already being designed with two distinct modes of
operation.

I think that SigComp is a special case. SigComp is needed when you
connect to IMS using certain access technologies (I don't think SigComp
is mandatory for all IMS access technologies), so you need to study what
the requirements are for those access technologies. It's not necessarily
something you negotiate in SIP - it's a "pre-condition".

>>> What is "IETF SIP"? What do I have to implement in order to be "IETF
>>> SIP" compliant? RFC3261? RFC3261 plus each and every extension out
>>> there?
>> =20
>RFC 3261 plus proper negotiation of any extensions you choose to
>support. More emphatically: any behavior that is not in 3261 or its
>references needs to be explicitly negotiated before it is engaged. This
>applies to both clients and network servers.

Just because you are able to negotiate it doesn't mean that you are able
to fulfill the requirements the operator has.

>Need something more clear-cut? Something you can apply empirically?
>Here's a litmus test for you: if the initial signaling between two
>network elements can't negotiate down to base SIP without any
>extensions, then it's no longer SIP.

If that is true, everything would work with 3261, and we wouldn't need
any extensions...

There are reasons we have defined extensions, and way to require support
of them, and that is because they are needed in certain environements,
and for certain services, features and use-cases. That is nothing 3GPP
specific - anyone designing/deploying a SIP based network and services
may require certain extensions in order to make things work.

Regards,

Christer

=20


------_=_NextPart_001_01C82CF2.73124527
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Re: [Sip] media-security-requirements and =
lawful intercept






Hi,



>> I don't understand this "IETF =
SIP" versus=20
"3GPP SIP" thing.
>>
>> "3GPP SIP" is a SIP profile, =
including=20
a number of SIP extensions, all
>> done in IETF. There is =
nothing which=20
a non-3GPP entity can't use.
>  
>
>I said =
the=20
bifurcation exists _in_ _the_ _market_. Did you follow the
>link I =

included? It's extraordinarily relevant. If you need =
more
>context: these=20
are screenshots from the SIP account configuration
>screens on the =
Nokia=20
E61:
>
><http://www.nost=
rum.com/~adam/images/too-late.png>


I did follow the link. My question was not directly =
towards you.=20
It was a more generic question, because this IETF SIP versus 3GPP SIP =
thing=20
comes up quite often.

>We can argue over whether the split is =
real on=20
the technical level (and there are several reasons that it is -- for =
example,=20
using SigComp without proper signaling of the intention to do so ahead =
of time),=20
but it's all a moot point: 
>products are =
already=20
being designed with two distinct modes of operation.


I =
think that SigComp=20
is a special case. SigComp is needed when you connect to IMS using =
certain=20
access technologies (I don't think SigComp is mandatory for all IMS =
access=20
technologies), so you need to study what the requirements are for those =
access=20
technologies. It's not necessarily something you negotiate in SIP - it's =
a=20
"pre-condition".



>>> What is =
"IETF SIP"?=20
What do I have to implement in order to be "IETF
>>> SIP" =
compliant?=20
RFC3261? RFC3261 plus each and every extension out
>>>=20
there?
>>  
>RFC 3261 plus proper negotiation =
of any=20
extensions you choose to
>support. More emphatically: any behavior =
that is=20
not in 3261 or its
>references needs to be explicitly negotiated =
before it=20
is engaged. This
>applies to both clients and network=20
servers.


Just because you are able to negotiate it doesn't mean =
that you=20
are able to fulfill the requirements the operator has.

>Need =
something=20
more clear-cut? Something you can apply empirically?
>Here's a =
litmus test=20
for you: if the initial signaling between two
>network elements =
can't=20
negotiate down to base SIP without any
>extensions, then it's no =
longer=20
SIP.


If that is true, everything would work with 3261, and =
we=20
wouldn't need any extensions...


There are reasons we have defined extensions, and =
way to=20
require support of them, and that is because they are needed in certain=20
environements, and for certain services, features and =
use-cases. That is nothing 3GPP specific - anyone=20
designing/deploying a SIP based network and services may require =
certain=20
extensions in order to make things work.


Regards,


Christer


 




------_=_NextPart_001_01C82CF2.73124527--



--===============1209744952==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1209744952==--





From sip-bounces@ietf.org Thu Nov 22 05:33:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv9Nd-0002Ts-M0; Thu, 22 Nov 2007 05:33:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv9Nc-0002Tn-M6
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 05:33:56 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9Nc-0002Tc-Ae
	for sip@ietf.org; Thu, 22 Nov 2007 05:33:56 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv9Nb-0008U7-FT
	for sip@ietf.org; Thu, 22 Nov 2007 05:33:56 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	DC61C203AF; Thu, 22 Nov 2007 11:33:54 +0100 (CET)
X-AuditID: c1b4fb3e-b0ea3bb00000459d-7b-47455b120c36
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	BA91420170; Thu, 22 Nov 2007 11:33:54 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 11:33:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 11:33:53 +0100
Message-ID: 
In-Reply-To: <2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFA=
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com>
	<2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
From: "Christer Holmberg" 
To: ,
	,
	
X-OriginalArrivalTime: 22 Nov 2007 10:33:54.0646 (UTC)
	FILETIME=[2E5B2760:01C82CF3]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

I agree with Ravi.=20

Eventhough you in theory is supposed to be able to receive what you
offer - no matter what you get in the answer - I think that in real life
the only codecs that participants will be prepared to send/receive are
the ones sent both in the offer and the answer. That is also the reason
why the answer normally doesn't contain additional codecs - it mostly
contains a subset of the codecs in the offer.

Regards,

Christer



>I was surprised to find=20
>=20
>>* There were implementations that offered an m-line with codecs A, B,=20
>>and C, got an answer with C, then got upset when they got RTP with A=20
>>(which is quite legal).
>=20
>On the list (like others who argued about it I think).
>=20
>I had some offline discussions with some of the members on this.
>While I agree this seems legal, this seems very=20
>counter-intuitive and may result in wasted resources, would it not?
>=20
>For example, if the offerer is a conference bridge or a=20
>transcoder, and has a limited number of codecs of each type=20
>he offers, why should it hold on to one codec of each type=20
>for the duration of the session, even though the answerer has=20
>not supported it?
>=20
>Any particular reason why this should be continued as a legal=20
>scenario?
>Would it not be possible change it to say that the Offerer=20
>needs to expect only those codecs which answerer has=20
>explicitly supported in the answer?
>=20
>Regards,
>Ravi.
>=20
> --
> =20
> Ravishankar. G. Shiroor
> Wipro Technologies, Bangalore.
> =20
> ravishankar.shiroor@wipro.com
> --
>=20
> > -----Original Message-----
> > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > Sent: Tuesday, November 20, 2007 2:38 AM
> > To: sip List
> > Subject: [Sip] SIPit 21 : Topics that attendees argued about
> >=20
> > Digging through my notes:
> >=20
> > Here are some of the topics where people were arguing. I'm=20
> capturing=20
> > the smaller topics here. Larger arguments will get their=20
> own message.
> >=20
> > * There were arguments about the dynamic payload map from=20
> numbers to=20
> > codecs (identified in the SDP and sent in the RTP) being=20
> the same in=20
> > the offer and the answer . The spec says they SHOULD. Some=20
> > implementations were insisting they MUST.
> > * There were arguments around preserving the relative order=20
> of codecs=20
> > on an m-line between the offer and the answer. The specs say SHOULD.
> > * There were implementations that offered an m-line with=20
> codecs A, B,=20
> > and C, got an answer with C, then got upset when they got=20
> RTP with A=20
> > (which is quite legal).
> > * There were arguments about deleting rejected m-lines on=20
> re-invites=20
> > (which you cannot do), and on reusing the slot they occupy in re-=20
> > invites (which you can do).
> > * There were implementations that didn't add the refresher tag in a=20
> > session-refresh message when they were the refresher and there were=20
> > arguments about whether that meant the other side could=20
> take the role.
> > * Several implementations handled a=3Dsendonly as a session=20
> attribute,=20
> > but not a media attribute - it can appear in either place.
> >=20
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 05:50:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv9dc-0004Ft-IN; Thu, 22 Nov 2007 05:50:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv9db-00042f-1b
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 05:50:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9da-0003tM-6b
	for sip@ietf.org; Thu, 22 Nov 2007 05:50:26 -0500
Received: from py-out-1112.google.com ([64.233.166.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv9dW-0003eW-W6
	for sip@ietf.org; Thu, 22 Nov 2007 05:50:26 -0500
Received: by py-out-1112.google.com with SMTP id d32so14472215pye
	for ; Thu, 22 Nov 2007 02:50:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:from:to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index:message-id;
	bh=V0voD+mDVNB2gQSARtwcugPsXGlkvGNsbL4IzOmA+6k=;
	b=arp54GfakrRnZLVkxY18sCgujk1C321D9Cla+3HsIYjlQqDEmbR/iiDxBWn49IPorTgZwS0hhzllfL+11fLgNrOgol7d20Oo9nPWcAHLRGvXFDRam3mlWW+k8WYTjUFd2GSmJnTsUpmXbFpKVjNkMP6lrGHWTGmdizjG2SIgc5U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:from:to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index:message-id;
	b=dxrwL620n0yk3bY12smKhWd/yzSb85Mt5JWu2x0fT3z33DGSljnH2hwaEDgcbDz8GNrGTqT32OJTCzNH8k/ghqxsdU9V7UnhTq+T0Kve45+74STLv76tMEaZWfMGLrOTM5U/b17sckCscCS7X5SEhjSO+Z9CV7LuvSujiw/Z8eI=
Received: by 10.64.27.13 with SMTP id a13mr19268632qba.1195728622269;
	Thu, 22 Nov 2007 02:50:22 -0800 (PST)
Received: from rjpc ( [69.121.211.94])
	by mx.google.com with ESMTPS id q16sm5007086qbq.2007.11.22.02.50.21
	(version=SSLv3 cipher=RC4-MD5); Thu, 22 Nov 2007 02:50:21 -0800 (PST)
From: "Raj Jain" 
To: "'Christer Holmberg'" ,
	, , 
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 05:50:20 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFAAAJTZIA==
Message-ID: <47455eed.102b400a.13a4.39b6@mx.google.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

You can always lock down a codec by updating the initial offer. Take a look
at section 10.2 of RFC 3264.

Raj


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
> Sent: Thursday, November 22, 2007 5:34 AM
> To: ravishankar.shiroor@wipro.com; rjsparks@nostrum.com; sip@ietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
> 
> 
> Hi,
> 
> I agree with Ravi. 
> 
> Eventhough you in theory is supposed to be able to receive 
> what you offer - no matter what you get in the answer - I 
> think that in real life the only codecs that participants 
> will be prepared to send/receive are the ones sent both in 
> the offer and the answer. That is also the reason why the 
> answer normally doesn't contain additional codecs - it mostly 
> contains a subset of the codecs in the offer.
> 
> Regards,
> 
> Christer
> 
> 
> 
> >I was surprised to find
> > 
> >>* There were implementations that offered an m-line with 
> codecs A, B, 
> >>and C, got an answer with C, then got upset when they got 
> RTP with A 
> >>(which is quite legal).
> > 
> >On the list (like others who argued about it I think).
> > 
> >I had some offline discussions with some of the members on this.
> >While I agree this seems legal, this seems very 
> counter-intuitive and 
> >may result in wasted resources, would it not?
> > 
> >For example, if the offerer is a conference bridge or a 
> transcoder, and 
> >has a limited number of codecs of each type he offers, why should it 
> >hold on to one codec of each type for the duration of the 
> session, even 
> >though the answerer has not supported it?
> > 
> >Any particular reason why this should be continued as a 
> legal scenario?
> >Would it not be possible change it to say that the Offerer needs to 
> >expect only those codecs which answerer has explicitly 
> supported in the 
> >answer?
> > 
> >Regards,
> >Ravi.
> > 
> > --
> >  
> > Ravishankar. G. Shiroor
> > Wipro Technologies, Bangalore.
> >  
> > ravishankar.shiroor@wipro.com
> > --
> > 
> > > -----Original Message-----
> > > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > > Sent: Tuesday, November 20, 2007 2:38 AM
> > > To: sip List
> > > Subject: [Sip] SIPit 21 : Topics that attendees argued about
> > > 
> > > Digging through my notes:
> > > 
> > > Here are some of the topics where people were arguing. I'm
> > capturing
> > > the smaller topics here. Larger arguments will get their
> > own message.
> > > 
> > > * There were arguments about the dynamic payload map from
> > numbers to
> > > codecs (identified in the SDP and sent in the RTP) being
> > the same in
> > > the offer and the answer . The spec says they SHOULD. Some 
> > > implementations were insisting they MUST.
> > > * There were arguments around preserving the relative order
> > of codecs
> > > on an m-line between the offer and the answer. The specs 
> say SHOULD.
> > > * There were implementations that offered an m-line with
> > codecs A, B,
> > > and C, got an answer with C, then got upset when they got
> > RTP with A
> > > (which is quite legal).
> > > * There were arguments about deleting rejected m-lines on
> > re-invites
> > > (which you cannot do), and on reusing the slot they occupy in re- 
> > > invites (which you can do).
> > > * There were implementations that didn't add the 
> refresher tag in a 
> > > session-refresh message when they were the refresher and 
> there were 
> > > arguments about whether that meant the other side could
> > take the role.
> > > * Several implementations handled a=sendonly as a session
> > attribute,
> > > but not a media attribute - it can appear in either place.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> 
> _______________________________________________
> 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



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 05:58:24 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv9lF-0004ZZ-LS; Thu, 22 Nov 2007 05:58:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iv9lE-0004ZO-Qz
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 05:58:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9lE-0004ZG-HE
	for sip@ietf.org; Thu, 22 Nov 2007 05:58:20 -0500
Received: from mxs1.siemens.at ([194.138.12.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv9l9-0003vG-C4
	for sip@ietf.org; Thu, 22 Nov 2007 05:58:20 -0500
Received: from vies1k7x.sie.siemens.at ([158.226.129.83])
	by mxs1.siemens.at  with ESMTP id lAMAwDvF012808;
	Thu, 22 Nov 2007 11:58:13 +0100
Received: from nets139a.ww300.siemens.net ([158.226.129.97])
	by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id
	lAMAwBsM018486; Thu, 22 Nov 2007 11:58:12 +0100
Received: from atnets15pa.ww300.siemens.net ([158.226.250.54]) by
	nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 22 Nov 2007 11:57:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 11:57:52 +0100
Message-ID: <5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFAAAK2sEA==
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com><2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
	
From: "Horvath, Ernst" 
To: "Christer Holmberg" ,
	, , 
X-OriginalArrivalTime: 22 Nov 2007 10:57:53.0388 (UTC)
	FILETIME=[87E9C2C0:01C82CF6]
X-purgate: clean
X-purgate: This mail is considered clean
X-purgate-type: clean
X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net
X-purgate-ID: 149917::071122115813-6719FBB0-1A4E52D6/0-0/0-15
X-purgate-size: 5571/0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I am surprised that this caused any confusion. RFC 3264 seems pretty
clear to me.

Citing from section 6.1:
  "The answerer MUST send using a media format in the offer
   that is also listed in the answer, and SHOULD send using the most
   preferred media format in the offer that is also listed in the
answer."

and from section 7:
  "The offerer MAY immediately cease listening for media formats that
   were listed in the initial offer, but not present in the answer."

So, why should the offerer be expected to deal with formats not present
in the answer? (Of course, the offerer must be prepared to receive ALL
offered formats BEFORE the answer arrives)

Regards,
Ernst Horvath


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
> Sent: Thursday, November 22, 2007 11:34 AM
> To: ravishankar.shiroor@wipro.com; rjsparks@nostrum.com; sip@ietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
>=20
>=20
> Hi,
>=20
> I agree with Ravi.=20
>=20
> Eventhough you in theory is supposed to be able to receive what you
> offer - no matter what you get in the answer - I think that=20
> in real life
> the only codecs that participants will be prepared to send/receive are
> the ones sent both in the offer and the answer. That is also=20
> the reason
> why the answer normally doesn't contain additional codecs - it mostly
> contains a subset of the codecs in the offer.
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
> >I was surprised to find=20
> >=20
> >>* There were implementations that offered an m-line with=20
> codecs A, B,=20
> >>and C, got an answer with C, then got upset when they got=20
> RTP with A=20
> >>(which is quite legal).
> >=20
> >On the list (like others who argued about it I think).
> >=20
> >I had some offline discussions with some of the members on this.
> >While I agree this seems legal, this seems very=20
> >counter-intuitive and may result in wasted resources, would it not?
> >=20
> >For example, if the offerer is a conference bridge or a=20
> >transcoder, and has a limited number of codecs of each type=20
> >he offers, why should it hold on to one codec of each type=20
> >for the duration of the session, even though the answerer has=20
> >not supported it?
> >=20
> >Any particular reason why this should be continued as a legal=20
> >scenario?
> >Would it not be possible change it to say that the Offerer=20
> >needs to expect only those codecs which answerer has=20
> >explicitly supported in the answer?
> >=20
> >Regards,
> >Ravi.
> >=20
> > --
> > =20
> > Ravishankar. G. Shiroor
> > Wipro Technologies, Bangalore.
> > =20
> > ravishankar.shiroor@wipro.com
> > --
> >=20
> > > -----Original Message-----
> > > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > > Sent: Tuesday, November 20, 2007 2:38 AM
> > > To: sip List
> > > Subject: [Sip] SIPit 21 : Topics that attendees argued about
> > >=20
> > > Digging through my notes:
> > >=20
> > > Here are some of the topics where people were arguing. I'm=20
> > capturing=20
> > > the smaller topics here. Larger arguments will get their=20
> > own message.
> > >=20
> > > * There were arguments about the dynamic payload map from=20
> > numbers to=20
> > > codecs (identified in the SDP and sent in the RTP) being=20
> > the same in=20
> > > the offer and the answer . The spec says they SHOULD. Some=20
> > > implementations were insisting they MUST.
> > > * There were arguments around preserving the relative order=20
> > of codecs=20
> > > on an m-line between the offer and the answer. The specs=20
> say SHOULD.
> > > * There were implementations that offered an m-line with=20
> > codecs A, B,=20
> > > and C, got an answer with C, then got upset when they got=20
> > RTP with A=20
> > > (which is quite legal).
> > > * There were arguments about deleting rejected m-lines on=20
> > re-invites=20
> > > (which you cannot do), and on reusing the slot they occupy in re-=20
> > > invites (which you can do).
> > > * There were implementations that didn't add the=20
> refresher tag in a=20
> > > session-refresh message when they were the refresher and=20
> there were=20
> > > arguments about whether that meant the other side could=20
> > take the role.
> > > * Several implementations handled a=3Dsendonly as a session=20
> > attribute,=20
> > > but not a media attribute - it can appear in either place.
> > >=20
> > >=20
> > >=20
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use=20
> > > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > > sipping@ietf.org for new developments on the application of sip
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip=20
> > Use sipping@ietf.org for new developments on the application of sip
> >=20
>=20
>=20
> _______________________________________________
> 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
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 06:40:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvAPz-0003JC-Hc; Thu, 22 Nov 2007 06:40:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvAPx-0003Am-K2
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 06:40:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvAPw-00036k-RJ
	for sip@ietf.org; Thu, 22 Nov 2007 06:40:24 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvAPw-00034f-7k
	for sip@ietf.org; Thu, 22 Nov 2007 06:40:24 -0500
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAMBeIWq018486; 
	Thu, 22 Nov 2007 05:40:18 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 05:40:18 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 12:40:17 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] draft-gunn-sip-req-for-rph-in-responses-00: What is
	impacton response?
Date: Thu, 22 Nov 2007 12:40:15 +0100
Message-ID: <5D1A7985295922448D5550C94DE291800197443E@DEEXC1U01.de.lucent.com>
In-Reply-To: <5A8C011C-2D22-44F7-B98A-47CC81C97F8E@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-gunn-sip-req-for-rph-in-responses-00: What is
	impacton response?
Thread-Index: Acgsi3yHf7U80LUkQlm0cffKaAe0iAAbwgVw
References: 
	<5A8C011C-2D22-44F7-B98A-47CC81C97F8E@softarmor.com>
From: "DRAGE, Keith \(Keith\)" 
To: "Dean Willis" ,
	"James M. Polk" 
X-OriginalArrivalTime: 22 Nov 2007 11:40:17.0106 (UTC)
	FILETIME=[74165320:01C82CFC]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

If this is an issue, I think it is an issue within the existing RFC in
regard to requests themselves:

RFC 4412 section 3.1.

   There is no protocol requirement that all requests within a SIP
   dialog or session use the 'Resource-Priority' header field.  Local
   administrative policy MAY mandate the inclusion of the
   'Resource-Priority' header field in all requests.  Implementations of
   this specification MUST allow inclusion to be either by explicit user
   request or automatic for all requests.

Additionally I could find no requirement that specified that the value
used in an INVITE request had to be the same as a value used in say, a
reINVITE request in the same dialog, even when the Resource-Priority
header was included in both requests.

I think this leads to the need of this discussion to clearly identify in
the questions raised:

-	whether the point concerns the enhancement to RFC 4412 to
support some new use cases;
-	whether there is a problem in the existing RFC 4412 itself, i.e.
the existing documentation is broken.

Regards

Keith
=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Wednesday, November 21, 2007 10:11 PM
> To: James M. Polk
> Cc: IETF SIP List
> Subject: Re: [Sip]=20
> draft-gunn-sip-req-for-rph-in-responses-00: What is impacton response?
>=20
>=20
> On Nov 21, 2007, at 3:22 PM, James M. Polk wrote:
> >> If the
> >> RPH value is not resent, then the RPH value would cease to apply.
> >
> > This isn't stated, but I think once a priority is=20
> established within a=20
> > dialog, it doesn't cease because a new transaction within=20
> that dialog=20
> > didn't contain the same namespace.priority-value.  But I do=20
> expect any=20
> > new transaction to contain at least the same RPH values as the=20
> > existing dialog.
>=20
> If RPH can change on a per-message cycle within a dialog, is=20
> the transmission of a message without an RPH header within=20
> the dialog the same as explicitly sending an RPH that conveys=20
> no priority? This needs to be clear in the documentation.
>=20
> --
> dean
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 07:13:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvAw4-000255-M5; Thu, 22 Nov 2007 07:13:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvAw3-00024o-I1
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 07:13:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvAw3-000226-4m
	for sip@ietf.org; Thu, 22 Nov 2007 07:13:35 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvAw2-0004AH-IB
	for sip@ietf.org; Thu, 22 Nov 2007 07:13:35 -0500
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAMCDUws023618; 
	Thu, 22 Nov 2007 06:13:32 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 06:13:32 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 13:13:30 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Need for RPH in SIP Responses
Date: Thu, 22 Nov 2007 13:13:29 +0100
Message-ID: <5D1A7985295922448D5550C94DE291800197445E@DEEXC1U01.de.lucent.com>
In-Reply-To: <4744B854.1040605@zonnet.nl>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Need for RPH in SIP Responses
Thread-Index: Acgskjxp/y6sbK47RqKB0bQpAy77cQAbqvrw
References: <47449FA0.6050904@zonnet.nl><28F05913385EAC43AF019413F674A0171246E6B9@OCCLUST04EVS1.ugd.att.com>
	<4744B854.1040605@zonnet.nl>
From: "DRAGE, Keith \(Keith\)" 
To: "Jeroen van Bemmel" ,
	"DOLLY, MARTIN C, ATTLABS" 
X-OriginalArrivalTime: 22 Nov 2007 12:13:30.0031 (UTC)
	FILETIME=[17F68BF0:01C82D01]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: sip@ietf.org, "Sandesara, Niranjan B" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Again, I would like to understand whether there is a specific issue with =
regard to RPH in responses, or whether this is a discussion of a failing =
of RFC 4412 as published for requests.

I am not seeing a point here that relations specifically to RPH in =
responses.

Regards

Keith=20

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20
> Sent: Wednesday, November 21, 2007 11:00 PM
> To: DOLLY, MARTIN C, ATTLABS
> Cc: sip@ietf.org; Sandesara, Niranjan B
> Subject: Re: [Sip] Need for RPH in SIP Responses
>=20
> Martin,
>=20
> It appears we have a different view on what constitutes the=20
> Internet - perhaps because I am not from the US. In any case,=20
> I was referring to the Internet as a whole, exactly as in RFC3455:
>=20
> The SIP extensions specified in this document make certain
>    assumptions regarding network topology, linkage between=20
> SIP and lower
>    layers, and the availability of transitive trust.  These=20
> assumptions
>    are generally NOT APPLICABLE in the Internet as a whole.
>=20
> The proposed mechanism is only secure under assumptions that=20
> do not hold in the Internet as a whole. It is not only a=20
> minor change from the current RPH usage, as=20
> draft-polk-sip-rph-in-responses-00 tries to say ("The only=20
> new security threat...")
>=20
> To me, there are 3 things that could happen:
> 1. ignore/accept it and generate an RFC
> 2. define additional security measures to mitigate 3.=20
> consider a different solution
>=20
> Regards,
> Jeroen
>=20
> DOLLY, MARTIN C, ATTLABS wrote:
> > Jeroen,
> >
> > It does apply to a concatenation of managed networks, lets say=20
> > UE-AT&T-Verizon-UE...Oh, this is the same concatenation for=20
> what you=20
> > are referring to as the "internet"..right? Only difference is a=20
> > different portion of our IP backbones.
> >
> > More important here (please just don't cut/paste the above without=20
> > this), for wireless access the user's priority level may=20
> change based=20
> > on call processing, including authentication, and this needs to be=20
> > relayed back to the wireless access.
> >
> > Cheers,
> >
> > Martin
> >
> > -----Original Message-----
> > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
> > Sent: Wednesday, November 21, 2007 4:14 PM
> > To: Sandesara, Niranjan B
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] Need for RPH in SIP Responses
> >
> > Niranjan,
> >
> >  =20
> >> As has been pointed out earlier, possible security risk of=20
> permitting=20
> >> RPH in SIP responses is minimal in managed IP networks where this=20
> >> capability is generally expected to be used.
> >>
> >>    =20
> > For this argument to apply, the element sending the RPH header in a=20
> > response and the element acting on it should both be in the=20
> same domain.
> >
> > In other words you are talking about a closed system, a=20
> very specific=20
> > environment. The use of this header in this way then=20
> clearly does not=20
> > apply to the Internet; the proper way to standardize this is as a=20
> > P-header (instead of taking a header which is already defined in a=20
> > "approved-for-the-Internet" RFC, and modifying its allowed use to=20
> > accommodate for a non-Internet use)
> >
> > Regards,
> > Jeroen
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >
> >  =20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 07:25:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvB6q-0005Og-KD; Thu, 22 Nov 2007 07:24:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvB6p-0005Mx-Il
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 07:24:43 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvB6o-0005Mn-PB
	for sip@ietf.org; Thu, 22 Nov 2007 07:24:42 -0500
Received: from wip-cdc-wd.wipro.com ([203.91.201.26])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvB6n-0004VG-6Y
	for sip@ietf.org; Thu, 22 Nov 2007 07:24:42 -0500
Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1])
	by localhost (Postfix) with ESMTP id ED0601805C
	for ; Thu, 22 Nov 2007 17:54:37 +0530 (IST)
Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91])
	by wip-cdc-wd.wipro.com (Postfix) with ESMTP id D7D7C18059
	for ; Thu, 22 Nov 2007 17:54:37 +0530 (IST)
Received: from BLR-EC-MBX02.wipro.com ([10.201.50.161]) by
	blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 22 Nov 2007 17:54:38 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 17:53:27 +0530
Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE05C04C1E@BLR-EC-MBX02.wipro.com>
In-Reply-To: <5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFAAAK2sEAAC204w
From: 
To: , ,
	, , 
X-OriginalArrivalTime: 22 Nov 2007 12:24:38.0199 (UTC)
	FILETIME=[A638E470:01C82D02]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Comments inline...

Regards,
Nataraju A B
=20
> -----Original Message-----
> From: Horvath, Ernst [mailto:ernst.horvath@siemens.com]=20
> Sent: Thursday, November 22, 2007 4:28 PM
> To: Christer Holmberg; RaviShankar Shiroor (WT01 - Telecom=20
> Applications and Solutions); rjsparks@nostrum.com; sip@ietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
>=20
> I am surprised that this caused any confusion. RFC 3264 seems=20
> pretty clear to me.
>=20
> Citing from section 6.1:
>   "The answerer MUST send using a media format in the offer
>    that is also listed in the answer, and SHOULD send using the most
>    preferred media format in the offer that is also listed in=20
> the answer."
>=20
> and from section 7:
>   "The offerer MAY immediately cease listening for media formats that
>    were listed in the initial offer, but not present in the answer."
>=20
> So, why should the offerer be expected to deal with formats=20
> not present in the answer? (Of course, the offerer must be=20
> prepared to receive ALL offered formats BEFORE the answer arrives)
>=20
[ABN] this looks to me that, UAC upon reception of answer is not
expected to listen for any codec's not listed in the answer. But
accepting even the other codec's published in offer but not in answer
makes it lineant in accepting the packets from the other peer. But this
clearly outside the scope of standards.=20

But if we turn off the accepting other codec's not listed in answer
would yield better hardware resource utilization.
Just for instance,=20

Offer: g711u, g711a, g729
Answer: g711u, g711a

In this case after the o/a negotiation completes, then if we tune the
hardware resources @ UAC for g711 codec handling only, then the
bandwidth/resource utilization @ UAC would be optimal. The same
resources could be utilized for other calls which need g729 packet
handling capability.

Hope this makes sense to turn off particular codec handling (@UAC) not
listed in answer, but published in offer.

> Regards,
> Ernst Horvath
>=20
>=20
> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > Sent: Thursday, November 22, 2007 11:34 AM
> > To: ravishankar.shiroor@wipro.com; rjsparks@nostrum.com;=20
> sip@ietf.org
> > Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
> >=20
> >=20
> > Hi,
> >=20
> > I agree with Ravi.=20
> >=20
> > Eventhough you in theory is supposed to be able to receive what you=20
> > offer - no matter what you get in the answer - I think that in real=20
> > life the only codec's that participants will be prepared to=20
> > send/receive are the ones sent both in the offer and the=20
> answer. That=20
> > is also the reason why the answer normally doesn't contain=20
> additional=20
> > codec's - it mostly contains a subset of the codec's in the offer.
> >=20
> > Regards,
> >=20
> > Christer
> >=20
> >=20
> >=20
> > >I was surprised to find
> > >=20
> > >>* There were implementations that offered an m-line with
> > codec's A, B,
> > >>and C, got an answer with C, then got upset when they got
> > RTP with A
> > >>(which is quite legal).
> > >=20
> > >On the list (like others who argued about it I think).
> > >=20
> > >I had some offline discussions with some of the members on this.
> > >While I agree this seems legal, this seems very=20
> counter-intuitive and=20
> > >may result in wasted resources, would it not?
> > >=20
> > >For example, if the offerer is a conference bridge or a=20
> transcoder,=20
> > >and has a limited number of codec's of each type he offers,=20
> why should=20
> > >it hold on to one codec of each type for the duration of=20
> the session,=20
> > >even though the answerer has not supported it?
> > >=20
> > >Any particular reason why this should be continued as a legal=20
> > >scenario?
> > >Would it not be possible change it to say that the Offerer=20
> needs to=20
> > >expect only those codec's which answerer has explicitly=20
> supported in=20
> > >the answer?
> > >=20
> > >Regards,
> > >Ravi.
> > >=20
> > > --
> > > =20
> > > Ravishankar. G. Shiroor
> > > Wipro Technologies, Bangalore.
> > > =20
> > > ravishankar.shiroor@wipro.com
> > > --
> > >=20
> > > > -----Original Message-----
> > > > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > > > Sent: Tuesday, November 20, 2007 2:38 AM
> > > > To: sip List
> > > > Subject: [Sip] SIPit 21 : Topics that attendees argued about
> > > >=20
> > > > Digging through my notes:
> > > >=20
> > > > Here are some of the topics where people were arguing. I'm
> > > capturing
> > > > the smaller topics here. Larger arguments will get their
> > > own message.
> > > >=20
> > > > * There were arguments about the dynamic payload map from
> > > numbers to
> > > > codec's (identified in the SDP and sent in the RTP) being
> > > the same in
> > > > the offer and the answer . The spec says they SHOULD. Some=20
> > > > implementations were insisting they MUST.
> > > > * There were arguments around preserving the relative order
> > > of codec's
> > > > on an m-line between the offer and the answer. The specs
> > say SHOULD.
> > > > * There were implementations that offered an m-line with
> > > codec's A, B,
> > > > and C, got an answer with C, then got upset when they got
> > > RTP with A
> > > > (which is quite legal).
> > > > * There were arguments about deleting rejected m-lines on
> > > re-invites
> > > > (which you cannot do), and on reusing the slot they=20
> occupy in re-=20
> > > > invites (which you can do).
> > > > * There were implementations that didn't add the
> > refresher tag in a
> > > > session-refresh message when they were the refresher and
> > there were
> > > > arguments about whether that meant the other side could
> > > take the role.
> > > > * Several implementations handled a=3Dsendonly as a session
> > > attribute,
> > > > but not a media attribute - it can appear in either place.
> > > >=20
> > > >=20
> > > >=20
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol Use=20
> > > > sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> > > > sipping@ietf.org for new developments on the application of sip
> > >=20
> > >=20
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use=20
> > > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > > sipping@ietf.org for new developments on the application of sip
> > >=20
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 07:28:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvBAj-00074U-OH; Thu, 22 Nov 2007 07:28:45 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvBAi-000714-Dq
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 07:28:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvBAi-0006yk-11
	for sip@ietf.org; Thu, 22 Nov 2007 07:28:44 -0500
Received: from bender-mail.tigertech.net ([64.62.209.30])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvBAh-0004bs-8D
	for sip@ietf.org; Thu, 22 Nov 2007 07:28:43 -0500
Received: from localhost (localhost [127.0.0.1])
	by bender.tigertech.net (Postfix) with ESMTP id 220FF7DE3;
	Thu, 22 Nov 2007 04:28:42 -0800 (PST)
Received: from [192.168.0.101] (pool-71-161-50-253.clppva.east.verizon.net
	[71.161.50.253])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bender.tigertech.net (Postfix) with ESMTP id A00C67DD0;
	Thu, 22 Nov 2007 04:28:39 -0800 (PST)
Message-ID: <474575F5.5000201@joelhalpern.com>
Date: Thu, 22 Nov 2007 07:28:37 -0500
From: "Joel M. Halpern" 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" 
Subject: Re: [Sip] Need for RPH in SIP Responses
References: <47449FA0.6050904@zonnet.nl><28F05913385EAC43AF019413F674A0171246E6B9@OCCLUST04EVS1.ugd.att.com>	<4744B854.1040605@zonnet.nl>
	<5D1A7985295922448D5550C94DE291800197445E@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE291800197445E@DEEXC1U01.de.lucent.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net
X-Spam-Status: No, hits=3.4 tagged_above=-999.0 required=7.0
	tests=RCVD_IN_SORBS_DUL, SPF_NEUTRAL
X-Spam-Level: ***
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , "Sandesara,
	Niranjan B" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

As I read the documents, there is a real point that prompts the need for
RPH in responses.  This has nothing to do with stateless proxies.
Rather, it has to do with the case where the device assigning the RPH is
upstream of a device that needs to make use of the information.

That situation seems to be quite reasonable, does not require a B2BUA,
and can be reasonably recognized and acted upon in a number of different
network topologies.

However, some of the discussion has raised questions that do need to be
clarified in the document which actually defines the extension.  Issues
such as whether a response can have a lower priority in its RPH than a
request, appropriately trusting / using the RPH in the response, etc.
It appears to me that part of the confusion about those issues is that
there are related issues (such as the scope of the RPH, and changes
during a dialog) that apply to the original document and are not well
specified.

Yours,
Joel M. Halpern

PS: In addition to the fact that the basic problem described in the I-D
does not depend upon the stateless / stateful nature of the proxy, the
reason I avoid the stateless proxy aspect is that I doubt very much that
an RPH in a response will noticeably affect the actual response
processing if no other steps were taken before one got to parsing
sufficient header to get to that.   Until this upstream notification was
brought forward, I was doubtful about the use of the header in this fashion.

DRAGE, Keith (Keith) wrote:
> Again, I would like to understand whether there is a specific issue with regard to RPH in responses, or whether this is a discussion of a failing of RFC 4412 as published for requests.
> 
> I am not seeing a point here that relations specifically to RPH in responses.
> 
> Regards
> 
> Keith 
> 
>> -----Original Message-----
>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] 
>> Sent: Wednesday, November 21, 2007 11:00 PM
>> To: DOLLY, MARTIN C, ATTLABS
>> Cc: sip@ietf.org; Sandesara, Niranjan B
>> Subject: Re: [Sip] Need for RPH in SIP Responses
>>
>> Martin,
>>
>> It appears we have a different view on what constitutes the 
>> Internet - perhaps because I am not from the US. In any case, 
>> I was referring to the Internet as a whole, exactly as in RFC3455:
>>
>> The SIP extensions specified in this document make certain
>>    assumptions regarding network topology, linkage between 
>> SIP and lower
>>    layers, and the availability of transitive trust.  These 
>> assumptions
>>    are generally NOT APPLICABLE in the Internet as a whole.
>>
>> The proposed mechanism is only secure under assumptions that 
>> do not hold in the Internet as a whole. It is not only a 
>> minor change from the current RPH usage, as 
>> draft-polk-sip-rph-in-responses-00 tries to say ("The only 
>> new security threat...")
>>
>> To me, there are 3 things that could happen:
>> 1. ignore/accept it and generate an RFC
>> 2. define additional security measures to mitigate 3. 
>> consider a different solution
>>
>> Regards,
>> Jeroen
>>
>> DOLLY, MARTIN C, ATTLABS wrote:
>>> Jeroen,
>>>
>>> It does apply to a concatenation of managed networks, lets say 
>>> UE-AT&T-Verizon-UE...Oh, this is the same concatenation for 
>> what you 
>>> are referring to as the "internet"..right? Only difference is a 
>>> different portion of our IP backbones.
>>>
>>> More important here (please just don't cut/paste the above without 
>>> this), for wireless access the user's priority level may 
>> change based 
>>> on call processing, including authentication, and this needs to be 
>>> relayed back to the wireless access.
>>>
>>> Cheers,
>>>
>>> Martin
>>>
>>> -----Original Message-----
>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
>>> Sent: Wednesday, November 21, 2007 4:14 PM
>>> To: Sandesara, Niranjan B
>>> Cc: sip@ietf.org
>>> Subject: Re: [Sip] Need for RPH in SIP Responses
>>>
>>> Niranjan,
>>>
>>>   
>>>> As has been pointed out earlier, possible security risk of 
>> permitting 
>>>> RPH in SIP responses is minimal in managed IP networks where this 
>>>> capability is generally expected to be used.
>>>>
>>>>     
>>> For this argument to apply, the element sending the RPH header in a 
>>> response and the element acting on it should both be in the 
>> same domain.
>>> In other words you are talking about a closed system, a 
>> very specific 
>>> environment. The use of this header in this way then 
>> clearly does not 
>>> apply to the Internet; the proper way to standardize this is as a 
>>> P-header (instead of taking a header which is already defined in a 
>>> "approved-for-the-Internet" RFC, and modifying its allowed use to 
>>> accommodate for a non-Internet use)
>>>
>>> Regards,
>>> Jeroen
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>   
>>
>> _______________________________________________
>> 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
>>
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 09:12:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvCmA-0005LW-28; Thu, 22 Nov 2007 09:11:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvCm8-0005LJ-4t
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:11:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCm7-0005LB-P8
	for sip@ietf.org; Thu, 22 Nov 2007 09:11:27 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvCm6-00085k-QF
	for sip@ietf.org; Thu, 22 Nov 2007 09:11:27 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	E2BF321205; Thu, 22 Nov 2007 15:11:25 +0100 (CET)
X-AuditID: c1b4fb3e-aee9fbb00000459d-21-47458e0d225d
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	C6527211F4; Thu, 22 Nov 2007 15:11:25 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 15:11:25 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 15:11:24 +0100
Message-ID: 
In-Reply-To: <5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFAAAK2sEAAG8e5Q
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com><2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
	
	<5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
From: "Christer Holmberg" 
To: "Horvath, Ernst" ,
	, , 
X-OriginalArrivalTime: 22 Nov 2007 14:11:25.0649 (UTC)
	FILETIME=[915C2C10:01C82D11]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,=20

>I am surprised that this caused any confusion. RFC 3264 seems=20
>pretty clear to me.
>=20
>Citing from section 6.1:
>  "The answerer MUST send using a media format in the offer
>   that is also listed in the answer, and SHOULD send using the most
>   preferred media format in the offer that is also listed in=20
>   the answer."

The question is not what the offerer is supposed to send, but what he
should be able to receive.


>and from section 7:
>   "The offerer MAY immediately cease listening for media formats that
>    were listed in the initial offer, but not present in the answer."

Yes. The problem with the "MAY" is that the other party doesn't know
whether the offerer will listen or not, so therefor I think it's more
saft to only use codecs which BOTH entities include in the SDP.

>So, why should the offerer be expected to deal with formats=20
>not present in the answer? (Of course, the offerer must be=20
>prepared to receive ALL offered formats BEFORE the answer arrives)

In many cases the offerer will not - due to different kind of reasons -
accept anything before he receives the answer (yes, yes, I know what
RFC3261 says...).

Regards,

Christer







> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > Sent: Thursday, November 22, 2007 11:34 AM
> > To: ravishankar.shiroor@wipro.com; rjsparks@nostrum.com;=20
> sip@ietf.org
> > Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
> >=20
> >=20
> > Hi,
> >=20
> > I agree with Ravi.=20
> >=20
> > Eventhough you in theory is supposed to be able to receive what you=20
> > offer - no matter what you get in the answer - I think that in real=20
> > life the only codecs that participants will be prepared to=20
> > send/receive are the ones sent both in the offer and the=20
> answer. That=20
> > is also the reason why the answer normally doesn't contain=20
> additional=20
> > codecs - it mostly contains a subset of the codecs in the offer.
> >=20
> > Regards,
> >=20
> > Christer
> >=20
> >=20
> >=20
> > >I was surprised to find
> > >=20
> > >>* There were implementations that offered an m-line with
> > codecs A, B,
> > >>and C, got an answer with C, then got upset when they got
> > RTP with A
> > >>(which is quite legal).
> > >=20
> > >On the list (like others who argued about it I think).
> > >=20
> > >I had some offline discussions with some of the members on this.
> > >While I agree this seems legal, this seems very=20
> counter-intuitive and=20
> > >may result in wasted resources, would it not?
> > >=20
> > >For example, if the offerer is a conference bridge or a=20
> transcoder,=20
> > >and has a limited number of codecs of each type he offers,=20
> why should=20
> > >it hold on to one codec of each type for the duration of=20
> the session,=20
> > >even though the answerer has not supported it?
> > >=20
> > >Any particular reason why this should be continued as a legal=20
> > >scenario?
> > >Would it not be possible change it to say that the Offerer=20
> needs to=20
> > >expect only those codecs which answerer has explicitly=20
> supported in=20
> > >the answer?
> > >=20
> > >Regards,
> > >Ravi.
> > >=20
> > > --
> > > =20
> > > Ravishankar. G. Shiroor
> > > Wipro Technologies, Bangalore.
> > > =20
> > > ravishankar.shiroor@wipro.com
> > > --
> > >=20
> > > > -----Original Message-----
> > > > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > > > Sent: Tuesday, November 20, 2007 2:38 AM
> > > > To: sip List
> > > > Subject: [Sip] SIPit 21 : Topics that attendees argued about
> > > >=20
> > > > Digging through my notes:
> > > >=20
> > > > Here are some of the topics where people were arguing. I'm
> > > capturing
> > > > the smaller topics here. Larger arguments will get their
> > > own message.
> > > >=20
> > > > * There were arguments about the dynamic payload map from
> > > numbers to
> > > > codecs (identified in the SDP and sent in the RTP) being
> > > the same in
> > > > the offer and the answer . The spec says they SHOULD. Some=20
> > > > implementations were insisting they MUST.
> > > > * There were arguments around preserving the relative order
> > > of codecs
> > > > on an m-line between the offer and the answer. The specs
> > say SHOULD.
> > > > * There were implementations that offered an m-line with
> > > codecs A, B,
> > > > and C, got an answer with C, then got upset when they got
> > > RTP with A
> > > > (which is quite legal).
> > > > * There were arguments about deleting rejected m-lines on
> > > re-invites
> > > > (which you cannot do), and on reusing the slot they=20
> occupy in re-=20
> > > > invites (which you can do).
> > > > * There were implementations that didn't add the
> > refresher tag in a
> > > > session-refresh message when they were the refresher and
> > there were
> > > > arguments about whether that meant the other side could
> > > take the role.
> > > > * Several implementations handled a=3Dsendonly as a session
> > > attribute,
> > > > but not a media attribute - it can appear in either place.
> > > >=20
> > > >=20
> > > >=20
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol Use=20
> > > > sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> > > > sipping@ietf.org for new developments on the application of sip
> > >=20
> > >=20
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use=20
> > > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > > sipping@ietf.org for new developments on the application of sip
> > >=20
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 09:14:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvCpN-0003dL-2Z; Thu, 22 Nov 2007 09:14:49 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvCpL-0003d7-HC
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:14:47 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCpL-0003cz-5l
	for sip@ietf.org; Thu, 22 Nov 2007 09:14:47 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvCpK-0008Bf-48
	for sip@ietf.org; Thu, 22 Nov 2007 09:14:47 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	893782080F; Thu, 22 Nov 2007 15:14:45 +0100 (CET)
X-AuditID: c1b4fb3c-b1f9bbb0000030cf-a1-47458ed5bb4a
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	6609320452; Thu, 22 Nov 2007 15:14:45 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 15:14:45 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
Date: Thu, 22 Nov 2007 15:14:44 +0100
Message-ID: 
In-Reply-To: <3100473D52017B48B9068E079BE2A6E6029AC62C@ZMY16EXM67.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit21: BNF future-proofing problem?
Thread-Index: AcgsSaCFMdxh9wfFTeKGF2CITLPJSAAAZ63wAAashzgAGJzNMAASUQ/g
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com><66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com><6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com>
	
	<3100473D52017B48B9068E079BE2A6E6029AC62C@ZMY16EXM67.ds.mot.com>
From: "Christer Holmberg" 
To: "T Satyanarayana-A12694" ,
	"Robert Sparks" 
X-OriginalArrivalTime: 22 Nov 2007 14:14:45.0254 (UTC)
	FILETIME=[08557A60:01C82D12]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ed68cc91cc637fea89623888898579ba
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,=20

>This would mean a large change to existing parsers and formatters. And
also, the "escaping" and "unescaping" overheads.

Existing parsers would not reject the message due to unsupported
characters, because you would only use characters already allowed.

Of course, parser would need to be able to unescapte those characters.
But, again, I wonder whether the characters we are talking about are
really needed in the first place...

>Changing the header-value BNF may be more acceptable?

Extending the definition is for sure going to have impacts on many
existing parsers.

Regards,

Christer





> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Wednesday, November 21, 2007 11:13 PM
> To: Christer Holmberg; Robert Sparks
> Cc: sip List
> Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
>=20
> Hi,
> =20
> Another alternative would be to define an escaping mechanism=20
> for quoted-strings in SIP messages, and require all=20
> characters not allowed by the header-value ABNF to be escaped.
> =20
> Regards,
> =20
> Christer=20
>=20
> ________________________________
>=20
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Wed 21/11/2007 15:33
> To: Robert Sparks
> Cc: sip List
> Subject: RE: [Sip] SIPit21: BNF future-proofing problem?
>=20
>=20
>=20
>=20
> Hi,
>=20
> >So to restate the problem that was reported:
> >
> >Right now, extension-header does not allow a new header that=20
> contains a
>=20
> >quoted-string.
> >
> >We have defined extensions (and are likely to define new
> >ones) that use quoted-string (anything that uses name-addr for=20
> >instance).
> >
> >This inconsistency has caused interoperability problems in real=20
> >implementations.
> >
> >My original note was to suggest that we change extension-header to=20
> >actually allow the headers we're going to define.
> >
> >Christer's response could be read as a proposal to change
> >quoted- string to achieve the same goal.
>=20
> Yes.
>=20
> Unless someone can show a use-case where the x00-x20=20
> characters would be needed, for backward compability reasons=20
> I think it's better to restrict quoted-string than to extend=20
> extension-header.
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
> > > Hi,
> > >
> > > I am still a little unclear what Robert is proposing, but=20
> is there=20
> > > really a need to be able to use characters between x00 and
> > x20 in SIP
> > > messages? Characters between x21 and x7F, and between x80
> > and xBF, are
> > > ok since they are covered by TEXT-UTF8char and UTF8-CONT.
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > >
> > > ________________________________
> > >
> > >     From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
> > >     Sent: 21. marraskuuta 2007 7:30
> > >     To: Robert Sparks
> > >     Cc: sip List
> > >     Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
> > >   =20
> > >   =20
> > >     I think I did misread Robert's original email. I=20
> thought header=20
> > > values having quoted strings are currently not allowed and Robert=20
> > > wanted to change RFC2822. Now I realise that you can have
> > header field
> > > values with quoted string. Therefore I support the=20
> correction that=20
> > > Robert is proposing.
> > >   =20
> > >     Hisham
> > >   =20
> > >   =20
> > >     On 21/11/2007, Hisham Khartabil 
> > > wrote:
> > >
> > >             This is a big change if we do adopt it. It will
> > cause a lot of
> > > problem to parsers that handle extenion headers today and is not=20
> > > backwards compatible. Why isn't the extension header as=20
> is defined=20
> > > today not sufficient?
> > >                           =20
> > >             Hisham
> > >           =20
> > >           =20
> > >                                             On 20/11/2007, Robert=20
> > > Sparks  wrote:
> > >
> > >                     The BNF in 3261 says the following:
> > >                   =20
> > >                     extension-header  =3D  header-name HCOLON
> > header-value
> > >                     header-value      =3D  *(TEXT-UTF8char=20
> / UTF8-CONT
> > > / LWS)
> > >                   =20
> > >                     This is intended to be the catch-all
> > field for all future
> > > extensions
> > >                     - older parsers working against this
> > BNF shouldn't barf
> > >                     when we introduce a new header field.
> > >                   =20
> > >                     Now, we may have new fields in the
> > future that look like:
> > >                   =20
> > >                     NewHeader =3D new-header-name HCOLON=20
> quoted-string
> > >                   =20
> > >                     And down inside quoted-string, we get:
> > >                   =20
> > >                           quoted-string  =3D  SWS DQUOTE
> > *(qdtext / quoted-pair ) DQUOTE
> > >                           qdtext         =3D  LWS / %x21 / %x23-5B =
/
> > > %x5D-7E
> > >                                             / UTF8-NONASCII
> > >                           quoted-pair  =3D  "\" (%x00-09 / %x0B-0C
> > >                                            / %x0E-7F)
> > >                   =20
> > >                     So, for instance, we could have inside
> > a quoted string the 2 byte
> > >                     sequence \ NULL
> > >                   =20
> > >                     This does not parse against
> > header-value above...
> > >                   =20
> > >                     Is this a problem? Some of the SIPit21
> > participants argued that it
> > > is.
> > >                   =20
> > >                     The projects I've been involved in
> > don't parse unknown headers and
> > >                     the stacks will just hand up an
> > unparsed bucket of bits (the only
> > > rules
> > >                     used are those necessary to identify
> > the next header-field
> > > starting).
> > >                   =20
> > >                     Would it be worth the effort to make
> > the BNF reflect that rather
> > > than
> > >                     continuing with the incongruity that we
> > currently specify?
> > >                   =20
> > >                     RjS
> > >                   =20
> > >                   =20
> > >                    =20
> _______________________________________________
> > >                     Sip mailing list=20
> > > 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
> > >                   =20
> > >
> > >
> > >           =20
> >
> >
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 09:58:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvDVv-0003jY-Ek; Thu, 22 Nov 2007 09:58:47 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvDVt-0003jG-Kw
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:58:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDVt-0003j8-A5
	for sip@ietf.org; Thu, 22 Nov 2007 09:58:45 -0500
Received: from wip-cdc-wd.wipro.com ([203.91.201.26])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvDVs-0001Gg-32
	for sip@ietf.org; Thu, 22 Nov 2007 09:58:45 -0500
Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1])
	by localhost (Postfix) with ESMTP id 0584418055
	for ; Thu, 22 Nov 2007 19:58:30 +0530 (IST)
Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91])
	by wip-cdc-wd.wipro.com (Postfix) with ESMTP id E6D6418051
	for ; Thu, 22 Nov 2007 19:58:29 +0530 (IST)
Received: from BLR-EC-MBX04.wipro.com ([10.201.50.168]) by
	blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 22 Nov 2007 19:58:30 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 19:58:30 +0530
Message-ID: <2C7074A1A040E54DA31B3E72C052FD520938CA13@BLR-EC-MBX04.wipro.com>
In-Reply-To: <47455eed.102b400a.13a4.39b6@mx.google.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFAAAJTZIAAHhi7w
References: 
	<47455eed.102b400a.13a4.39b6@mx.google.com>
From: 
To: , ,
	, 
X-OriginalArrivalTime: 22 Nov 2007 14:28:30.0603 (UTC)
	FILETIME=[F447BDB0:01C82D13]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

>=20
> You can always lock down a codec by updating the initial offer. Take a
> look
> at section 10.2 of RFC 3264.

That would be when you have to lock down to a subset of what has been
supported in the answer. Lets say if the offer contained A,B,C and the
answer contained only B, what would be the need to lockdown specifically
by another offer answer?

I am trying to understand if there is any particular reason why it has
been kept as it has been kept, considering that one more offer answer
would mean one more round of signaling overhead.

Regards,
Ravi.

>=20
> Raj
>=20
>=20
> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > Sent: Thursday, November 22, 2007 5:34 AM
> > To: ravishankar.shiroor@wipro.com; rjsparks@nostrum.com;
sip@ietf.org
> > Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
> >
> >
> > Hi,
> >
> > I agree with Ravi.
> >
> > Eventhough you in theory is supposed to be able to receive
> > what you offer - no matter what you get in the answer - I
> > think that in real life the only codecs that participants
> > will be prepared to send/receive are the ones sent both in
> > the offer and the answer. That is also the reason why the
> > answer normally doesn't contain additional codecs - it mostly
> > contains a subset of the codecs in the offer.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> > >I was surprised to find
> > >
> > >>* There were implementations that offered an m-line with
> > codecs A, B,
> > >>and C, got an answer with C, then got upset when they got
> > RTP with A
> > >>(which is quite legal).
> > >
> > >On the list (like others who argued about it I think).
> > >
> > >I had some offline discussions with some of the members on this.
> > >While I agree this seems legal, this seems very
> > counter-intuitive and
> > >may result in wasted resources, would it not?
> > >
> > >For example, if the offerer is a conference bridge or a
> > transcoder, and
> > >has a limited number of codecs of each type he offers, why should
it
> > >hold on to one codec of each type for the duration of the
> > session, even
> > >though the answerer has not supported it?
> > >
> > >Any particular reason why this should be continued as a
> > legal scenario?
> > >Would it not be possible change it to say that the Offerer needs to
> > >expect only those codecs which answerer has explicitly
> > supported in the
> > >answer?
> > >
> > >Regards,
> > >Ravi.
> > >
> > > --
> > >
> > > Ravishankar. G. Shiroor
> > > Wipro Technologies, Bangalore.
> > >
> > > ravishankar.shiroor@wipro.com
> > > --
> > >
> > > > -----Original Message-----
> > > > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > > > Sent: Tuesday, November 20, 2007 2:38 AM
> > > > To: sip List
> > > > Subject: [Sip] SIPit 21 : Topics that attendees argued about
> > > >
> > > > Digging through my notes:
> > > >
> > > > Here are some of the topics where people were arguing. I'm
> > > capturing
> > > > the smaller topics here. Larger arguments will get their
> > > own message.
> > > >
> > > > * There were arguments about the dynamic payload map from
> > > numbers to
> > > > codecs (identified in the SDP and sent in the RTP) being
> > > the same in
> > > > the offer and the answer . The spec says they SHOULD. Some
> > > > implementations were insisting they MUST.
> > > > * There were arguments around preserving the relative order
> > > of codecs
> > > > on an m-line between the offer and the answer. The specs
> > say SHOULD.
> > > > * There were implementations that offered an m-line with
> > > codecs A, B,
> > > > and C, got an answer with C, then got upset when they got
> > > RTP with A
> > > > (which is quite legal).
> > > > * There were arguments about deleting rejected m-lines on
> > > re-invites
> > > > (which you cannot do), and on reusing the slot they occupy in
re-
> > > > invites (which you can do).
> > > > * There were implementations that didn't add the
> > refresher tag in a
> > > > session-refresh message when they were the refresher and
> > there were
> > > > arguments about whether that meant the other side could
> > > take the role.
> > > > * Several implementations handled a=3Dsendonly as a session
> > > attribute,
> > > > but not a media attribute - it can appear in either place.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > >
> > > _______________________________________________
> > > 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
> > >
> >
> >
> > _______________________________________________
> > 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



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 10:00:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvDXi-0005UB-7p; Thu, 22 Nov 2007 10:00:38 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvDXh-0005U0-0t
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 10:00:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDXg-0005Ts-NA
	for sip@ietf.org; Thu, 22 Nov 2007 10:00:36 -0500
Received: from mxs1.siemens.at ([194.138.12.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvDXZ-0003Fe-Iu
	for sip@ietf.org; Thu, 22 Nov 2007 10:00:36 -0500
Received: from vies1k7x.sie.siemens.at ([158.226.129.83])
	by mxs1.siemens.at  with ESMTP id lAMF0R12027487;
	Thu, 22 Nov 2007 16:00:27 +0100
Received: from nets139a.ww300.siemens.net ([158.226.129.97])
	by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id
	lAMF0QG0005327; Thu, 22 Nov 2007 16:00:27 +0100
Received: from atnets15pa.ww300.siemens.net ([158.226.250.54]) by
	nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 22 Nov 2007 16:00:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 16:00:26 +0100
Message-ID: <5AB8CA778E49D149B6EAEC3B864C7A8C015B24D4@atnets15pa.ww300.siemens.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFAAAK2sEAAG8e5QAAE/XNA=
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com><2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
	
	<5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
	
From: "Horvath, Ernst" 
To: "Christer Holmberg" ,
	, , 
X-OriginalArrivalTime: 22 Nov 2007 15:00:26.0810 (UTC)
	FILETIME=[6A6DB9A0:01C82D18]
X-purgate: clean
X-purgate: This mail is considered clean
X-purgate-type: clean
X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net
X-purgate-ID: 149917::071122160027-6719CBB0-258E3DA8/0-0/0-15
X-purgate-size: 7857/0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

See inline comments.=20

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
> Sent: Thursday, November 22, 2007 3:11 PM
> To: Horvath, Ernst; ravishankar.shiroor@wipro.com;=20
> rjsparks@nostrum.com; sip@ietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
>=20
>=20
> Hi,=20
>=20
> >I am surprised that this caused any confusion. RFC 3264 seems=20
> >pretty clear to me.
> >=20
> >Citing from section 6.1:
> >  "The answerer MUST send using a media format in the offer
> >   that is also listed in the answer, and SHOULD send using the most
> >   preferred media format in the offer that is also listed in=20
> >   the answer."
>=20
> The question is not what the offerer is supposed to send, but what he
> should be able to receive.
>=20

So what's the problem? The text talks about what the answerer is
supposed to send, not the offerer.  Initially the offerer must expect
any format that he included in the offer. But once the answer has
arrived, an answerer that conforms to RFC 3264 WILL send only formats
included in the answer, so the offerer CAN stop listening for all other
formats.

>=20
> >and from section 7:
> >   "The offerer MAY immediately cease listening for media=20
> formats that
> >    were listed in the initial offer, but not present in the answer."
>=20
> Yes. The problem with the "MAY" is that the other party doesn't know
> whether the offerer will listen or not, so therefor I think it's more
> saft to only use codecs which BOTH entities include in the SDP.

No, the MAY gives a conformant offerer the permission to stop listening
immediately on arrival of the answer. That means for the conformant
answerer that he MUST NOT assume that the offerer is still listening for
formats that were not in the answer. I know, auxiliary verbs can be
tricky, but the two cited excerpts from RFC 3264 are entirely
consistent.

Regards,
Ernst

>=20
> >So, why should the offerer be expected to deal with formats=20
> >not present in the answer? (Of course, the offerer must be=20
> >prepared to receive ALL offered formats BEFORE the answer arrives)
>=20
> In many cases the offerer will not - due to different kind of=20
> reasons -
> accept anything before he receives the answer (yes, yes, I know what
> RFC3261 says...).
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > > Sent: Thursday, November 22, 2007 11:34 AM
> > > To: ravishankar.shiroor@wipro.com; rjsparks@nostrum.com;=20
> > sip@ietf.org
> > > Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
> > >=20
> > >=20
> > > Hi,
> > >=20
> > > I agree with Ravi.=20
> > >=20
> > > Eventhough you in theory is supposed to be able to=20
> receive what you=20
> > > offer - no matter what you get in the answer - I think=20
> that in real=20
> > > life the only codecs that participants will be prepared to=20
> > > send/receive are the ones sent both in the offer and the=20
> > answer. That=20
> > > is also the reason why the answer normally doesn't contain=20
> > additional=20
> > > codecs - it mostly contains a subset of the codecs in the offer.
> > >=20
> > > Regards,
> > >=20
> > > Christer
> > >=20
> > >=20
> > >=20
> > > >I was surprised to find
> > > >=20
> > > >>* There were implementations that offered an m-line with
> > > codecs A, B,
> > > >>and C, got an answer with C, then got upset when they got
> > > RTP with A
> > > >>(which is quite legal).
> > > >=20
> > > >On the list (like others who argued about it I think).
> > > >=20
> > > >I had some offline discussions with some of the members on this.
> > > >While I agree this seems legal, this seems very=20
> > counter-intuitive and=20
> > > >may result in wasted resources, would it not?
> > > >=20
> > > >For example, if the offerer is a conference bridge or a=20
> > transcoder,=20
> > > >and has a limited number of codecs of each type he offers,=20
> > why should=20
> > > >it hold on to one codec of each type for the duration of=20
> > the session,=20
> > > >even though the answerer has not supported it?
> > > >=20
> > > >Any particular reason why this should be continued as a legal=20
> > > >scenario?
> > > >Would it not be possible change it to say that the Offerer=20
> > needs to=20
> > > >expect only those codecs which answerer has explicitly=20
> > supported in=20
> > > >the answer?
> > > >=20
> > > >Regards,
> > > >Ravi.
> > > >=20
> > > > --
> > > > =20
> > > > Ravishankar. G. Shiroor
> > > > Wipro Technologies, Bangalore.
> > > > =20
> > > > ravishankar.shiroor@wipro.com
> > > > --
> > > >=20
> > > > > -----Original Message-----
> > > > > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > > > > Sent: Tuesday, November 20, 2007 2:38 AM
> > > > > To: sip List
> > > > > Subject: [Sip] SIPit 21 : Topics that attendees argued about
> > > > >=20
> > > > > Digging through my notes:
> > > > >=20
> > > > > Here are some of the topics where people were arguing. I'm
> > > > capturing
> > > > > the smaller topics here. Larger arguments will get their
> > > > own message.
> > > > >=20
> > > > > * There were arguments about the dynamic payload map from
> > > > numbers to
> > > > > codecs (identified in the SDP and sent in the RTP) being
> > > > the same in
> > > > > the offer and the answer . The spec says they SHOULD. Some=20
> > > > > implementations were insisting they MUST.
> > > > > * There were arguments around preserving the relative order
> > > > of codecs
> > > > > on an m-line between the offer and the answer. The specs
> > > say SHOULD.
> > > > > * There were implementations that offered an m-line with
> > > > codecs A, B,
> > > > > and C, got an answer with C, then got upset when they got
> > > > RTP with A
> > > > > (which is quite legal).
> > > > > * There were arguments about deleting rejected m-lines on
> > > > re-invites
> > > > > (which you cannot do), and on reusing the slot they=20
> > occupy in re-=20
> > > > > invites (which you can do).
> > > > > * There were implementations that didn't add the
> > > refresher tag in a
> > > > > session-refresh message when they were the refresher and
> > > there were
> > > > > arguments about whether that meant the other side could
> > > > take the role.
> > > > > * Several implementations handled a=3Dsendonly as a session
> > > > attribute,
> > > > > but not a media attribute - it can appear in either place.
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > _______________________________________________
> > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > This list is for NEW development of the core SIP Protocol Use=20
> > > > > sip-implementors@cs.columbia.edu for questions on=20
> > current sip Use=20
> > > > > sipping@ietf.org for new developments on the=20
> application of sip
> > > >=20
> > > >=20
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol Use=20
> > > > sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> > > > sipping@ietf.org for new developments on the application of sip
> > > >=20
> > >=20
> > >=20
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use=20
> > > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > > sipping@ietf.org for new developments on the application of sip
> > >=20
> >=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 10:15:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvDlM-0007UN-6s; Thu, 22 Nov 2007 10:14:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvDlK-0007U7-Jn
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 10:14:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDlK-0007Tw-9u
	for sip@ietf.org; Thu, 22 Nov 2007 10:14:42 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvDlF-0003mU-P2
	for sip@ietf.org; Thu, 22 Nov 2007 10:14:42 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	BB55C211A6; Thu, 22 Nov 2007 16:13:21 +0100 (CET)
X-AuditID: c1b4fb3e-ae69ebb00000459d-be-47459c916ddf
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	95AEA21191; Thu, 22 Nov 2007 16:13:21 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 16:13:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 16:13:20 +0100
Message-ID: 
In-Reply-To: <5AB8CA778E49D149B6EAEC3B864C7A8C015B24D4@atnets15pa.ww300.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFAAAK2sEAAG8e5QAAE/XNAAAOEUcA==
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com><2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
	
	<5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
	
	<5AB8CA778E49D149B6EAEC3B864C7A8C015B24D4@atnets15pa.ww300.siemens.net>
From: "Christer Holmberg" 
To: "Horvath, Ernst" ,
	, , 
X-OriginalArrivalTime: 22 Nov 2007 15:13:21.0486 (UTC)
	FILETIME=[382BE6E0:01C82D1A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,=20

>>>I am surprised that this caused any confusion. RFC 3264 seems pretty=20
>>>clear to me.
>>>=20
>>>Citing from section 6.1:
>>>  "The answerer MUST send using a media format in the offer
>>>   that is also listed in the answer, and SHOULD send using the most
>>>   preferred media format in the offer that is also listed in=20
>>>   the answer."
>>=20
>>The question is not what the offerer is supposed to send,=20
>>but what he should be able to receive.
>>=20
>=20
>So what's the problem? The text talks about what the answerer=20
>is supposed to send, not the offerer.=20

Correct, my misstake. When reading the text again, I agree that it is
clear: whatever codec the answerer is going to send must be both in the
offer AND in the answer.


>Initially the offerer must expect any format that he included in the
offer. But=20
>once the answer has arrived, an answerer that conforms to RFC=20
>3264 WILL send only formats included in the answer, so the=20
>offerer CAN stop listening for all other formats.
>=20
>>=20
>>>and from section 7:
>>>"The offerer MAY immediately cease listening for media formats that
>>>were listed in the initial offer, but not present in the answer."
>>=20
>>Yes. The problem with the "MAY" is that the other party doesn't know=20
>>whether the offerer will listen or not, so therefor I think it's more=20
>>saft to only use codecs which BOTH entities include in the SDP.
>=20
>No, the MAY gives a conformant offerer the permission to stop=20
>listening immediately on arrival of the answer. That means=20
>for the conformant answerer that he MUST NOT assume that the=20
>offerer is still listening for formats that were not in the=20
>answer. I know, auxiliary verbs can be tricky, but the two=20
>cited excerpts from RFC 3264 are entirely consistent.

Yes, when re-reading the first citing the second citing makes sense.

Regards,

Christer





> > >So, why should the offerer be expected to deal with formats not=20
> > >present in the answer? (Of course, the offerer must be prepared to=20
> > >receive ALL offered formats BEFORE the answer arrives)
> >=20
> > In many cases the offerer will not - due to different kind=20
> of reasons=20
> > - accept anything before he receives the answer (yes, yes,=20
> I know what
> > RFC3261 says...).
> >=20
> > Regards,
> >=20
> > Christer
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > > > -----Original Message-----
> > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > > > Sent: Thursday, November 22, 2007 11:34 AM
> > > > To: ravishankar.shiroor@wipro.com; rjsparks@nostrum.com;
> > > sip@ietf.org
> > > > Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
> > > >=20
> > > >=20
> > > > Hi,
> > > >=20
> > > > I agree with Ravi.=20
> > > >=20
> > > > Eventhough you in theory is supposed to be able to
> > receive what you
> > > > offer - no matter what you get in the answer - I think
> > that in real
> > > > life the only codecs that participants will be prepared to=20
> > > > send/receive are the ones sent both in the offer and the
> > > answer. That
> > > > is also the reason why the answer normally doesn't contain
> > > additional
> > > > codecs - it mostly contains a subset of the codecs in the offer.
> > > >=20
> > > > Regards,
> > > >=20
> > > > Christer
> > > >=20
> > > >=20
> > > >=20
> > > > >I was surprised to find
> > > > >=20
> > > > >>* There were implementations that offered an m-line with
> > > > codecs A, B,
> > > > >>and C, got an answer with C, then got upset when they got
> > > > RTP with A
> > > > >>(which is quite legal).
> > > > >=20
> > > > >On the list (like others who argued about it I think).
> > > > >=20
> > > > >I had some offline discussions with some of the=20
> members on this.
> > > > >While I agree this seems legal, this seems very
> > > counter-intuitive and
> > > > >may result in wasted resources, would it not?
> > > > >=20
> > > > >For example, if the offerer is a conference bridge or a
> > > transcoder,
> > > > >and has a limited number of codecs of each type he offers,
> > > why should
> > > > >it hold on to one codec of each type for the duration of
> > > the session,
> > > > >even though the answerer has not supported it?
> > > > >=20
> > > > >Any particular reason why this should be continued as a legal=20
> > > > >scenario?
> > > > >Would it not be possible change it to say that the Offerer
> > > needs to
> > > > >expect only those codecs which answerer has explicitly
> > > supported in
> > > > >the answer?
> > > > >=20
> > > > >Regards,
> > > > >Ravi.
> > > > >=20
> > > > > --
> > > > > =20
> > > > > Ravishankar. G. Shiroor
> > > > > Wipro Technologies, Bangalore.
> > > > > =20
> > > > > ravishankar.shiroor@wipro.com
> > > > > --
> > > > >=20
> > > > > > -----Original Message-----
> > > > > > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > > > > > Sent: Tuesday, November 20, 2007 2:38 AM
> > > > > > To: sip List
> > > > > > Subject: [Sip] SIPit 21 : Topics that attendees argued about
> > > > > >=20
> > > > > > Digging through my notes:
> > > > > >=20
> > > > > > Here are some of the topics where people were arguing. I'm
> > > > > capturing
> > > > > > the smaller topics here. Larger arguments will get their
> > > > > own message.
> > > > > >=20
> > > > > > * There were arguments about the dynamic payload map from
> > > > > numbers to
> > > > > > codecs (identified in the SDP and sent in the RTP) being
> > > > > the same in
> > > > > > the offer and the answer . The spec says they SHOULD. Some=20
> > > > > > implementations were insisting they MUST.
> > > > > > * There were arguments around preserving the relative order
> > > > > of codecs
> > > > > > on an m-line between the offer and the answer. The specs
> > > > say SHOULD.
> > > > > > * There were implementations that offered an m-line with
> > > > > codecs A, B,
> > > > > > and C, got an answer with C, then got upset when they got
> > > > > RTP with A
> > > > > > (which is quite legal).
> > > > > > * There were arguments about deleting rejected m-lines on
> > > > > re-invites
> > > > > > (which you cannot do), and on reusing the slot they
> > > occupy in re-
> > > > > > invites (which you can do).
> > > > > > * There were implementations that didn't add the
> > > > refresher tag in a
> > > > > > session-refresh message when they were the refresher and
> > > > there were
> > > > > > arguments about whether that meant the other side could
> > > > > take the role.
> > > > > > * Several implementations handled a=3Dsendonly as a session
> > > > > attribute,
> > > > > > but not a media attribute - it can appear in either place.
> > > > > >=20
> > > > > >=20
> > > > > >=20
> > > > > > _______________________________________________
> > > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > > This list is for NEW development of the core SIP=20
> Protocol Use=20
> > > > > > sip-implementors@cs.columbia.edu for questions on
> > > current sip Use
> > > > > > sipping@ietf.org for new developments on the
> > application of sip
> > > > >=20
> > > > >=20
> > > > > _______________________________________________
> > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > This list is for NEW development of the core SIP Protocol Use=20
> > > > > sip-implementors@cs.columbia.edu for questions on
> > current sip Use
> > > > > sipping@ietf.org for new developments on the=20
> application of sip
> > > > >=20
> > > >=20
> > > >=20
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol Use=20
> > > > sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> > > > sipping@ietf.org for new developments on the application of sip
> > > >=20
> > >=20
> >=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 10:21:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvDrd-00070x-8D; Thu, 22 Nov 2007 10:21:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvDrb-00070m-Iz
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 10:21:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDrb-00070d-96
	for sip@ietf.org; Thu, 22 Nov 2007 10:21:11 -0500
Received: from py-out-1112.google.com ([64.233.166.179])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvDrX-0003zs-5l
	for sip@ietf.org; Thu, 22 Nov 2007 10:21:11 -0500
Received: by py-out-1112.google.com with SMTP id d32so14670746pye
	for ; Thu, 22 Nov 2007 07:21:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:from:to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index:message-id;
	bh=xuGrTKeiWLGIxW9Rc57pPqw0yUt0wtgNKRzWrKBRxPo=;
	b=LkGyHZDBHCTugK8RLlZ1gvAvo3URLNKo+C1qCLVWy8brjWbMmQsB0haZJGMSEOUXlo0bsAyagAimbHlxhCYZkW1ycAubBlLTR0U8rSB9vbQ3+F3SDxdvQFPEL7hemNHX96IRqRBGwuXAYuDjo+IkVAWk5ngLU4Rjex58HLSLT6E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:from:to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index:message-id;
	b=FrfmnuKEaN/oVjLPspG2QiXc9jRRx2FMFcjSqofHxGuX8VbclMviVbMrRNc9q1crTYBIt2+SnhkYYYIbzTYG0afY1gS9EsVIBQwqdEHbLYlJvKKLy3rpQN/BJM7j/HACErmVFSUFkGtQUnMWFoOV7EOP4x7ABZqSx3gnFa5vCTg=
Received: by 10.65.154.2 with SMTP id g2mr19783031qbo.1195744866465;
	Thu, 22 Nov 2007 07:21:06 -0800 (PST)
Received: from rjpc ( [69.121.211.94])
	by mx.google.com with ESMTPS id f18sm752390qba.2007.11.22.07.21.04
	(version=SSLv3 cipher=RC4-MD5); Thu, 22 Nov 2007 07:21:05 -0800 (PST)
From: "Raj Jain" 
To: , ,
	, 
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 10:21:04 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <2C7074A1A040E54DA31B3E72C052FD520938CA13@BLR-EC-MBX04.wipro.com>
Thread-Index: Acgq8FQ1k2wuESd9ThCNbAjY1Dy/SACALhqQAABpuFAAAJTZIAAHhi7wAAFr0SA=
Message-ID: <47459e61.1239400a.1fc2.7005@mx.google.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

 
> 
> > > You can always lock down a codec by updating the initial 
> offer. Take 
> > > a
> > look
> > at section 10.2 of RFC 3264.
> 
> That would be when you have to lock down to a subset of what 
> has been supported in the answer. Lets say if the offer 
> contained A,B,C and the answer contained only B, what would 
> be the need to lockdown specifically by another offer answer?

Yes, there is obviously no need to lock down in that case. You are probably
aware that the offerer must be willing to accept any of the codecs that it
offered before the answer arrives (early media). If your offerer
implementation can not handle that then a=inactive in the offer and then a
subsequent update with a=sendrecv will do the trick.

Anyway, you seem to be more concerned about what happens post-answer. I
think RFC 3264 is pretty clear about this. In your example, if the answerer
(who answered with only B) actually sends codecs A or C in the media, then
that answerer is broken. Somebody cited section 6.1 of RFC 3264 in an
earlier posting which clearly spells it out.

Regards,
Raj Jain



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 11:44:16 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvF9t-0004vw-5T; Thu, 22 Nov 2007 11:44:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvF9r-0004vg-HF
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 11:44:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvF9r-0004vW-5Z
	for sip@ietf.org; Thu, 22 Nov 2007 11:44:07 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvF9q-0004rf-Ca
	for sip@ietf.org; Thu, 22 Nov 2007 11:44:07 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAMGi1gY022822;
	Thu, 22 Nov 2007 10:44:05 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 10:44:01 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Nov 2007 17:43:59 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Need for RPH in SIP Responses
Date: Thu, 22 Nov 2007 17:43:58 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019745B2@DEEXC1U01.de.lucent.com>
In-Reply-To: <474575F5.5000201@joelhalpern.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Need for RPH in SIP Responses
Thread-Index: AcgtAzs5Wf8yplfKShqrQmbnLJIUJQAI0TlA
References: <47449FA0.6050904@zonnet.nl><28F05913385EAC43AF019413F674A0171246E6B9@OCCLUST04EVS1.ugd.att.com>	<4744B854.1040605@zonnet.nl>
	<5D1A7985295922448D5550C94DE291800197445E@DEEXC1U01.de.lucent.com>
	<474575F5.5000201@joelhalpern.com>
From: "DRAGE, Keith \(Keith\)" 
To: "Joel M. Halpern" 
X-OriginalArrivalTime: 22 Nov 2007 16:43:59.0334 (UTC)
	FILETIME=[E161A860:01C82D26]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Just to be clear, I personally was not arguing against the use cases.

I was pointing out that issues were being raised in discussing RPH in =
responses that were nothing to do with the new use cases, but appeared =
to be equally issues with RPH in requests.

Such discussion is an issue with RFC 4412, not an issue with either =
author draft, and should be discussed, but on a different thread.=20

Regards

Keith

> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20
> Sent: Thursday, November 22, 2007 12:29 PM
> To: DRAGE, Keith (Keith)
> Cc: Jeroen van Bemmel; DOLLY, MARTIN C, ATTLABS;=20
> sip@ietf.org; Sandesara, Niranjan B
> Subject: Re: [Sip] Need for RPH in SIP Responses
>=20
> As I read the documents, there is a real point that prompts=20
> the need for RPH in responses.  This has nothing to do with=20
> stateless proxies.
> Rather, it has to do with the case where the device assigning=20
> the RPH is upstream of a device that needs to make use of the=20
> information.
>=20
> That situation seems to be quite reasonable, does not require=20
> a B2BUA, and can be reasonably recognized and acted upon in a=20
> number of different network topologies.
>=20
> However, some of the discussion has raised questions that do=20
> need to be clarified in the document which actually defines=20
> the extension.  Issues such as whether a response can have a=20
> lower priority in its RPH than a request, appropriately=20
> trusting / using the RPH in the response, etc.
> It appears to me that part of the confusion about those=20
> issues is that there are related issues (such as the scope of=20
> the RPH, and changes during a dialog) that apply to the=20
> original document and are not well specified.
>=20
> Yours,
> Joel M. Halpern
>=20
> PS: In addition to the fact that the basic problem described=20
> in the I-D does not depend upon the stateless / stateful=20
> nature of the proxy, the reason I avoid the stateless proxy=20
> aspect is that I doubt very much that an RPH in a response=20
> will noticeably affect the actual response processing if no=20
> other steps were taken before one got to parsing
> sufficient header to get to that.   Until this upstream=20
> notification was
> brought forward, I was doubtful about the use of the header=20
> in this fashion.
>=20
> DRAGE, Keith (Keith) wrote:
> > Again, I would like to understand whether there is a=20
> specific issue with regard to RPH in responses, or whether=20
> this is a discussion of a failing of RFC 4412 as published=20
> for requests.
> >=20
> > I am not seeing a point here that relations specifically to=20
> RPH in responses.
> >=20
> > Regards
> >=20
> > Keith
> >=20
> >> -----Original Message-----
> >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
> >> Sent: Wednesday, November 21, 2007 11:00 PM
> >> To: DOLLY, MARTIN C, ATTLABS
> >> Cc: sip@ietf.org; Sandesara, Niranjan B
> >> Subject: Re: [Sip] Need for RPH in SIP Responses
> >>
> >> Martin,
> >>
> >> It appears we have a different view on what constitutes=20
> the Internet=20
> >> - perhaps because I am not from the US. In any case, I was=20
> referring=20
> >> to the Internet as a whole, exactly as in RFC3455:
> >>
> >> The SIP extensions specified in this document make certain
> >>    assumptions regarding network topology, linkage between SIP and=20
> >> lower
> >>    layers, and the availability of transitive trust.  These=20
> >> assumptions
> >>    are generally NOT APPLICABLE in the Internet as a whole.
> >>
> >> The proposed mechanism is only secure under assumptions=20
> that do not=20
> >> hold in the Internet as a whole. It is not only a minor=20
> change from=20
> >> the current RPH usage, as=20
> draft-polk-sip-rph-in-responses-00 tries to=20
> >> say ("The only new security threat...")
> >>
> >> To me, there are 3 things that could happen:
> >> 1. ignore/accept it and generate an RFC 2. define=20
> additional security=20
> >> measures to mitigate 3.
> >> consider a different solution
> >>
> >> Regards,
> >> Jeroen
> >>
> >> DOLLY, MARTIN C, ATTLABS wrote:
> >>> Jeroen,
> >>>
> >>> It does apply to a concatenation of managed networks, lets say=20
> >>> UE-AT&T-Verizon-UE...Oh, this is the same concatenation for
> >> what you
> >>> are referring to as the "internet"..right? Only difference is a=20
> >>> different portion of our IP backbones.
> >>>
> >>> More important here (please just don't cut/paste the=20
> above without=20
> >>> this), for wireless access the user's priority level may
> >> change based
> >>> on call processing, including authentication, and this=20
> needs to be=20
> >>> relayed back to the wireless access.
> >>>
> >>> Cheers,
> >>>
> >>> Martin
> >>>
> >>> -----Original Message-----
> >>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
> >>> Sent: Wednesday, November 21, 2007 4:14 PM
> >>> To: Sandesara, Niranjan B
> >>> Cc: sip@ietf.org
> >>> Subject: Re: [Sip] Need for RPH in SIP Responses
> >>>
> >>> Niranjan,
> >>>
> >>>  =20
> >>>> As has been pointed out earlier, possible security risk of
> >> permitting
> >>>> RPH in SIP responses is minimal in managed IP networks=20
> where this=20
> >>>> capability is generally expected to be used.
> >>>>
> >>>>    =20
> >>> For this argument to apply, the element sending the RPH=20
> header in a=20
> >>> response and the element acting on it should both be in the
> >> same domain.
> >>> In other words you are talking about a closed system, a
> >> very specific
> >>> environment. The use of this header in this way then
> >> clearly does not
> >>> apply to the Internet; the proper way to standardize this is as a=20
> >>> P-header (instead of taking a header which is already=20
> defined in a=20
> >>> "approved-for-the-Internet" RFC, and modifying its allowed use to=20
> >>> accommodate for a non-Internet use)
> >>>
> >>> Regards,
> >>> Jeroen
> >>>
> >>>
> >>> _______________________________________________
> >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the core SIP Protocol Use=20
> >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >>> sipping@ietf.org for new developments on the application of sip
> >>>
> >>>  =20
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use=20
> >> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >> sipping@ietf.org for new developments on the application of sip
> >>
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 11:57:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvFMR-0004l2-F4; Thu, 22 Nov 2007 11:57:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvFMP-0004kO-8B
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 11:57:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFMO-0004k9-T5
	for sip@ietf.org; Thu, 22 Nov 2007 11:57:04 -0500
Received: from poster.unibo.it ([137.204.24.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFMO-0005Mt-71
	for sip@ietf.org; Thu, 22 Nov 2007 11:57:04 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by poster.unibo.it (Postfix) with ESMTP id 52268452;
	Thu, 22 Nov 2007 17:57:03 +0100 (CET)
Received: from EXBK03 (unknown [137.204.25.211])
	by poster.unibo.it (Postfix) with ESMTP id E981F8B;
	Thu, 22 Nov 2007 17:56:52 +0100 (CET)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: R: [Sip] a question about IETF draft location conveyance 09
Date: Thu, 22 Nov 2007 17:56:52 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] a question about IETF draft location conveyance 09
Thread-Index: Acgsl9IvrmTIh6AAQ8CwTy/zYck4hgAjkBVB
References: <4742BDF5.9040302@unibo.it>
	
	
	
	
	
	
From: "daniel grotti" 
To: "Ted Hardie" , "James M. Polk" ,
	"IETF SIP List" 
X-Virus-Scanned: Cineca AppOs 1.00 at poster.unibo.it
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I believe that if a UA puts "recipient=3Drouting-entity" paramenter into =
locationValue, the location information should be read only by Proxy =
Server for location-based routing.=20
But if a UA wants its own location information to be known and seen by =
endusers, then UA have to insert the "recipient=3Dendpoints" paramenter. =
In this case Proxy server, from my view, should only forward the message =
to the destination. UA would just like to bring its own location to an =
endpoint, and    could not interested in location-based routing.

Does this make sense?

Regards,
Daniel




-----------------------------
       Daniel  Grotti
DEIS - Universita' di Bologna
-----------------------------
       Via Venezia, 52
  47023 Cesena (FC) - ITALY
-----------------------------
email:daniel.grotti@unibo.it
-----------------------------=20



-----Messaggio originale-----
Da: Ted Hardie [mailto:hardie@qualcomm.com]
Inviato: gio 11/22/2007 12:36
A: James M. Polk; daniel grotti; IETF SIP List
Oggetto: Re: [Sip] a question about IETF draft location conveyance 09
=20
At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>\
>Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains =
to the SIP WG's expertise in knowing and agreeing with SIP's ability to =
foresee the type of topology from UAC to UAS, and each server (whether =
there even is one) in between.  I'm not so sure the SIP WG agrees that a =
UAC can make this determination, and am soliciting their input here in a =
broad way.
>
>Can a UAC understand enough about the topology of the Internet to =
understand where it is sending a request, including how SIP servers may =
or may not act upon that request?
>
>I believe, if the answer is no, the the "recipient=3D" parameter is a =
flawed SIP header parameter.
>
>If the answer is yes, then it stays with no further arguments from me.


I think we have fundamentally different ideas of how much understanding =
of the
topology this implies.  My view is that the header as currently =
specified says
either "This is meant for the person answering the call/taking the =
session" or
"This is meant to help get the call through/get the session to the right =
responder".
Within the latter case, it requires no knowledge at all of topology; it =
does
not distinguish among the many different routing elements which might be
trying to make that happen.=20

A UA that does not care whether it is used for routing can enter "both"
and all is well.  A UA that *wants* it to be used this way can enter =
"routing-entity".
The availability of "endpoint" as a separate possibility makes sure that
an endpoint can indicate that use by the routing system is not intended. =

If the SIP community believes "routing-entity" is too vague
and needs to be broken out, I do not see how the GeoPRIV could object or
why it would want to; certainly this working group should have the final =
word
on that.  But collapsing things so that entering "endpoint" is
not an indicator to the routing entities that they should just pass =
things along
would find opposition (at the very least from me).  That would break a =
pretty
fundamental assumption that users are in control of the pidf-lo =
distributions.

Hope you have a great Thanksgiving,
				Ted



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 12:34:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvFvw-0006rT-L4; Thu, 22 Nov 2007 12:33:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvFvv-0006r9-AN
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 12:33:47 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFvt-0006qj-EG
	for sip@ietf.org; Thu, 22 Nov 2007 12:33:46 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFvs-0006oA-G8
	for sip@ietf.org; Thu, 22 Nov 2007 12:33:44 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAMHXauZ012298
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 22 Nov 2007 11:33:38 -0600
In-Reply-To: 
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
	<1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
	<65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <474234E7-F898-464A-BAA3-E27890D7909B@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Thu, 22 Nov 2007 11:33:28 -0600
To: Robert Sparks 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 22, 2007, at 2:25 AM, Robert Sparks wrote:

> I'm still not sure what you originally objected to. Just to be  
> point out that the UPDATE can come from either side, I'm copying  
> figure 1 from the UPDATE RFC here.
>
> Tell me what SDP you think is safe to put in message 9.

Either the SDP from message 2 (the answer that corresponds to the  
offer from INVITE), or nothing. No other SDP can go there.

> I _think_ you're saying it should be answer 1 from message 2. How  
> could that help anybody? The session described by offer1/answer1 is  
> long long gone.

It's not particularly useful, though it might have been had the  
UPDATE sequence not occurred. And for those UAs that neither  
implement answer-in-provisional nor UPDATE, it will at least result  
in a working call.

> If you repeat offer 3 from message 7, again - how could that help  
> anybody?

That would be a state mismatch, so don't do it.
>
> I'll accept that you don't like the whole idea of early dialogs and  
> early media. But that cat's so far out of the bag its forgotten  
> what the bag smells like.
> Given that this stuff is now _deployed_, what's the best answer to  
> my original question?
>

Either the final answer has to match the provisional answer, or it  
has to contain nothing. There are cases of not-quite-right UAs where  
either will cause disaster. It's a probability game.

> What Paul points out causes me to champion making a much clearer  
> MUST NOT put SDP in the 200-INVITE if you're using 100-rel.
>
> And my questions about how the repeat of either of those SDPs is  
> earnest, not rhetorical. I really don't see how its helping  
> something work.
> Can you diagram the scenario where not repeating the SDP you want  
> to repeat leads to abject failure?
>

It is not uncommon for older UAs to completely ignore SDP in a  
provisional response. I think both the SIP phones at my house do this  
(although one also doesn't do reliable provisional at all, but I'm  
not sure it rejects the 180 correctly).

if we skip the SDP in 4, Caller thinks he has never received an answer:


                 Caller                        Callee
                    |                             |
                    |                             |
                    |(1) INVITE with offer 1      |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |(2) 180 with answer 1        |
                    |<----------------------------|
         ans.       |                             |
         ignored    |                             |
                    |(3) PRACK                    |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |                             |
                    |(4) 200 INVITE with ans 1    |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(5) ACK                     |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |                             |
                    |                             |


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 12:34:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvFwC-00088V-KT; Thu, 22 Nov 2007 12:34:04 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvFwA-0007xc-Q3
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 12:34:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFwA-0007vT-Es
	for sip@ietf.org; Thu, 22 Nov 2007 12:34:02 -0500
Received: from qmta02.westchester.pa.mail.comcast.net ([76.96.62.24])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFw9-0006ou-Uy
	for sip@ietf.org; Thu, 22 Nov 2007 12:34:02 -0500
Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44])
	by QMTA02.westchester.pa.mail.comcast.net with comcast
	id FsKu1Y0020xGWP80507w00; Thu, 22 Nov 2007 17:34:01 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA12.westchester.pa.mail.comcast.net with comcast
	id Fta11Y0020umElk0300000; Thu, 22 Nov 2007 17:34:01 +0000
X-Authority-Analysis: v=1.0 c=1 a=ebSiwEMrWRMA:10 a=Ny5PqMoyXcTVEmQGyV4A:9
	a=jQasNBDSlm-vKYMbiLcA:7 a=4CE6UYoUobSx78v1mgx9NuuFyvcA:4
	a=k4qQewaewV0A:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAMHY0SV020607
	for ; Thu, 22 Nov 2007 12:34:00 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAMHY0Nq020603;
	Thu, 22 Nov 2007 12:34:00 -0500
Date: Thu, 22 Nov 2007 12:34:00 -0500
Message-Id: <200711221734.lAMHY0Nq020603@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
	(ernst.horvath@siemens.com)
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com><2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
	
	<5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Horvath, Ernst" 

   > >>* There were implementations that offered an m-line with codecs A, B, 
   > >>and C, got an answer with C, then got upset when they got RTP with A 
   > >>(which is quite legal).

   I am surprised that this caused any confusion. RFC 3264 seems pretty
   clear to me.

   Citing from section 6.1:
     "The answerer MUST send using a media format in the offer
      that is also listed in the answer, and SHOULD send using the most
      preferred media format in the offer that is also listed in the
   answer."

   and from section 7:
     "The offerer MAY immediately cease listening for media formats that
      were listed in the initial offer, but not present in the answer."

Perhaps the matter hinges on the meaning of "upset" in the original
post.  It's perfectly legal (per RFC 3264 cited above) for the
receiver to not render RTP using a codec not in the answer, but since
such packets may be lingering in the network, it must not fail or be
problematic if it receives such RTP.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 12:34:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvFvw-0006rT-L4; Thu, 22 Nov 2007 12:33:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvFvv-0006r9-AN
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 12:33:47 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFvt-0006qj-EG
	for sip@ietf.org; Thu, 22 Nov 2007 12:33:46 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFvs-0006oA-G8
	for sip@ietf.org; Thu, 22 Nov 2007 12:33:44 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAMHXauZ012298
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 22 Nov 2007 11:33:38 -0600
In-Reply-To: 
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
	<1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
	<65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <474234E7-F898-464A-BAA3-E27890D7909B@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Thu, 22 Nov 2007 11:33:28 -0600
To: Robert Sparks 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 22, 2007, at 2:25 AM, Robert Sparks wrote:

> I'm still not sure what you originally objected to. Just to be  
> point out that the UPDATE can come from either side, I'm copying  
> figure 1 from the UPDATE RFC here.
>
> Tell me what SDP you think is safe to put in message 9.

Either the SDP from message 2 (the answer that corresponds to the  
offer from INVITE), or nothing. No other SDP can go there.

> I _think_ you're saying it should be answer 1 from message 2. How  
> could that help anybody? The session described by offer1/answer1 is  
> long long gone.

It's not particularly useful, though it might have been had the  
UPDATE sequence not occurred. And for those UAs that neither  
implement answer-in-provisional nor UPDATE, it will at least result  
in a working call.

> If you repeat offer 3 from message 7, again - how could that help  
> anybody?

That would be a state mismatch, so don't do it.
>
> I'll accept that you don't like the whole idea of early dialogs and  
> early media. But that cat's so far out of the bag its forgotten  
> what the bag smells like.
> Given that this stuff is now _deployed_, what's the best answer to  
> my original question?
>

Either the final answer has to match the provisional answer, or it  
has to contain nothing. There are cases of not-quite-right UAs where  
either will cause disaster. It's a probability game.

> What Paul points out causes me to champion making a much clearer  
> MUST NOT put SDP in the 200-INVITE if you're using 100-rel.
>
> And my questions about how the repeat of either of those SDPs is  
> earnest, not rhetorical. I really don't see how its helping  
> something work.
> Can you diagram the scenario where not repeating the SDP you want  
> to repeat leads to abject failure?
>

It is not uncommon for older UAs to completely ignore SDP in a  
provisional response. I think both the SIP phones at my house do this  
(although one also doesn't do reliable provisional at all, but I'm  
not sure it rejects the 180 correctly).

if we skip the SDP in 4, Caller thinks he has never received an answer:


                 Caller                        Callee
                    |                             |
                    |                             |
                    |(1) INVITE with offer 1      |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |(2) 180 with answer 1        |
                    |<----------------------------|
         ans.       |                             |
         ignored    |                             |
                    |(3) PRACK                    |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |                             |
                    |(4) 200 INVITE with ans 1    |
                    |<----------------------------|
                    |                             |
                    |                             |
                    |(5) ACK                     |
                    |---------------------------->|
                    |                             |
                    |                             |
                    |                             |
                    |                             |


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 12:34:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvFwC-00088V-KT; Thu, 22 Nov 2007 12:34:04 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvFwA-0007xc-Q3
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 12:34:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFwA-0007vT-Es
	for sip@ietf.org; Thu, 22 Nov 2007 12:34:02 -0500
Received: from qmta02.westchester.pa.mail.comcast.net ([76.96.62.24])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFw9-0006ou-Uy
	for sip@ietf.org; Thu, 22 Nov 2007 12:34:02 -0500
Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44])
	by QMTA02.westchester.pa.mail.comcast.net with comcast
	id FsKu1Y0020xGWP80507w00; Thu, 22 Nov 2007 17:34:01 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA12.westchester.pa.mail.comcast.net with comcast
	id Fta11Y0020umElk0300000; Thu, 22 Nov 2007 17:34:01 +0000
X-Authority-Analysis: v=1.0 c=1 a=ebSiwEMrWRMA:10 a=Ny5PqMoyXcTVEmQGyV4A:9
	a=jQasNBDSlm-vKYMbiLcA:7 a=4CE6UYoUobSx78v1mgx9NuuFyvcA:4
	a=k4qQewaewV0A:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAMHY0SV020607
	for ; Thu, 22 Nov 2007 12:34:00 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAMHY0Nq020603;
	Thu, 22 Nov 2007 12:34:00 -0500
Date: Thu, 22 Nov 2007 12:34:00 -0500
Message-Id: <200711221734.lAMHY0Nq020603@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
	(ernst.horvath@siemens.com)
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com><2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
	
	<5AB8CA778E49D149B6EAEC3B864C7A8C015B23FF@atnets15pa.ww300.siemens.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Horvath, Ernst" 

   > >>* There were implementations that offered an m-line with codecs A, B, 
   > >>and C, got an answer with C, then got upset when they got RTP with A 
   > >>(which is quite legal).

   I am surprised that this caused any confusion. RFC 3264 seems pretty
   clear to me.

   Citing from section 6.1:
     "The answerer MUST send using a media format in the offer
      that is also listed in the answer, and SHOULD send using the most
      preferred media format in the offer that is also listed in the
   answer."

   and from section 7:
     "The offerer MAY immediately cease listening for media formats that
      were listed in the initial offer, but not present in the answer."

Perhaps the matter hinges on the meaning of "upset" in the original
post.  It's perfectly legal (per RFC 3264 cited above) for the
receiver to not render RTP using a codec not in the answer, but since
such packets may be lingering in the network, it must not fail or be
problematic if it receives such RTP.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 12:35:17 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvFxM-0003MM-Eo; Thu, 22 Nov 2007 12:35:16 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvFxK-00037O-Ey
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 12:35:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFxK-00033K-0R
	for sip@ietf.org; Thu, 22 Nov 2007 12:35:14 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvFxF-0008Ld-Pj
	for sip@ietf.org; Thu, 22 Nov 2007 12:35:13 -0500
Received: (qmail invoked by alias); 22 Nov 2007 17:35:08 -0000
Received: from p54987B3E.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.123.62]
	by mail.gmx.net (mp029) with SMTP; 22 Nov 2007 18:35:08 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19R7+oEGylR762pXrEygH/B/2DhjFEh+LwTO7HHcq
	i0X17JOwGAOYF3
Message-ID: <4745BDC7.30003@gmx.net>
Date: Thu, 22 Nov 2007 18:35:03 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: daniel grotti 
Subject: Re: R: [Sip] a question about IETF draft location conveyance 09
References: <4742BDF5.9040302@unibo.it>						
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: IETF SIP List , "James M. Polk" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi Daniel,

daniel grotti wrote:
> I believe that if a UA puts "recipient=routing-entity" paramenter into locationValue, the location information should be read only by Proxy Server for location-based routing. 
> But if a UA wants its own location information to be known and seen by endusers, then UA have to insert the "recipient=endpoints" paramenter. In this case Proxy server, from my view, should only forward the message to the destination. UA would just like to bring its own location to an endpoint, and    could not interested in location-based routing.
>
> Does this make sense?
>
>   

Correct and makes sense.

The recipient parameter is just a hint for processing. It does not have 
security properties.

Ciao
Hannes



> Regards,
> Daniel
>
>
>
>
> -----------------------------
>        Daniel  Grotti
> DEIS - Universita' di Bologna
> -----------------------------
>        Via Venezia, 52
>   47023 Cesena (FC) - ITALY
> -----------------------------
> email:daniel.grotti@unibo.it
> ----------------------------- 
>
>
>
> -----Messaggio originale-----
> Da: Ted Hardie [mailto:hardie@qualcomm.com]
> Inviato: gio 11/22/2007 12:36
> A: James M. Polk; daniel grotti; IETF SIP List
> Oggetto: Re: [Sip] a question about IETF draft location conveyance 09
>  
> At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>   
>> \
>> Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains to the SIP WG's expertise in knowing and agreeing with SIP's ability to foresee the type of topology from UAC to UAS, and each server (whether there even is one) in between.  I'm not so sure the SIP WG agrees that a UAC can make this determination, and am soliciting their input here in a broad way.
>>
>> Can a UAC understand enough about the topology of the Internet to understand where it is sending a request, including how SIP servers may or may not act upon that request?
>>
>> I believe, if the answer is no, the the "recipient=" parameter is a flawed SIP header parameter.
>>
>> If the answer is yes, then it stays with no further arguments from me.
>>     
>
>
> I think we have fundamentally different ideas of how much understanding of the
> topology this implies.  My view is that the header as currently specified says
> either "This is meant for the person answering the call/taking the session" or
> "This is meant to help get the call through/get the session to the right responder".
> Within the latter case, it requires no knowledge at all of topology; it does
> not distinguish among the many different routing elements which might be
> trying to make that happen. 
>
> A UA that does not care whether it is used for routing can enter "both"
> and all is well.  A UA that *wants* it to be used this way can enter "routing-entity".
> The availability of "endpoint" as a separate possibility makes sure that
> an endpoint can indicate that use by the routing system is not intended. 
> If the SIP community believes "routing-entity" is too vague
> and needs to be broken out, I do not see how the GeoPRIV could object or
> why it would want to; certainly this working group should have the final word
> on that.  But collapsing things so that entering "endpoint" is
> not an indicator to the routing entities that they should just pass things along
> would find opposition (at the very least from me).  That would break a pretty
> fundamental assumption that users are in control of the pidf-lo distributions.
>
> Hope you have a great Thanksgiving,
> 				Ted
>
>
>
> _______________________________________________
> 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
>   



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 12:42:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvG45-00051d-Jv; Thu, 22 Nov 2007 12:42:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvG44-00051W-A2
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 12:42:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvG44-00051N-0Y
	for sip@ietf.org; Thu, 22 Nov 2007 12:42:12 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvG40-00007b-2G
	for sip@ietf.org; Thu, 22 Nov 2007 12:42:11 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAMHfxRH012404
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 22 Nov 2007 11:42:01 -0600
In-Reply-To: 
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com>
	<2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <67A74E87-B494-445B-9D11-B998B269EF81@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
Date: Thu, 22 Nov 2007 11:41:51 -0600
To: "Christer Holmberg" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 22, 2007, at 4:33 AM, Christer Holmberg wrote:

>
> Hi,
>
> I agree with Ravi.
>
> Eventhough you in theory is supposed to be able to receive what you
> offer - no matter what you get in the answer - I think that in real  
> life
> the only codecs that participants will be prepared to send/receive are
> the ones sent both in the offer and the answer. That is also the  
> reason
> why the answer normally doesn't contain additional codecs - it mostly
> contains a subset of the codecs in the offer.

So how do you deal with asymmetric encoding?

--
Dean 


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 13:19:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvGdo-0007c9-H1; Thu, 22 Nov 2007 13:19:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvGdn-0007c2-3O
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 13:19:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGdm-0007bu-O3
	for sip@ietf.org; Thu, 22 Nov 2007 13:19:06 -0500
Received: from poster.unibo.it ([137.204.24.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvGdl-0008K4-Uy
	for sip@ietf.org; Thu, 22 Nov 2007 13:19:06 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by poster.unibo.it (Postfix) with ESMTP id 41FFD734;
	Thu, 22 Nov 2007 19:19:05 +0100 (CET)
Received: from EXBK03 (unknown [137.204.25.211])
	by poster.unibo.it (Postfix) with ESMTP id 3B1A37E4;
	Thu, 22 Nov 2007 19:09:28 +0100 (CET)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: R: R: [Sip] a question about IETF draft location conveyance 09
Date: Thu, 22 Nov 2007 19:08:23 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: [Sip] a question about IETF draft location conveyance 09
Thread-Index: AcgtMPo3UgmFWbLfSR2keAQUHXkr6AAAbG0y
References: <4742BDF5.9040302@unibo.it>						
	
	<4745BDC7.30003@gmx.net>
From: "daniel grotti" 
To: "Hannes Tschofenig" 
X-Virus-Scanned: Cineca AppOs 1.00 at poster.unibo.it
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: IETF SIP List , "James M. Polk" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi all,
so why don't emphasize this point in the next draft, saying : "Proxy =
server MUST not read messages with "recipient=3Dendpoint" paramenter =
setted".
This is my point of you.

What do you think? James?

Regards,
Daniel

----------------------------------
       Daniel  Grotti
D.E.I.S. - University of Bologna
----------------------------------
       Via Venezia, 52
  47023 Cesena (FC) - ITALY
----------------------------------
e-mail: daniel.grotti@unibo.it
----------------------------------=20



-----Messaggio originale-----
Da: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Inviato: gio 22/11/2007 18.35
A: daniel grotti
Cc: Ted Hardie; James M. Polk; IETF SIP List
Oggetto: Re: R: [Sip] a question about IETF draft location conveyance 09
=20
Hi Daniel,

daniel grotti wrote:
> I believe that if a UA puts "recipient=3Drouting-entity" paramenter =
into locationValue, the location information should be read only by =
Proxy Server for location-based routing.=20
> But if a UA wants its own location information to be known and seen by =
endusers, then UA have to insert the "recipient=3Dendpoints" paramenter. =
In this case Proxy server, from my view, should only forward the message =
to the destination. UA would just like to bring its own location to an =
endpoint, and    could not interested in location-based routing.
>
> Does this make sense?
>
>  =20

Correct and makes sense.

The recipient parameter is just a hint for processing. It does not have=20
security properties.

Ciao
Hannes



> Regards,
> Daniel
>
>
>
>
> -----------------------------
>        Daniel  Grotti
> DEIS - Universita' di Bologna
> -----------------------------
>        Via Venezia, 52
>   47023 Cesena (FC) - ITALY
> -----------------------------
> email:daniel.grotti@unibo.it
> -----------------------------=20
>
>
>
> -----Messaggio originale-----
> Da: Ted Hardie [mailto:hardie@qualcomm.com]
> Inviato: gio 11/22/2007 12:36
> A: James M. Polk; daniel grotti; IETF SIP List
> Oggetto: Re: [Sip] a question about IETF draft location conveyance 09
> =20
> At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>  =20
>> \
>> Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains =
to the SIP WG's expertise in knowing and agreeing with SIP's ability to =
foresee the type of topology from UAC to UAS, and each server (whether =
there even is one) in between.  I'm not so sure the SIP WG agrees that a =
UAC can make this determination, and am soliciting their input here in a =
broad way.
>>
>> Can a UAC understand enough about the topology of the Internet to =
understand where it is sending a request, including how SIP servers may =
or may not act upon that request?
>>
>> I believe, if the answer is no, the the "recipient=3D" parameter is a =
flawed SIP header parameter.
>>
>> If the answer is yes, then it stays with no further arguments from =
me.
>>    =20
>
>
> I think we have fundamentally different ideas of how much =
understanding of the
> topology this implies.  My view is that the header as currently =
specified says
> either "This is meant for the person answering the call/taking the =
session" or
> "This is meant to help get the call through/get the session to the =
right responder".
> Within the latter case, it requires no knowledge at all of topology; =
it does
> not distinguish among the many different routing elements which might =
be
> trying to make that happen.=20
>
> A UA that does not care whether it is used for routing can enter =
"both"
> and all is well.  A UA that *wants* it to be used this way can enter =
"routing-entity".
> The availability of "endpoint" as a separate possibility makes sure =
that
> an endpoint can indicate that use by the routing system is not =
intended.=20
> If the SIP community believes "routing-entity" is too vague
> and needs to be broken out, I do not see how the GeoPRIV could object =
or
> why it would want to; certainly this working group should have the =
final word
> on that.  But collapsing things so that entering "endpoint" is
> not an indicator to the routing entities that they should just pass =
things along
> would find opposition (at the very least from me).  That would break a =
pretty
> fundamental assumption that users are in control of the pidf-lo =
distributions.
>
> Hope you have a great Thanksgiving,
> 				Ted
>
>
>
> _______________________________________________
> 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
>  =20




_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 13:31:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvGq2-0006Ni-Mz; Thu, 22 Nov 2007 13:31:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvGq1-0006Nc-Bw
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 13:31:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGq1-0006NT-26
	for sip@ietf.org; Thu, 22 Nov 2007 13:31:45 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvGpy-0001jH-CI
	for sip@ietf.org; Thu, 22 Nov 2007 13:31:45 -0500
Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net
	[96.226.64.76]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAMIValm088879
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 22 Nov 2007 12:31:36 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <474234E7-F898-464A-BAA3-E27890D7909B@softarmor.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
	<1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
	<65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
	
	<474234E7-F898-464A-BAA3-E27890D7909B@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2AF2438D-78D2-4CA4-81AA-11303276ADE4@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Thu, 22 Nov 2007 12:31:37 -0600
To: Dean Willis 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4883/Thu Nov 22 03:20:36 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I disbelieve that there are any UAs that claim support for 100rel and  
don't pay attention to the answer in the 180.
Please show me one (send me traces please).

Are you mixing the non-reliable 18x case in here? (I think that might  
be where you're coming from since you say "older" UAs).'
That's not what we're discussing. Repeating the answer in the 200  
here makes sense.

And what do you mean "rejects the 180"? That makes no sense.

Do you have a UAS that's tries to send 100rel responses when the UA  
hasn't indicated support?

RjS

On Nov 22, 2007, at 11:33 AM, Dean Willis wrote:

>
> On Nov 22, 2007, at 2:25 AM, Robert Sparks wrote:
>
>> I'm still not sure what you originally objected to. Just to be  
>> point out that the UPDATE can come from either side, I'm copying  
>> figure 1 from the UPDATE RFC here.
>>
>> Tell me what SDP you think is safe to put in message 9.
>
> Either the SDP from message 2 (the answer that corresponds to the  
> offer from INVITE), or nothing. No other SDP can go there.
>
>> I _think_ you're saying it should be answer 1 from message 2. How  
>> could that help anybody? The session described by offer1/answer1  
>> is long long gone.
>
> It's not particularly useful, though it might have been had the  
> UPDATE sequence not occurred. And for those UAs that neither  
> implement answer-in-provisional nor UPDATE, it will at least result  
> in a working call.
>
>> If you repeat offer 3 from message 7, again - how could that help  
>> anybody?
>
> That would be a state mismatch, so don't do it.
>>
>> I'll accept that you don't like the whole idea of early dialogs  
>> and early media. But that cat's so far out of the bag its  
>> forgotten what the bag smells like.
>> Given that this stuff is now _deployed_, what's the best answer to  
>> my original question?
>>
>
> Either the final answer has to match the provisional answer, or it  
> has to contain nothing. There are cases of not-quite-right UAs  
> where either will cause disaster. It's a probability game.
>
>> What Paul points out causes me to champion making a much clearer  
>> MUST NOT put SDP in the 200-INVITE if you're using 100-rel.
>>
>> And my questions about how the repeat of either of those SDPs is  
>> earnest, not rhetorical. I really don't see how its helping  
>> something work.
>> Can you diagram the scenario where not repeating the SDP you want  
>> to repeat leads to abject failure?
>>
>
> It is not uncommon for older UAs to completely ignore SDP in a  
> provisional response. I think both the SIP phones at my house do  
> this (although one also doesn't do reliable provisional at all, but  
> I'm not sure it rejects the 180 correctly).
>
> if we skip the SDP in 4, Caller thinks he has never received an  
> answer:
>
>
>                 Caller                        Callee
>                    |                             |
>                    |                             |
>                    |(1) INVITE with offer 1      |
>                    |---------------------------->|
>                    |                             |
>                    |                             |
>                    |(2) 180 with answer 1        |
>                    |<----------------------------|
>         ans.       |                             |
>         ignored    |                             |
>                    |(3) PRACK                    |
>                    |---------------------------->|
>                    |                             |
>                    |                             |
>                    |                             |
>                    |(4) 200 INVITE with ans 1    |
>                    |<----------------------------|
>                    |                             |
>                    |                             |
>                    |(5) ACK                     |
>                    |---------------------------->|
>                    |                             |
>                    |                             |
>                    |                             |
>                    |                             |



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 14:28:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvHiY-00072S-Bm; Thu, 22 Nov 2007 14:28:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvHiX-000729-3i
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 14:28:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvHiW-00070t-Pv
	for sip@ietf.org; Thu, 22 Nov 2007 14:28:04 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvHiS-0003mC-Ej
	for sip@ietf.org; Thu, 22 Nov 2007 14:28:04 -0500
Received: (qmail invoked by alias); 22 Nov 2007 19:27:58 -0000
Received: from p54987B3E.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.123.62]
	by mail.gmx.net (mp024) with SMTP; 22 Nov 2007 20:27:58 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX195TEtptZN57GWL7BMi19n35RfLjevBe62CMk/++W
	uaHK9QG0mxb9t3
Message-ID: <4745D839.4000902@gmx.net>
Date: Thu, 22 Nov 2007 20:27:53 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: daniel grotti 
Subject: Re: R: R: [Sip] a question about IETF draft location conveyance 09
References: <4742BDF5.9040302@unibo.it>						
	
	<4745BDC7.30003@gmx.net>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: IETF SIP List , "James M. Polk" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

RFC 2119 language aims to accomplish interoperability.
The MUST NOT in that sentence does not accomplish interoperability.
It does not do harm for the proxy to still read it.

I would be fine with a sentence that indicates that it is not useful for 
the proxy to read the location information if the recipient parameter is 
set to "endpoint".

Ciao
Hannes


daniel grotti wrote:
> Hi all,
> so why don't emphasize this point in the next draft, saying : "Proxy server MUST not read messages with "recipient=endpoint" paramenter setted".
> This is my point of you.
>
> What do you think? James?
>
> Regards,
> Daniel
>
> ----------------------------------
>        Daniel  Grotti
> D.E.I.S. - University of Bologna
> ----------------------------------
>        Via Venezia, 52
>   47023 Cesena (FC) - ITALY
> ----------------------------------
> e-mail: daniel.grotti@unibo.it
> ---------------------------------- 
>
>
>
> -----Messaggio originale-----
> Da: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Inviato: gio 22/11/2007 18.35
> A: daniel grotti
> Cc: Ted Hardie; James M. Polk; IETF SIP List
> Oggetto: Re: R: [Sip] a question about IETF draft location conveyance 09
>  
> Hi Daniel,
>
> daniel grotti wrote:
>   
>> I believe that if a UA puts "recipient=routing-entity" paramenter into locationValue, the location information should be read only by Proxy Server for location-based routing. 
>> But if a UA wants its own location information to be known and seen by endusers, then UA have to insert the "recipient=endpoints" paramenter. In this case Proxy server, from my view, should only forward the message to the destination. UA would just like to bring its own location to an endpoint, and    could not interested in location-based routing.
>>
>> Does this make sense?
>>
>>   
>>     
>
> Correct and makes sense.
>
> The recipient parameter is just a hint for processing. It does not have 
> security properties.
>
> Ciao
> Hannes
>
>
>
>   
>> Regards,
>> Daniel
>>
>>
>>
>>
>> -----------------------------
>>        Daniel  Grotti
>> DEIS - Universita' di Bologna
>> -----------------------------
>>        Via Venezia, 52
>>   47023 Cesena (FC) - ITALY
>> -----------------------------
>> email:daniel.grotti@unibo.it
>> ----------------------------- 
>>
>>
>>
>> -----Messaggio originale-----
>> Da: Ted Hardie [mailto:hardie@qualcomm.com]
>> Inviato: gio 11/22/2007 12:36
>> A: James M. Polk; daniel grotti; IETF SIP List
>> Oggetto: Re: [Sip] a question about IETF draft location conveyance 09
>>  
>> At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>>   
>>     
>>> \
>>> Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains to the SIP WG's expertise in knowing and agreeing with SIP's ability to foresee the type of topology from UAC to UAS, and each server (whether there even is one) in between.  I'm not so sure the SIP WG agrees that a UAC can make this determination, and am soliciting their input here in a broad way.
>>>
>>> Can a UAC understand enough about the topology of the Internet to understand where it is sending a request, including how SIP servers may or may not act upon that request?
>>>
>>> I believe, if the answer is no, the the "recipient=" parameter is a flawed SIP header parameter.
>>>
>>> If the answer is yes, then it stays with no further arguments from me.
>>>     
>>>       
>> I think we have fundamentally different ideas of how much understanding of the
>> topology this implies.  My view is that the header as currently specified says
>> either "This is meant for the person answering the call/taking the session" or
>> "This is meant to help get the call through/get the session to the right responder".
>> Within the latter case, it requires no knowledge at all of topology; it does
>> not distinguish among the many different routing elements which might be
>> trying to make that happen. 
>>
>> A UA that does not care whether it is used for routing can enter "both"
>> and all is well.  A UA that *wants* it to be used this way can enter "routing-entity".
>> The availability of "endpoint" as a separate possibility makes sure that
>> an endpoint can indicate that use by the routing system is not intended. 
>> If the SIP community believes "routing-entity" is too vague
>> and needs to be broken out, I do not see how the GeoPRIV could object or
>> why it would want to; certainly this working group should have the final word
>> on that.  But collapsing things so that entering "endpoint" is
>> not an indicator to the routing entities that they should just pass things along
>> would find opposition (at the very least from me).  That would break a pretty
>> fundamental assumption that users are in control of the pidf-lo distributions.
>>
>> Hope you have a great Thanksgiving,
>> 				Ted
>>
>>
>>
>> _______________________________________________
>> 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
>>   
>>     
>
>   



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 14:48:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvI2J-00024Z-O4; Thu, 22 Nov 2007 14:48:31 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvI2I-0001vj-D2
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 14:48:30 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvI2H-0001sP-Us
	for sip@ietf.org; Thu, 22 Nov 2007 14:48:30 -0500
Received: from poster3.unibo.it ([137.204.24.100])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvI2H-0003H0-07
	for sip@ietf.org; Thu, 22 Nov 2007 14:48:29 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by poster3.unibo.it (Postfix) with ESMTP id 41DB4373;
	Thu, 22 Nov 2007 20:48:28 +0100 (CET)
Received: from EXBK03 (unknown [137.204.25.211])
	by poster3.unibo.it (Postfix) with ESMTP id B0683377;
	Thu, 22 Nov 2007 20:48:14 +0100 (CET)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: R: R: R: [Sip] a question about IETF draft location conveyance 09
Date: Thu, 22 Nov 2007 20:46:13 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: R: [Sip] a question about IETF draft location conveyance 09
Thread-Index: AcgtP4KpPKJ+zr4QRrmHK7TRQfJonwAANQpv
References: <4742BDF5.9040302@unibo.it>						
	
	<4745BDC7.30003@gmx.net>
	
	<4745D839.4000902@gmx.net>
From: "daniel grotti" 
To: "Hannes Tschofenig" 
X-Virus-Scanned: Cineca AppOs 1.00 at poster3.unibo.it
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7
Cc: IETF SIP List , "James M. Polk" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

yes, right. :)

Ciao
daniel


-----Messaggio originale-----
Da: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Inviato: gio 22/11/2007 20.27
A: daniel grotti
Cc: Ted Hardie; James M. Polk; IETF SIP List
Oggetto: Re: R: R: [Sip] a question about IETF draft location conveyance =
09
=20
RFC 2119 language aims to accomplish interoperability.
The MUST NOT in that sentence does not accomplish interoperability.
It does not do harm for the proxy to still read it.

I would be fine with a sentence that indicates that it is not useful for =

the proxy to read the location information if the recipient parameter is =

set to "endpoint".

Ciao
Hannes


daniel grotti wrote:
> Hi all,
> so why don't emphasize this point in the next draft, saying : "Proxy =
server MUST not read messages with "recipient=3Dendpoint" paramenter =
setted".
> This is my point of you.
>
> What do you think? James?
>
> Regards,
> Daniel
>
> ----------------------------------
>        Daniel  Grotti
> D.E.I.S. - University of Bologna
> ----------------------------------
>        Via Venezia, 52
>   47023 Cesena (FC) - ITALY
> ----------------------------------
> e-mail: daniel.grotti@unibo.it
> ----------------------------------=20
>
>
>
> -----Messaggio originale-----
> Da: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Inviato: gio 22/11/2007 18.35
> A: daniel grotti
> Cc: Ted Hardie; James M. Polk; IETF SIP List
> Oggetto: Re: R: [Sip] a question about IETF draft location conveyance =
09
> =20
> Hi Daniel,
>
> daniel grotti wrote:
>  =20
>> I believe that if a UA puts "recipient=3Drouting-entity" paramenter =
into locationValue, the location information should be read only by =
Proxy Server for location-based routing.=20
>> But if a UA wants its own location information to be known and seen =
by endusers, then UA have to insert the "recipient=3Dendpoints" =
paramenter. In this case Proxy server, from my view, should only forward =
the message to the destination. UA would just like to bring its own =
location to an endpoint, and    could not interested in location-based =
routing.
>>
>> Does this make sense?
>>
>>  =20
>>    =20
>
> Correct and makes sense.
>
> The recipient parameter is just a hint for processing. It does not =
have=20
> security properties.
>
> Ciao
> Hannes
>
>
>
>  =20
>> Regards,
>> Daniel
>>
>>
>>
>>
>> -----------------------------
>>        Daniel  Grotti
>> DEIS - Universita' di Bologna
>> -----------------------------
>>        Via Venezia, 52
>>   47023 Cesena (FC) - ITALY
>> -----------------------------
>> email:daniel.grotti@unibo.it
>> -----------------------------=20
>>
>>
>>
>> -----Messaggio originale-----
>> Da: Ted Hardie [mailto:hardie@qualcomm.com]
>> Inviato: gio 11/22/2007 12:36
>> A: James M. Polk; daniel grotti; IETF SIP List
>> Oggetto: Re: [Sip] a question about IETF draft location conveyance 09
>> =20
>> At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>>  =20
>>    =20
>>> \
>>> Ted -- This header parameter is for a PIDF-LO, yes -- but it =
pertains to the SIP WG's expertise in knowing and agreeing with SIP's =
ability to foresee the type of topology from UAC to UAS, and each server =
(whether there even is one) in between.  I'm not so sure the SIP WG =
agrees that a UAC can make this determination, and am soliciting their =
input here in a broad way.
>>>
>>> Can a UAC understand enough about the topology of the Internet to =
understand where it is sending a request, including how SIP servers may =
or may not act upon that request?
>>>
>>> I believe, if the answer is no, the the "recipient=3D" parameter is =
a flawed SIP header parameter.
>>>
>>> If the answer is yes, then it stays with no further arguments from =
me.
>>>    =20
>>>      =20
>> I think we have fundamentally different ideas of how much =
understanding of the
>> topology this implies.  My view is that the header as currently =
specified says
>> either "This is meant for the person answering the call/taking the =
session" or
>> "This is meant to help get the call through/get the session to the =
right responder".
>> Within the latter case, it requires no knowledge at all of topology; =
it does
>> not distinguish among the many different routing elements which might =
be
>> trying to make that happen.=20
>>
>> A UA that does not care whether it is used for routing can enter =
"both"
>> and all is well.  A UA that *wants* it to be used this way can enter =
"routing-entity".
>> The availability of "endpoint" as a separate possibility makes sure =
that
>> an endpoint can indicate that use by the routing system is not =
intended.=20
>> If the SIP community believes "routing-entity" is too vague
>> and needs to be broken out, I do not see how the GeoPRIV could object =
or
>> why it would want to; certainly this working group should have the =
final word
>> on that.  But collapsing things so that entering "endpoint" is
>> not an indicator to the routing entities that they should just pass =
things along
>> would find opposition (at the very least from me).  That would break =
a pretty
>> fundamental assumption that users are in control of the pidf-lo =
distributions.
>>
>> Hope you have a great Thanksgiving,
>> 				Ted
>>
>>
>>
>> _______________________________________________
>> 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
>>  =20
>>    =20
>
>  =20




_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 22 19:29:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvMPE-0000IM-PC; Thu, 22 Nov 2007 19:28:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvMPC-0008Ti-Jz
	for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 19:28:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvMPC-0008R6-5t
	for sip@ietf.org; Thu, 22 Nov 2007 19:28:26 -0500
Received: from mail145.messagelabs.com ([216.82.245.115])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvMPB-0004e9-JE
	for sip@ietf.org; Thu, 22 Nov 2007 19:28:26 -0500
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-10.tower-145.messagelabs.com!1195777704!16015002!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 24994 invoked from network); 23 Nov 2007 00:28:24 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88)
	by server-10.tower-145.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Nov 2007 00:28:24 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta102.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id
	lAN0SStl008405 for ; Thu, 22 Nov 2007 19:28:28 -0500
To: sip@ietf.org
Subject: Fw: [Sip] draft-gunn-sip-req-for-rph-in-responses-00: What is impact
	on response?
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn 
Message-ID: 
Date: Thu, 22 Nov 2007 19:28:20 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF180|March 29, 2007) at 11/22/2007 07:26:48 PM,
	Serialize complete at 11/22/2007 07:26:48 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1296902671=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============1296902671==
Content-Type: multipart/alternative;
	boundary="=_alternative 000295BB8525739C_="

This is a multipart message in MIME format.
--=_alternative 000295BB8525739C_=
Content-Type: text/plain; charset="US-ASCII"

Janet P Gunn/FED/CSC wrote on 11/22/2007 03:14:07 PM:

> I just want to point out that, for the use case presented in draft-
> gunn-sip-req-for-rph-in-responses-00, 
> the "priority status of the call target" is not relevant.  Priority 
> treatment is dependant
> entirely on the priority status of the calling party.
> 
> There might be other use case/scenarios which do depend on the 
> priority status of the call target- but not this one.
> 
> Janet

> 
> Dean Willis  wrote on 11/21/2007 03:14:24 PM:
> 
> > 
> > I'm still struggling with the rph-in-response question. I was hoping 
> > to get some insight from draft-gunn-sip-req-for-rph-in-responses-00, 
> > but I'm still left unclear on a few points.
> > 
> > For the record, this draft adds supporting rationale for draft-polk- 
> > sip-rph-in-responses-00.txt.
> > 
> > I understand from this draft that a node making a call that would 
> > need RPH information might not know what RPH value would apply at the 
> > time the call is launched by sending INVITE. This is because the 
> > priority granted will depend on external factors, including 
> > potentially the priority status of the call target. So we need a way 
> > to inform the network elements along the path (including the UAC) as 
> > to what priority they should grant the call.
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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

--=_alternative 000295BB8525739C_=
Content-Type: text/html; charset="US-ASCII"







Janet P Gunn/FED/CSC wrote on 11/22/2007 03:14:07
PM:



> I just want to point out that, for the use case presented in draft-

> gunn-sip-req-for-rph-in-responses-00,  

> the "priority status of the call target"
is not relevant.  Priority 

> treatment is dependant

> entirely on the priority status of the calling
party.

> 

> There might be other use case/scenarios which do depend on the 

> priority status of the call target- but not this one.

> 

> Janet



> 

> Dean Willis <dean.willis@softarmor.com> wrote on 11/21/2007
03:14:24 PM:

> 

> > 

> > I'm still struggling with the rph-in-response question. I was
hoping  

> > to get some insight from draft-gunn-sip-req-for-rph-in-responses-00,
 

> > but I'm still left unclear on a few points.

> > 

> > For the record, this draft adds supporting rationale for draft-polk-


> > sip-rph-in-responses-00.txt.

> > 

> > I understand from this draft that a node making a call that would
 

> > need RPH information might not know what RPH value would apply
at the  

> > time the call is launched by sending INVITE. This is because
the  

> > priority granted will depend on external factors, including  

> > potentially the priority status of the call target. So we need
a way  

> > to inform the network elements along the path (including the
UAC) as  

> > to what priority they should grant the call.

> > 

> > 

> > 

> > 

> > 

> > 

> > _______________________________________________

> > 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


--=_alternative 000295BB8525739C_=--



--===============1296902671==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1296902671==--





From sip-bounces@ietf.org Fri Nov 23 05:50:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvW6j-0001t3-Fx; Fri, 23 Nov 2007 05:50:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvW6h-0001sg-MF
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 05:49:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvW6h-0001ru-BH
	for sip@ietf.org; Fri, 23 Nov 2007 05:49:59 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvW6d-000406-VA
	for sip@ietf.org; Fri, 23 Nov 2007 05:49:59 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	A2D68207AC; Fri, 23 Nov 2007 11:49:53 +0100 (CET)
X-AuditID: c1b4fb3e-aee9fbb00000459d-fb-4746b051a24a
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	81C96201DD; Fri, 23 Nov 2007 11:49:53 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 11:49:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Fri, 23 Nov 2007 11:48:19 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: AcgtLwEk/s+lzhobQfu/gKC4j30tTAAj1rye
References: <82FF9D7A-F7B4-4C06-A0CB-5CA74504413E@nostrum.com>
	<2C7074A1A040E54DA31B3E72C052FD520938C6DC@BLR-EC-MBX04.wipro.com>
	
	<67A74E87-B494-445B-9D11-B998B269EF81@softarmor.com>
From: "Christer Holmberg" 
To: "Dean Willis" 
X-OriginalArrivalTime: 23 Nov 2007 10:49:53.0290 (UTC)
	FILETIME=[942A5EA0:01C82DBE]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,

>> I agree with Ravi.
>>
>> Eventhough you in theory is supposed to be able to receive what you
>> offer - no matter what you get in the answer - I think that in real=20
>> life the only codecs that participants will be prepared to =
send/receive are
>> the ones sent both in the offer and the answer. That is also the=20
>> reason
>> why the answer normally doesn't contain additional codecs - it mostly
>> contains a subset of the codecs in the offer.
>So how do you deal with asymmetric encoding?

You may use different codecs in each direction (eventhough I don't think =
it happens very often), as long as all codecs have been present in both =
the offer and the answer.

Regards,

Christer

=20



_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 05:54:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvWAg-0000I5-Si; Fri, 23 Nov 2007 05:54:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvWAf-0000Hn-E2
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 05:54:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvWAf-0000He-3U
	for sip@ietf.org; Fri, 23 Nov 2007 05:54:05 -0500
Received: from fw.polycom.co.il ([212.179.41.2]
	helo=isrexch01.israel.polycom.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvWAe-0004uQ-AT
	for sip@ietf.org; Fri, 23 Nov 2007 05:54:04 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Fri, 23 Nov 2007 12:55:53 +0200
Message-ID: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: AcgtLwEk/s+lzhobQfu/gKC4j30tTAAj1ryeAAA1xkA=
From: "Even, Roni" 
To: "Christer Holmberg" ,
	"Dean Willis" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,
The offerer need to be able to receive any codec that he declared in the =
offer regardless of answer.
The offerer may send a re-invite after the answer to fix the set of =
codecs to a smaller set.
Roni Even=20

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Friday, November 23, 2007 12:48 PM
> To: Dean Willis
> Cc: sip@ietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
>=20
> Hi,
>=20
> >> I agree with Ravi.
> >>
> >> Eventhough you in theory is supposed to be able to receive what you
> >> offer - no matter what you get in the answer - I think that in real
> >> life the only codecs that participants will be prepared to =
send/receive
> are
> >> the ones sent both in the offer and the answer. That is also the
> >> reason
> >> why the answer normally doesn't contain additional codecs - it =
mostly
> >> contains a subset of the codecs in the offer.
> >So how do you deal with asymmetric encoding?
>=20
> You may use different codecs in each direction (eventhough I don't =
think
> it happens very often), as long as all codecs have been present in =
both
> the offer and the answer.
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 06:17:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvWXj-0002Zp-Oa; Fri, 23 Nov 2007 06:17:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvWXh-0002NE-PI
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 06:17:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvWXh-0002Lp-FK
	for sip@ietf.org; Fri, 23 Nov 2007 06:17:53 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvWXd-0004mW-P5
	for sip@ietf.org; Fri, 23 Nov 2007 06:17:53 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	8EDA521211; Fri, 23 Nov 2007 12:16:39 +0100 (CET)
X-AuditID: c1b4fb3e-aee9fbb00000459d-a3-4746b6970491
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	7A97F20261; Fri, 23 Nov 2007 12:16:39 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 12:16:39 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
Date: Fri, 23 Nov 2007 12:12:47 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21 : Topics that attendees argued about
Thread-Index: AcgtLwEk/s+lzhobQfu/gKC4j30tTAAj1ryeAAA1xkAAAKT1kQ==
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>
From: "Christer Holmberg" 
To: "Even, Roni" ,
	"Dean Willis" 
X-OriginalArrivalTime: 23 Nov 2007 11:16:39.0405 (UTC)
	FILETIME=[517C11D0:01C82DC2]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi,

>The offerer need to be able to receive any codec that he declared in =
the offer regardless of answer.

Before or after he has received the answer?

BEFORE he has received the answer he may accept anything that was in the =
offer (eventhough in many cases he will not accept - or even receive =
(due to gates etc) - anything until he has received the answer).

AFTER he has received the answer he may accept only what both parties =
have indicated support for.


>The offerer may send a re-invite after the answer to fix the set of =
codecs to a smaller set.

That is normally done when both the offer and the answer have contained =
multiple codecs which both support.

But, if I offer you A, B and C, and you send back C, I am not =
necessarily going to send a re-INVITE to "remove" A and B - I may assume =
that we will only use C (based on the text from 3264 we've seen cited in =
this thread).

Regards,

Christer

=20

=20


Roni Even

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Friday, November 23, 2007 12:48 PM
> To: Dean Willis
> Cc: sip@ietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
>
> Hi,
>
> >> I agree with Ravi.
> >>
> >> Eventhough you in theory is supposed to be able to receive what you
> >> offer - no matter what you get in the answer - I think that in real
> >> life the only codecs that participants will be prepared to =
send/receive
> are
> >> the ones sent both in the offer and the answer. That is also the
> >> reason
> >> why the answer normally doesn't contain additional codecs - it =
mostly
> >> contains a subset of the codecs in the offer.
> >So how do you deal with asymmetric encoding?
>
> You may use different codecs in each direction (eventhough I don't =
think
> it happens very often), as long as all codecs have been present in =
both
> the offer and the answer.
>
> Regards,
>
> Christer
>
>
>
>
>
> _______________________________________________
> 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




_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 07:29:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvXeE-0008MC-SO; Fri, 23 Nov 2007 07:28:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvXeD-0008Ly-50
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 07:28:41 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXeC-0008Lp-Oy
	for sip@ietf.org; Fri, 23 Nov 2007 07:28:40 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvXeB-0007JF-Rd
	for sip@ietf.org; Fri, 23 Nov 2007 07:28:40 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lANCSWrb013957
	for ; Fri, 23 Nov 2007 06:28:39 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 06:28:34 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 13:28:33 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Nov 2007 13:28:32 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019747E9@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SIP WG status (document in progress by WG)
Thread-Index: AcgtzFyJ3ZBuEJI6TjyG2bweNmLInQ==
From: "DRAGE, Keith \(Keith\)" 
To: 
X-OriginalArrivalTime: 23 Nov 2007 12:28:33.0494 (UTC)
	FILETIME=[5CE1CF60:01C82DCC]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
Subject: [Sip] SIP WG status (document in progress by WG)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

(As SIP WG cochair)

An update on the current status of WG documents. This is the batch of
documents that the WG is still working on, and which you as a working
group should be putting resource in to progress.

I will be sending out mail on a couple of individual items on this. If
you have comments on any specific document, please feel free to start a
separate thread (the more the better - these are documents we are
working on).

Regards

Keith


Documents returned to the WG from IESG
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

draft-ietf-sip-e2m-sec-06 (Proposed standard)
Dean Willis is document shepherd=20
IESG last call completed 14th May 2007. No last call comments. Problems
with proposed standard status
Current status: Waiting for AD Go ahead

draft-ietf-sip-fork-loop-fix-05 (Proposed standard)
Keith Drage is document shepherd
IESG last call completed 14th May 2007.=20
Agreed at IETF#69 that will incorporate
draft-sparks-sipping-max-breadth-01
Current version at:
http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-06.txt
Current status: Waiting for AD Go ahead:: Revised ID needed

Documents in working group last call
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

draft-ietf-sip-connect-reuse-08
Candidate: Proposed standard
Milestone to IESG August 2007
WGLC began 26th October 2005. WGLC continuation announced 23rd October
2007 to complete 6th November 2007. Extended until 24th November 2007.
Has some dependency on:=20
draft-ietf-sip-domain-certs-00.txt
draft-ietf-sip-eku-00.txt
Keith Drage is PROTO document shepherd
Token currently with editor to update based on WGLC comments - then we
need to determine if it is ready for publish request

draft-ietf-sip-location-conveyance-09=20
Candidate: Proposed standard
Milestone for submission to IESG is July 2007
Review team assembled: Authors, WG chairs, Shida Schubert, Joszef Varga,
Henning Schulzrinne, Richard Barnes, Hannes Tschofenig
WGLC initiated 4th March 2007 to complete 2nd April 2007. WGLC also
issued in GEOPRIV WG
See
http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html
for current status of review. New version (-09) issued but still working
WGLC comments?
Keith Drage is PROTO document shepherd

draft-ietf-sip-outbound-11
Candidate: Proposed standard
Milestone for WGLC is March 2007
WGLC initiated 9th July 2007 to complete 6th August 2007
Milestone for sending to IESG is June 2007
Review team to supplement WGLC. Review team so far: Authors, WG chairs,
Jonathan Rosenberg, Fredrick Thulin, Kevin Johns, Christer Holmberg, AC
Mahendran, Alan Hawrylyshen, Byron Campen, Derek McDonald, EKR, Nils
Ohlmeier, Francois Audet
Dean Willis is PROTO document shepherd

draft-ietf-sip-subnot-etags-01
Agreed as WG item (subject to AD) at IETF#67
Candidate: proposed standard
September 2007 -- Extension for use of etags in conditional notification
to WGLC
WGLC initiated 4th September 2007 to complete 18th September 2007
Token: Waiting on resolution of WGLC comments from editor then expected
to be finished in WG
Dean Willis is PROTO document shepherd
December 2007 -- Extension for use in etags in conditional notification
to IESG (PS)

draft-ietf-sip-hitchhikers-guide-04
Candidate: Informational
Milestone for WGLC December 2007
WGLC announced 15th October 2007 to complete 29th October 2007
Keith Drage is PROTO document shepherd
Milestone for submission to IESG December 2007

draft-polk-sip-rph-new-namespaces-01
Candidate: Proposed standard
Milestone for WGLC September 2007
WGLC announced 31st October 2007 to complete 14th November 2007
Keith Drage is PROTO document shepherd
Milestone for submission to IESG October 2007
Waiting for editor to submit revision based on last call comments

Documents still in discussion in working group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

draft-ietf-sip-hop-limit-diagnostics-03=20
Candidate: Proposed standard
Milestone for WGLC is July 2007
Milestone for submission to IESG is November 2007
Scope of charter item is more general than hop limit diagnostics
Key issue is size of response when it has to traverse UDP transports.
Editor has procedures for reducing size of response body - does this
render the mechanism of limited use if this occurs
Issue has resulted in generation of:
draft-gurbani-sip-large-udp-response-00=20
draft-petithuguenin-sip-fragmentation-responses-02
Should document go forward as is?
Draft expired and removed from drafts directory - where next - WG polled

draft-ietf-sip-sec-flows-01
Candidate: Informational
Milestone for WGLC is July 2007
Milestone for submission to IESG is September 2007
To a certain extent dependent on resolution of ideas in (and therefore
waiting on them):
draft-ietf-sip-sips-02 =20
draft-gurbani-sip-domain-certs-04=20
Draft expired and removed from drafts directory=20

draft-ietf-sip-saml-03
Candidate: Proposed standard
Milestone for WGLC is September 2007
Milestone for submission to IESG is December 2007
Need milestone revision to post IETF#71

draft-ietf-sip-xcap-config-00
Candidate: proposed standard
Milestone for WGLC July 2007
Milestone for submission to IESG December 2007
Document transferred from SIPPING because of potential need for new
response code
Related documents in SIPPING
draft-ietf-sipping-config-framework-11
draft-petrie-sipping-identity-dataset-01=20
draft-petrie-sipping-profile-datasets-04=20
draft-petrie-sipping-sip-dataset-02=20
draft-petrie-sipping-voip-features-dataset-01=20
See also draft-petrie-sip-event-param-err-00.txt
Waiting on SIPPING rewrite of draft-ietf-sipping-config-framework
OMA liaison - possible interaction with draft-ietf-simple-xcap-diff and
draft-urpalainen-sip-xcap-diff-event-01
Draft currently expired and removed from archive
Looks like should be replaced with
draft-urpalainen-sip-xcap-diff-event-03 which will need a milestone
revision
=20
draft-rosenberg-sip-ua-loose-route-00
Agreed as WG item at IETF#67
Candidate: proposed standard
December 2007: Delivering request-URI and parameters to UAS via proxy to
WGLC
February 2008: Delivering request-URI and parameters to UAS via proxy to
IESG (PS)
Author to submit sip-00 version - however lack of input post discussion
IETF#69=20

draft-ietf-sip-domain-certs-00
Candidate: Informational
Milestone for WGLC November 2007
Keith Drage is PROTO document shepherd
Milestone for submission to IESG January 2008

draft-ietf-sip-eku-00
Candidate: Proposed standard
Milestone for WGLC November 2007
Keith Drage is PROTO document shepherd
Milestone for submission to IESG January 2008

draft-ietf-sip-body-handling-00
Candidate: Proposed standard
Milestone for WGLC January 2008
Dean Willis is PROTO document shepherd
Milestone for submission to IESG April 2008
draft-ietf-sip-ua-privacy-00

draft-ietf-sip-media-security-requirements-01
Candidate: Best Current Practice (we may downgrade / upgrade this based
on discussion of the contents)
Milestone for WGLC May 2008
Milestone for submission to IESG July 2008
Needs discussion of what we really need to say in such a document

draft-ietf-sip-dtls-srtp-framework-00=20
Candidate: Informational
Milestone for WGLC September 2007
Dean Willis is PROTO document shepherd
Milestone for submission to IESG November 2007

draft-ietf-sip-record-route-fix-00
Candidate: Proposed standard
Milestone for WGLC December 2007
Dean Willis is PROTO document shepherd
Milestone for submission to IESG February 2008

Essential corrections
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Milestone: 1st batch to IESG in April 2008
Robert Sparks to be lead editor
Process in draft-drage-sip-essential-correction-02
Will roll in RFC 3420 and draft-ietf-sip-fork-loop-fix in first
published version of RFC 3261 update
See:
http://www.softarmor.com/mediawiki/index.php/Essential_Corrections_Track
ing
Current documents under consideration:
draft-ietf-sip-record-route-fix-01.txt
draft-gurbani-sip-ipv6-abnf-fix-00.txt
draft-hilt-sip-correction-503-01.txt
draft-dotson-sip-mutual-auth-00.txt
draft-sparks-sip-invfix-00

Status: Identify requirements for test matrix to move SIP to Draft
Standard
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D
Milestone Feb 2008
Robert Sparks coordinating input


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 07:29:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvXe5-0008Do-I0; Fri, 23 Nov 2007 07:28:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvXe3-00082p-N0
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 07:28:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXe3-000817-CY
	for sip@ietf.org; Fri, 23 Nov 2007 07:28:31 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvXdz-0006Y1-BS
	for sip@ietf.org; Fri, 23 Nov 2007 07:28:31 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lANCSOX6013850
	for ; Fri, 23 Nov 2007 06:28:26 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 06:28:24 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 13:28:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Nov 2007 13:28:20 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019747E7@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SIP WG status (those completed by WG)
Thread-Index: AcgtzFU3eKADTIvzQ0Sz1G2L6vE95Q==
From: "DRAGE, Keith \(Keith\)" 
To: 
X-OriginalArrivalTime: 23 Nov 2007 12:28:21.0844 (UTC)
	FILETIME=[55F02940:01C82DCC]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Subject: [Sip] SIP WG status (those completed by WG)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

(As SIP WG cochair)

An update on the current status of WG documents. This is the batch of
documents that the WG has essentially finished with and are currently
being processed.

If you have comments on specific documents, then please start a separate
thread.

Regards

Keith


Documents published since IETF #69
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

None.

Documents in RFC editor's queue
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

draft-ietf-sip-acr-code-05 (Proposed standard)
Dean Willis is document shepherd
Currently in state: In RFC Editor's Queue - RFC-EDITOR.

draft-ietf-sip-gruu-14 (Proposed standard)
Keith Drage is document shepherd
Currently in state: In RFC Editor's Queue - MISSREF (waiting for
draft-ietf-sip-outbound).

Documents with IESG
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

draft-ietf-sip-answermode-06 (Proposed standard)
Keith Drage is document shepherd
IESG last call initiated 10th July 2007 to complete 5th August 2007.
Currently in state: IESG Evaluation :: Revised ID Needed.

draft-ietf-sip-ice-option-tag-02 (Proposed standard)
Keith Drage is PROTO document shepherd
IESG last call initiated 2nd August 2007 to complete 16th August 2007.=20
Currently in state: Approval-announcement to be sent :: External Party
Currently held by AD pending approval of draft-ietf-behave-rfc3489bis-12
and draft-ietf-behave-turn-04: "This draft is ref blocked by
ICE/STUN/TURN. There is a slight possible that a small change may be
needed here to negotiation things once TURN / STUN are all done. It is
waiting for theses to be complete to check that no change is needed here
before sending it on"

draft-ietf-sip-multiple-refer-02  (Proposed standard)
Keith Drage is document shepherd
IESG last call initiated 19th November 2007 to complete 10th December
2007
Currently in state: In last call

draft-ietf-sip-uri-list-message-02  (Proposed standard)
Keith Drage is document shepherd
IESG last call initiated 19th November 2007 to complete 10th December
2007
Currently in state: In last call

draft-ietf-sip-uri-list-conferencing-02  (Proposed standard)
Keith Drage is document shepherd
IESG last call initiated 19th November 2007 to complete 10th December
2007
Currently in state: In last call

draft-ietf-sip-uri-list-subscribe-02  (Proposed standard)
Keith Drage is document shepherd
IESG last call initiated 19th November 2007 to complete 10th December
2007
Currently in state: In last call

draft-ietf-sip-consent-framework-03 (Proposed standard)
Keith Drage is document shepherd
IESG last call initiated 19th November 2007 to complete 10th December
2007
Currently in state: In last call

Documents finished in the WG, awaiting submission to IESG
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

draft-ietf-sip-certs-04 (Proposed standard)
Candidate: Proposed standard
Dean Willis is PROTO document shepherd
Milestone for sending to IESG is June 2007
Token currently with PROTO shepherd

draft-ietf-sip-session-policy-framework-02
Candidate: Proposed standard
SIPPING WG review initiated 4th August 2006 to complete 25th August 2006
WGLC initiated 21st May 2007 to complete 11th June 2007.=20
Keith Drage is PROTO document shepherd
Token currently with PROTO shepherd
Milestone for submission to IESG September 2007

draft-ietf-sip-sips-06
Candidate: Proposed standard
WGLC initiated 29th June 2007 to complete 16th July 2007
Dean Willis is PROTO document shepherd
Token currently with PROTO shepherd. Need to make sure it updates RFC
3261 and IANA registry in relation to Warning header.
Milestone for submission to IESG September 2007


_______________________________________________
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

From sip-bounces@ietf.org Fri Nov 23 07:29:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvXf6-0000pJ-LS; Fri, 23 Nov 2007 07:29:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvXf4-0000p5-Jh
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 07:29:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXf3-0000nQ-L4
	for sip@ietf.org; Fri, 23 Nov 2007 07:29:33 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvXez-0006aT-7p
	for sip@ietf.org; Fri, 23 Nov 2007 07:29:33 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lANCTFOU005483
	for ; Fri, 23 Nov 2007 06:29:27 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 06:29:22 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 13:29:20 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Nov 2007 13:29:19 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019747EA@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SIP WG status (author drafts)
Thread-Index: AcgtzHhK4av2P3b2RPu007ZjP6RaOQ==
From: "DRAGE, Keith \(Keith\)" 
To: 
X-OriginalArrivalTime: 23 Nov 2007 12:29:20.0500 (UTC)
	FILETIME=[78E65B40:01C82DCC]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Subject: [Sip] SIP WG status (author drafts)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

(As SIP WG cochair)

This is the set of author drafts I have identified for SIP that are not
otherwise mentioned in the status update elsewhere (i.e. there are some
we are already taking some steps to progress).

If you consider any of these documents should be advanced, then please
start an appropriate thread.

There may well be drafts tagged as "sipping" that should go direct to
SIP because they are security related, or because once SIPPING has
endorsed the requirements because RFC 3427 specifies that they should.

Additionally, some of these listed need to have requirements endorsed by
SIPPING first.

Regards

Keith

Identified author drafts
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

draft-burger-sip-info-02.txt (proposed agenda time IETF#70)
draft-dotson-sip-certificate-auth-04.txt
draft-gurbani-sip-sipsec-01.txt
draft-jennings-sip-dtls-05.txt
draft-jennings-sip-hashcash-06.txt
draft-lee-sip-dns-sd-uri-02.txt
draft-mahy-http-change-notification-via-sip-00.txt
draft-mahy-sieve-notify-sip-00.txt
draft-manand-test-sip-ims-compliance-00.txt
draft-melnikov-sieve-notify-sip-message-00.txt
draft-munakata-sip-privacy-guideline-01.txt
draft-munakata-sip-privacy-new-01.txt
draft-ott-sip-serv-indication-notification-00.txt
draft-polk-sip-rph-in-responses-00 (proposed agenda time IETF#70 -
agreed to progress at IETF#69 but issues with use cases)
draft-poretsky-bmwg-sip-bench-meth-01.txt
draft-poretsky-sip-bench-term-03.txt
draft-rosenberg-sip-app-media-tag-01.txt
draft-schwartz-sip-nsr-code-00.txt
draft-wing-sip-identity-media-01.txt (proposed agenda time IETF#70)
draft-xu-yang-retargeting-security-00.txt
draft-giordano-sip-call-hold-revision-00.txt
draft-kaplan-sip-info-events-00.txt (proposed agenda time IETF#70)
draft-rosenberg-sip-ice-error-code-00.txt
draft-gunn-sip-req-for-rph-in-responses-00.txt (proposed agenda time
IETF#70)


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 09:14:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvZHk-00047y-Bg; Fri, 23 Nov 2007 09:13:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvZHi-00047o-UA
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 09:13:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZHi-00047g-KC
	for sip@ietf.org; Fri, 23 Nov 2007 09:13:34 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvZHg-0001K0-2I
	for sip@ietf.org; Fri, 23 Nov 2007 09:13:34 -0500
Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net
	[96.226.64.76]) (authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lANEDHwx047449
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 23 Nov 2007 08:13:18 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: 
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
Date: Fri, 23 Nov 2007 08:13:19 -0600
To: "Christer Holmberg" 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4890/Fri Nov 23 04:34:41 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: sip@ietf.org, "Even, Roni" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 23, 2007, at 5:12 AM, Christer Holmberg wrote:

> Hi,
>
>> The offerer need to be able to receive any codec that he declared  
>> in the offer regardless of answer.
>
> Before or after he has received the answer?
>
> BEFORE he has received the answer he may accept anything that was  
> in the offer (eventhough in many cases he will not accept - or even  
> receive (due to gates etc) - anything until he has received the  
> answer).
>
> AFTER he has received the answer he may accept only what both  
> parties have indicated support for.

I don't think that's right. Can you show me the text that supports  
that claim?

I'm pretty sure the answer event has no effect on what he needs to  
receive.

>
>
>> The offerer may send a re-invite after the answer to fix the set  
>> of codecs to a smaller set.
>
> That is normally done when both the offer and the answer have  
> contained multiple codecs which both support.
>
> But, if I offer you A, B and C, and you send back C, I am not  
> necessarily going to send a re-INVITE to "remove" A and B - I may  
> assume that we will only use C (based on the text from 3264 we've  
> seen cited in this thread).
>
> Regards,
>
> Christer
>
>
>
>
>
>
> Roni Even
>
>> -----Original Message-----
>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>> Sent: Friday, November 23, 2007 12:48 PM
>> To: Dean Willis
>> Cc: sip@ietf.org
>> Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about
>>
>> Hi,
>>
>>>> I agree with Ravi.
>>>>
>>>> Eventhough you in theory is supposed to be able to receive what you
>>>> offer - no matter what you get in the answer - I think that in real
>>>> life the only codecs that participants will be prepared to send/ 
>>>> receive
>> are
>>>> the ones sent both in the offer and the answer. That is also the
>>>> reason
>>>> why the answer normally doesn't contain additional codecs - it  
>>>> mostly
>>>> contains a subset of the codecs in the offer.
>>> So how do you deal with asymmetric encoding?
>>
>> You may use different codecs in each direction (eventhough I don't  
>> think
>> it happens very often), as long as all codecs have been present in  
>> both
>> the offer and the answer.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
>
>
> _______________________________________________
> 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



_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 11:22:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvbI8-0002Pz-CF; Fri, 23 Nov 2007 11:22:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvbI6-0002I1-US
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 11:22:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbI6-0002GK-9u
	for sip@ietf.org; Fri, 23 Nov 2007 11:22:06 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvbI1-0005Ik-Qu
	for sip@ietf.org; Fri, 23 Nov 2007 11:22:06 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 23 Nov 2007 11:22:02 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lANGM1g3017479; 
	Fri, 23 Nov 2007 11:22:01 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lANGH807000560; 
	Fri, 23 Nov 2007 16:21:48 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 11:20:40 -0500
Received: from [10.82.210.128] ([10.82.210.128]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 11:20:40 -0500
Message-ID: <4746FDD7.3020402@cisco.com>
Date: Fri, 23 Nov 2007 11:20:39 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com> <474500A5.5040605@alcatel-lucent.com>
In-Reply-To: <474500A5.5040605@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Nov 2007 16:20:40.0643 (UTC)
	FILETIME=[CA1C1930:01C82DEC]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1970; t=1195834921;
	x=1196698921; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20WGLC=3A=20draft-ietf-sip-connect-reuse-08.txt
	|Sender:=20
	|To:=20=22Vijay=20K.=20Gurbani=22=20;
	bh=25o+lQ45Guy/QoBapC0uQO1ktMkFmER2FDP7habj3Qc=;
	b=Po8PjZ2oHi8RkpBCXflP6TpwFbWtTK3M9tgxe+1ZxSoM/BJqrG9eLfPxwZeHaWricsG4xxnO
	bop6ZgIVYeNFDHFVDqDyS9p9wP+vJqYScAwLwZtNcXY4FsIHYcph8Yjf;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: IETF SIP List , Rohan Mahy ,
	Brett Tate 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Vijay K. Gurbani wrote:
> Paul Kyzivat wrote:
>> I think much less should be said.
>>
>> Don't say that A must reject requests sent to it over the connection. 
>> But also don't specify, or even imply, a mechanism by which B might 
>> decide it is ok to send requests on this connection.
> 
> Any way you cut, slice, and dice this thing, TCP connection reuse
> in the backwards direction is bad.  Note that it does not work with
> virtual servers at all.
> 
> Unfortunately, people are using it and as such something ought to
> be said about it in the draft.  I agree that as the less said, the
> better.  I also agree that putting the "alias" parameter in the
> Via request for TCP.

There seems to be something wrong with the last sentence. Did you forget 
a word or two?

> Going back to our scenario of A opening a connection to B, it
> probably suffices to massage the text you proposed in an earlier
> email of this thread:
> 
>    B MUST NOT reuse this connection for requests to the
>    supposed party at the other end UNLESS it has some way
>    of verifying the identity of that party to the same level
>    of assurance as it would have by doing the DNS lookup and
>    establishing its own connection. For instance, if a DNS
>    lookup resolved to the same address and port as the source
>    port of the inbound connection then that ought be be good
>    enough.

I was thinking about that too. That "for instance" *seems* reasonable to 
me, but I would like to hear what others think.

> This still does not solve the problem of reusing TCP connections
> for virtual servers; i.e., B does not know that that A's physical
> IP address is being used by multiple virtual domains. 

I don't understand what point you are making here.

	Thanks,
	Paul

> Again, I
> can just point this out for the TCP and SCTP transport in
> the virtual server section more emphatically and leave it at that.
> 
> - vijay


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 11:33:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvbTK-0007ns-21; Fri, 23 Nov 2007 11:33:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvbTI-0007Qt-De
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 11:33:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbTH-0007J1-S7
	for sip@ietf.org; Fri, 23 Nov 2007 11:33:39 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IvbTD-0005eT-8u for sip@ietf.org; Fri, 23 Nov 2007 11:33:39 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-2.cisco.com with ESMTP; 23 Nov 2007 08:33:36 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lANGXYsf031830; 
	Fri, 23 Nov 2007 08:33:34 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lANGXQB7027588;
	Fri, 23 Nov 2007 16:33:32 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 11:33:30 -0500
Received: from [10.82.210.128] ([10.82.210.128]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 11:33:29 -0500
Message-ID: <474700D9.7090809@cisco.com>
Date: Fri, 23 Nov 2007 11:33:29 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>	<47448C1B.7000603@alcatel-lucent.com>
	<200711212343.lALNh17e006911@dragon.ariadne.com>
In-Reply-To: <200711212343.lALNh17e006911@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Nov 2007 16:33:29.0957 (UTC)
	FILETIME=[94A81950:01C82DEE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1880; t=1195835614;
	x=1196699614; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20Re=3A=20URI=20comparison=20rules=20-=20IPv6=2
	0addresses |Sender:=20;
	bh=MBgMzPhhzHYsq1qUHsvssvAGiLBTNNtScCUBHBQbmPY=;
	b=cfSz3kAWil+dbIaEsRD2s4NfhO2NClGuvnwb/R9KydrEVet8iLtMViSVnwtQATsvLSHZHog4
	0dLuyF71nunEj1UefkZgA1Mu+pytDmvBGqEna/MISD9mwxzhl2vthhPI;
Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Dale.Worley@comcast.net wrote:
>    From: "Vijay K. Gurbani" 
> 
>    Jeroen van Bemmel wrote:
>    > Vijay,
>    > It's not only IPv6: what about 127.0.0.1 versus 127.000.000.1?
> 
>    Jeroen: Pedantically speaking, you are probably right.  But
>    in practice we do not generally see leading zeros in an IPv4
>    octet.
> 
> Even worse, in some places, including some early RFCs, the leading
> zero is used to indicate that the octet is represented in octal!
> 
> But I think Jeroen's point is actually well-taken, when comparing
> representations of IP addresses (not DNS names), the comparison is
> implicitly of the address represented, not the textual
> representation.  And this applies in IPv4 as well as IPv6.
> 
> In regard to loop detection, there are two approaches:  (1) Whatever
> attempts to detect loops can canonicalize the addresses before
> comparing them or whatever. 

I agree with all the above.

> (2) Since there are a limited number of
> likely representations of any address, having different entities use
> different representations will only delay loop detection, not prevent
> it.  And loops will be detected even if address comparisons have
> occasional false negatives.

While the number is *limited*, the limit is pretty large.

Consider an IPv4 address where each of the components requires only two 
digits. Then each can be represented two ways - with two digits or 
three. That means there are 16 different valid representations of the 
address. Of course it would be much worse for Ipv6 addresses.

Port numbers are worse. The syntax for the port number is 1*DIGIT. So a 
port number can be represented with *any* number of leading zeros.

Bottom line - I think you can't rely on exhausting all the permutations 
of hostport before detecting a loop.

	Thanks,
	Paul


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 12:18:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvcAc-0004Yq-Kb; Fri, 23 Nov 2007 12:18:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvcAb-0004Yj-EP
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 12:18:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvcAb-0004YZ-4e
	for sip@ietf.org; Fri, 23 Nov 2007 12:18:25 -0500
Received: from qmta09.emeryville.ca.mail.comcast.net ([76.96.30.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvcAY-0007Qt-N8
	for sip@ietf.org; Fri, 23 Nov 2007 12:18:25 -0500
Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11])
	by QMTA09.emeryville.ca.mail.comcast.net with comcast
	id GEbm1Y00D0EPcho0A07N00; Fri, 23 Nov 2007 17:18:25 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA01.emeryville.ca.mail.comcast.net with comcast
	id GHJP1Y00A0umElk0800000; Fri, 23 Nov 2007 17:18:25 +0000
X-Authority-Analysis: v=1.0 c=1 a=a641SQi2628A:10 a=TuTjrK6NIXZLs9kHL5cA:9
	a=bcJCUyKy842PDYUFjTIA:7 a=EzupH82ytDUhBSrTWJnM9AhRH7AA:4
	a=vU1iTpKjMEAA:10 a=BVuZ65sqfIUA:10 a=6YrVqOImHl8A:10
	a=MQMG9OawIewA:10 a=JfD0Fch1gWkA:10 a=hx3tvJ9Yf1UA:10
	a=_2n4yEj-CikA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lANHIJSV027172
	for ; Fri, 23 Nov 2007 12:18:19 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lANHIJ6r027168;
	Fri, 23 Nov 2007 12:18:19 -0500
Date: Fri, 23 Nov 2007 12:18:19 -0500
Message-Id: <200711231718.lANHIJ6r027168@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <4744C622.300@cisco.com> (mat@cisco.com)
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>	<47448C1B.7000603@alcatel-lucent.com>
	<200711212343.lALNh17e006911@dragon.ariadne.com>
	<4744C622.300@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Michael Thomas 

   Given that a particular IP address might serve many, many different
   URI's (think about the outsourced case), I doesn't seem to me that this
   would be a very good assumption. It might be perfectly reasonable for
   a method to traverse from IP address A and then back through IP address
   A again without being a loop since it might be outsource1.com through
   outsource2.com which is legal, right? This case certainly comes up with
   email and is actually really common(*).

But if sip:...@outsource1.com is turned into sip:...@outsource2.com,
it hasn't looped yet.  It's only when the latter gets turned into
sip:...@outsource1.com again that there's a loop.  And in any case,
these are DNS names, not IP addresses, so they're not relevant to the
question at hand.

(Amusingly, "..." is a legitimate user-part in a SIP URI.)

Dale


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 12:21:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvcDE-0000R7-S8; Fri, 23 Nov 2007 12:21:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvcDD-0000Qy-FY
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 12:21:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvcDD-0000Qo-5L
	for sip@ietf.org; Fri, 23 Nov 2007 12:21:07 -0500
Received: from qmta05.emeryville.ca.mail.comcast.net ([76.96.30.48])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvcDC-0008UR-OJ
	for sip@ietf.org; Fri, 23 Nov 2007 12:21:07 -0500
Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12])
	by QMTA05.emeryville.ca.mail.comcast.net with comcast
	id GDAY1Y0060FhH240A0DV00; Fri, 23 Nov 2007 17:21:09 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA08.emeryville.ca.mail.comcast.net with comcast
	id GHM71Y00B0umElk0800000; Fri, 23 Nov 2007 17:21:09 +0000
X-Authority-Analysis: v=1.0 c=1 a=a641SQi2628A:10 a=FO4_DPHR8zsQfEvtuP0A:9
	a=aPY_TtD8OT17jqWuRq4Y2b1toJQA:4 a=JfD0Fch1gWkA:10
	a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lANHL3SV027365
	for ; Fri, 23 Nov 2007 12:21:03 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lANHL35M027361;
	Fri, 23 Nov 2007 12:21:03 -0500
Date: Fri, 23 Nov 2007 12:21:03 -0500
Message-Id: <200711231721.lANHL35M027361@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <474700D9.7090809@cisco.com> (pkyzivat@cisco.com)
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl>	<47448C1B.7000603@alcatel-lucent.com>
	<200711212343.lALNh17e006911@dragon.ariadne.com>
	<474700D9.7090809@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Paul Kyzivat 

   > (2) Since there are a limited number of
   > likely representations of any address, having different entities use
   > different representations will only delay loop detection, not prevent
   > it.  And loops will be detected even if address comparisons have
   > occasional false negatives.

   While the number is *limited*, the limit is pretty large.

True, but I expect in practice there will be no cases with more than 3
representations of the same address used by any one SIP agent unless
it's deliberately trying to defeat loop detection.  That case is
ameliorated by (1) a malicious agent would have to handle the message
"every time around the loop", which would place a high burden on it,
and (2) loops will eventually be detected by Max-Forwards in any case.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 12:31:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvcN4-0005XU-Oz; Fri, 23 Nov 2007 12:31:18 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvcN3-0005XO-IE
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 12:31:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvcN3-0005WP-7t
	for sip@ietf.org; Fri, 23 Nov 2007 12:31:17 -0500
Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvcN0-0007rw-Tl
	for sip@ietf.org; Fri, 23 Nov 2007 12:31:17 -0500
Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59])
	by QMTA04.westchester.pa.mail.comcast.net with comcast
	id GG5Y1Y0051GhbT80507200; Fri, 23 Nov 2007 17:31:14 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA07.westchester.pa.mail.comcast.net with comcast
	id GHXD1Y00K0umElk0300000; Fri, 23 Nov 2007 17:31:14 +0000
X-Authority-Analysis: v=1.0 c=1 a=ebSiwEMrWRMA:10 a=Wqm5xmrNe1gIqbeeA64A:9
	a=jXyeOGCOb6QojLtgdx9ctUO3afsA:4 a=0MAqpqVwYqEA:10
	a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lANHVESV028139
	for ; Fri, 23 Nov 2007 12:31:14 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lANHVE4Z028135;
	Fri, 23 Nov 2007 12:31:14 -0500
Date: Fri, 23 Nov 2007 12:31:14 -0500
Message-Id: <200711231731.lANHVE4Z028135@dragon.ariadne.com>
From: Dale.Worley@comcast.net
To: sip@ietf.org
In-reply-to: 
	(rjsparks@nostrum.com)
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>
	
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Robert Sparks 

   On Nov 23, 2007, at 5:12 AM, Christer Holmberg wrote:
   > AFTER he has received the answer he may accept only what both  
   > parties have indicated support for.

   I don't think that's right. Can you show me the text that supports  
   that claim?

Here's section 7 of RFC 3264 (found by Ernst Horvath):

7 Offerer Processing of the Answer

   When the offerer receives the answer, it MAY send media on the
   accepted stream(s) (assuming it is listed as sendrecv or recvonly in
   the answer).  It MUST send using a media format listed in the answer,
   and it SHOULD use the first media format listed in the answer when it
   does send.

      The reason this is a SHOULD, and not a MUST (its also a SHOULD,
      and not a MUST, for the answerer), is because there will
      oftentimes be a need to change codecs on the fly.  For example,
      during silence periods, an agent might like to switch to a comfort
      noise codec.  Or, if the user presses a number on the keypad, the
      agent might like to send that using RFC 2833 [9].  Congestion
      control might necessitate changing to a lower rate codec based on
      feedback.

   The offerer SHOULD send media according to the value of any ptime and
   bandwidth attribute in the answer.

   The offerer MAY immediately cease listening for media formats that
   were listed in the initial offer, but not present in the answer.

I skimmed draft-ietf-sipping-sip-offeranswer-04 and I see nothing in
it that would alter the interpretation of this section.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 15:11:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iveql-0006Xq-LD; Fri, 23 Nov 2007 15:10:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iveqk-0006Xj-B6
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 15:10:06 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iveqk-0006XK-0F
	for sip@ietf.org; Fri, 23 Nov 2007 15:10:06 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iveqc-0006os-NE
	for sip@ietf.org; Fri, 23 Nov 2007 15:10:03 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lANK9lRC022621; 
	Fri, 23 Nov 2007 14:09:47 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lANK9lj17488; Fri, 23 Nov 2007 14:09:47 -0600 (CST)
Message-ID: <4747338B.8090203@alcatel-lucent.com>
Date: Fri, 23 Nov 2007 14:09:47 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Paul Kyzivat 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com> <474500A5.5040605@alcatel-lucent.com>
	<4746FDD7.3020402@cisco.com>
In-Reply-To: <4746FDD7.3020402@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:
>> Unfortunately, people are using it and as such something ought to
>> be said about it in the draft.  I agree that as the less said, the
>> better.  I also agree that putting the "alias" parameter in the
>> Via request for TCP.
> 
> There seems to be something wrong with the last sentence. Did you forget 
> a word or two?

Yes, sorry; I meant to say that "I also agree that putting the "alias"
parameter in the Via request for TCP is not a good idea."

>> This still does not solve the problem of reusing TCP connections
>> for virtual servers; i.e., B does not know that that A's physical
>> IP address is being used by multiple virtual domains. 
> 
> I don't understand what point you are making here.

Consider named-based virtual hosting in SIP, where the same IP
address supports multiple domains.  red.com and blue.com are hosted
on a physical server that uses one IP address.  Now, when red.com
makes a TCP connection to another domain -- example.com -- then
example.com may want to use this TCP connection to send requests
to blue.com (because blue.com's IP address matches red.com's).

Same problem we had in TLS, except the way we solved it in TLS
was to associate the identity picked up from the certificate with
the connection.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 17:21:01 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ivgsu-0000XJ-SM; Fri, 23 Nov 2007 17:20:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ivgst-0000XE-Mj
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 17:20:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivgst-0000X6-DB
	for sip@ietf.org; Fri, 23 Nov 2007 17:20:27 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivgsp-0001Mb-Rz
	for sip@ietf.org; Fri, 23 Nov 2007 17:20:27 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 23 Nov 2007 14:20:23 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lANMKNdL018899; 
	Fri, 23 Nov 2007 14:20:23 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lANMJfB9027277;
	Fri, 23 Nov 2007 22:20:18 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 17:20:05 -0500
Received: from [10.86.240.194] ([10.86.240.194]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 17:20:04 -0500
Message-ID: <47475214.9040003@cisco.com>
Date: Fri, 23 Nov 2007 17:20:04 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com> <474500A5.5040605@alcatel-lucent.com>
	<4746FDD7.3020402@cisco.com> <4747338B.8090203@alcatel-lucent.com>
In-Reply-To: <4747338B.8090203@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Nov 2007 22:20:05.0036 (UTC)
	FILETIME=[FF7D56C0:01C82E1E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1547; t=1195856423;
	x=1196720423; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20WGLC=3A=20draft-ietf-sip-connect-reuse-08.txt
	|Sender:=20; bh=mSYxRdW5MIrg/1wWY3he0TiZARrYnGbGhaJEMF97TiI=;
	b=CEdO71CnTMpbO0Y0OjcY02vC6IRUj0WNRjiNhiFTF3n9QN66SL274/7+QcguecmErEAYbC41
	IGB4vkM9nRNlMHRK2x7+bR/FNJzX4D5YZ8VHMygtuctPwJP3YPhEb82Btn57kgBcHqxtJd5F4b
	OpmoevsrKtI5U5ByIvxiF/FnY=;
Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Interestingly, doing the DNS lookup for blue.com, and recognizing that 
you already have a connection from that address would work in this case.

	Paul

Vijay K. Gurbani wrote:
> Paul Kyzivat wrote:
>>> Unfortunately, people are using it and as such something ought to
>>> be said about it in the draft.  I agree that as the less said, the
>>> better.  I also agree that putting the "alias" parameter in the
>>> Via request for TCP.
>>
>> There seems to be something wrong with the last sentence. Did you 
>> forget a word or two?
> 
> Yes, sorry; I meant to say that "I also agree that putting the "alias"
> parameter in the Via request for TCP is not a good idea."
> 
>>> This still does not solve the problem of reusing TCP connections
>>> for virtual servers; i.e., B does not know that that A's physical
>>> IP address is being used by multiple virtual domains. 
>>
>> I don't understand what point you are making here.
> 
> Consider named-based virtual hosting in SIP, where the same IP
> address supports multiple domains.  red.com and blue.com are hosted
> on a physical server that uses one IP address.  Now, when red.com
> makes a TCP connection to another domain -- example.com -- then
> example.com may want to use this TCP connection to send requests
> to blue.com (because blue.com's IP address matches red.com's).
> 
> Same problem we had in TLS, except the way we solved it in TLS
> was to associate the identity picked up from the certificate with
> the connection.
> 
> Thanks,
> 
> - vijay


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 18:38:44 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ivi66-00039a-Px; Fri, 23 Nov 2007 18:38:10 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ivi65-00039N-Ex
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 18:38:09 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivi65-00038n-4j
	for sip@ietf.org; Fri, 23 Nov 2007 18:38:09 -0500
Received: from qmta08.emeryville.ca.mail.comcast.net ([76.96.30.80])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivi64-00060U-MO
	for sip@ietf.org; Fri, 23 Nov 2007 18:38:09 -0500
Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51])
	by QMTA08.emeryville.ca.mail.comcast.net with comcast
	id GNlE1Y00816AWCU0A02F00; Fri, 23 Nov 2007 23:38:11 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA06.emeryville.ca.mail.comcast.net with comcast
	id GPe91Y0060umElk0800000; Fri, 23 Nov 2007 23:38:11 +0000
X-Authority-Analysis: v=1.0 c=1 a=5NpDE1_nZ8zolrb8gY0A:9
	a=Q3gvGodsQ5CtACcDhSYA:7 a=CT61Ba0hZWGJBJ5b8c1jDLc6lTMA:4
	a=0MAqpqVwYqEA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lANNc5SV022579
	for ; Fri, 23 Nov 2007 18:38:05 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lANNc5Au022575;
	Fri, 23 Nov 2007 18:38:05 -0500
Date: Fri, 23 Nov 2007 18:38:05 -0500
Message-Id: <200711232338.lANNc5Au022575@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <04F6CAAC-A1DD-4F42-A343-E36D2B7D1477@nostrum.com>
	(rjsparks@nostrum.com)
Subject: Re: [Sip] Errant Proxy Behavior?
References: <9d6632e0711211020t15344ca7i11022838e505cdc2@mail.gmail.com>
	<04F6CAAC-A1DD-4F42-A343-E36D2B7D1477@nostrum.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Robert Sparks 

   Now, for the particular transformation you're describing - it's not  
   legal. Replacing a %41 with an 'A' or vice-versa would be legal (but  
   unwise). "$", on the other hand, is special.

   The text in section 19.1.4 (URI Comparison) says:
   ...
      SIP and SIPS URIs are compared for equality
       according to the following rules:
   ...
	  o  Characters other than those in the "reserved" set (see RFC  
   2396
	     [5]) are equivalent to their ""%" HEX HEX" encoding.

   But

	  reserved    =  ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
			 / "$" / ","

Hmmmm, I agree that this is what the RFCs say, but is it what we
really want?  That '%41' is expected to be equivalent to 'A' but '%24'
is *not* equivalent to '$', in a context where '$' is a character with
no exceptional semantics?  That seems like opening a big can of worms.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 20:27:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvjnL-0004v6-Bg; Fri, 23 Nov 2007 20:26:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvjnK-0004uo-16
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 20:26:54 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvjnJ-0004ug-MZ
	for sip@ietf.org; Fri, 23 Nov 2007 20:26:53 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvjnJ-0000LC-97
	for sip@ietf.org; Fri, 23 Nov 2007 20:26:53 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAO1QnNs028191
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 23 Nov 2007 19:26:51 -0600
In-Reply-To: <2AF2438D-78D2-4CA4-81AA-11303276ADE4@nostrum.com>
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
	<1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
	<65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
	
	<474234E7-F898-464A-BAA3-E27890D7909B@softarmor.com>
	<2AF2438D-78D2-4CA4-81AA-11303276ADE4@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <60D18834-31D6-4C80-8F6A-3FCA47A2CE7A@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
Date: Fri, 23 Nov 2007 19:26:39 -0600
To: Robert Sparks 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 22, 2007, at 12:31 PM, Robert Sparks wrote:

> I disbelieve that there are any UAs that claim support for 100rel  
> and don't pay attention to the answer in the 180.
> Please show me one (send me traces please).
>

I believe I have some that also ignore the 100-rel, neither sending a  
prack nor paying attention to the answer.

> Are you mixing the non-reliable 18x case in here? (I think that  
> might be where you're coming from since you say "older" UAs).'
> That's not what we're discussing. Repeating the answer in the 200  
> here makes sense.

For some really old UAs, this is the same use case.
>
> And what do you mean "rejects the 180"? That makes no sense.

Some nodes will treat an SDP-bearing 183 as a non-SDP-bearing 180.  
Others will just ignore the whole response.

>
> Do you have a UAS that's tries to send 100rel responses when the UA  
> hasn't indicated support?
>

Ah now, that's a better question. I don't have such a thing, but I  
wouldn't be surprised if it happened.

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 20:33:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvjtJ-0007Ro-I0; Fri, 23 Nov 2007 20:33:05 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvjtI-0007Oe-6k
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 20:33:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvjtH-0007Mm-SY
	for sip@ietf.org; Fri, 23 Nov 2007 20:33:03 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvjtD-0007Dd-BB
	for sip@ietf.org; Fri, 23 Nov 2007 20:33:03 -0500
Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may
	be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAO1WpS3028222
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 23 Nov 2007 19:32:54 -0600
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>						
	
	<4745BDC7.30003@gmx.net>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: R: R: [Sip] a question about IETF draft location conveyance 09
Date: Fri, 23 Nov 2007 19:32:41 -0600
To: daniel grotti 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: IETF SIP List , "James M. Polk" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:

> Hi all,
> so why don't emphasize this point in the next draft, saying :  
> "Proxy server MUST not read messages with "recipient=endpoint"  
> paramenter setted".
> This is my point of you.
>
>


because from a security standpoint, this prohibition is meaningless.  
Intermediate nodes can and will read anything that's in plaintext,  
and SOMEBODY will come up with a rationale, in some context or  
another, for doing so.

And has been pointed out, doing so does not appear to create a  
compatibility problem. It doesn't break the protocol. It might defeat  
security-through-obscurity. It might be rude, or otherwise socially  
unacceptable. But those don't qualify for a MUST level protocol  
prohibition.

--
Dean



_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 23 21:47:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ivl2e-0001nB-Ab; Fri, 23 Nov 2007 21:46:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ivl2b-0001jQ-Ux
	for sip-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 21:46:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivl2b-0001jI-LQ
	for sip@ietf.org; Fri, 23 Nov 2007 21:46:45 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivl2Y-0000Rt-3z
	for sip@ietf.org; Fri, 23 Nov 2007 21:46:45 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 23 Nov 2007 21:46:33 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAO2kXaJ014496; 
	Fri, 23 Nov 2007 21:46:33 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAO2kSxX004707; 
	Sat, 24 Nov 2007 02:46:28 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 21:46:28 -0500
Received: from [10.86.240.194] ([10.86.240.194]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Nov 2007 21:46:28 -0500
Message-ID: <47479082.3030300@cisco.com>
Date: Fri, 23 Nov 2007 21:46:26 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Dean Willis 
Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
References: <8983EC086A9D954BA74D9763E853CF3E0437EE12@xmb-rtp-215.amer.cisco.com>		<32B7DC57-3B9C-43B9-A23E-D4C09F263B6E@softarmor.com>	<650EED83-56EA-4C77-B2CC-D8FF5AE0ECC2@nostrum.com>
	<48A4B771-1AD7-4CCD-BC52-230CE9014DFC@softarmor.com>
	<4744BC10.40301@cisco.com>
	<309C3407-D4BC-4011-BEBE-5E522D338174@softarmor.com>
	<1A9A6E61-88DE-4B77-A133-49102E39A466@nostrum.com>
	<65A5FCCD-EE46-4FF9-B7CA-2C4ACE2CB72F@softarmor.com>
	
	<474234E7-F898-464A-BAA3-E27890D7909B@softarmor.com>
	<2AF2438D-78D2-4CA4-81AA-11303276ADE4@nostrum.com>
	<60D18834-31D6-4C80-8F6A-3FCA47A2CE7A@softarmor.com>
In-Reply-To: <60D18834-31D6-4C80-8F6A-3FCA47A2CE7A@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Nov 2007 02:46:28.0104 (UTC)
	FILETIME=[3623F880:01C82E44]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1384; t=1195872393;
	x=1196736393; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit21=3A=20SDP=20in=20a=20200OK=20when=20us
	ing=20100rel |Sender:=20
	|To:=20Dean=20Willis=20;
	bh=oa+56uAwQuxAe1cgcVfPsQgviOnNB+Uwb80y2RSFFWM=;
	b=0Yz6odvCRI/qgPdHxwtjlzqjybSZ2KlV5gx0jLfjmnrrtulTyUJQVzx+tLS0pisouK9Fsoj6
	tllF5PoKJq2m54+tDlREhxc2xtcCYz5tqoopZsWyZEEsaVBTVrANIi5k;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: "Sanjay Sinha \(sanjsinh\)" , sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dean,

So are you saying the ignores the Require:100rel in the response and 
then fails to send the PRACK?

And then the UAS is supposed to not mind that it isn't getting the PRACK???

This is *so* broken that we shouldn't even be discussing it.

	Paul

Dean Willis wrote:
> 
> On Nov 22, 2007, at 12:31 PM, Robert Sparks wrote:
> 
>> I disbelieve that there are any UAs that claim support for 100rel and 
>> don't pay attention to the answer in the 180.
>> Please show me one (send me traces please).
>>
> 
> I believe I have some that also ignore the 100-rel, neither sending a 
> prack nor paying attention to the answer.
> 
>> Are you mixing the non-reliable 18x case in here? (I think that might 
>> be where you're coming from since you say "older" UAs).'
>> That's not what we're discussing. Repeating the answer in the 200 here 
>> makes sense.
> 
> For some really old UAs, this is the same use case.
>>
>> And what do you mean "rejects the 180"? That makes no sense.
> 
> Some nodes will treat an SDP-bearing 183 as a non-SDP-bearing 180. 
> Others will just ignore the whole response.
> 
>>
>> Do you have a UAS that's tries to send 100rel responses when the UA 
>> hasn't indicated support?
>>
> 
> Ah now, that's a better question. I don't have such a thing, but I 
> wouldn't be surprised if it happened.
> 
> -- 
> Dean
> 


_______________________________________________
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



From sip-bounces@ietf.org Sat Nov 24 06:36:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvtIo-0007l0-1M; Sat, 24 Nov 2007 06:36:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvtIm-0007kN-03
	for sip-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:36:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvtIl-0007jZ-MP; Sat, 24 Nov 2007 06:35:59 -0500
Received: from [202.99.23.227] (helo=people.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1IvtIf-0006xB-9t; Sat, 24 Nov 2007 06:35:59 -0500
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jm26647483410; Sat, 24 Nov 2007 19:48:49 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id jma44741a857; Mon, 19 Nov 2007 22:04:42 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 22:04:42 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu713-0002zX-Jd; Mon, 19 Nov 2007 08:50:21 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu70k-0002NK-C2; Mon, 19 Nov 2007 08:50:02 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Iu70j-0008S9-VN; Mon, 19 Nov 2007 08:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DCDC32AC5E;
	Mon, 19 Nov 2007 13:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Iu70j-0004oO-KX; Mon, 19 Nov 2007 08:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Mon, 19 Nov 2007 08:50:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Archive: 
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: Internet-Drafts@ietf.org
X-Auto-Forward: jaglee@people.com.cn
 jag@kw.com.cn
X-Spam-Score: 2.8 (++)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: sip@ietf.org
Subject: [Sip] I-D Action:draft-ietf-sip-outbound-11.txt 
X-BeenThere: sip@ietf.org
Reply-To: internet-drafts@ietf.org
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


	Title           : Managing Client Initiated Connections in the Session Initiation Protocol (SIP)
	Author(s)       : C. Jennings, R. Mahy
	Filename        : draft-ietf-sip-outbound-11.txt
	Pages           : 43
	Date            : 2007-11-19

The Session Initiation Protocol (SIP) allows proxy servers to
initiate TCP connections and send asynchronous UDP datagrams to User
Agents in order to deliver requests.  However, many practical
considerations, such as the existence of firewalls and Network
Address Translators (NATs), prevent servers from connecting to User
Agents in this way.  This specification defines behaviors for User
Agents, registrars and proxy servers that allow requests to be
delivered on existing connections established by the User Agent.  It
also defines keep alive behaviors needed to keep NAT bindings open
and specifies the usage of multiple connections from the User Agent
to its Registrar.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-11.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-outbound-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-outbound-11.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-19084019.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-outbound-11.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-outbound-11.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-19084019.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--






From sip-bounces@ietf.org Sat Nov 24 06:38:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvtKq-0001Gt-Is; Sat, 24 Nov 2007 06:38:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IvtKp-0001CJ-4G
	for sip-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:38:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtKo-0001AW-4U
	for sip@ietf.org; Sat, 24 Nov 2007 06:38:06 -0500
Received: from poster3.unibo.it ([137.204.24.100])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvtKn-0001Ka-Jf
	for sip@ietf.org; Sat, 24 Nov 2007 06:38:06 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by poster3.unibo.it (Postfix) with ESMTP id 58A2A2FE;
	Sat, 24 Nov 2007 12:38:04 +0100 (CET)
Received: from EXBK03 (unknown [137.204.25.211])
	by poster3.unibo.it (Postfix) with ESMTP id EBE49167;
	Sat, 24 Nov 2007 12:37:55 +0100 (CET)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: R: R: R: [Sip] a question about IETF draft location conveyance 09
Date: Sat, 24 Nov 2007 12:37:55 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: R: [Sip] a question about IETF draft location conveyance 09
Thread-Index: AcguOftcpiqOEOUgQ9WPkSnSiLbCzAAU0NU1
References: <4742BDF5.9040302@unibo.it>						
	
	<4745BDC7.30003@gmx.net>
	
	
From: "daniel grotti" 
To: "Dean Willis" 
X-Virus-Scanned: Cineca AppOs 1.00 at poster3.unibo.it
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: IETF SIP List , "James M. Polk" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I know.=20
May be SHOULD NOT instead MUST NOT could be better.

daniel


----------------------------------
       Daniel  Grotti
D.E.I.S. - University of Bologna
----------------------------------
       Via Venezia, 52
  47023 Cesena (FC) - ITALY
----------------------------------
e-mail: daniel.grotti@unibo.it
----------------------------------=20



-----Messaggio originale-----
Da: Dean Willis [mailto:dean.willis@softarmor.com]
Inviato: sab 24/11/2007 2.32
A: daniel grotti
Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
Oggetto: Re: R: R: [Sip] a question about IETF draft location conveyance =
09
=20

On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:

> Hi all,
> so why don't emphasize this point in the next draft, saying : =20
> "Proxy server MUST not read messages with "recipient=3Dendpoint" =20
> paramenter setted".
> This is my point of you.
>
>


because from a security standpoint, this prohibition is meaningless. =20
Intermediate nodes can and will read anything that's in plaintext, =20
and SOMEBODY will come up with a rationale, in some context or =20
another, for doing so.

And has been pointed out, doing so does not appear to create a =20
compatibility problem. It doesn't break the protocol. It might defeat =20
security-through-obscurity. It might be rude, or otherwise socially =20
unacceptable. But those don't qualify for a MUST level protocol =20
prohibition.

--
Dean




_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 11:53:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwKjH-0006K8-EQ; Sun, 25 Nov 2007 11:53:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwKjG-0006Je-HK
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 11:53:10 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwKjG-0006H1-5r
	for sip@ietf.org; Sun, 25 Nov 2007 11:53:10 -0500
Received: from qmta09.emeryville.ca.mail.comcast.net ([76.96.30.96])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwKjF-0004af-DH
	for sip@ietf.org; Sun, 25 Nov 2007 11:53:10 -0500
Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52])
	by QMTA09.emeryville.ca.mail.comcast.net with comcast
	id H4JU1Y00117UAYk0A02R00; Sun, 25 Nov 2007 16:53:12 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA13.emeryville.ca.mail.comcast.net with comcast
	id H4tA1Y0010umElk0800000; Sun, 25 Nov 2007 16:53:11 +0000
X-Authority-Analysis: v=1.0 c=1 a=sI1JDbO7msgA:10 a=Zf4c24IlOEAW_Y3B6r4A:9
	a=NzXevNqCVormw29o1mYA:7 a=pvIaKZWDXKmNhUv78eFDABLEzSgA:4
	a=0MAqpqVwYqEA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAPGr6SV018567
	for ; Sun, 25 Nov 2007 11:53:06 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAPGr66n018563;
	Sun, 25 Nov 2007 11:53:06 -0500
Date: Sun, 25 Nov 2007 11:53:06 -0500
Message-Id: <200711251653.lAPGr66n018563@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com>
	(rjsparks@nostrum.com)
Subject: Re: [Sip] SIPit21: BNF future-proofing problem?
References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Robert Sparks 

   The BNF in 3261 says the following:

   extension-header  =  header-name HCOLON header-value
   header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)

   This is intended to be the catch-all field for all future extensions  
   - older parsers working against this BNF shouldn't barf
   when we introduce a new header field.

   Now, we may have new fields in the future that look like:

   NewHeader = new-header-name HCOLON quoted-string

   And down inside quoted-string, we get:

	  quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
	  qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
			    / UTF8-NONASCII
	  quoted-pair  =  "\" (%x00-09 / %x0B-0C
			   / %x0E-7F)

The whole situation is rather icky.  I can see five problems:

1. header-value generates solo UTF8-CONT, the extension bytes of UTF-8
characters, which are the range x80-BF.  Why this is so is unclear --
the syntax cannot generate a solo UTF-8 initial byte which would
govern the extension byte, but the syntax also does not admit the
(single-byte) encodings of a lot of the characters in the ISO-8859-*
character sets, so the syntax does not permit embedding the one-byte
ISO-8859 encodings.  It appears to me that the inclusion of UTF8-CONT
in the production is unintended.

2. quoted-string admits (most of) x00-1F even though extension-header
does not.

3. Since quoted-string is used in many defined headers, we are
already in the position of having defined headers that cannot be
parsed as extension-header as a catch-all mechanism.

4. Given that there is no common character encoding within which all
of these productions can be uniformly interpreted, the only overall
description that can be given of the encoding of SIP headers is
"*OCTET".  And yet SIP headers are not intended to be a binary
protocol.

5. In quoted-string, a backslash is permitted to quote any ASCII
character, but not any Unicode character x80 or higher.  (Despite that
the backslash is not used to quote a solo UTF-8 initial byte.)  This
leads to the peculiar result that some letters used in (e.g.) French
can be preceeded by backslash in quoted-string, but others cannot.

Based on RFC 3261 section 7:

   SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 [7]).

my understanding is that the intention for SIP headers is that they
are sequences of Unicode characters encoded using UTF-8.  I see no
reason to abandon that principle and I've not heard of any instance
where anyone has done so deliberately.

To hold to that principle and clean up the above problems, the BNF
would need to be revised to be:

   extension-header  =  header-name HCOLON header-value
   header-value      =  *(TEXT-UTF8char / LWS)

	  quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
	  qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
			    / UTF8-NONASCII
	  quoted-pair  =  "\" (%x20-7E / UTF8-NONASCII)

or equivalently

	  quoted-pair  =  "\" (SP / TEXT-UTF8char)

Relative to other proposals, in a sense I'm proposing that
extension-header and quoted-string be contracted so that they
coincide, as I think that makes all the rules consistent and
conceptually coherent and does not exclude any current usage.  This
leaves me in the dark why interoperability problems have been seen.
Robert, can you show us some examples?

Dale


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 12:52:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwLee-0005PZ-MF; Sun, 25 Nov 2007 12:52:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwLed-0005PU-Bj
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 12:52:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwLed-0005PM-2G
	for sip@ietf.org; Sun, 25 Nov 2007 12:52:27 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwLeZ-0002xL-Nc
	for sip@ietf.org; Sun, 25 Nov 2007 12:52:27 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 25 Nov 2007 09:52:23 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAPHqNxh008884; 
	Sun, 25 Nov 2007 09:52:23 -0800
Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id lAPHqMB0028854;
	Sun, 25 Nov 2007 17:52:22 GMT
In-Reply-To: <4741BB94.80202@cisco.com>
References: <4741BB94.80202@cisco.com>
Impp: xmpp:cullenfluffyjennings@jabber.org
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
Date: Sun, 25 Nov 2007 09:51:44 -0800
To: IETF SIP List 
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4780; t=1196013143;
	x=1196877143; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20
	|Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20; bh=E2vwSMbZcjAp9jNXi4Jgevttyo4nNHfhEAKMzYTXxBQ=;
	b=LC3lkN+w41UsvjlUiUbOzEeFBKTRnwruv9j6pwxjK+wCZqRrbEhfp2MhdTgCp/hk7GUwxeKr
	9g+1QDTmRiqL9oDDsrs/Vj62l3baJ2nD6PnnpOCjNQwV/5KTex4dbZy+xFK7ueUwp/Wq1Vg4ty
	P8WcEdzkzhV3kSSJRQfW4gfI8=;
Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 19, 2007, at 8:36 AM, Jonathan Rosenberg wrote:

>
> What this means is that when phone numbers are in use, a MITM can  
> easily rewrite the From field. So if it was sip: 
> 9739525060@example.com they can rewrite to sip:9739525060@middle- 
> domain.com, insert a media intermediary and new fingerprint and  
> resign. The called UA or terminating proxy will verify that the  
> identity is valid (which it is) and the called party is presented  
> with the caller ID, which is JUST the phone number. So they don't  
> notice a problem at all.
>
> Thus, in practice, I fear dtls-srtp will easily allow proxies and  
> SBCs on the chain to intercept and modify the media stream, similar  
> to what they could do with sdescriptions. This is really a problem  
> with sip identity itself that carries over here. But I think this  
> issue needs to be mentioned and discussed. The draft makes itself  
> out to be substantially more secu

This gets to exactly the heart of why I think there is no need for  
the  draft-wing-sip-identity-media draft. Let's talk about how trust  
is going to work with phone numbers as identifies (ignoring that it  
is even SIP here).

Say company some phone with the number +1 123 555-1111 makes a call -  
it is at company with a PBX, call them IBM, connect to a telephony  
service provider, call them Sprint, and sends the call to another  
called say AT&T, that hands the call to another company PBX called,  
say Cisco, and we want to assert something about the caller's phone  
number.

There is no practical way for Cisco to know who +1 123 555-1111 was  
allocated to or for that person to prove they can use it. What  
happens is that Cisco has a relationship with AT&T and trust them not  
to deliver correct information. LIkewise AT&T has contracts with some  
people as trusts Sprint. They may not trust every telco they peer  
with in this form but for this example let's say they do trust Sprint  
to correctly not lie if Sprint claims they can verify the number is  
correct. (It's fine for Sprint to pass calls where they do not claim  
to know the number is correct too). Now sprint does know what numbers  
it allocated to IBM and has  contract with IBM so Sprint can decide  
if  +1 123 555-1111 was OK or not.

Now Identity gives us a way to realize all of this that protects from  
attackers modifying things along the chain.  IBM signs and the number  
as IBM and sends on to sprint. Sprint can use this to decide if they  
believe this OK or not along with their policy information. Now if  
sprint thinks it OK, they insert the assertion they think it OK and  
hand to AT&T. AT&T looks at it and decides that it was OK for sprint,  
then it is OK for them and inserts their assertion that it OK and  
hands down to Cisco. Cisco looks for the AT&T assertion and since it  
one of the carriers they trust, decides it is OK.
 As far as I can tell, anything other than this won't work for  
phone numbers . This means that the PBX needs to require that  
the identity it trusts to sign numbers is some it trusts -  
practically this means the one or more carriers that it connects to.  
These carriers need to have their SBC (or proxies if they used  
theses) insert an assertion about if the number is OK or not.

You might think there is something better than this but really it is  
about who owns the namespace. If Sprint decides to give the number +1  
123 555-1111 to some other customer, say Acme, now Cisco needs to  
consider any assertion from IBM that they are 555-1111 to be false.  
The only person that knows there was a change was the namespace  
owner, Sprint in this case.  The number could even be given to a  
different carrier.  This solution is the best we can do given the  
constraints of the namespace allocation process. We can do much  
better with the names like sip:fluffy@cisco.com but that is a  
different topic.

Encrypted media is all constrained by it is no good having encrypted  
media to the attacker and the strength of the security is limited by  
the strength of how well you know who you are talking too. Here the  
DTLS keying fingerprint strength is exactly tied to the identity  
strength. If someone had some other way to knowing who they were  
talking too, such as SAS codes if that worked, then you can use those  
too.

The high point I am trying to make here is that you always have to  
trust whoever controls the namespace and for the case we are  
interested in here for phonenumbers, that implies a certain trust of  
the carriers. This in turn means that the Cisco  PBX in the example  
above needs to reject the signature of a phone number from middle- 
domain.com.



_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 19:12:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwRa5-00052g-Sp; Sun, 25 Nov 2007 19:12:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwRa4-00052b-45
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 19:12:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwRa3-00052T-Qb
	for sip@ietf.org; Sun, 25 Nov 2007 19:12:07 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwRa0-0003Ty-8q
	for sip@ietf.org; Sun, 25 Nov 2007 19:12:07 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lAQ0BxNc011941; 
	Sun, 25 Nov 2007 18:11:59 -0600 (CST)
Received: from [135.244.2.121] (vkg.lra.lucent.com [135.244.2.121])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAQ0Bxj28360; Sun, 25 Nov 2007 18:11:59 -0600 (CST)
Message-ID: <474A0F4E.8040904@alcatel-lucent.com>
Date: Sun, 25 Nov 2007 18:11:58 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Paul Kyzivat 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com> <474500A5.5040605@alcatel-lucent.com>
	<4746FDD7.3020402@cisco.com> <4747338B.8090203@alcatel-lucent.com>
	<47475214.9040003@cisco.com>
In-Reply-To: <47475214.9040003@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:
> Interestingly, doing the DNS lookup for blue.com, and recognizing that 
> you already have a connection from that address would work in this case.

Precisely, and therein lies the problem, right?  example.com
is using one connection to the virtual server to deliver requests
destined for another domain on the same virtual server.

Or are we talking past each other?

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 20:58:17 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwTEZ-00083H-J1; Sun, 25 Nov 2007 20:58:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwTEY-000812-9e
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 20:58:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTEX-00080u-V6
	for sip@ietf.org; Sun, 25 Nov 2007 20:58:02 -0500
Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwTEX-0000es-FM
	for sip@ietf.org; Sun, 25 Nov 2007 20:58:01 -0500
Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43])
	by QMTA01.westchester.pa.mail.comcast.net with comcast
	id HBlq1Y0010vyq2s050Bz00; Mon, 26 Nov 2007 01:58:00 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA05.westchester.pa.mail.comcast.net with comcast
	id HDxz1Y00V0umElk0300000; Mon, 26 Nov 2007 01:58:00 +0000
X-Authority-Analysis: v=1.0 c=1 a=l08YMMoWFoqKhX96NvwA:9
	a=J6aX2YtgzN8lQ-SnCJAA:7 a=f1xHBtnb1mDCJcu3GiEQ09SErf8A:4
	a=3FZX-ydVlcEA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAQ1w0SV025914
	for ; Sun, 25 Nov 2007 20:58:00 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAQ1w0fs025910;
	Sun, 25 Nov 2007 20:58:00 -0500
Date: Sun, 25 Nov 2007 20:58:00 -0500
Message-Id: <200711260158.lAQ1w0fs025910@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <473E020C.2080701@alcatel-lucent.com> (vkg@alcatel-lucent.com)
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>	<200711112208.lABM8xh5016388@dragon.ariadne.com>	<473DCE36.8070105@lucent.com>
	<200711161811.lAGIB6FL007091@dragon.ariadne.com>
	<473E020C.2080701@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Vijay K. Gurbani" 

   > The problem I see is that the table is not labeled as a mataphor; it
   > is described as if its existence is mandatory.  But what the standard
   > will actually prescribe is the *behavior* that is carried out by the
   > example mechanism you are describing; 

   I think you are being too literal about the table; the table itself
   is first described in S5, the opening paragraph of which is: "This
   section is tutorial in nature, and does not specify any normative
   behavior."  Thus, I do not see how one can construe that the existence
   of the table is mandatory.  Furthermore, rfc3261 essentially uses
   the same information in S18, where it talks about "These connections
   are indexed by the tuple formed from the address, port, and transport
   protocol at the far end of the connection."  The table in connect-
   reuse is the same information, albeit in an easy to visualize manner.
   I really do not see the harm.

After thinking about this some more, I'll retract my objection.  In
principle, I think the problem still stands, but this case is simple
enough that no trouble can result.

Do note:  You introduce the table in section 5, which is marked
non-normative.  But you refer to the table 16 times in section 8,
which is marked normative, and furthermore you don't re-introduce the
table or its behavior.  Which, unless I've overlooked something again,
means that the normative section 8 contains a prerequisite reference
to the non-normative section 5.  I think you're going to have to
adjust that.

   >    > The use of "alias descriptor" is unfortunate.  To start with, it is 
   >    > confusing -- initially I mistook it for some sort of identification
   >    > of the row of the alias table.  But the concept of "descriptor" as
   >    > being a small integer identifying a network connection, as well as
   >    > the very term "descriptor", are Unix-specific.
   > 
   >    Anything wrong with that :-) ?
   > 
   > In a standard?

   Sure ... this is the IETF, right?  This protocol specification is
   supposed to be read by programmers who would know what a Unix-
   style file descriptor is.  In fact, if you go back to rfc2543, it
   actually had actual *C code* for demonstrating how to write a forking
   proxy (which I must say was great for understanding forking
   mechanics when I wrote my first forking proxy back in 1998.)  Other
   RFCs also have code and domain-specific nomenclature (see for example
   drafts and RFCs in PKIX, many of which have ASN, BER, DER and other
   encodings and cryptographic language pertinent to and rooted in that
   domain.)

I doubt harm can come from it, but I don't see the Posix programming
model as being one of the background domains for understanding SIP.
Suppose, for example, that one's SIP stack was written in Java...

Dale


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 21:08:44 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwTOs-0007dl-6I; Sun, 25 Nov 2007 21:08:42 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwTOq-0007dN-9w
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 21:08:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTOq-0007dE-0H
	for sip@ietf.org; Sun, 25 Nov 2007 21:08:40 -0500
Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwTOm-0006Ka-HS
	for sip@ietf.org; Sun, 25 Nov 2007 21:08:39 -0500
Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20])
	by QMTA02.emeryville.ca.mail.comcast.net with comcast
	id HDfj1Y0070S2fkC0A02Z00; Mon, 26 Nov 2007 02:08:39 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA09.emeryville.ca.mail.comcast.net with comcast
	id HE8d1Y0020umElk0800000; Mon, 26 Nov 2007 02:08:38 +0000
X-Authority-Analysis: v=1.0 c=1 a=ph5_-uGK9Y3420C7TdkA:9
	a=neGIHHBjwtherv-qUpYA:7 a=cCWkle9aKPO4HuiwxlYtZ98n4NMA:4
	a=Hkcw0gMY5FQA:10 a=4rq7TwIXcRUA:10 a=3FZX-ydVlcEA:10
	a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAQ28XSV026668
	for ; Sun, 25 Nov 2007 21:08:33 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAQ28XKk026664;
	Sun, 25 Nov 2007 21:08:33 -0500
Date: Sun, 25 Nov 2007 21:08:33 -0500
Message-Id: <200711260208.lAQ28XKk026664@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <474A0F4E.8040904@alcatel-lucent.com> (vkg@alcatel-lucent.com)
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com> <474500A5.5040605@alcatel-lucent.com>
	<4746FDD7.3020402@cisco.com> <4747338B.8090203@alcatel-lucent.com>
	<47475214.9040003@cisco.com> <474A0F4E.8040904@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Vijay K. Gurbani" 

   Paul Kyzivat wrote:
   > Interestingly, doing the DNS lookup for blue.com, and recognizing that 
   > you already have a connection from that address would work in this case.

   Precisely, and therein lies the problem, right?  example.com
   is using one connection to the virtual server to deliver requests
   destined for another domain on the same virtual server.

Why would it be a problem?  By hypothesis, that port on that address
must be able to receive and process messages for both domains.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 21:26:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwTgE-0005G4-2N; Sun, 25 Nov 2007 21:26:38 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwTgC-0005Fz-Or
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 21:26:36 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTgC-0005Fr-E7
	for sip@ietf.org; Sun, 25 Nov 2007 21:26:36 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwTgC-0001Lk-0b
	for sip@ietf.org; Sun, 25 Nov 2007 21:26:36 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Sun, 25 Nov 2007 21:26:35 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Sun, 25 Nov 2007 21:26:35 -0500
From: Hadriel Kaplan 
To: "Vijay K. Gurbani" , Paul Kyzivat
	
Date: Sun, 25 Nov 2007 21:26:34 -0500
Subject: RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Topic: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Thread-Index: AcgvwQjLt5LzrJz2TPmTbo1tdAiqrAAENxuw
Message-ID: 
References: 
	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>
	
	<473E220B.7020509@lucent.com>
	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com> <474500A5.5040605@alcatel-lucent.com>
	<4746FDD7.3020402@cisco.com> <4747338B.8090203@alcatel-lucent.com>
	<47475214.9040003@cisco.com> <474A0F4E.8040904@alcatel-lucent.com>
In-Reply-To: <474A0F4E.8040904@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I think you're talking past each other.  Your original statement did not sp=
ecify their listen ports would be different.  If they're not different, ie =
if both domains end up pointing to the same IP+port on the server, then the=
y are the same server, which just happens to be servicing multiple domains,=
 and sending to the same connection is fine.  If they're the same IP but di=
fferent ports, such that SRV resolves example.com to port 5060 and blue.com=
 to 5070, for example, then you shouldn't send to both domains on the same =
connection - because they may well be two different processes, and example.=
com could lie and take over blue.com's requests.

-hadriel

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]
> Sent: Sunday, November 25, 2007 7:12 PM
> To: Paul Kyzivat
> Cc: IETF SIP List
> Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
>
> Paul Kyzivat wrote:
> > Interestingly, doing the DNS lookup for blue.com, and recognizing that
> > you already have a connection from that address would work in this case=
.
>
> Precisely, and therein lies the problem, right?  example.com
> is using one connection to the virtual server to deliver requests
> destined for another domain on the same virtual server.
>
> Or are we talking past each other?
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs
>
>
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 21:47:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwU02-0005HS-5F; Sun, 25 Nov 2007 21:47:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwU00-0005Er-Sf
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 21:47:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwU00-0005Ei-9J
	for sip@ietf.org; Sun, 25 Nov 2007 21:47:04 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwTzx-0007N8-2K
	for sip@ietf.org; Sun, 25 Nov 2007 21:47:04 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Sun, 25 Nov 2007 21:47:00 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Sun, 25 Nov 2007 21:47:00 -0500
From: Hadriel Kaplan 
To: Cullen Jennings , IETF SIP List 
Date: Sun, 25 Nov 2007 21:46:56 -0500
Subject: RE: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Topic: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Index: Acgvi/jMVCpaE9rcRM6r0tL1i50ghwARvoeg
Message-ID: 
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
In-Reply-To: <4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Sunday, November 25, 2007 12:52 PM
> To: IETF SIP List
> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
>
>
> On Nov 19, 2007, at 8:36 AM, Jonathan Rosenberg wrote:
>
> This gets to exactly the heart of why I think there is no need for
> the  draft-wing-sip-identity-media draft. Let's talk about how trust
> is going to work with phone numbers as identifies (ignoring that it
> is even SIP here).

I don't think it does.  The draft is more about real SIP URIs, such as sip:=
fluffy@cisco.com.


> There is no practical way for Cisco to know who +1 123 555-1111 was
> allocated to or for that person to prove they can use it. What
> happens is that Cisco has a relationship with AT&T and trust them not
> to deliver correct information.

I assume you mean "incorrect" information. :)


> Now Identity gives us a way to realize all of this that protects from
> attackers modifying things along the chain.  IBM signs and the number
> as IBM and sends on to sprint. Sprint can use this to decide if they
> believe this OK or not along with their policy information. Now if
> sprint thinks it OK, they insert the assertion they think it OK and
> hand to AT&T. AT&T looks at it and decides that it was OK for sprint,
> then it is OK for them and inserts their assertion that it OK and
> hands down to Cisco. Cisco looks for the AT&T assertion and since it
> one of the carriers they trust, decides it is OK.
>  As far as I can tell, anything other than this won't work for
> phone numbers . This means that the PBX needs to require that
> the identity it trusts to sign numbers is some it trusts -
> practically this means the one or more carriers that it connects to.
> These carriers need to have their SBC (or proxies if they used
> theses) insert an assertion about if the number is OK or not.

This already happens through P-Asserted.  What you describe is hop-by-hop t=
rust of identity, so why would you believe a 4474 signed request by your tr=
usted previous-hop any less than a P-Asserted claim from it?  And what's mo=
re, why would each hop bother with the overhead of 4474 if it can just use =
P-Asserted?  If Cisco was concerned with something between them and AT&T, o=
r AT&T concerned with something between them and Sprint, or Sprint concerne=
d with something between them and IBM, why wouldn't they just use SIP/TLS f=
or those peer connections?  It's less overhead and provides better security=
 for those connections than 4474.

RFC4474's real use-case is one where there is an unchangeable namespace (ie=
, sip:fluffy@cisco.com) and the request crosses multiple domains.  But that=
 is the one use case it will fail at without this draft.

-hadriel


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 22:03:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwUFl-0003hB-QM; Sun, 25 Nov 2007 22:03:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwUFk-0003h3-2U
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 22:03:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUFj-0003gp-Ob
	for sip@ietf.org; Sun, 25 Nov 2007 22:03:19 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IwUFf-0007pB-LP for sip@ietf.org; Sun, 25 Nov 2007 22:03:19 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-3.cisco.com with ESMTP; 25 Nov 2007 19:03:14 -0800
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAQ33E5Q008994
	for ; Sun, 25 Nov 2007 22:03:14 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQ33ExX020132
	for ; Mon, 26 Nov 2007 03:03:14 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 25 Nov 2007 22:03:13 -0500
Received: from [10.86.240.194] ([10.86.240.194]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 25 Nov 2007 22:03:13 -0500
Message-ID: <474A376F.7060102@cisco.com>
Date: Sun, 25 Nov 2007 22:03:11 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Cullen Jennings 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
In-Reply-To: <4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2007 03:03:13.0812 (UTC)
	FILETIME=[E26A5540:01C82FD8]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6692; t=1196046194;
	x=1196910194; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20 |To:=20Cullen=20Jennings=20;
	bh=OqBfyVBilRIZWIm9K7Ethb9/8ih2pJWazrIX9atfiXY=;
	b=IMVuxdy7lp+1v1XlA9F7kSbowHsrbPxZRzSA1WULSJq8JoM6HsojOmsna9B3UTRf4+wm8PkD
	y5fODgC//IeKKGsCifVvlTp7C8JcrIk0Zi7RZv4qf0BHnU3U1TOmgSQ2;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Cullen,

I agree with you that the sort of transitive trust you describe seems 
like a practical approach in many common sorts of deployments.

A fundamental part of this is that the recipient of identity only 
display this in a way that will be interpreted as trustworthy unless it 
indeed has reason to trust the identity. (This is a "duh" but is 
apparently widely violated.)

Earlier in this thread I proposed the idea of generating identity for 
calls from "phone numbers" (represented as TEL URIs) based on the enum 
lookup representation of the phone number. It is just a wild idea that I 
haven't thought through at all, but it might work. In practice it would 
probably mean that you might start with:

     From: "+1-978-555-1234" 

and as a result have a cert for that signed by 
 which in turn would be signed by 
, etc.

(I guess in practice there would be fewer levels of delegation of 
authority than the number of digits.)

That would trade trust in the intermediaries that the call routes 
through for the ones that handle the actual assignments.

That of course depends on the existence of public enum for the identity 
of the caller, which doesn't seem the be a priority when the big 
carriers are involved. But it does seem to be a good complement to the 
sip identity mechanism, for use with phone numbers.

	Thanks,
	Paul

Cullen Jennings wrote:
> 
> On Nov 19, 2007, at 8:36 AM, Jonathan Rosenberg wrote:
> 
>>
>> What this means is that when phone numbers are in use, a MITM can 
>> easily rewrite the From field. So if it was sip:9739525060@example.com 
>> they can rewrite to sip:9739525060@middle-domain.com, insert a media 
>> intermediary and new fingerprint and resign. The called UA or 
>> terminating proxy will verify that the identity is valid (which it is) 
>> and the called party is presented with the caller ID, which is JUST 
>> the phone number. So they don't notice a problem at all.
>>
>> Thus, in practice, I fear dtls-srtp will easily allow proxies and SBCs 
>> on the chain to intercept and modify the media stream, similar to what 
>> they could do with sdescriptions. This is really a problem with sip 
>> identity itself that carries over here. But I think this issue needs 
>> to be mentioned and discussed. The draft makes itself out to be 
>> substantially more secu
> 
> This gets to exactly the heart of why I think there is no need for the  
> draft-wing-sip-identity-media draft. Let's talk about how trust is going 
> to work with phone numbers as identifies (ignoring that it is even SIP 
> here).
> 
> Say company some phone with the number +1 123 555-1111 makes a call - it 
> is at company with a PBX, call them IBM, connect to a telephony service 
> provider, call them Sprint, and sends the call to another called say 
> AT&T, that hands the call to another company PBX called, say Cisco, and 
> we want to assert something about the caller's phone number.
> 
> There is no practical way for Cisco to know who +1 123 555-1111 was 
> allocated to or for that person to prove they can use it. What happens 
> is that Cisco has a relationship with AT&T and trust them not to deliver 
> correct information. LIkewise AT&T has contracts with some people as 
> trusts Sprint. They may not trust every telco they peer with in this 
> form but for this example let's say they do trust Sprint to correctly 
> not lie if Sprint claims they can verify the number is correct. (It's 
> fine for Sprint to pass calls where they do not claim to know the number 
> is correct too). Now sprint does know what numbers it allocated to IBM 
> and has  contract with IBM so Sprint can decide if  +1 123 555-1111 was 
> OK or not.
> 
> Now Identity gives us a way to realize all of this that protects from 
> attackers modifying things along the chain.  IBM signs and the number as 
> IBM and sends on to sprint. Sprint can use this to decide if they 
> believe this OK or not along with their policy information. Now if 
> sprint thinks it OK, they insert the assertion they think it OK and hand 
> to AT&T. AT&T looks at it and decides that it was OK for sprint, then it 
> is OK for them and inserts their assertion that it OK and hands down to 
> Cisco. Cisco looks for the AT&T assertion and since it one of the 
> carriers they trust, decides it is OK.
>  As far as I can tell, anything other than this won't work for 
> phone numbers . This means that the PBX needs to require that the 
> identity it trusts to sign numbers is some it trusts - practically this 
> means the one or more carriers that it connects to. These carriers need 
> to have their SBC (or proxies if they used theses) insert an assertion 
> about if the number is OK or not.
> 
> You might think there is something better than this but really it is 
> about who owns the namespace. If Sprint decides to give the number +1 
> 123 555-1111 to some other customer, say Acme, now Cisco needs to 
> consider any assertion from IBM that they are 555-1111 to be false. The 
> only person that knows there was a change was the namespace owner, 
> Sprint in this case.  The number could even be given to a different 
> carrier.  This solution is the best we can do given the constraints of 
> the namespace allocation process. We can do much better with the names 
> like sip:fluffy@cisco.com but that is a different topic.
> 
> Encrypted media is all constrained by it is no good having encrypted 
> media to the attacker and the strength of the security is limited by the 
> strength of how well you know who you are talking too. Here the DTLS 
> keying fingerprint strength is exactly tied to the identity strength. If 
> someone had some other way to knowing who they were talking too, such as 
> SAS codes if that worked, then you can use those too.
> 
> The high point I am trying to make here is that you always have to trust 
> whoever controls the namespace and for the case we are interested in 
> here for phonenumbers, that implies a certain trust of the carriers. 
> This in turn means that the Cisco  PBX in the example above needs to 
> reject the signature of a phone number from middle-domain.com.
> 
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 22:08:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwUKd-0007DJ-Qh; Sun, 25 Nov 2007 22:08:23 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwUKZ-0007D1-L4
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 22:08:19 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUKY-0007Cl-Vq
	for sip@ietf.org; Sun, 25 Nov 2007 22:08:19 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwUKY-0002Xl-Mj
	for sip@ietf.org; Sun, 25 Nov 2007 22:08:18 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 25 Nov 2007 22:08:18 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAQ38Ipi032028; 
	Sun, 25 Nov 2007 22:08:18 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAQ38IKH000536; 
	Mon, 26 Nov 2007 03:08:18 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 25 Nov 2007 22:08:17 -0500
Received: from [10.86.240.194] ([10.86.240.194]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 25 Nov 2007 22:08:17 -0500
Message-ID: <474A38A0.5080206@cisco.com>
Date: Sun, 25 Nov 2007 22:08:16 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com> <474500A5.5040605@alcatel-lucent.com>
	<4746FDD7.3020402@cisco.com> <4747338B.8090203@alcatel-lucent.com>
	<47475214.9040003@cisco.com> <474A0F4E.8040904@alcatel-lucent.com>
In-Reply-To: <474A0F4E.8040904@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2007 03:08:17.0449 (UTC)
	FILETIME=[9765A990:01C82FD9]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=647; t=1196046498;
	x=1196910498; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20WGLC=3A=20draft-ietf-sip-connect-reuse-08.txt
	|Sender:=20
	|To:=20=22Vijay=20K.=20Gurbani=22=20;
	bh=La8xEyxA99BLo9lUxoQHiBEnLt15eUzebOnlvP0ram8=;
	b=e8JFt1PAvSH5OOg5tbtOY1E4njaN4A/4oTZs6jQYu/s51Je2go6YqDbS0dbsdJ4eQvQovQ++
	P6NkudaOY0x30hmZYByR8Mm83EOLQwgT5+tKZhXjSk5PxfUiV069hUGZ;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Vijay K. Gurbani wrote:
> Paul Kyzivat wrote:
>> Interestingly, doing the DNS lookup for blue.com, and recognizing that 
>> you already have a connection from that address would work in this case.
> 
> Precisely, and therein lies the problem, right?  example.com
> is using one connection to the virtual server to deliver requests
> destined for another domain on the same virtual server.
> 
> Or are we talking past each other?

Perhaps. I guess it depends on your assumptions about how these things 
are demultiplexed. If at the connection level then it is a problem. If 
at the message level then it isn't a problem.

	Paul


_______________________________________________
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



From sip-bounces@ietf.org Sun Nov 25 23:04:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwVCS-0003Z8-5q; Sun, 25 Nov 2007 23:04:00 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwVCR-0003X3-9F
	for sip-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 23:03:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVCQ-0003WJ-RJ
	for sip@ietf.org; Sun, 25 Nov 2007 23:03:58 -0500
Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwVCN-0000mx-HH
	for sip@ietf.org; Sun, 25 Nov 2007 23:03:58 -0500
Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12])
	by QMTA04.westchester.pa.mail.comcast.net with comcast
	id HE8z1Y0070Fqzac0506A00; Mon, 26 Nov 2007 04:03:54 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA08.westchester.pa.mail.comcast.net with comcast
	id HG3u1Y00S0umElk0300000; Mon, 26 Nov 2007 04:03:55 +0000
X-Authority-Analysis: v=1.0 c=1 a=0eejQrQQNob9gvFYIVkA:9
	a=0XNrVcYUq9U7GDi0TsKtJbJdtmwA:4 a=JfD0Fch1gWkA:10
	a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAQ43sSV002635
	for ; Sun, 25 Nov 2007 23:03:54 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAQ43soX002631;
	Sun, 25 Nov 2007 23:03:54 -0500
Date: Sun, 25 Nov 2007 23:03:54 -0500
Message-Id: <200711260403.lAQ43soX002631@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <474A38A0.5080206@cisco.com> (pkyzivat@cisco.com)
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>	
	<4741D470.6030308@alcatel-lucent.com> <4741F132.6060300@cisco.com>
	
	<474367FD.4090800@cisco.com>
	
	<47437A45.40409@cisco.com> <4744AFB8.7030801@lucent.com>
	<4744BF62.3040806@cisco.com> <474500A5.5040605@alcatel-lucent.com>
	<4746FDD7.3020402@cisco.com> <4747338B.8090203@alcatel-lucent.com>
	<47475214.9040003@cisco.com> <474A0F4E.8040904@alcatel-lucent.com>
	<474A38A0.5080206@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Paul Kyzivat 

   Perhaps. I guess it depends on your assumptions about how these things 
   are demultiplexed. If at the connection level then it is a problem. If 
   at the message level then it isn't a problem.

My impression has always been that demultiplexing is done at the
message level.  It seems implicit in the RFC 3263 processes that once
one has resolved the address/port that any connection (with the right
protocol) to that address/port is OK.  In any case, the recipient
would have to see the first message before committing to service only
one domain, as there isn't any other way to tell which domain a new
connection is for.

Which has a derivative problem when setting up TLS that the recipient
doesn't know which domain it needs to provide a certificate for when
the connection is established.  IIRC, someone has proposed a solution
where the recipient presents a certificate that specifies all of the
domains it is authoritative for.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 03:40:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwZUx-00010P-3S; Mon, 26 Nov 2007 03:39:23 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwZUw-00010K-8l
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 03:39:22 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZUv-00010C-To
	for sip@ietf.org; Mon, 26 Nov 2007 03:39:21 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwZUu-0001w3-R9
	for sip@ietf.org; Mon, 26 Nov 2007 03:39:21 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JS30037IUNG52@siemenscomms.co.uk> for sip@ietf.org; Mon,
	26 Nov 2007 08:38:04 +0000 (GMT)
Date: Mon, 26 Nov 2007 08:38:03 +0000
From: "Elwell, John" 
Subject: RE: [Sip] comments on draft-ietf-sip-dtls-framework
In-reply-to: <4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
To: Cullen Jennings , IETF SIP List 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Index: AcgvjgnAhKN2fxFOSSmOuehQXmZ7wwAdcIRQ
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Cullen,

I always thought that user@domain1 and user@domain2 are not equivalent -
each domain has its own namespace for the user part. I am not aware of
anywhere that says this is untrue also for phone numbers. I believe
+123456789@example1.com;user=phone and
+1213456789@example2.com;user=phone are not equivalent. Also I
understand you cannot just take a SIP URI that includes a telephone
number and say that this is equivalent to a TEL URI.  I am not sure
where I got this understanding from, because it does not appear to be in
RFC 3261 - perhaps from an old email thread.

So if somebody submits a request to +123456789@example1.com;user=phone,
it should be routed to domain example1.com, which then will route it to
the user to which it has assigned this identifier. It has nothing to do
with whether domain example1.comn owns the E.164 number +123456789. On
the other hand, if somebody submits a request to TEL:+123456789, then
that should indeed be routed to whoever "owns" that E.164 number, which
may or may not be example.com.

If an originating domain asserts +123456789@example1.com;user=phone, and
that assertion is carried through any intermediate domains to the
destination domain, and if that assertion is backed up by cryptographic
means, then the terminating user can have confidence that the
originating user is in domain example1.com. If media is secured based on
this assertion, the user can be confident that media is secured to/from
a user in example.com. Receiving an assertion from mitm.net (even if
this is a carrier with which the terminating user or his/her
organisation has a contractual relationship), on the other hand, does
not give the terminating user any such confidence that he is talking to
someone in example1.com.

The fact that the request originates at a user in domain example1.com is
the important thing here - whether that domain "owns" E.164 number
+123456789 is unimportant. SIP identity makes no such claim, and such a
claim is not needed in order to obtain the media security properties we
are seeking.

Of course, if a UAS effectively converts such a SIP URI back to a TEL
URI and displays it just as an E.164 number, without displaying the
domain part, this is the root of the problem (as somebody remarked
earlier in this thread). It gives the called user the wrong information.

I thought the whole idea of the dtls-srtp work (and indeed the whole RAI
media security discussions) was to try to find a means of achieving near
end-to-end security for media. If we just blindly trust the next hop
domain, we might as well stick to something like SIPS + Sdescriptions.

John

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com] 
> Sent: 25 November 2007 17:52
> To: IETF SIP List
> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
> 
> 
> On Nov 19, 2007, at 8:36 AM, Jonathan Rosenberg wrote:
> 
> >
> > What this means is that when phone numbers are in use, a MITM can  
> > easily rewrite the From field. So if it was sip: 
> > 9739525060@example.com they can rewrite to sip:9739525060@middle- 
> > domain.com, insert a media intermediary and new fingerprint and  
> > resign. The called UA or terminating proxy will verify that the  
> > identity is valid (which it is) and the called party is presented  
> > with the caller ID, which is JUST the phone number. So they don't  
> > notice a problem at all.
> >
> > Thus, in practice, I fear dtls-srtp will easily allow proxies and  
> > SBCs on the chain to intercept and modify the media stream, 
> similar  
> > to what they could do with sdescriptions. This is really a problem  
> > with sip identity itself that carries over here. But I think this  
> > issue needs to be mentioned and discussed. The draft makes itself  
> > out to be substantially more secu
> 
> This gets to exactly the heart of why I think there is no need for  
> the  draft-wing-sip-identity-media draft. Let's talk about how trust  
> is going to work with phone numbers as identifies (ignoring that it  
> is even SIP here).
> 
> Say company some phone with the number +1 123 555-1111 makes 
> a call -  
> it is at company with a PBX, call them IBM, connect to a telephony  
> service provider, call them Sprint, and sends the call to another  
> called say AT&T, that hands the call to another company PBX called,  
> say Cisco, and we want to assert something about the caller's phone  
> number.
> 
> There is no practical way for Cisco to know who +1 123 555-1111 was  
> allocated to or for that person to prove they can use it. What  
> happens is that Cisco has a relationship with AT&T and trust 
> them not  
> to deliver correct information. LIkewise AT&T has contracts 
> with some  
> people as trusts Sprint. They may not trust every telco they peer  
> with in this form but for this example let's say they do 
> trust Sprint  
> to correctly not lie if Sprint claims they can verify the number is  
> correct. (It's fine for Sprint to pass calls where they do not claim  
> to know the number is correct too). Now sprint does know what 
> numbers  
> it allocated to IBM and has  contract with IBM so Sprint can decide  
> if  +1 123 555-1111 was OK or not.
> 
> Now Identity gives us a way to realize all of this that 
> protects from  
> attackers modifying things along the chain.  IBM signs and 
> the number  
> as IBM and sends on to sprint. Sprint can use this to decide if they  
> believe this OK or not along with their policy information. Now if  
> sprint thinks it OK, they insert the assertion they think it OK and  
> hand to AT&T. AT&T looks at it and decides that it was OK for 
> sprint,  
> then it is OK for them and inserts their assertion that it OK and  
> hands down to Cisco. Cisco looks for the AT&T assertion and since it  
> one of the carriers they trust, decides it is OK.
>  As far as I can tell, anything other than this won't work for  
> phone numbers . This means that the PBX needs to require that  
> the identity it trusts to sign numbers is some it trusts -  
> practically this means the one or more carriers that it connects to.  
> These carriers need to have their SBC (or proxies if they used  
> theses) insert an assertion about if the number is OK or not.
> 
> You might think there is something better than this but really it is  
> about who owns the namespace. If Sprint decides to give the 
> number +1  
> 123 555-1111 to some other customer, say Acme, now Cisco needs to  
> consider any assertion from IBM that they are 555-1111 to be false.  
> The only person that knows there was a change was the namespace  
> owner, Sprint in this case.  The number could even be given to a  
> different carrier.  This solution is the best we can do given the  
> constraints of the namespace allocation process. We can do much  
> better with the names like sip:fluffy@cisco.com but that is a  
> different topic.
> 
> Encrypted media is all constrained by it is no good having encrypted  
> media to the attacker and the strength of the security is limited by  
> the strength of how well you know who you are talking too. Here the  
> DTLS keying fingerprint strength is exactly tied to the identity  
> strength. If someone had some other way to knowing who they were  
> talking too, such as SAS codes if that worked, then you can 
> use those  
> too.
> 
> The high point I am trying to make here is that you always have to  
> trust whoever controls the namespace and for the case we are  
> interested in here for phonenumbers, that implies a certain trust of  
> the carriers. This in turn means that the Cisco  PBX in the example  
> above needs to reject the signature of a phone number from middle- 
> domain.com.
> 
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 07:54:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwdU3-0000Jm-BT; Mon, 26 Nov 2007 07:54:43 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwdU2-0000Jh-Gg
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 07:54:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwdU2-0000JZ-4f
	for sip@ietf.org; Mon, 26 Nov 2007 07:54:42 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwdU1-0007qk-1J
	for sip@ietf.org; Mon, 26 Nov 2007 07:54:42 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 26 Nov 2007 07:54:40 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAQCsePw031729; 
	Mon, 26 Nov 2007 07:54:40 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQCrxxx021707; 
	Mon, 26 Nov 2007 12:54:40 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 07:54:30 -0500
Received: from [10.86.240.194] ([10.86.240.194]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 07:54:29 -0500
Message-ID: <474AC204.9080606@cisco.com>
Date: Mon, 26 Nov 2007 07:54:28 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Elwell, John" 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
References: <4741BB94.80202@cisco.com>	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2007 12:54:29.0937 (UTC)
	FILETIME=[7BD56A10:01C8302B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9494; t=1196081680;
	x=1196945680; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20
	|To:=20=22Elwell,=20John=22=20;
	bh=lRjjlzRWW0L8Y2AmzOSvVWgfKdLRBfIPPqj8743T9CU=;
	b=DyxkVOTl5eJ+K06H8eyENsVHtgI9srTzKRFKAj01N+CCyeNJm7LC3hqn9ZP+TAoUbGt0u8t+
	AYHCa0m2LIvAYfWHfkOn213RMfX4owURG7J+prX/lmnqGN7cE/fW0bhM;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd
Cc: Cullen Jennings , IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

John,

I agree with your analysis. And yet in many contexts there is a strong 
desire to display "phone numbers", because of custom and limitations of 
protocols and devices. So there is a tendency to coerce a sip URI into a 
phone number whenever it looks like that can be done.

I think these two views (your analysis and Cullen's) can coexist in 
certain environments. Specifically, a UA that receives a call with 
sip:+123456789@example1.com as the caller identity can assume this is 
equivalent to TEL:+123456789 *if* it has an agreement with example.com 
that such an equivalence is true. This certainly isn't true in general, 
but may be true in some important cases, expecially when the domain 
belongs to a service provider.

	Thanks,
	Paul

Elwell, John wrote:
> Cullen,
> 
> I always thought that user@domain1 and user@domain2 are not equivalent -
> each domain has its own namespace for the user part. I am not aware of
> anywhere that says this is untrue also for phone numbers. I believe
> +123456789@example1.com;user=phone and
> +1213456789@example2.com;user=phone are not equivalent. Also I
> understand you cannot just take a SIP URI that includes a telephone
> number and say that this is equivalent to a TEL URI.  I am not sure
> where I got this understanding from, because it does not appear to be in
> RFC 3261 - perhaps from an old email thread.
> 
> So if somebody submits a request to +123456789@example1.com;user=phone,
> it should be routed to domain example1.com, which then will route it to
> the user to which it has assigned this identifier. It has nothing to do
> with whether domain example1.comn owns the E.164 number +123456789. On
> the other hand, if somebody submits a request to TEL:+123456789, then
> that should indeed be routed to whoever "owns" that E.164 number, which
> may or may not be example.com.
> 
> If an originating domain asserts +123456789@example1.com;user=phone, and
> that assertion is carried through any intermediate domains to the
> destination domain, and if that assertion is backed up by cryptographic
> means, then the terminating user can have confidence that the
> originating user is in domain example1.com. If media is secured based on
> this assertion, the user can be confident that media is secured to/from
> a user in example.com. Receiving an assertion from mitm.net (even if
> this is a carrier with which the terminating user or his/her
> organisation has a contractual relationship), on the other hand, does
> not give the terminating user any such confidence that he is talking to
> someone in example1.com.
> 
> The fact that the request originates at a user in domain example1.com is
> the important thing here - whether that domain "owns" E.164 number
> +123456789 is unimportant. SIP identity makes no such claim, and such a
> claim is not needed in order to obtain the media security properties we
> are seeking.
> 
> Of course, if a UAS effectively converts such a SIP URI back to a TEL
> URI and displays it just as an E.164 number, without displaying the
> domain part, this is the root of the problem (as somebody remarked
> earlier in this thread). It gives the called user the wrong information.
> 
> I thought the whole idea of the dtls-srtp work (and indeed the whole RAI
> media security discussions) was to try to find a means of achieving near
> end-to-end security for media. If we just blindly trust the next hop
> domain, we might as well stick to something like SIPS + Sdescriptions.
> 
> John
> 
>> -----Original Message-----
>> From: Cullen Jennings [mailto:fluffy@cisco.com] 
>> Sent: 25 November 2007 17:52
>> To: IETF SIP List
>> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
>>
>>
>> On Nov 19, 2007, at 8:36 AM, Jonathan Rosenberg wrote:
>>
>>> What this means is that when phone numbers are in use, a MITM can  
>>> easily rewrite the From field. So if it was sip: 
>>> 9739525060@example.com they can rewrite to sip:9739525060@middle- 
>>> domain.com, insert a media intermediary and new fingerprint and  
>>> resign. The called UA or terminating proxy will verify that the  
>>> identity is valid (which it is) and the called party is presented  
>>> with the caller ID, which is JUST the phone number. So they don't  
>>> notice a problem at all.
>>>
>>> Thus, in practice, I fear dtls-srtp will easily allow proxies and  
>>> SBCs on the chain to intercept and modify the media stream, 
>> similar  
>>> to what they could do with sdescriptions. This is really a problem  
>>> with sip identity itself that carries over here. But I think this  
>>> issue needs to be mentioned and discussed. The draft makes itself  
>>> out to be substantially more secu
>> This gets to exactly the heart of why I think there is no need for  
>> the  draft-wing-sip-identity-media draft. Let's talk about how trust  
>> is going to work with phone numbers as identifies (ignoring that it  
>> is even SIP here).
>>
>> Say company some phone with the number +1 123 555-1111 makes 
>> a call -  
>> it is at company with a PBX, call them IBM, connect to a telephony  
>> service provider, call them Sprint, and sends the call to another  
>> called say AT&T, that hands the call to another company PBX called,  
>> say Cisco, and we want to assert something about the caller's phone  
>> number.
>>
>> There is no practical way for Cisco to know who +1 123 555-1111 was  
>> allocated to or for that person to prove they can use it. What  
>> happens is that Cisco has a relationship with AT&T and trust 
>> them not  
>> to deliver correct information. LIkewise AT&T has contracts 
>> with some  
>> people as trusts Sprint. They may not trust every telco they peer  
>> with in this form but for this example let's say they do 
>> trust Sprint  
>> to correctly not lie if Sprint claims they can verify the number is  
>> correct. (It's fine for Sprint to pass calls where they do not claim  
>> to know the number is correct too). Now sprint does know what 
>> numbers  
>> it allocated to IBM and has  contract with IBM so Sprint can decide  
>> if  +1 123 555-1111 was OK or not.
>>
>> Now Identity gives us a way to realize all of this that 
>> protects from  
>> attackers modifying things along the chain.  IBM signs and 
>> the number  
>> as IBM and sends on to sprint. Sprint can use this to decide if they  
>> believe this OK or not along with their policy information. Now if  
>> sprint thinks it OK, they insert the assertion they think it OK and  
>> hand to AT&T. AT&T looks at it and decides that it was OK for 
>> sprint,  
>> then it is OK for them and inserts their assertion that it OK and  
>> hands down to Cisco. Cisco looks for the AT&T assertion and since it  
>> one of the carriers they trust, decides it is OK.
>>  As far as I can tell, anything other than this won't work for  
>> phone numbers . This means that the PBX needs to require that  
>> the identity it trusts to sign numbers is some it trusts -  
>> practically this means the one or more carriers that it connects to.  
>> These carriers need to have their SBC (or proxies if they used  
>> theses) insert an assertion about if the number is OK or not.
>>
>> You might think there is something better than this but really it is  
>> about who owns the namespace. If Sprint decides to give the 
>> number +1  
>> 123 555-1111 to some other customer, say Acme, now Cisco needs to  
>> consider any assertion from IBM that they are 555-1111 to be false.  
>> The only person that knows there was a change was the namespace  
>> owner, Sprint in this case.  The number could even be given to a  
>> different carrier.  This solution is the best we can do given the  
>> constraints of the namespace allocation process. We can do much  
>> better with the names like sip:fluffy@cisco.com but that is a  
>> different topic.
>>
>> Encrypted media is all constrained by it is no good having encrypted  
>> media to the attacker and the strength of the security is limited by  
>> the strength of how well you know who you are talking too. Here the  
>> DTLS keying fingerprint strength is exactly tied to the identity  
>> strength. If someone had some other way to knowing who they were  
>> talking too, such as SAS codes if that worked, then you can 
>> use those  
>> too.
>>
>> The high point I am trying to make here is that you always have to  
>> trust whoever controls the namespace and for the case we are  
>> interested in here for phonenumbers, that implies a certain trust of  
>> the carriers. This in turn means that the Cisco  PBX in the example  
>> above needs to reject the signature of a phone number from middle- 
>> domain.com.
>>
>>
>>
>> _______________________________________________
>> 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
>>
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 09:28:38 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwewj-0008Rq-Rn; Mon, 26 Nov 2007 09:28:25 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwewi-0008Re-Af
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:28:24 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwewh-0008RT-Vv
	for sip@ietf.org; Mon, 26 Nov 2007 09:28:24 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwewh-0001by-Gd
	for sip@ietf.org; Mon, 26 Nov 2007 09:28:23 -0500
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAQES1an005649; 
	Mon, 26 Nov 2007 08:28:17 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 08:28:10 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 15:28:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: R: R: [Sip] a question about IETF draft location conveyance 09
Date: Mon, 26 Nov 2007 15:28:10 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918001974BEC@DEEXC1U01.de.lucent.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: R: [Sip] a question about IETF draft location conveyance 09
Thread-Index: AcguOftcpiqOEOUgQ9WPkSnSiLbCzAAU0NU1AGqxJPA=
References: <4742BDF5.9040302@unibo.it>						<4745BDC7.30003@gmx.net>
	
From: "DRAGE, Keith \(Keith\)" 
To: "daniel grotti" ,
	"Dean Willis" 
X-OriginalArrivalTime: 26 Nov 2007 14:28:07.0454 (UTC)
	FILETIME=[90227BE0:01C83038]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: IETF SIP List , "James M. Polk" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

This just seems to me to be an inappropriate change of RFC 2119 =
language.=20

If we really mean either of these, then we should be specifying that the =
message is encrypted in the first place.

What we probably mean is something informative (because we cannot make a =
normative statement on what applications do with the data), stating that =
usage of the message so tagged is inappropriate because the sender did =
not intend it to be used for this purpose.

Regards

Keith

> -----Original Message-----
> From: daniel grotti [mailto:daniel.grotti@unibo.it]=20
> Sent: Saturday, November 24, 2007 11:38 AM
> To: Dean Willis
> Cc: IETF SIP List; James M. Polk
> Subject: R: R: R: [Sip] a question about IETF draft location=20
> conveyance 09
>=20
> I know.=20
> May be SHOULD NOT instead MUST NOT could be better.
>=20
> daniel
>=20
>=20
> ----------------------------------
>        Daniel  Grotti
> D.E.I.S. - University of Bologna
> ----------------------------------
>        Via Venezia, 52
>   47023 Cesena (FC) - ITALY
> ----------------------------------
> e-mail: daniel.grotti@unibo.it
> ----------------------------------=20
>=20
>=20
>=20
> -----Messaggio originale-----
> Da: Dean Willis [mailto:dean.willis@softarmor.com]
> Inviato: sab 24/11/2007 2.32
> A: daniel grotti
> Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
> Oggetto: Re: R: R: [Sip] a question about IETF draft location=20
> conveyance 09
> =20
>=20
> On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:
>=20
> > Hi all,
> > so why don't emphasize this point in the next draft, saying : =20
> > "Proxy server MUST not read messages with "recipient=3Dendpoint" =20
> > paramenter setted".
> > This is my point of you.
> >
> >
>=20
>=20
> because from a security standpoint, this prohibition is meaningless. =20
> Intermediate nodes can and will read anything that's in=20
> plaintext, and SOMEBODY will come up with a rationale, in=20
> some context or another, for doing so.
>=20
> And has been pointed out, doing so does not appear to create=20
> a compatibility problem. It doesn't break the protocol. It=20
> might defeat security-through-obscurity. It might be rude, or=20
> otherwise socially unacceptable. But those don't qualify for=20
> a MUST level protocol prohibition.
>=20
> --
> Dean
>=20
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 11:52:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwhBt-0000A6-Mb; Mon, 26 Nov 2007 11:52:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwhBs-0008WK-9T
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:52:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhBr-0008V4-V7
	for sip@ietf.org; Mon, 26 Nov 2007 11:52:11 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhBm-0003HC-8l
	for sip@ietf.org; Mon, 26 Nov 2007 11:52:11 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAQGpvFs068227
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 26 Nov 2007 10:51:57 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <200711231731.lANHVE4Z028135@dragon.ariadne.com>
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>
	
	
	<200711231731.lANHVE4Z028135@dragon.ariadne.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
Date: Mon, 26 Nov 2007 10:51:52 -0600
To: Dale.Worley@comcast.net
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4926/Mon Nov 26 07:21:22 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dale -

What you quoted talks about what the offer can _send_.
It doesn't talk about what the offerer must be willing to receive  
(nor does it constrain what the answerer can send).

RjS

On Nov 23, 2007, at 11:31 AM, Dale.Worley@comcast.net wrote:

>    From: Robert Sparks 
>
>    On Nov 23, 2007, at 5:12 AM, Christer Holmberg wrote:
>> AFTER he has received the answer he may accept only what both
>> parties have indicated support for.
>
>    I don't think that's right. Can you show me the text that supports
>    that claim?
>
> Here's section 7 of RFC 3264 (found by Ernst Horvath):
>
> 7 Offerer Processing of the Answer
>
>    When the offerer receives the answer, it MAY send media on the
>    accepted stream(s) (assuming it is listed as sendrecv or  
> recvonly in
>    the answer).  It MUST send using a media format listed in the  
> answer,
>    and it SHOULD use the first media format listed in the answer  
> when it
>    does send.
>
>       The reason this is a SHOULD, and not a MUST (its also a SHOULD,
>       and not a MUST, for the answerer), is because there will
>       oftentimes be a need to change codecs on the fly.  For example,
>       during silence periods, an agent might like to switch to a  
> comfort
>       noise codec.  Or, if the user presses a number on the keypad,  
> the
>       agent might like to send that using RFC 2833 [9].  Congestion
>       control might necessitate changing to a lower rate codec  
> based on
>       feedback.
>
>    The offerer SHOULD send media according to the value of any  
> ptime and
>    bandwidth attribute in the answer.
>
>    The offerer MAY immediately cease listening for media formats that
>    were listed in the initial offer, but not present in the answer.
>
> I skimmed draft-ietf-sipping-sip-offeranswer-04 and I see nothing in
> it that would alter the interpretation of this section.
>
> Dale
>
>
> _______________________________________________
> 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



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 12:34:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwhqv-0001JN-Cr; Mon, 26 Nov 2007 12:34:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwhqt-0001Dw-Dy
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:34:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhqt-0001Dm-2Q
	for sip@ietf.org; Mon, 26 Nov 2007 12:34:35 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwhqs-00081r-D2
	for sip@ietf.org; Mon, 26 Nov 2007 12:34:34 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 26 Nov 2007 12:34:34 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAQHYYnn001042; 
	Mon, 26 Nov 2007 12:34:34 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAQHYGKr014394; 
	Mon, 26 Nov 2007 17:34:34 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 12:34:28 -0500
Received: from [161.44.174.179] ([161.44.174.179]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 12:34:27 -0500
Message-ID: <474B03A3.2040406@cisco.com>
Date: Mon, 26 Nov 2007 12:34:27 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Robert Sparks 
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>			<200711231731.lANHVE4Z028135@dragon.ariadne.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2007 17:34:27.0674 (UTC)
	FILETIME=[9810ABA0:01C83052]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5176; t=1196098474;
	x=1196962474; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20SIPit=2021=20=3A=20Topics=20that=20attendees=
	20argued=20about |Sender:=20
	|To:=20Robert=20Sparks=20;
	bh=XFdQIBXPhvE7ltKAj6wE4goE058jX/fjkOpgjPbEu0U=;
	b=gwMpv2NmGr+9dTuJYGeLUcAI98ftOGchdGNs0VqcDHqiUOyqyv57S55zVhZfTUzFt1lnLfi2
	uBSMbP9DGAM2KjGiwcdvCEMuFSLO2blNo66dZ7aeaAX/xIGY0cd5+nui;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Robert Sparks wrote:
> Dale -
> 
> What you quoted talks about what the offer can _send_.

The second sentence says what format the offerer MUST use when sending. 
A corollary of that is that it MUST NOT use some other format. And a 
corollary of *that* is that the answerer MUST be prepared to receive any 
of the formats listed in the answer, and MAY NOT be prepared to receive 
any other format.

Note that this apparently includes formats listed in the answer but not 
in the offer! So if the offerer is capable of using any of the "extra" 
formats listed in the answer (which the answerer has no way of knowing) 
then it may go ahead and use those.

> It doesn't talk about what the offerer must be willing to receive (nor 
> does it constrain what the answerer can send).

Yes, you are right - it doesn't.

Section 5.1 says:

    ... If multiple formats are listed, it
    means that the offerer is capable of making use of any of those
    formats during the session.  In other words, the answerer MAY change
    formats in the middle of the session, making use of any of the
    formats listed, without sending a new offer. ...

That certainly at least *implies* that the offerer MUST initially be 
capable of receiving any format listed in the offer.

Then Section 6.1 says:

    Once the answerer has sent the answer, it MUST be prepared to receive
    media for any recvonly streams described by that answer.  It MUST be
    prepared to send and receive media for any sendrecv streams in the
    answer, and it MAY send media immediately.  The answerer MUST be
    prepared to receive media for recvonly or sendrecv streams using any
    media formats listed for those streams in the answer, and it MAY send
    media immediately.  When sending media, it SHOULD use a packetization
    interval equal to the value of the ptime attribute in the offer, if
    any was present.  It SHOULD send media using a bandwidth no higher
    than the value of the bandwidth attribute in the offer, if any was
    present.  The answerer MUST send using a media format in the offer
    that is also listed in the answer, and SHOULD send using the most
    preferred media format in the offer that is also listed in the
    answer.  In the case of RTP, it MUST use the payload type numbers
    from the offer, even if they differ from those in the answer.

*This* says that the answerer is constrained to send on a format in the 
intersection of the offer and the answer. So the offerer must be 
prepared to receive everything it offers initially, and then it can 
*reduce* what it expects and is capable of receiving once it receives 
the answer.

	Thanks,
	Paul


> RjS
> 
> On Nov 23, 2007, at 11:31 AM, Dale.Worley@comcast.net wrote:
> 
>>    From: Robert Sparks 
>>
>>    On Nov 23, 2007, at 5:12 AM, Christer Holmberg wrote:
>>> AFTER he has received the answer he may accept only what both
>>> parties have indicated support for.
>>
>>    I don't think that's right. Can you show me the text that supports
>>    that claim?
>>
>> Here's section 7 of RFC 3264 (found by Ernst Horvath):
>>
>> 7 Offerer Processing of the Answer
>>
>>    When the offerer receives the answer, it MAY send media on the
>>    accepted stream(s) (assuming it is listed as sendrecv or recvonly in
>>    the answer).  It MUST send using a media format listed in the answer,
>>    and it SHOULD use the first media format listed in the answer when it
>>    does send.
>>
>>       The reason this is a SHOULD, and not a MUST (its also a SHOULD,
>>       and not a MUST, for the answerer), is because there will
>>       oftentimes be a need to change codecs on the fly.  For example,
>>       during silence periods, an agent might like to switch to a comfort
>>       noise codec.  Or, if the user presses a number on the keypad, the
>>       agent might like to send that using RFC 2833 [9].  Congestion
>>       control might necessitate changing to a lower rate codec based on
>>       feedback.
>>
>>    The offerer SHOULD send media according to the value of any ptime and
>>    bandwidth attribute in the answer.
>>
>>    The offerer MAY immediately cease listening for media formats that
>>    were listed in the initial offer, but not present in the answer.
>>
>> I skimmed draft-ietf-sipping-sip-offeranswer-04 and I see nothing in
>> it that would alter the interpretation of this section.
>>
>> Dale
>>
>>
>> _______________________________________________
>> 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
> 
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 13:07:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwiMe-0002q1-Ra; Mon, 26 Nov 2007 13:07:24 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwiMe-0002pw-7Y
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 13:07:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiMd-0002pj-UE
	for sip@ietf.org; Mon, 26 Nov 2007 13:07:23 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IwiMa-00073D-KC for sip@ietf.org; Mon, 26 Nov 2007 13:07:23 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-2.cisco.com with ESMTP; 26 Nov 2007 10:07:20 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAQI7Kdp009762; 
	Mon, 26 Nov 2007 10:07:20 -0800
Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAQI6ib6003249;
	Mon, 26 Nov 2007 18:07:19 GMT
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
Impp: xmpp:cullenfluffyjennings@jabber.org
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Cullen Jennings 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
Date: Mon, 26 Nov 2007 10:06:48 -0800
To: "Elwell, John" 
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1091; t=1196100440;
	x=1196964440; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20
	|Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20; bh=TeOJo2ctvLZNGnjNvtZ6it2z+HlXEhZnvxpHHxCdL44=;
	b=D80a/vKR6YOSr3xlMZKZHVpTIl9cvPnx9yBpf2YUPbPfwOCkW8xBShmZE5VtrZUv2Ootevjs
	0FOXovIovfu921jaSMUGPOqj168CPN6kv6y/D1Zdf0TOSGsljgk6hRZ2;
Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


I should reply to whole thread but out of time right now .... agree  
with lost of what was said ...

On Nov 26, 2007, at 12:38 AM, Elwell, John wrote:

> I always thought that user@domain1 and user@domain2 are not  
> equivalent -
> each domain has its own namespace for the user part. I

Yes, agree with this. This does not however stop a domain from having  
a policy that user names that start with + are E.164 numbers (or some  
some similar policy such as names that start with a digit are dial  
strings of some sort). Now a domain that takes a E.164 number as a  
user name and goes to route that to another domain that it peers with  
needs to understand something about the policy of the next domain.  
Should it use a tel, should it use a sip uri and have a + in front of  
it, etc. But there is nothing wrong with domains having policy about  
how they map user names to telephone numbers and nothing wrong about  
them understanding the policies of other domains they peer with. I  
think all of this is very commonly done in deployed systems today.

  


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 14:44:20 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwjsJ-0004uW-Nb; Mon, 26 Nov 2007 14:44:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwjsJ-0004uR-4O
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:44:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjsI-0004uB-87
	for sip@ietf.org; Mon, 26 Nov 2007 14:44:10 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwjsG-0001Q2-2b
	for sip@ietf.org; Mon, 26 Nov 2007 14:44:10 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAQJi5ui000535; 
	Mon, 26 Nov 2007 13:44:05 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAQJi0j02558; Mon, 26 Nov 2007 13:44:05 -0600 (CST)
Message-ID: <474B21FF.2010203@alcatel-lucent.com>
Date: Mon, 26 Nov 2007 13:43:59 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan , Paul Kyzivat 
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>		<4741D470.6030308@alcatel-lucent.com>
	<4741F132.6060300@cisco.com>		<474367FD.4090800@cisco.com>		<47437A45.40409@cisco.com>
	<4744AFB8.7030801@lucent.com>	<4744BF62.3040806@cisco.com>
	<474500A5.5040605@alcatel-lucent.com>	<4746FDD7.3020402@cisco.com>
	<4747338B.8090203@alcatel-lucent.com>	<47475214.9040003@cisco.com>
	<474A0F4E.8040904@alcatel-lucent.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hadriel Kaplan wrote:
> I think you're talking past each other.  Your original statement did
>  not specify their listen ports would be different.

Yes, Hadriel is accurate in pointing that out.

> If they're not different, ie if both domains end up pointing to the 
> same IP+port on the server, then they are the same server, which just
> happens to be servicing multiple domains, and sending to the same 
> connection is fine.

...but fraught with peril, though.  Technically this is feasible,
because there is enough information in the signaling to allow
routing to the right virtual server (I think.)  HTTP uses the Host
header to allow the virtual server to distinguish different
domains.  The SIP equivalent is the domain name in the R-URI or
topmost Route header; the domain in one of these URIs should point
to the right virtual domain.

Now, whether we should be actively encouraging this over TCP is
another question.  Note that over TLS, we do not.  That is,
if red.com opens a TLS connection to example.com, then red.com's
identity (sip:red.com) is saved in the alias table.  Thus,
when example.com sends a request to blue.com, even though
rfc3263 resolution will result in the same IP+port, the earlier
connection will not be reused because the identity does not
match (i.e., sip:red.com != sip:blue.com).

> If they're the same IP but different ports, such that SRV resolves
> example.com to port 5060 and blue.com to 5070, for example, then you
   ^^^^^^^^^^^ red.com
> shouldn't send to both domains on the same connection - because they
> may well be two different processes, and example.com could lie and
                                            ^^^^^^^^^^^ red.com
> take over blue.com's requests.

Right.  That is what I was worried about.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 14:44:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwjsZ-0005Bo-0P; Mon, 26 Nov 2007 14:44:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwjsV-00058g-I9
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:44:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjsU-00056y-WE
	for sip@ietf.org; Mon, 26 Nov 2007 14:44:23 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwjsU-0003In-IQ
	for sip@ietf.org; Mon, 26 Nov 2007 14:44:22 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAQJiLRj000850; 
	Mon, 26 Nov 2007 13:44:21 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAQJiLj02738; Mon, 26 Nov 2007 13:44:21 -0600 (CST)
Message-ID: <474B2214.1050304@lucent.com>
Date: Mon, 26 Nov 2007 13:44:20 -0600
From: "Vijay K. Gurbani" 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>	<200711112208.lABM8xh5016388@dragon.ariadne.com>	<473DCE36.8070105@lucent.com>	<200711161811.lAGIB6FL007091@dragon.ariadne.com>	<473E020C.2080701@alcatel-lucent.com>
	<200711260158.lAQ1w0fs025910@dragon.ariadne.com>
In-Reply-To: <200711260158.lAQ1w0fs025910@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dale.Worley@comcast.net wrote:
> After thinking about this some more, I'll retract my objection.  In
> principle, I think the problem still stands, but this case is simple
> enough that no trouble can result.
> 
> Do note:  You introduce the table in section 5, which is marked
> non-normative.  But you refer to the table 16 times in section 8,
> which is marked normative, and furthermore you don't re-introduce the
> table or its behavior.  Which, unless I've overlooked something again,
> means that the normative section 8 contains a prerequisite reference
> to the non-normative section 5.  I think you're going to have to
> adjust that.

OK; that is reasonable.

> I doubt harm can come from it, but I don't see the Posix programming
> model as being one of the background domains for understanding SIP.
> Suppose, for example, that one's SIP stack was written in Java...

Why, convert it to C/C++, of course ;-)  But seriously, I will
add some text equating the alias descriptor to connection objects
found in other languages.

Thanks, Dale.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 14:44:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwjsg-0005Oq-L9; Mon, 26 Nov 2007 14:44:34 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwjsc-0005OS-Ni
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:44:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjsc-0005OK-Dy
	for sip@ietf.org; Mon, 26 Nov 2007 14:44:30 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwjsa-0001Qc-3S
	for sip@ietf.org; Mon, 26 Nov 2007 14:44:30 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lAQJiQNX000951; 
	Mon, 26 Nov 2007 13:44:26 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAQJiQj02781; Mon, 26 Nov 2007 13:44:26 -0600 (CST)
Message-ID: <474B221A.6020607@lucent.com>
Date: Mon, 26 Nov 2007 13:44:26 -0600
From: "Vijay K. Gurbani" 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>		<4741D470.6030308@alcatel-lucent.com>
	<4741F132.6060300@cisco.com>		<474367FD.4090800@cisco.com>		<47437A45.40409@cisco.com>
	<4744AFB8.7030801@lucent.com>	<4744BF62.3040806@cisco.com>
	<474500A5.5040605@alcatel-lucent.com>	<4746FDD7.3020402@cisco.com>
	<4747338B.8090203@alcatel-lucent.com>	<47475214.9040003@cisco.com>
	<474A0F4E.8040904@alcatel-lucent.com>	<474A38A0.5080206@cisco.com>
	<200711260403.lAQ43soX002631@dragon.ariadne.com>
In-Reply-To: <200711260403.lAQ43soX002631@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dale.Worley@comcast.net wrote:
> Which has a derivative problem when setting up TLS that the recipient
> doesn't know which domain it needs to provide a certificate for when
> the connection is established.  IIRC, someone has proposed a solution
> where the recipient presents a certificate that specifies all of the
> domains it is authoritative for.

With the TLS extended hello (rfc3546) this is no longer a problem.
In an extended hello, the client can include the "server_name"
extension to allow the server to present the right certificate.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 15:17:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwkOU-00018g-UW; Mon, 26 Nov 2007 15:17:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwkOT-00018Q-78
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 15:17:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkOS-00018I-OL
	for sip@ietf.org; Mon, 26 Nov 2007 15:17:24 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwkOR-00040E-UQ
	for sip@ietf.org; Mon, 26 Nov 2007 15:17:24 -0500
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lAQKHJNx079445
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 26 Nov 2007 14:17:19 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <474B03A3.2040406@cisco.com>
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>			<200711231731.lANHVE4Z028135@dragon.ariadne.com>
	
	<474B03A3.2040406@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0D9987D7-DB05-4231-86B6-DDB62B0F760E@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
Subject: Summary of "what answerer can send" thread (was Re: [Sip] SIPit 21 :
	Topics that attendees argued about)
Date: Mon, 26 Nov 2007 14:17:15 -0600
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4928/Mon Nov 26 12:10:39 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Ok - I think we've found the necessary chunks of text needed to put  
this part of the thread down.

My introduction of the thread had a wrong conclusion in it (per 3254  
6.1).

To re-summarize:

If an m-line in the offer offers codecs A, B, and C then until all  
possible answers are received (think forking),
the offerer must be prepared to receive RTP containing A, B, or C.  
After each answer (again remember forking),
that answerer MUST only send RTP packets using the codecs that are in  
the intersection of the offer and the answer
for that m-line. So, for instance, if that m-line in the answer  
contained only B, the answerer can only send B. Once it's
received the answer, the offerer can decide to only render B, but due  
to race conditions it should anticipate seeing some
A or C coded packets, but nobody should expect it to do anything  
useful with them.

Now we need to find where to put pointers to this so that it  isn't  
so hard for implementers in the future to find.

RjS

On Nov 26, 2007, at 11:34 AM, Paul Kyzivat wrote:

>
>
> Robert Sparks wrote:
>> Dale -
>> What you quoted talks about what the offer can _send_.
>
> The second sentence says what format the offerer MUST use when  
> sending. A corollary of that is that it MUST NOT use some other  
> format. And a corollary of *that* is that the answerer MUST be  
> prepared to receive any of the formats listed in the answer, and  
> MAY NOT be prepared to receive any other format.
>
> Note that this apparently includes formats listed in the answer but  
> not in the offer! So if the offerer is capable of using any of the  
> "extra" formats listed in the answer (which the answerer has no way  
> of knowing) then it may go ahead and use those.
>
>> It doesn't talk about what the offerer must be willing to receive  
>> (nor does it constrain what the answerer can send).
>
> Yes, you are right - it doesn't.
>
> Section 5.1 says:
>
>    ... If multiple formats are listed, it
>    means that the offerer is capable of making use of any of those
>    formats during the session.  In other words, the answerer MAY  
> change
>    formats in the middle of the session, making use of any of the
>    formats listed, without sending a new offer. ...
>
> That certainly at least *implies* that the offerer MUST initially  
> be capable of receiving any format listed in the offer.
>
> Then Section 6.1 says:
>
>    Once the answerer has sent the answer, it MUST be prepared to  
> receive
>    media for any recvonly streams described by that answer.  It  
> MUST be
>    prepared to send and receive media for any sendrecv streams in the
>    answer, and it MAY send media immediately.  The answerer MUST be
>    prepared to receive media for recvonly or sendrecv streams using  
> any
>    media formats listed for those streams in the answer, and it MAY  
> send
>    media immediately.  When sending media, it SHOULD use a  
> packetization
>    interval equal to the value of the ptime attribute in the offer, if
>    any was present.  It SHOULD send media using a bandwidth no higher
>    than the value of the bandwidth attribute in the offer, if any was
>    present.  The answerer MUST send using a media format in the offer
>    that is also listed in the answer, and SHOULD send using the most
>    preferred media format in the offer that is also listed in the
>    answer.  In the case of RTP, it MUST use the payload type numbers
>    from the offer, even if they differ from those in the answer.
>
> *This* says that the answerer is constrained to send on a format in  
> the intersection of the offer and the answer. So the offerer must  
> be prepared to receive everything it offers initially, and then it  
> can *reduce* what it expects and is capable of receiving once it  
> receives the answer.
>
> 	Thanks,
> 	Paul
>
>
>> RjS
>> On Nov 23, 2007, at 11:31 AM, Dale.Worley@comcast.net wrote:
>>>    From: Robert Sparks 
>>>
>>>    On Nov 23, 2007, at 5:12 AM, Christer Holmberg wrote:
>>>> AFTER he has received the answer he may accept only what both
>>>> parties have indicated support for.
>>>
>>>    I don't think that's right. Can you show me the text that  
>>> supports
>>>    that claim?
>>>
>>> Here's section 7 of RFC 3264 (found by Ernst Horvath):
>>>
>>> 7 Offerer Processing of the Answer
>>>
>>>    When the offerer receives the answer, it MAY send media on the
>>>    accepted stream(s) (assuming it is listed as sendrecv or  
>>> recvonly in
>>>    the answer).  It MUST send using a media format listed in the  
>>> answer,
>>>    and it SHOULD use the first media format listed in the answer  
>>> when it
>>>    does send.
>>>
>>>       The reason this is a SHOULD, and not a MUST (its also a  
>>> SHOULD,
>>>       and not a MUST, for the answerer), is because there will
>>>       oftentimes be a need to change codecs on the fly.  For  
>>> example,
>>>       during silence periods, an agent might like to switch to a  
>>> comfort
>>>       noise codec.  Or, if the user presses a number on the  
>>> keypad, the
>>>       agent might like to send that using RFC 2833 [9].  Congestion
>>>       control might necessitate changing to a lower rate codec  
>>> based on
>>>       feedback.
>>>
>>>    The offerer SHOULD send media according to the value of any  
>>> ptime and
>>>    bandwidth attribute in the answer.
>>>
>>>    The offerer MAY immediately cease listening for media formats  
>>> that
>>>    were listed in the initial offer, but not present in the answer.
>>>
>>> I skimmed draft-ietf-sipping-sip-offeranswer-04 and I see nothing in
>>> it that would alter the interpretation of this section.
>>>
>>> Dale
>>>
>>>
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 15:33:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwkeJ-0004SE-JS; Mon, 26 Nov 2007 15:33:47 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwkeI-0004S9-JA
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 15:33:46 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkeI-0004S1-7g
	for sip@ietf.org; Mon, 26 Nov 2007 15:33:46 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwkeH-0004LV-B0
	for sip@ietf.org; Mon, 26 Nov 2007 15:33:46 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 26 Nov 2007 15:33:45 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAQKXiM6025062; 
	Mon, 26 Nov 2007 15:33:44 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQKXZxf003035; 
	Mon, 26 Nov 2007 20:33:44 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 15:33:40 -0500
Received: from [161.44.174.179] ([161.44.174.179]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 15:33:39 -0500
Message-ID: <474B2DA2.8090803@cisco.com>
Date: Mon, 26 Nov 2007 15:33:38 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Robert Sparks 
Subject: Re: Summary of "what answerer can send" thread (was Re: [Sip] SIPit
	21 : Topics that attendees argued about)
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>			<200711231731.lANHVE4Z028135@dragon.ariadne.com>
	
	<474B03A3.2040406@cisco.com>
	<0D9987D7-DB05-4231-86B6-DDB62B0F760E@nostrum.com>
In-Reply-To: <0D9987D7-DB05-4231-86B6-DDB62B0F760E@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2007 20:33:39.0641 (UTC)
	FILETIME=[A0BCA290:01C8306B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6827; t=1196109224;
	x=1196973224; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20Summary=20of=20=22what=20answerer=20can=20send=22=20t
	hread=20(was=20Re=3A=20[Sip]=20SIPit=0A=2021=20=3A=20Topics=20that=20atten
	dees=20argued=20about) |Sender:=20
	|To:=20Robert=20Sparks=20;
	bh=kOLma1qLDq63Vmb8lO0Zt2/EGKogcEBHdQSrFjE2CBw=;
	b=WDEJhI4mbyyv05MOejldbDzaU5OClKXMDJaTDG8XaYIxQO/2K21YVJsk+DpV0kw6D3efHjoi
	ZaayItBot57ZssTMxOLWZo4D7TOrvEXcrkzmgUazNIuXogqlTkNCtDGB;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Cc: sip@ietf.org, Takuya Sawada 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I think this would fit nicely as a new section of 
draft-ietf-sipping-sip-offeranswer-xx. (Probably between the existing 
sections 5 and 6.) But that has already completed wglc, so adding an 
entirely new section may be problematic.

	Paul

Robert Sparks wrote:
> Ok - I think we've found the necessary chunks of text needed to put this 
> part of the thread down.
> 
> My introduction of the thread had a wrong conclusion in it (per 3254 6.1).
> 
> To re-summarize:
> 
> If an m-line in the offer offers codecs A, B, and C then until all 
> possible answers are received (think forking),
> the offerer must be prepared to receive RTP containing A, B, or C. After 
> each answer (again remember forking),
> that answerer MUST only send RTP packets using the codecs that are in 
> the intersection of the offer and the answer
> for that m-line. So, for instance, if that m-line in the answer 
> contained only B, the answerer can only send B. Once it's
> received the answer, the offerer can decide to only render B, but due to 
> race conditions it should anticipate seeing some
> A or C coded packets, but nobody should expect it to do anything useful 
> with them.
> 
> Now we need to find where to put pointers to this so that it  isn't so 
> hard for implementers in the future to find.
> 
> RjS
> 
> On Nov 26, 2007, at 11:34 AM, Paul Kyzivat wrote:
> 
>>
>>
>> Robert Sparks wrote:
>>> Dale -
>>> What you quoted talks about what the offer can _send_.
>>
>> The second sentence says what format the offerer MUST use when 
>> sending. A corollary of that is that it MUST NOT use some other 
>> format. And a corollary of *that* is that the answerer MUST be 
>> prepared to receive any of the formats listed in the answer, and MAY 
>> NOT be prepared to receive any other format.
>>
>> Note that this apparently includes formats listed in the answer but 
>> not in the offer! So if the offerer is capable of using any of the 
>> "extra" formats listed in the answer (which the answerer has no way of 
>> knowing) then it may go ahead and use those.
>>
>>> It doesn't talk about what the offerer must be willing to receive 
>>> (nor does it constrain what the answerer can send).
>>
>> Yes, you are right - it doesn't.
>>
>> Section 5.1 says:
>>
>>    ... If multiple formats are listed, it
>>    means that the offerer is capable of making use of any of those
>>    formats during the session.  In other words, the answerer MAY change
>>    formats in the middle of the session, making use of any of the
>>    formats listed, without sending a new offer. ...
>>
>> That certainly at least *implies* that the offerer MUST initially be 
>> capable of receiving any format listed in the offer.
>>
>> Then Section 6.1 says:
>>
>>    Once the answerer has sent the answer, it MUST be prepared to receive
>>    media for any recvonly streams described by that answer.  It MUST be
>>    prepared to send and receive media for any sendrecv streams in the
>>    answer, and it MAY send media immediately.  The answerer MUST be
>>    prepared to receive media for recvonly or sendrecv streams using any
>>    media formats listed for those streams in the answer, and it MAY send
>>    media immediately.  When sending media, it SHOULD use a packetization
>>    interval equal to the value of the ptime attribute in the offer, if
>>    any was present.  It SHOULD send media using a bandwidth no higher
>>    than the value of the bandwidth attribute in the offer, if any was
>>    present.  The answerer MUST send using a media format in the offer
>>    that is also listed in the answer, and SHOULD send using the most
>>    preferred media format in the offer that is also listed in the
>>    answer.  In the case of RTP, it MUST use the payload type numbers
>>    from the offer, even if they differ from those in the answer.
>>
>> *This* says that the answerer is constrained to send on a format in 
>> the intersection of the offer and the answer. So the offerer must be 
>> prepared to receive everything it offers initially, and then it can 
>> *reduce* what it expects and is capable of receiving once it receives 
>> the answer.
>>
>>     Thanks,
>>     Paul
>>
>>
>>> RjS
>>> On Nov 23, 2007, at 11:31 AM, Dale.Worley@comcast.net wrote:
>>>>    From: Robert Sparks 
>>>>
>>>>    On Nov 23, 2007, at 5:12 AM, Christer Holmberg wrote:
>>>>> AFTER he has received the answer he may accept only what both
>>>>> parties have indicated support for.
>>>>
>>>>    I don't think that's right. Can you show me the text that supports
>>>>    that claim?
>>>>
>>>> Here's section 7 of RFC 3264 (found by Ernst Horvath):
>>>>
>>>> 7 Offerer Processing of the Answer
>>>>
>>>>    When the offerer receives the answer, it MAY send media on the
>>>>    accepted stream(s) (assuming it is listed as sendrecv or recvonly in
>>>>    the answer).  It MUST send using a media format listed in the 
>>>> answer,
>>>>    and it SHOULD use the first media format listed in the answer 
>>>> when it
>>>>    does send.
>>>>
>>>>       The reason this is a SHOULD, and not a MUST (its also a SHOULD,
>>>>       and not a MUST, for the answerer), is because there will
>>>>       oftentimes be a need to change codecs on the fly.  For example,
>>>>       during silence periods, an agent might like to switch to a 
>>>> comfort
>>>>       noise codec.  Or, if the user presses a number on the keypad, the
>>>>       agent might like to send that using RFC 2833 [9].  Congestion
>>>>       control might necessitate changing to a lower rate codec based on
>>>>       feedback.
>>>>
>>>>    The offerer SHOULD send media according to the value of any ptime 
>>>> and
>>>>    bandwidth attribute in the answer.
>>>>
>>>>    The offerer MAY immediately cease listening for media formats that
>>>>    were listed in the initial offer, but not present in the answer.
>>>>
>>>> I skimmed draft-ietf-sipping-sip-offeranswer-04 and I see nothing in
>>>> it that would alter the interpretation of this section.
>>>>
>>>> Dale
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 16:02:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwl6O-00079O-8d; Mon, 26 Nov 2007 16:02:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwl6N-00079J-Kg
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 16:02:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwl6N-00079B-B9
	for sip@ietf.org; Mon, 26 Nov 2007 16:02:47 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Iwl6J-0003Cm-7w for sip@ietf.org; Mon, 26 Nov 2007 16:02:47 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-3.cisco.com with ESMTP; 26 Nov 2007 13:02:42 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAQL2gDi031326; 
	Mon, 26 Nov 2007 13:02:42 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lAQL2c0W010956;
	Mon, 26 Nov 2007 21:02:38 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 13:02:37 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.113.135]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 13:02:37 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 26 Nov 2007 15:02:35 -0600
To: "DRAGE, Keith \(Keith\)" ,
	"daniel grotti" ,
	"Dean Willis" 
From: "James M. Polk" 
Subject: RE: R: R: [Sip] a question about IETF draft location
  conveyance 09
In-Reply-To: <5D1A7985295922448D5550C94DE2918001974BEC@DEEXC1U01.de.luce
	nt.com>
References: <4742BDF5.9040302@unibo.it>
	
	
	
	
	
	
	
	<4745BDC7.30003@gmx.net>
	
	
	
	<5D1A7985295922448D5550C94DE2918001974BEC@DEEXC1U01.de.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 26 Nov 2007 21:02:37.0376 (UTC)
	FILETIME=[AC81F400:01C8306F]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4860; t=1196110962;
	x=1196974962; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20RE=3A=20R=3A=20R=3A=20[Sip]=20a=20question=20about=20IETF=20d
	raft=20location=0A=20=20conveyance=2009 |Sender:=20;
	bh=K+eAVr0BSIGgZA2mWT7Yyw1efQV1zKunubCXp0jSZiM=;
	b=kl7O2qvLvOYmjB/Km/PxSp+2YwL1Ds4THGmPz/i9NjouNYjl6Y8rMtH6LQFYwOMJQoyNaUdD
	IzwjGVHAAdke23Ivv8nHqD0e67S9HkN3uSOm4xmeH3qV5xaicmM9mDG3uJYnhWNQ/5qvbS5QI1
	BgsAOt56SKjeTWAH6nl5DTX6I=;
Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

This also gets back to one of my original points, does SIP expect a 
UAC to understand the topology of a message's path to the ultimate destination?

Is Ted's intent of the "recipient=endpoint" parameter to prevent 
proxies from reading location in a message *and* a "recipient=server" 
parameter to prevent endpoints from reading location in a message?

Does the UAC always know that there are only proxies between it and 
the destination UAS?

Does the UAC always understand a particular message does or does not 
need to be routed based on the location within the request?

Emergency services is an example of, always allow proxy routing when 
the UAC knows this is an emergency request.  But will this be true 
for all applications of location conveyance in the (relatively 
near-term) future?  I'm not so sure.

The UAC has a mechanism for making location not readable by proxies 
if it doesn't want them to, use encryption e2e.  But this has 
interesting properties in at least one case, the a user calls the 
nearest Pizza Hut.

A UAC can encrypt its location in the first INVITE, but if Pizza Hut 
has a national or regional number, that routes on the location of the 
caller, the message will probably return a 493 (undecipherable).

Does the UAC then send location to PizzaHut.com unencrypted, knowing 
this is required to get the INVITE to the right store?

There are other usages of this, other than Pizza Hut.

Does anyone have a suggestion for informative text that can address 
each of these two (or more) situations?

At the moment, all text around "recipient=" is suggestive, and not 
definitive, because of what Dean says below.

That said, I could put something in like "unless a future standards 
track RFC says otherwise, the use of "recipient=" parameter within 
any locationValue is informative in nature", thus leaving the door 
open for ECRIT's phoneBCP doc to refine usage in the emergency 
context, as well as any other service defining document to do the 
same type of refinement.

James

At 08:28 AM 11/26/2007, DRAGE, Keith \(Keith\) wrote:
>This just seems to me to be an inappropriate change of RFC 2119 language.
>
>If we really mean either of these, then we should be specifying that 
>the message is encrypted in the first place.
>
>What we probably mean is something informative (because we cannot 
>make a normative statement on what applications do with the data), 
>stating that usage of the message so tagged is inappropriate because 
>the sender did not intend it to be used for this purpose.
>
>Regards
>
>Keith
>
> > -----Original Message-----
> > From: daniel grotti [mailto:daniel.grotti@unibo.it]
> > Sent: Saturday, November 24, 2007 11:38 AM
> > To: Dean Willis
> > Cc: IETF SIP List; James M. Polk
> > Subject: R: R: R: [Sip] a question about IETF draft location
> > conveyance 09
> >
> > I know.
> > May be SHOULD NOT instead MUST NOT could be better.
> >
> > daniel
> >
> >
> > ----------------------------------
> >        Daniel  Grotti
> > D.E.I.S. - University of Bologna
> > ----------------------------------
> >        Via Venezia, 52
> >   47023 Cesena (FC) - ITALY
> > ----------------------------------
> > e-mail: daniel.grotti@unibo.it
> > ----------------------------------
> >
> >
> >
> > -----Messaggio originale-----
> > Da: Dean Willis [mailto:dean.willis@softarmor.com]
> > Inviato: sab 24/11/2007 2.32
> > A: daniel grotti
> > Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
> > Oggetto: Re: R: R: [Sip] a question about IETF draft location
> > conveyance 09
> >
> >
> > On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:
> >
> > > Hi all,
> > > so why don't emphasize this point in the next draft, saying :
> > > "Proxy server MUST not read messages with "recipient=endpoint"
> > > paramenter setted".
> > > This is my point of you.
> > >
> > >
> >
> >
> > because from a security standpoint, this prohibition is meaningless.
> > Intermediate nodes can and will read anything that's in
> > plaintext, and SOMEBODY will come up with a rationale, in
> > some context or another, for doing so.
> >
> > And has been pointed out, doing so does not appear to create
> > a compatibility problem. It doesn't break the protocol. It
> > might defeat security-through-obscurity. It might be rude, or
> > otherwise socially unacceptable. But those don't qualify for
> > a MUST level protocol prohibition.
> >
> > --
> > Dean
> >
> >
> >
> >
> > _______________________________________________
> > 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
> >


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 16:24:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwlRb-0004ug-Ps; Mon, 26 Nov 2007 16:24:43 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwlRa-0004uV-PW
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 16:24:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlRa-0004uK-Fw
	for sip@ietf.org; Mon, 26 Nov 2007 16:24:42 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwlRW-000527-K2
	for sip@ietf.org; Mon, 26 Nov 2007 16:24:42 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JS40029GU51HT@siemenscomms.co.uk> for sip@ietf.org; Mon,
	26 Nov 2007 21:24:37 +0000 (GMT)
Date: Mon, 26 Nov 2007 21:24:35 +0000
From: "Elwell, John" 
Subject: RE: [Sip] comments on draft-ietf-sip-dtls-framework
In-reply-to: 
To: Cullen Jennings 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441BFA@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Index: AcgwVzGitt1o8ANpTPG+Y7d4LgrhzAAG2oSw
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Cullen,

I agree, of course, that this is common practice.

John=20

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]=20
> Sent: 26 November 2007 18:07
> To: Elwell, John
> Cc: IETF SIP List
> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
>=20
>=20
> I should reply to whole thread but out of time right now .... agree =20
> with lost of what was said ...
>=20
> On Nov 26, 2007, at 12:38 AM, Elwell, John wrote:
>=20
> > I always thought that user@domain1 and user@domain2 are not =20
> > equivalent -
> > each domain has its own namespace for the user part. I
>=20
> Yes, agree with this. This does not however stop a domain=20
> from having =20
> a policy that user names that start with + are E.164 numbers=20
> (or some =20
> some similar policy such as names that start with a digit are dial =20
> strings of some sort). Now a domain that takes a E.164 number as a =20
> user name and goes to route that to another domain that it=20
> peers with =20
> needs to understand something about the policy of the next domain. =20
> Should it use a tel, should it use a sip uri and have a + in=20
> front of =20
> it, etc. But there is nothing wrong with domains having policy about =20
> how they map user names to telephone numbers and nothing wrong about =20
> them understanding the policies of other domains they peer with. I =20
> think all of this is very commonly done in deployed systems today.
>=20
>  =20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 17:08:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwm89-0003Eg-2G; Mon, 26 Nov 2007 17:08:41 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwm87-0003EZ-Q2
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 17:08:39 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwm87-0003ER-DZ
	for sip@ietf.org; Mon, 26 Nov 2007 17:08:39 -0500
Received: from mx12.bbn.com ([128.33.0.81])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwm86-000531-D7
	for sip@ietf.org; Mon, 26 Nov 2007 17:08:39 -0500
Received: from mail.bbn.com ([128.33.1.19])
	by mx12.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1Iwm7w-0004gk-6K; Mon, 26 Nov 2007 17:08:29 -0500
Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1])
	by mail.bbn.com with esmtp (Exim 4.67)
	(envelope-from )
	id 1Iwm7w-0006zB-Vq; Mon, 26 Nov 2007 17:08:28 -0500
Message-ID: <474B4364.60609@bbn.com>
Date: Mon, 26 Nov 2007 17:06:28 -0500
From: Matt Lepinski 
Organization: BBN
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "James M. Polk" 
Subject: Re: R: R: [Sip] a question about IETF draft location  conveyance
 09
References: <4742BDF5.9040302@unibo.it>								<4745BDC7.30003@gmx.net>				<5D1A7985295922448D5550C94DE2918001974BEC@DEEXC1U01.de.lucent.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
Cc: IETF SIP List , "DRAGE,
	Keith \(Keith\)" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

James,

I do believe that the intent of Ted (as well as others in the GEOPRIV 
working group, including myself) is that if a UAC specifies 
"recipient=endpoint" then a compliant proxy will not 'read' the location 
body. In particular, "recipient=endpoint" indicates that a SIP proxy in 
the signaling path does not have permission to store the location (or 
any derived information) for longer than is necessary to forward the SIP 
message and does not have permission to send the location to any third 
party (for any reason including location-based routing) other than the 
next-hop SIP proxy. That is, the intent of "recipient=endpoint" that if 
a call requires location-based routing in order to succeed, then the 
call should fail.

Personally, I believe (and I think this is a point Ted was trying to 
make) that a UAC must have a way to indicate that a location is to be 
read by the endpoint and no one else. This goes back to RFC 3693 which 
dictates that a target must have a way of articulating privacy rules and 
that using protocols must enforce those rules. In particular, see 
requirements 7, 10 and 11 in RFC 3693. (Note that RFC 3693 explicitly 
makes an exception for the emergency case, and so this discussion is in 
the context of non-emergency conveyance of location information ... e.g. 
Pizza Hut.)

(Also note: there is always the issue that a malicious proxy might not 
obey the wishes expressed by the UAC, but SIP is an architecture in 
which there is implicit trust by the UAC that the proxy acting on his 
behave properly and comply with all relevant specifications. 
Implications of the SIP trust model are a topic for another thread ... 
See for example:  
http://www1.ietf.org/mail-archive/web/sip/current/msg20319.html)

Clearly, there are many mechanisms that satisfy the desideratum that a 
target be able to indicate that its location is to be read only by the 
SIP endpoint. For example, this desire could be encoded as a privacy 
rule within the PIDF-LO and each SIP proxy could parse the privacy rules 
in a PIDF-LO to determine the target's intent. Alternatively, a 
location-by-value could be encrypted end-to-end; or location could be 
conveyed by-reference using an LIS with certificate-based access 
controls. The GEOPRIV working group discussed various mechanisms last 
May (See the thread beginning with: 
http://www1.ietf.org/mail-archive/web/geopriv/current/msg03521.html) and 
I believe there was rough consensus that the "recipient=endpoint" 
mechanism described in the current conveyance draft was the best 
mechanism for achieving the above desideratum.

This seems to leave us with three options going forward:

1) Deny the UAC the opertunity to indicate that location is to be read 
only by the SIP endpoint. (That is, declare that SIP is not a GEOPRIV 
using protocol in sense of RFC 3693).

2) Revisit the mechanism discussion and attempt to reach consensus on a 
better mechanism for indicating that location is to be read only by the 
SIP endpoint.

3) Craft text explaining that when the "recipient=endpoint" parameter is 
used that a compliant SIP proxy is not to 'read' the location 
information. (Note that this text should also indicate that when 
"recipient=endpoint" is used that calls requiring location-based routing 
will fail, and thus should only be used when call failure is preferred 
over disclosure of location information to a routing entity.)

- Matt Lepinski


James M. Polk wrote:

> This also gets back to one of my original points, does SIP expect a 
> UAC to understand the topology of a message's path to the ultimate 
> destination?
>
> Is Ted's intent of the "recipient=endpoint" parameter to prevent 
> proxies from reading location in a message *and* a "recipient=server" 
> parameter to prevent endpoints from reading location in a message?
>
> Does the UAC always know that there are only proxies between it and 
> the destination UAS?
>
> Does the UAC always understand a particular message does or does not 
> need to be routed based on the location within the request?
>
> Emergency services is an example of, always allow proxy routing when 
> the UAC knows this is an emergency request.  But will this be true for 
> all applications of location conveyance in the (relatively near-term) 
> future?  I'm not so sure.
>
> The UAC has a mechanism for making location not readable by proxies if 
> it doesn't want them to, use encryption e2e.  But this has interesting 
> properties in at least one case, the a user calls the nearest Pizza Hut.
>
> A UAC can encrypt its location in the first INVITE, but if Pizza Hut 
> has a national or regional number, that routes on the location of the 
> caller, the message will probably return a 493 (undecipherable).
>
> Does the UAC then send location to PizzaHut.com unencrypted, knowing 
> this is required to get the INVITE to the right store?
>
> There are other usages of this, other than Pizza Hut.
>
> Does anyone have a suggestion for informative text that can address 
> each of these two (or more) situations?
>
> At the moment, all text around "recipient=" is suggestive, and not 
> definitive, because of what Dean says below.
>
> That said, I could put something in like "unless a future standards 
> track RFC says otherwise, the use of "recipient=" parameter within any 
> locationValue is informative in nature", thus leaving the door open 
> for ECRIT's phoneBCP doc to refine usage in the emergency context, as 
> well as any other service defining document to do the same type of 
> refinement.
>
> James
>
> At 08:28 AM 11/26/2007, DRAGE, Keith \(Keith\) wrote:
>
>> This just seems to me to be an inappropriate change of RFC 2119 
>> language.
>>
>> If we really mean either of these, then we should be specifying that 
>> the message is encrypted in the first place.
>>
>> What we probably mean is something informative (because we cannot 
>> make a normative statement on what applications do with the data), 
>> stating that usage of the message so tagged is inappropriate because 
>> the sender did not intend it to be used for this purpose.
>>
>> Regards
>>
>> Keith
>>
>> > -----Original Message-----
>> > From: daniel grotti [mailto:daniel.grotti@unibo.it]
>> > Sent: Saturday, November 24, 2007 11:38 AM
>> > To: Dean Willis
>> > Cc: IETF SIP List; James M. Polk
>> > Subject: R: R: R: [Sip] a question about IETF draft location
>> > conveyance 09
>> >
>> > I know.
>> > May be SHOULD NOT instead MUST NOT could be better.
>> >
>> > daniel
>> >
>> >
>> > ----------------------------------
>> >        Daniel  Grotti
>> > D.E.I.S. - University of Bologna
>> > ----------------------------------
>> >        Via Venezia, 52
>> >   47023 Cesena (FC) - ITALY
>> > ----------------------------------
>> > e-mail: daniel.grotti@unibo.it
>> > ----------------------------------
>> >
>> >
>> >
>> > -----Messaggio originale-----
>> > Da: Dean Willis [mailto:dean.willis@softarmor.com]
>> > Inviato: sab 24/11/2007 2.32
>> > A: daniel grotti
>> > Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
>> > Oggetto: Re: R: R: [Sip] a question about IETF draft location
>> > conveyance 09
>> >
>> >
>> > On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:
>> >
>> > > Hi all,
>> > > so why don't emphasize this point in the next draft, saying :
>> > > "Proxy server MUST not read messages with "recipient=endpoint"
>> > > paramenter setted".
>> > > This is my point of you.
>> > >
>> > >
>> >
>> >
>> > because from a security standpoint, this prohibition is meaningless.
>> > Intermediate nodes can and will read anything that's in
>> > plaintext, and SOMEBODY will come up with a rationale, in
>> > some context or another, for doing so.
>> >
>> > And has been pointed out, doing so does not appear to create
>> > a compatibility problem. It doesn't break the protocol. It
>> > might defeat security-through-obscurity. It might be rude, or
>> > otherwise socially unacceptable. But those don't qualify for
>> > a MUST level protocol prohibition.
>> >
>> > --
>> > Dean
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>> >
>
>
>
> _______________________________________________
> 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
>




_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 19:20:15 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwoBC-00033v-Tx; Mon, 26 Nov 2007 19:19:58 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwoBB-00033g-Dj
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:19:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoBB-00033Y-49
	for sip@ietf.org; Mon, 26 Nov 2007 19:19:57 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwoB8-0007E1-K5
	for sip@ietf.org; Mon, 26 Nov 2007 19:19:57 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 26 Nov 2007 16:19:54 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAR0Jshh004819; 
	Mon, 26 Nov 2007 16:19:54 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAR0JevG008588;
	Tue, 27 Nov 2007 00:19:53 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 16:19:50 -0800
Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 16:19:50 -0800
Message-ID: <474B62C7.6050604@cisco.com>
Date: Mon, 26 Nov 2007 19:20:23 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Paul Kyzivat 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
References: <4741BB94.80202@cisco.com>	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
	<474AC204.9080606@cisco.com>
In-Reply-To: <474AC204.9080606@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Nov 2007 00:19:50.0123 (UTC)
	FILETIME=[395FDBB0:01C8308B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1511; t=1196122794;
	x=1196986794; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20; bh=wy+naldqeq7wFGs8hmuYUaemwF7IfxJ5YD1ZuZBpKvw=;
	b=Qrl7XnDcuaYjY7V+DUP/6uvWts1lR3Zp0Lw72CPZvkCAFsvFCKNzd/AkpzwziIw2cHQhAm9T
	Wn0CdUIPAcN1I6GB4EwMov5MyIh1ZW6zlg6jS7+YQjspes3wLBtNF985;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: Cullen Jennings , IETF SIP List , "Elwell,
	John" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

inline:

Paul Kyzivat wrote:
> John,
> 
> I agree with your analysis. And yet in many contexts there is a strong 
> desire to display "phone numbers", because of custom and limitations of 
> protocols and devices. So there is a tendency to coerce a sip URI into a 
> phone number whenever it looks like that can be done.

Its more than a rendering problem. The identifier is meaningful for 
security because the person on the receiving end of the call can tie it 
to user - the one that they know has been assigned this identifier. And 
thus, they can be assured that, when they answer the phone, they know 
the user that is calling (let us put aside issues when someone else uses 
  my phone to make calls).

The root issue is that FUNDAMENTALLY, phone numbers are not scoped 
within a domain. For this reason, the mapping that exists in peoples 
heads from identifiers to users is of one of two forms:

"user@domain" --> some person
"1 (408) 902-5000" ---> some person

so, even if you user interface could render the fact that, the call was 
from sip:14089025000@somedomain.com, I believe that users would anyway 
ignore the domain part since there is no domain part for phone numbers.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 19:21:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwoD3-00047s-4C; Mon, 26 Nov 2007 19:21:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwoD2-00047m-4Z
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:21:52 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoD1-00047d-Oh
	for sip@ietf.org; Mon, 26 Nov 2007 19:21:51 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwoD0-00010i-7o
	for sip@ietf.org; Mon, 26 Nov 2007 19:21:51 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-3.cisco.com with ESMTP; 26 Nov 2007 16:21:49 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAR0LnEA006727; 
	Mon, 26 Nov 2007 16:21:49 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAR0Lnb4021680;
	Tue, 27 Nov 2007 00:21:49 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 16:21:49 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.113.135]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 16:21:48 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 26 Nov 2007 18:21:47 -0600
To: Matt Lepinski 
From: "James M. Polk" 
Subject: Re: R: R: [Sip] a question about IETF draft location conveyance 09
In-Reply-To: <474B4364.60609@bbn.com>
References: <4742BDF5.9040302@unibo.it>
	
	
	
	
	
	
	
	<4745BDC7.30003@gmx.net>
	
	
	
	<5D1A7985295922448D5550C94DE2918001974BEC@DEEXC1U01.de.lucent.com>
	
	<474B4364.60609@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 27 Nov 2007 00:21:48.0624 (UTC)
	FILETIME=[8001AD00:01C8308B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12182; t=1196122909;
	x=1196986909; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20R=3A=20R=3A=20[Sip]=20a=20question=20about=20IETF=20d
	raft=20location=20=0A=20=20conveyance=2009 |Sender:=20;
	bh=JmryrIBrTpXNsEBDAlUvB31um08e28WtVXNAazAc++o=;
	b=DijqrQVNNbTtPSuSe+FNNMDoW296zK1Ku+RvgUi83925kkOfcCORbP4EzhyiDysKis9dN5ex
	cP1Rk9m93M7F0VBkRD2QIjnvEDPHAog5b5pUL+BOwnOroKQjLAgpNo3r;
Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e
Cc: IETF SIP List , "DRAGE,
	Keith \(Keith\)" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Matt

in-line

At 04:06 PM 11/26/2007, Matt Lepinski wrote:
>James,
>
>I do believe that the intent of Ted (as well as others in the 
>GEOPRIV working group, including myself) is that if a UAC specifies 
>"recipient=endpoint" then a compliant proxy will not 'read' the location body.

Why isn't the message body not encrypted to make sure the Proxy doesn't?

What about the situation in which there are multiple proxies between 
Alice and Bob, but only one will do anything good with the 
location.  What is "recipient=" set to, to ensure only the good proxy 
reads the location body, and the no-so-good proxies obey the 
parameter and don't look at the location?

>In particular, "recipient=endpoint" indicates that a SIP proxy in 
>the signaling path does not have permission to store the location 
>(or any derived information) for longer than is necessary to forward 
>the SIP message and does not have permission to send the location to 
>any third party (for any reason including location-based routing) 
>other than the next-hop SIP proxy.

The RFC4119 defined PIDF-LO  element (section 
2.2.2) covers this already, for any proxy that reads the message 
body. Why does this also need to be in a SIP header parameter?

What you describe above is a proxy that receives a SIP request, uses 
location (without sending it to anywhere else) to determine its next 
SIP hop, and forwards the message. Yet, this isn't the scenario you 
want, is it?

>That is, the intent of "recipient=endpoint" that if a call requires 
>location-based routing in order to succeed, then the call should fail.

With what error?

-09 defines lots of errors, but not one for this type of error - in 
which the UAC knows how to correct it in a subsequent message it 
doesn't want to fail for the same reason.

What is the SIP response, for that matter? It is not a timeout 
message, and it is not a server refusal message.  Is it simply a 400?

That said, if there is not a Geolocation-Error code, the UAC is blind 
as to what to do.


>Personally, I believe (and I think this is a point Ted was trying to 
>make) that a UAC must have a way to indicate that a location is to 
>be read by the endpoint and no one else.

See, I think this is covered by SIP with the use of message body 
encryption, or in 4119 with a  element set to "no".

>This goes back to RFC 3693 which dictates that a target must have a 
>way of articulating privacy rules and that using protocols must 
>enforce those rules.

-09 states the usage-rules of 3693 are to be maintained, and the 
 element set to "no" addresses this, IMO.

>In particular, see requirements 7, 10 and 11 in RFC 3693. (Note that 
>RFC 3693 explicitly makes an exception for the emergency case, and 
>so this discussion is in the context of non-emergency conveyance of 
>location information ... e.g. Pizza Hut.)

fair, but know that I'm a co-author of 3693, and I'm the one who put 
in the exception for the emergency case text in that RFC.


>(Also note: there is always the issue that a malicious proxy might 
>not obey the wishes expressed by the UAC, but SIP is an architecture 
>in which there is implicit trust by the UAC that the proxy acting on 
>his behave properly and comply with all relevant specifications. 
>Implications of the SIP trust model are a topic for another thread 
>... See for example:
>http://www1.ietf.org/mail-archive/web/sip/current/msg20319.html)
>
>Clearly, there are many mechanisms that satisfy the desideratum that 
>a target be able to indicate that its location is to be read only by 
>the SIP endpoint.

yeah, encryption ensure this, a header parameter doesn't.

>For example, this desire could be encoded as a privacy rule within 
>the PIDF-LO and each SIP proxy could parse the privacy rules in a 
>PIDF-LO to determine the target's intent.

that has been discussed previously, and is the URI that is in the 
optional "ruleset-reference" element, that's within section 2.2.2 of RFC 4119.

>Alternatively, a location-by-value could be encrypted end-to-end; or 
>location could be conveyed by-reference using an LIS with 
>certificate-based access controls. The GEOPRIV working group 
>discussed various mechanisms last May (See the thread beginning 
>with: 
>http://www1.ietf.org/mail-archive/web/geopriv/current/msg03521.html) 
>and I believe there was rough consensus that the 
>"recipient=endpoint" mechanism described in the current conveyance 
>draft was the best mechanism for achieving the above desideratum.

This is something that the SIP WG needed to be in on, since this is 
not a Geopriv header parameter, it is a SIP header parameter.  Given 
that one SIP WG chair has already said this mechanism is doubtful to 
work, there needs to be a more thorough discussion in SIP about this.


>This seems to leave us with three options going forward:

Exactly who is "us" in the above?


>1) Deny the UAC the opertunity to indicate that location is to be 
>read only by the SIP endpoint. (That is, declare that SIP is not a 
>GEOPRIV using protocol in sense of RFC 3693).

encryption of the message body does this, all of which is already 
defined in SIP (RFC 3261), so this option is not really a choice


>2) Revisit the mechanism discussion and attempt to reach consensus 
>on a better mechanism for indicating that location is to be read 
>only by the SIP endpoint.

How doesn't encryption do this?

BTW - the discussion needs to be in the Using Protocol's WG, where 
the expertise is for that Using protocol.


>3) Craft text explaining that when the "recipient=endpoint" 
>parameter is used that a compliant SIP proxy is not to 'read' the 
>location information. (Note that this text should also indicate that 
>when "recipient=endpoint" is used that calls requiring 
>location-based routing will fail, and thus should only be used when 
>call failure is preferred over disclosure of location information to 
>a routing entity.)

This option is only satisfied when there is an agreeable SIP response 
with Geolocation-Error code indication that informs the UAC why this 
failure occurred, so it can make an informed decision about what the 
next step is.


>- Matt Lepinski
>
>
>James M. Polk wrote:
>
>>This also gets back to one of my original points, does SIP expect a 
>>UAC to understand the topology of a message's path to the ultimate destination?
>>
>>Is Ted's intent of the "recipient=endpoint" parameter to prevent 
>>proxies from reading location in a message *and* a 
>>"recipient=server" parameter to prevent endpoints from reading 
>>location in a message?
>>
>>Does the UAC always know that there are only proxies between it and 
>>the destination UAS?
>>
>>Does the UAC always understand a particular message does or does 
>>not need to be routed based on the location within the request?
>>
>>Emergency services is an example of, always allow proxy routing 
>>when the UAC knows this is an emergency request.  But will this be 
>>true for all applications of location conveyance in the (relatively 
>>near-term) future?  I'm not so sure.
>>
>>The UAC has a mechanism for making location not readable by proxies 
>>if it doesn't want them to, use encryption e2e.  But this has 
>>interesting properties in at least one case, the a user calls the 
>>nearest Pizza Hut.
>>
>>A UAC can encrypt its location in the first INVITE, but if Pizza 
>>Hut has a national or regional number, that routes on the location 
>>of the caller, the message will probably return a 493 (undecipherable).
>>
>>Does the UAC then send location to PizzaHut.com unencrypted, 
>>knowing this is required to get the INVITE to the right store?
>>
>>There are other usages of this, other than Pizza Hut.
>>
>>Does anyone have a suggestion for informative text that can address 
>>each of these two (or more) situations?
>>
>>At the moment, all text around "recipient=" is suggestive, and not 
>>definitive, because of what Dean says below.
>>
>>That said, I could put something in like "unless a future standards 
>>track RFC says otherwise, the use of "recipient=" parameter within 
>>any locationValue is informative in nature", thus leaving the door 
>>open for ECRIT's phoneBCP doc to refine usage in the emergency 
>>context, as well as any other service defining document to do the 
>>same type of refinement.
>>
>>James
>>
>>At 08:28 AM 11/26/2007, DRAGE, Keith \(Keith\) wrote:
>>
>>>This just seems to me to be an inappropriate change of RFC 2119 language.
>>>
>>>If we really mean either of these, then we should be specifying 
>>>that the message is encrypted in the first place.
>>>
>>>What we probably mean is something informative (because we cannot 
>>>make a normative statement on what applications do with the data), 
>>>stating that usage of the message so tagged is inappropriate 
>>>because the sender did not intend it to be used for this purpose.
>>>
>>>Regards
>>>
>>>Keith
>>>
>>> > -----Original Message-----
>>> > From: daniel grotti [mailto:daniel.grotti@unibo.it]
>>> > Sent: Saturday, November 24, 2007 11:38 AM
>>> > To: Dean Willis
>>> > Cc: IETF SIP List; James M. Polk
>>> > Subject: R: R: R: [Sip] a question about IETF draft location
>>> > conveyance 09
>>> >
>>> > I know.
>>> > May be SHOULD NOT instead MUST NOT could be better.
>>> >
>>> > daniel
>>> >
>>> >
>>> > ----------------------------------
>>> >        Daniel  Grotti
>>> > D.E.I.S. - University of Bologna
>>> > ----------------------------------
>>> >        Via Venezia, 52
>>> >   47023 Cesena (FC) - ITALY
>>> > ----------------------------------
>>> > e-mail: daniel.grotti@unibo.it
>>> > ----------------------------------
>>> >
>>> >
>>> >
>>> > -----Messaggio originale-----
>>> > Da: Dean Willis [mailto:dean.willis@softarmor.com]
>>> > Inviato: sab 24/11/2007 2.32
>>> > A: daniel grotti
>>> > Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
>>> > Oggetto: Re: R: R: [Sip] a question about IETF draft location
>>> > conveyance 09
>>> >
>>> >
>>> > On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:
>>> >
>>> > > Hi all,
>>> > > so why don't emphasize this point in the next draft, saying :
>>> > > "Proxy server MUST not read messages with "recipient=endpoint"
>>> > > paramenter setted".
>>> > > This is my point of you.
>>> > >
>>> > >
>>> >
>>> >
>>> > because from a security standpoint, this prohibition is meaningless.
>>> > Intermediate nodes can and will read anything that's in
>>> > plaintext, and SOMEBODY will come up with a rationale, in
>>> > some context or another, for doing so.
>>> >
>>> > And has been pointed out, doing so does not appear to create
>>> > a compatibility problem. It doesn't break the protocol. It
>>> > might defeat security-through-obscurity. It might be rude, or
>>> > otherwise socially unacceptable. But those don't qualify for
>>> > a MUST level protocol prohibition.
>>> >
>>> > --
>>> > Dean
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>
>>
>>
>>_______________________________________________
>>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
>
>
>
>
>_______________________________________________
>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


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 19:23:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwoET-0005wt-Hr; Mon, 26 Nov 2007 19:23:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwoER-0005u0-8d
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:23:19 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoEQ-0005tq-U1
	for sip@ietf.org; Mon, 26 Nov 2007 19:23:18 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwoEQ-00013A-EC
	for sip@ietf.org; Mon, 26 Nov 2007 19:23:18 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 26 Nov 2007 16:23:17 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAR0NH0e012674; 
	Mon, 26 Nov 2007 16:23:17 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAR0N8b6022612;
	Tue, 27 Nov 2007 00:23:09 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 16:23:06 -0800
Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 16:23:06 -0800
Message-ID: <474B638C.6050502@cisco.com>
Date: Mon, 26 Nov 2007 19:23:40 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
References: <4741BB94.80202@cisco.com>	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Nov 2007 00:23:06.0437 (UTC)
	FILETIME=[AE62FF50:01C8308B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2540; t=1196122997;
	x=1196986997; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework
	|Sender:=20; bh=8n5bJZHNuOvdF585q/9JGyhr06LHuHlJQpM7VLLtLkk=;
	b=DWcqTPFKjwjw0uLAqrhrrHk02BRZiMkPm8Yj+9YJjF0ZYiN9bw5663NPyndPBzGqsIDFU8i7
	ixMgULtYrYJxioAjGa/vRCGLerSTMy5gL/Osc2dsgOxxa2itW0GvK2EHj9U+d7Ukh9imBmAeQI
	1WqMsF8DGejUu7IBnvMkcuts0=;
Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: Cullen Jennings , IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

inline:

Hadriel Kaplan wrote:

> 
>> Now Identity gives us a way to realize all of this that protects
>> from attackers modifying things along the chain.  IBM signs and the
>> number as IBM and sends on to sprint. Sprint can use this to decide
>> if they believe this OK or not along with their policy information.
>> Now if sprint thinks it OK, they insert the assertion they think it
>> OK and hand to AT&T. AT&T looks at it and decides that it was OK
>> for sprint, then it is OK for them and inserts their assertion that
>> it OK and hands down to Cisco. Cisco looks for the AT&T assertion
>> and since it one of the carriers they trust, decides it is OK. 
>>  As far as I can tell, anything other than this won't work
>> for phone numbers . This means that the PBX needs to require
>> that the identity it trusts to sign numbers is some it trusts - 
>> practically this means the one or more carriers that it connects
>> to. These carriers need to have their SBC (or proxies if they used 
>> theses) insert an assertion about if the number is OK or not.
> 
> This already happens through P-Asserted.  What you describe is
> hop-by-hop trust of identity, so why would you believe a 4474 signed
> request by your trusted previous-hop any less than a P-Asserted claim
> from it?  And what's more, why would each hop bother with the
> overhead of 4474 if it can just use P-Asserted?  If Cisco was
> concerned with something between them and AT&T, or AT&T concerned
> with something between them and Sprint, or Sprint concerned with
> something between them and IBM, why wouldn't they just use SIP/TLS
> for those peer connections?  It's less overhead and provides better
> security for those connections than 4474.

I agree with Hadriel here. There is no point in RFC 4474 if anyway every 
hop is going to resign. Cullen - what value do you see in it over 3325?

My current view, unfortunately, is that, in environments that use phone 
numbers as identifiers, 4474 and DTLS-SRTP add no security whatsoever 
above their "weaker" cousins - 3325 and sdescriptions. If we all agree 
this is in fact true, that better be amazingly clear in documents we are 
producing. Since right now it isn't.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 19:36:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwoQd-0007B1-R8; Mon, 26 Nov 2007 19:35:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwoQb-0007AR-Ml
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:35:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoQb-0007AF-BC
	for sip@ietf.org; Mon, 26 Nov 2007 19:35:53 -0500
Received: from numenor.qualcomm.com ([129.46.51.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwoQa-00020E-AZ
	for sip@ietf.org; Mon, 26 Nov 2007 19:35:53 -0500
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lAR0Znod012612
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 26 Nov 2007 16:35:49 -0800
Received: from [10.0.1.199] (carbuncle.qualcomm.com [129.46.226.27])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	lAR0Zl5x013965; Mon, 26 Nov 2007 16:35:48 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>
	
	
	
	
	
	
	
	<4745BDC7.30003@gmx.net>
	
	
	
	<5D1A7985295922448D5550C94DE2918001974BEC@DEEXC1U01.de.lucent.com>
	
Date: Mon, 26 Nov 2007 16:35:46 -0800
To: "James M. Polk" ,
	"DRAGE, Keith \(Keith\)" ,
	"daniel grotti" ,
	"Dean Willis" 
From: Ted Hardie 
Subject: RE: R: R: [Sip] a question about IETF draft location   conveyance 09
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Cc: IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 3:02 PM -0600 11/26/07, James M. Polk wrote:
>This also gets back to one of my original points, does SIP expect a UAC to understand the topology of a message's path to the ultimate destination?

I don't think it ever did.  Why would it do so now?

>Is Ted's intent of the "recipient=endpoint" parameter to prevent proxies from reading location in a message *and* a "recipient=server" parameter to prevent endpoints from reading location in a message?

PIDF-LO resources contain statements about things like retransmission.  The intent here
is to make sure those reading the SIP message containing a PIDF-LO understand to
whom those statements are being made.  If you are not the intended recipient,
you do not act on the basis of the information in the PIDF-LO; you either forward it
along (routing-entity) or ignore it (endpoint).

Yes, this expects folks to behave according to the rules in a pidf-lo without
encryption forcing them to, or a gun to their head, or any other coercion.  That's
been the case for pidf-lo resources for a long time now, and it should not come
as a suprise to at least those that have followed that discussion.  If you would
like to re-visit it, expect to be working on this document for a long, long time.


>Does the UAC always know that there are only proxies between it and the destination UAS?
>
>Does the UAC always understand a particular message does or does not need to be routed based on the location within the request?

Try asking the question "Are there circumstances in which the US can decide not to
allow its location to be used in determining where to route the call?"   We had that
discussion over many months, and, I think the rough consensus was yes.  The result
of that may well be calls that do not go through--but that is the consequence of
the UA-determined behavior.  It's their location, and they control it in the
PIDF-LO world.



>Emergency services is an example of, always allow proxy routing when the UAC knows this is an emergency request.  But will this be true for all applications of location conveyance in the (relatively near-term) future?  I'm not so sure.
>
>The UAC has a mechanism for making location not readable by proxies if it doesn't want them to, use encryption e2e.  But this has interesting properties in at least one case, the a user calls the nearest Pizza Hut.

There's a difference between "not readable" and "does not desire that the proxy act on
it".    You don't need all the heavyweight mechanisms of encryption to say to the
routing system "the included location is not intended for you; don't do location based
routing using it--fail instead".  All you need for that is knowledge of the intended
recipient.  Encryption is available for cases where the end-user feels it is needed,
but it should not be required for the base case.

>A UAC can encrypt its location in the first INVITE, but if Pizza Hut has a national or regional number, that routes on the location of the caller, the message will probably return a 493 (undecipherable).
>
>Does the UAC then send location to PizzaHut.com unencrypted, knowing this is required to get the INVITE to the right store?
>
>There are other usages of this, other than Pizza Hut.
>
>Does anyone have a suggestion for informative text that can address each of these two (or more) situations?
>
>At the moment, all text around "recipient=" is suggestive, and not definitive, because of what Dean says below.
>
>That said, I could put something in like "unless a future standards track RFC says otherwise, the use of "recipient=" parameter within any locationValue is informative in nature", thus leaving the door open for ECRIT's phoneBCP doc to refine usage in the emergency context, as well as any other service defining document to do the same type of refinement.

If you do that, you are violating both the rough consensus of the GeoPRIV working group,
and the use of PIDF-LO as already set out in standards track documents.  Don't expect
smooth sailing on that.

Ted


>James
>
>At 08:28 AM 11/26/2007, DRAGE, Keith \(Keith\) wrote:
>>This just seems to me to be an inappropriate change of RFC 2119 language.
>>
>>If we really mean either of these, then we should be specifying that the message is encrypted in the first place.
>>
>>What we probably mean is something informative (because we cannot make a normative statement on what applications do with the data), stating that usage of the message so tagged is inappropriate because the sender did not intend it to be used for this purpose.
>>
>>Regards
>>
>>Keith
>>
>>> -----Original Message-----
>>> From: daniel grotti [mailto:daniel.grotti@unibo.it]
>>> Sent: Saturday, November 24, 2007 11:38 AM
>>> To: Dean Willis
>>> Cc: IETF SIP List; James M. Polk
>>> Subject: R: R: R: [Sip] a question about IETF draft location
>>> conveyance 09
>>>
>>> I know.
>>> May be SHOULD NOT instead MUST NOT could be better.
>>>
>>> daniel
>>>
>>>
>>> ----------------------------------
>>>        Daniel  Grotti
>>> D.E.I.S. - University of Bologna
>>> ----------------------------------
>>>        Via Venezia, 52
>>>   47023 Cesena (FC) - ITALY
>>> ----------------------------------
>>> e-mail: daniel.grotti@unibo.it
>>> ----------------------------------
>>>
>>>
>>>
>>> -----Messaggio originale-----
>>> Da: Dean Willis [mailto:dean.willis@softarmor.com]
>>> Inviato: sab 24/11/2007 2.32
>>> A: daniel grotti
>>> Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
>>> Oggetto: Re: R: R: [Sip] a question about IETF draft location
>>> conveyance 09
>>>
>>>
>>> On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:
>>>
>>> > Hi all,
>>> > so why don't emphasize this point in the next draft, saying :
>>> > "Proxy server MUST not read messages with "recipient=endpoint"
>>> > paramenter setted".
>>> > This is my point of you.
>>> >
>>> >
>>>
>>>
>>> because from a security standpoint, this prohibition is meaningless.
>>> Intermediate nodes can and will read anything that's in
>>> plaintext, and SOMEBODY will come up with a rationale, in
>>> some context or another, for doing so.
>>>
>>> And has been pointed out, doing so does not appear to create
>>> a compatibility problem. It doesn't break the protocol. It
>>> might defeat security-through-obscurity. It might be rude, or
>>> otherwise socially unacceptable. But those don't qualify for
>>> a MUST level protocol prohibition.
>>>
>>> --
>>> Dean
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>
>
>_______________________________________________
>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



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 20:12:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwoze-0004s2-Ds; Mon, 26 Nov 2007 20:12:06 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwozc-0004rc-Hh
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 20:12:04 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwozc-0004rQ-6B
	for sip@ietf.org; Mon, 26 Nov 2007 20:12:04 -0500
Received: from numenor.qualcomm.com ([129.46.51.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwoza-0005Su-Dv
	for sip@ietf.org; Mon, 26 Nov 2007 20:12:03 -0500
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	lAR1BiMh016444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 26 Nov 2007 17:11:45 -0800
Received: from [10.0.1.199] (carbuncle.qualcomm.com [129.46.226.27])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAR1BhDT021157;
	Mon, 26 Nov 2007 17:11:44 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4742BDF5.9040302@unibo.it>
	
	
	
	
	
	
	
	<4745BDC7.30003@gmx.net>
	
	
	
	<5D1A7985295922448D5550C94DE2918001974BEC@DEEXC1U01.de.lucent.com>
	
	<474B4364.60609@bbn.com>
	
Date: Mon, 26 Nov 2007 17:11:42 -0800
To: "James M. Polk" , Matt Lepinski 
From: Ted Hardie 
Subject: Re: R: R: [Sip] a question about IETF draft location conveyance 09
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
Cc: IETF SIP List , "DRAGE,
	Keith \(Keith\)" ,
	Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 6:21 PM -0600 11/26/07, James M. Polk wrote:
>Matt
>
>in-line
>
>At 04:06 PM 11/26/2007, Matt Lepinski wrote:
>>James,
>>
>>I do believe that the intent of Ted (as well as others in the GEOPRIV working group, including myself) is that if a UAC specifies "recipient=endpoint" then a compliant proxy will not 'read' the location body.
>
>Why isn't the message body not encrypted to make sure the Proxy doesn't?
>
>What about the situation in which there are multiple proxies between Alice and Bob, but only one will do anything good with the location.  What is "recipient=" set to, to ensure only the good proxy reads the location body, and the no-so-good proxies obey the parameter and don't look at the location?

To go back to your first question, how does proxy 1 know that later proxies
won't do anything with the location if they are permitted to?  Having
a UA able to say "permit this for routing-entities/don't permit this for routing-entities"
is pretty binary, but discussion in the past covered the problems with trying
to enumerate roles beyond that. 



>>In particular, "recipient=endpoint" indicates that a SIP proxy in the signaling path does not have permission to store the location (or any derived information) for longer than is necessary to forward the SIP message and does not have permission to send the location to any third party (for any reason including location-based routing) other than the next-hop SIP proxy.
>
>The RFC4119 defined PIDF-LO  element (section 2.2.2) covers this already, for any proxy that reads the message body. Why does this also need to be in a SIP header parameter?

James, we had this discussion over many months in the geopriv working group.  You
were certainly present for all of that; if you want to summarize the arguments made
and detail where you disagree, that would be useful.  Acting as if the questions
hadn't been asked and answered already is both tedious and tendentious.  It's deeply
weird to talk to the author of a document that includes all these changes based on
those agreements while the author is acting like those changes appeared magically
by the action of bad elves. 

As the previous discussion made clear, relying on "retransmission-allowed" without a clear statement of the intended recipient would bounce a lot of messages, as the default is "no".  The suggestion that "no" be considered yes for routing was a non-starter.
Recommending that retransmission-allowed be set to "yes" for all the cases of
location-based routing would mean both that the  intermediate systems could use it
*and that the end-user would be able to retransmit it*, which might not be wanted. 
Your previous draft suggested an update to RFC 4119 to include a
"routing-query-allowed" element; geopriv didn't want to make a generic change
to 4119 for what seemed like a SIP-specific case when a SIP header mechanism
looked like it worked as well or better.  (For what it's worth, I agreed with that,
but was also personally willing to tolerate the cruft to get the right thing done)

Are we back on the same page here?

>
>fair, but know that I'm a co-author of 3693, and I'm the one who put in the exception for the emergency case text in that RFC.

And we all have agreed, many times, that all bets are off in the emergency case;
if an emergency system needs to route based on an included location, it gets to
ignore this value.  That doesn't change the base design.

>
>>Alternatively, a location-by-value could be encrypted end-to-end; or location could be conveyed by-reference using an LIS with certificate-based access controls. The GEOPRIV working group discussed various mechanisms last May (See the thread beginning with: http://www1.ietf.org/mail-archive/web/geopriv/current/msg03521.html) and I believe there was rough consensus that the "recipient=endpoint" mechanism described in the current conveyance draft was the best mechanism for achieving the above desideratum.
>
>This is something that the SIP WG needed to be in on, since this is not a Geopriv header parameter, it is a SIP header parameter.  Given that one SIP WG chair has already said this mechanism is doubtful to work, there needs to be a more thorough discussion in SIP about this.

As I asked before, and Dean reinforced, please start from the GeoPRIV consensus.
If you don't do that, we're going to have a long, hard slog through something that
is otherwise pretty damn close to done.


>
>>This seems to leave us with three options going forward:
>
>Exactly who is "us" in the above?

James, come on.  How about "those of us who care"?


>
>>1) Deny the UAC the opertunity to indicate that location is to be read only by the SIP endpoint. (That is, declare that SIP is not a GEOPRIV using protocol in sense of RFC 3693).
>
>encryption of the message body does this, all of which is already defined in SIP (RFC 3261), so this option is not really a choice

But without this, you're still left with the same problem.  If there is a plain text
pidf-lo and "retransmission=no" (remember, kids, that's the default), what does
the routing entity do after doing location-based routing?


>
>>2) Revisit the mechanism discussion and attempt to reach consensus on a better mechanism for indicating that location is to be read only by the SIP endpoint.
>
>How doesn't encryption do this?

Because e2e encryption isn't available in at least some of the cases we've
discussed?

>BTW - the discussion needs to be in the Using Protocol's WG, where the expertise is for that Using protocol.

But it has to be based on the principles already set out in the documents that
Using Protocol has chosen to reference.  You want to re-use GeoPRIV for
something, you don't get to ignore those principles.  We've been through
that several times already, eh?


>
>>3) Craft text explaining that when the "recipient=endpoint" parameter is used that a compliant SIP proxy is not to 'read' the location information. (Note that this text should also indicate that when "recipient=endpoint" is used that calls requiring location-based routing will fail, and thus should only be used when call failure is preferred over disclosure of location information to a routing entity.)
>
>This option is only satisfied when there is an agreeable SIP response with Geolocation-Error code indication that informs the UAC why this failure occurred, so it can make an informed decision about what the next step is.


			regards,
				Ted




>
>>- Matt Lepinski
>>
>>
>>James M. Polk wrote:
>>
>>>This also gets back to one of my original points, does SIP expect a UAC to understand the topology of a message's path to the ultimate destination?
>>>
>>>Is Ted's intent of the "recipient=endpoint" parameter to prevent proxies from reading location in a message *and* a "recipient=server" parameter to prevent endpoints from reading location in a message?
>>>
>>>Does the UAC always know that there are only proxies between it and the destination UAS?
>>>
>>>Does the UAC always understand a particular message does or does not need to be routed based on the location within the request?
>>>
>>>Emergency services is an example of, always allow proxy routing when the UAC knows this is an emergency request.  But will this be true for all applications of location conveyance in the (relatively near-term) future?  I'm not so sure.
>>>
>>>The UAC has a mechanism for making location not readable by proxies if it doesn't want them to, use encryption e2e.  But this has interesting properties in at least one case, the a user calls the nearest Pizza Hut.
>>>
>>>A UAC can encrypt its location in the first INVITE, but if Pizza Hut has a national or regional number, that routes on the location of the caller, the message will probably return a 493 (undecipherable).
>>>
>>>Does the UAC then send location to PizzaHut.com unencrypted, knowing this is required to get the INVITE to the right store?
>>>
>>>There are other usages of this, other than Pizza Hut.
>>>
>>>Does anyone have a suggestion for informative text that can address each of these two (or more) situations?
>>>
>>>At the moment, all text around "recipient=" is suggestive, and not definitive, because of what Dean says below.
>>>
>>>That said, I could put something in like "unless a future standards track RFC says otherwise, the use of "recipient=" parameter within any locationValue is informative in nature", thus leaving the door open for ECRIT's phoneBCP doc to refine usage in the emergency context, as well as any other service defining document to do the same type of refinement.
>>>
>>>James
>>>
>>>At 08:28 AM 11/26/2007, DRAGE, Keith \(Keith\) wrote:
>>>
>>>>This just seems to me to be an inappropriate change of RFC 2119 language.
>>>>
>>>>If we really mean either of these, then we should be specifying that the message is encrypted in the first place.
>>>>
>>>>What we probably mean is something informative (because we cannot make a normative statement on what applications do with the data), stating that usage of the message so tagged is inappropriate because the sender did not intend it to be used for this purpose.
>>>>
>>>>Regards
>>>>
>>>>Keith
>>>>
>>>>> -----Original Message-----
>>>>> From: daniel grotti [mailto:daniel.grotti@unibo.it]
>>>>> Sent: Saturday, November 24, 2007 11:38 AM
>>>>> To: Dean Willis
>>>>> Cc: IETF SIP List; James M. Polk
>>>>> Subject: R: R: R: [Sip] a question about IETF draft location
>>>>> conveyance 09
>>>>>
>>>>> I know.
>>>>> May be SHOULD NOT instead MUST NOT could be better.
>>>>>
>>>>> daniel
>>>>>
>>>>>
>>>>> ----------------------------------
>>>>>        Daniel  Grotti
>>>>> D.E.I.S. - University of Bologna
>>>>> ----------------------------------
>>>>>        Via Venezia, 52
>>>>>   47023 Cesena (FC) - ITALY
>>>>> ----------------------------------
>>>>> e-mail: daniel.grotti@unibo.it
>>>>> ----------------------------------
>>>>>
>>>>>
>>>>>
>>>>> -----Messaggio originale-----
>>>>> Da: Dean Willis [mailto:dean.willis@softarmor.com]
>>>>> Inviato: sab 24/11/2007 2.32
>>>>> A: daniel grotti
>>>>> Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
>>>>> Oggetto: Re: R: R: [Sip] a question about IETF draft location
>>>>> conveyance 09
>>>>>
>>>>>
>>>>> On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:
>>>>>
>>>>> > Hi all,
>>>>> > so why don't emphasize this point in the next draft, saying :
>>>>> > "Proxy server MUST not read messages with "recipient=endpoint"
>>>>> > paramenter setted".
>>>>> > This is my point of you.
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> because from a security standpoint, this prohibition is meaningless.
>>>>> Intermediate nodes can and will read anything that's in
>>>>> plaintext, and SOMEBODY will come up with a rationale, in
>>>>> some context or another, for doing so.
>>>>>
>>>>> And has been pointed out, doing so does not appear to create
>>>>> a compatibility problem. It doesn't break the protocol. It
>>>>> might defeat security-through-obscurity. It might be rude, or
>>>>> otherwise socially unacceptable. But those don't qualify for
>>>>> a MUST level protocol prohibition.
>>>>>
>>>>> --
>>>>> Dean
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>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
>>
>>
>>
>>
>>_______________________________________________
>>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
>
>
>_______________________________________________
>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



_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 20:14:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwp27-0001QG-KH; Mon, 26 Nov 2007 20:14:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwp26-0001Q8-JH
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 20:14:38 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwp26-0001Pz-7M
	for sip@ietf.org; Mon, 26 Nov 2007 20:14:38 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwp25-0005pS-7x
	for sip@ietf.org; Mon, 26 Nov 2007 20:14:38 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-3.cisco.com with ESMTP; 26 Nov 2007 17:14:36 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAR1Eaw2006133; 
	Mon, 26 Nov 2007 17:14:36 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAR1EZAx019811;
	Tue, 27 Nov 2007 01:14:35 GMT
From: "Dan Wing" 
To: "'Jonathan Rosenberg'" 
References: <4741BB94.80202@cisco.com>	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net><474AC204.9080606@cisco.com>
	<474B62C7.6050604@cisco.com>
Subject: SIP E.164 Return Routability Test [was RE: [Sip] comments on
	draft-ietf-sip-dtls-framework]
Date: Mon, 26 Nov 2007 17:14:31 -0800
Message-ID: <134b01c83092$ddee7590$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <474B62C7.6050604@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acgwi07Crf47s/HJTi62Zh6Z781p2QAAYaKw
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7848; t=1196126076;
	x=1196990076; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20SIP=20E.164=20Return=20Routability=20Test=20[was=20RE=3A=20[S
	ip]=20comments=20on=20draft-ietf-sip-dtls-framework]
	|Sender:=20; bh=+77S79fA1R9ddN8YWMakvxH5qw1QR9FLQz6h8ktZ10A=;
	b=A2WG7KnbNC/ak1TeZ2M4OL6S6I1DnnW2tcWlqoV/4xC0KqwZH5Urp6f0X7EUHflJOlhFWeri
	z7LSgBTQUToJmhnt3kXWKZq8gTQmTnQyrf+cBvlh/GMV9q0ntA3E2Bv/;
Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Cc: 'Cullen Jennings' , 'IETF SIP List' ,
	'Paul Kyzivat' , "'Elwell,
	John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

In one message, Jonathan Rosenberg wrote:

> My current view, unfortunately, is that, in environments that 
> use phone numbers as identifiers, 4474 and DTLS-SRTP add no 
> security whatsoever above their "weaker" cousins - 3325 and 
> sdescriptions. If we all agree this is in fact true, that 
> better be amazingly clear in documents we are 
> producing. Since right now it isn't.

This is not a defect or deficiency of DTLS-SRTP, as Eric 
pointed out.  Rather, it is a deficiency caused by SIP's
use of the E.164 namespace (which humans understand) in 
conjunction with domain names; mixing them doesn't work
well.  It comes down to the question:  are these 
equivalent:

  +1-408-555-1234@att.net
  +1-408-555-1234@toms-pizza.sj.ca.us


In another message, Jonathan Rosenberg wrote:

> The root issue is that FUNDAMENTALLY, phone numbers are not scoped 
> within a domain. For this reason, the mapping that exists in peoples 
> heads from identifiers to users is of one of two forms:
> 
> "user@domain" --> some person
> "1 (408) 902-5000" ---> some person
>
> so, even if you user interface could render the fact that, 
> the call was from sip:14089025000@somedomain.com, I believe 
> that users would anyway ignore the domain part since there is 
> no domain part for phone numbers.

Right.  The problem is mixing E.164 namespace with SIP namespace.

But for SIP identity, we need to decide if an entity
that signed an E.164 is authorized, by our own domain's view
of 'authorized', to sign for it.

Cullen suggests that the RFC4474 Verifier have a list of 
domains that the Verifier will trust to sign any E.164.  That
is the best that can be done with RFC4474 by itself.  As you
stated, this allows that trusted entity to violate that
trust (insert their own a=fingerprint, and do their own
DTLS handshake).

As Paul and Francois suggested, using ENUM could provide a way
to determine if the signer was authorized to sign for a certain
E.164.  However, ENUM is not widely deployed and is mired in
non-technical issues.  Furthermore, even if the non-technical
issues were resolved, and we had ENUM available everywhere,
operators that use SBCs and use RFC4474 would have to re-sign
SIP requests, destroying the original signature in the process.
So ENUM is not a viable path (unless we also invent a way to
do end-to-end identity, along the lines of 
-wing-sip-identity-media).


Another approach that I have considered is a SIP return-
routability test.  This provides better flexibility and
does not require a priori configuration of policy for which
domains you trust to sign or to resign; of course, if you 
do trust  certain domains to resign certain things, you can 
short-cut this return-routability (because it will always 
return the same information you already have).  Thus, you 
can consider the SIP return-routability an additional 
enhancement for a SIP network where you don't already 
know which domains are going to send you Invites.

I have written this up, but it is still immature.  However,
there seems to be interest in this thanks to Jonathan's
good analysis of how RFC4474 and today's use of E.164 
collide to reduce the value of RFC4474 signatures (and,
thus, DTLS-SRTP that relies on RFC4474 signatures to
prevent active MitM attacks).

Please consider this a straw-man idea.


SIP E.164 Return Routability Test
---------------------------------

Introduction:

On today's Internet, many protocols have had to protect themselves from
malicious traffic with spoofed identites. As most IP protocols use IP
addresses as the identity, the protection has involved source IP address
verification using a cookie (TCP cookies, [PHOTURIS], [IKE]). SIP [RFC3261]
itself uses cookies, but only for its Digest authentication.


Overview of Operation:

Upon receipt of an INVITE where the From: address contains a SIP URI with an
E.164, a Verifier (as defined in RFC4474 and in SIP-Identity-Media) needs to
verify if the signer is authorized to sign for that domain. This verification
is done by sending an out of dialogue SIP message to that E.164, using the
Verifier's default SIP routing rules for routing an E.164 address. If this
routes to the same domain as the originating Invite, the cookie will be
returned.

To do this, the Verifier sends an out-of-dialogue SIP message to the identity
in the From: address, using the Verifier's normal SIP message routing. This
out-of-diaglogue SIP message is a SUBSCRIBE to an event that causes the
calling UA to send one NOTIFY. The SUBSCRIBE also contains a cookie. The
calling UA's NOTIFY contains the originating UA's DTLS fingerprint and the
SUBSCRIBE's cookie. Upon receiving the NOTIFY, the Verifier ensures
fingerprints in the NOTIFY and INVITE match, and then passes the INVITE to the
called UA. 

Following SIP-Identity-Media, the called UA performs a DTLS-SRTP handshake
with the calling UA, and via the DTLS-SRTP handshake the called UA proves
possession of the private key associated with its public key (and certificate
fingerprint). 


Message Flow:

Calling    Auth.     SBCs and               Called
  UA      Service     B2BUAs    Verifier      UA
-------   -------    --------   --------    ------
  |          |          |          |          |
  | Invite   |          |          |          |
  |--------->|          |          |          |
  |          |          |          |          |
  |    (signs request)  |          |          |
  |          |          |          |          |
  |          | Invite   |          |          |
  |          |--------->| Invite   |          |
  |100       |          |--------->|          |
  |<---------|100       |          |          |
  |          |<---------|100       |          |
  |          |          |<---------|          |
  |          |          |          |          |
  |          |          |    (validates       |
  |          |          |     signature)      |
  |          |          |          |          |
  |          |          |Subscribe |          |
  |          |Subscribe |<---------|          |
  |Subscribe |<---------|          |          |
  |<---------|          |          |          |
  |          |          |          |          |
  |200 Ok    |          |          |          |
  |--------->|200 Ok    |          |          |
  |          |--------->|200 Ok    |          |
  |Notify    |          |--------->|          |
  |--------->|          |          |          |
  |          |          |          |          |
  |    (signs request)  |          |          |
  |          |          |          |          |
  |          |Notify    |          |          |
  |          |--------->|Notify    |          |
  |          |          |--------->|          |
  |          |          |          |          |
  |          |          |200 Ok    |          |
  |          |200 Ok    |<---------|          |
  |200 Ok    |<---------|          |          |
  |<---------|          |          |          |
  |          |          |     (a=fingerprint  |
  |          |          |       matches)      |
  |          |          |          |          |
  |          |          |          | Invite   |
  |          |          |          |--------->|
  |          |          |          |          |
  |          | DTLS-SRTP Handshake |          |
  |<=========...=======>|<==...==============>|
  |          |          |          |          |
  |          |          |          |     (handshake 
  |          |          |          |      successful)
  |          |          |          |          |
  |          |          |          |          |display e.164
  |          |          |          |          |------------>
 

-d


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 21:42:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwqOd-0001fg-HD; Mon, 26 Nov 2007 21:41:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwqOb-0001fa-Oa
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 21:41:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqOb-0001fS-EY
	for sip@ietf.org; Mon, 26 Nov 2007 21:41:57 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwqOb-0001O7-4H
	for sip@ietf.org; Mon, 26 Nov 2007 21:41:57 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-3.cisco.com with ESMTP; 26 Nov 2007 18:41:56 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAR2fusG009798
	for ; Mon, 26 Nov 2007 18:41:56 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAR2fub4001999
	for ; Tue, 27 Nov 2007 02:41:56 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 18:41:56 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.113.135]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Nov 2007 18:41:55 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 26 Nov 2007 20:41:54 -0600
To: sip@ietf.org
From: "James M. Polk" 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 27 Nov 2007 02:41:56.0063 (UTC)
	FILETIME=[133B0EF0:01C8309F]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=548; t=1196131316;
	x=1196995316; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20SIP=20RPH=20New=20Namespaces=20revved=20(-01)
	|Sender:=20; bh=3H5iMzn62pUs2MIn2qQgjKWRRYD+ZG8aPaM7p/nCI6o=;
	b=NQgSAaf7cA7P8NqNUpDID11oQCmQ6jfykPA33rZMJgmDvOrbNyS+GvmSckafmDw0bbLzvfhd
	t2T6BFDeUOYzR7xBkzpccwtceVMWh0NKK1U8pHL8eozn4ZDZldNT0ra6BU7mpXE1GGgfFA+VS8
	zqygs6/VaHJmXJTq6//s/dun8=;
Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Subject: [Sip] SIP RPH New Namespaces revved (-01)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I have revved draft-ietf-sip-rph-new-namespaces to version -01.
http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-01.txt

The primary changes are

#1 - to comments asking for a little more explanation for these new namespaces
and
#2 - to change the priority-values from 0,2,4,6,8 to a range of 0-9 
for all namespaces.

Both were to address comments made during WGLC.

The author believes this document has closed all remaining open 
issues, and requests this ID progress forwards for IESG consideration.

James


_______________________________________________
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



From sip-bounces@ietf.org Mon Nov 26 23:53:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwsRr-0003lO-HP; Mon, 26 Nov 2007 23:53:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwsRq-0003kG-9h
	for sip-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 23:53:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwsRp-0003k1-V6
	for sip@ietf.org; Mon, 26 Nov 2007 23:53:26 -0500
Received: from qmta10.westchester.pa.mail.comcast.net ([76.96.62.17])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwsRp-0002cH-KM
	for sip@ietf.org; Mon, 26 Nov 2007 23:53:25 -0500
Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20])
	by QMTA10.westchester.pa.mail.comcast.net with comcast
	id He401Y0090SCNGk050Cx00; Tue, 27 Nov 2007 04:53:25 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA09.westchester.pa.mail.comcast.net with comcast
	id HgtQ1Y0050umElk0300000; Tue, 27 Nov 2007 04:53:25 +0000
X-Authority-Analysis: v=1.0 c=1 a=Fe6bWW-4Vu_OvKmRpcAA:9
	a=fewrZ9sRzpvMJ6moVaW0pO-Bzh8A:4 a=3FZX-ydVlcEA:10
	a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAR4rOSV014235
	for ; Mon, 26 Nov 2007 23:53:24 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAR4rOaa014231;
	Mon, 26 Nov 2007 23:53:24 -0500
Date: Mon, 26 Nov 2007 23:53:24 -0500
Message-Id: <200711270453.lAR4rOaa014231@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <474B21FF.2010203@alcatel-lucent.com> (vkg@alcatel-lucent.com)
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
References: 	<5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE29180018C877A@DEEXC1U01.de.lucent.com>		<473E220B.7020509@lucent.com>		<4741D470.6030308@alcatel-lucent.com>
	<4741F132.6060300@cisco.com>		<474367FD.4090800@cisco.com>		<47437A45.40409@cisco.com>
	<4744AFB8.7030801@lucent.com>	<4744BF62.3040806@cisco.com>
	<474500A5.5040605@alcatel-lucent.com>	<4746FDD7.3020402@cisco.com>
	<4747338B.8090203@alcatel-lucent.com>	<47475214.9040003@cisco.com>
	<474A0F4E.8040904@alcatel-lucent.com>
	
	<474B21FF.2010203@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: "Vijay K. Gurbani" 

   > If they're not different, ie if both domains end up pointing to the 
   > same IP+port on the server, then they are the same server, which just
   > happens to be servicing multiple domains, and sending to the same 
   > connection is fine.

   ...but fraught with peril, though.  Technically this is feasible,
   because there is enough information in the signaling to allow
   routing to the right virtual server (I think.)

Actually, in SIP there isn't peril, because SIP is carefully designed
so that the destination is coded absolutely in the SIP request; no
contextual information is needed (in the usual cases) to get the
message to its destination.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 00:14:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwsm1-0002Rk-L3; Tue, 27 Nov 2007 00:14:17 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwslz-0002Qm-SD
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 00:14:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwslz-0002Nx-GG
	for sip@ietf.org; Tue, 27 Nov 2007 00:14:15 -0500
Received: from qmta02.westchester.pa.mail.comcast.net ([76.96.62.24])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwslz-0004td-3Q
	for sip@ietf.org; Tue, 27 Nov 2007 00:14:15 -0500
Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52])
	by QMTA02.westchester.pa.mail.comcast.net with comcast
	id HeCX1Y00817dt5G050GT00; Tue, 27 Nov 2007 05:14:14 +0000
Received: from dragon.ariadne.com ([24.34.79.42])
	by OMTA13.westchester.pa.mail.comcast.net with comcast
	id HhEE1Y00A0umElk0300000; Tue, 27 Nov 2007 05:14:14 +0000
X-Authority-Analysis: v=1.0 c=1 a=ebSiwEMrWRMA:10 a=JjlezId7K38pn6hwvqQA:9
	a=5vcWlS0MO6ElMUnFWskA:7 a=KkprUg3I-Jnuh4TRgUrYIWGE_jwA:4
	a=0MAqpqVwYqEA:10 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lAR5EESV015778
	for ; Tue, 27 Nov 2007 00:14:14 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lAR5EE0L015774;
	Tue, 27 Nov 2007 00:14:14 -0500
Date: Tue, 27 Nov 2007 00:14:14 -0500
Message-Id: <200711270514.lAR5EE0L015774@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: 
	(rjsparks@nostrum.com)
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>
	
	
	<200711231731.lANHVE4Z028135@dragon.ariadne.com>
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

   From: Robert Sparks 

   What you quoted talks about what the offer can _send_.
   It doesn't talk about what the offerer must be willing to receive  
   (nor does it constrain what the answerer can send).

Perhaps I'm misunderstanding you, but in regard to what the offerer
must be willing to receive, this seems unambiguous:

   > Here's section 7 of RFC 3264 (found by Ernst Horvath):
   > [...]
   >    The offerer MAY immediately cease listening for media formats that
   >    were listed in the initial offer, but not present in the answer.

In regard to what the answerer can send, RFC 3264 section 6.1 is
clear:

   The answerer MUST send using a media format in the offer that is
   also listed in the answer [...].


   From: Robert Sparks 

   Now we need to find where to put pointers to this so that it isn't  
   so hard for implementers in the future to find.

I don't want to sound snarky, but isn't "Read RFC 3264." implicit in
regard to SIP implementation?

I'm willing to have it pointed out to me that it's easier to overlook
this information than I'm allowing for, but it seems to me that the
answers to these questions are both what one would naively expect, and
also are documented in the sections of the document that one would
expect to find them in.  The only gotcha that I can see is the
consequences of forking, if the offer is contained in a dialog-forming
request, in that until the transaction of the dialog-forming request
is terminated, the UAC must behave as if there are unknown un-answered
offers in flight.  But that is implicit in the RFC 3264 model once one
thinks about it.

Dale


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 01:40:30 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwu7A-0005KS-Os; Tue, 27 Nov 2007 01:40:12 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwu78-0005KI-VM
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 01:40:10 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwu78-0005KA-IP
	for sip@ietf.org; Tue, 27 Nov 2007 01:40:10 -0500
Received: from gws04.hcl.in ([203.105.186.20])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwu77-0003f9-4P
	for sip@ietf.org; Tue, 27 Nov 2007 01:40:10 -0500
Received: from gws04.hcl.in (gws04 [10.249.64.135])
	by localhost.hcl.in (Postfix) with ESMTP id BC6EB360055
	for ; Tue, 27 Nov 2007 12:10:04 +0530 (IST)
Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by 
	gws04.hcl.in (Postfix) with ESMTP id 976DA3670F1for ;
	Tue, 27 Nov 2007 12:10:04 +0530 (IST)
Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by 
	chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830);
	Tue, 27 Nov 2007 12:10:03 +0530
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 27 Nov 2007 12:10:03 +0530
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: If the registrar and presence server and proxy are co-located,
	how will the Presence Server send out NOTIFY  in case of Outbound
Thread-Index: AcgwwFcUigv0ioiISE+wx3UoR7+BgQ==
From: "Karthikeyan Gopal , TLS-Chennai" 
To: 
X-OriginalArrivalTime: 27 Nov 2007 06:40:03.0947 (UTC) 
	FILETIME=[577923B0:01C830C0]
X-imss-version: 2.049
X-imss-result: Passed
X-imss-scanInfo: M:T L:E SM:1
X-imss-tmaseResult: TT:1 TS:-8.8371 TC:1F TRN:62 TV:5.0.1023(15570.002)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121
Subject: [Sip] 
	If the registrar and presence server and proxy are co-located, how 
	will the Presence Server send out NOTIFY  in case of Outbound
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0044024832=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0044024832==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C830C0.57612258"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C830C0.57612258
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi All,

      Registration is done with Registrar as per the outbound draft=2E

Binding will be created in Registrar based on instance_id and AOR=2E

=20

If we send SUBSCRIBE how the Presence Server will send Notify back?

Bcoz, the Presence Server will try to send NOTIFY based on the contact
header of SUBSCRIBE=2E But this contact has NO info about the instance-id=
=2E


=20

But the fd is stored against the instance-id=2E=20

=20

How will the NOTIFY be sent out?

=20

Thanks & Regards,

Karthikeyan



DISCLAIMER:
---------------------------------------------------------------------------=
--------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and=
 intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its=
 affiliates=2E Any views or opinions presented in=20
this email are solely those of the author and may not necessarily reflect=
 the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,=
 distribution and / or publication of=20
this message without the prior written consent of the author of this e-mail=
 is strictly prohibited=2E If you have=20
received this email in error please delete it and notify the sender=
 immediately=2E Before opening any mail and=20
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------=
--------------------------------------------
------_=_NextPart_001_01C830C0.57612258
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi=
 All,



      Registration is done
with Registrar as per the outbound draft=2E



Binding will be=
 created in
Registrar based on instance_id and AOR=2E



 



If we send SUBSCRIBE=
 how the
Presence Server will send Notify back?



Bcoz, the Presence=
 Server
will try to send NOTIFY based on the contact header of SUBSCRIBE=2E But=
 this
contact has NO info about the instance-id=2E 



 



But the fd is stored=
 against
the instance-id=2E 



 



How will the NOTIFY=
 be sent
out?



 



Thanks &=
 Regards,



Karthikeyan










DISCLAIMER:

---------------------------------------------------------------------------=
--------------------------------------------



The contents of this e-mail and any attachment(s) are confidential and=
 intended for the named recipient(s) only=2E

It shall not attach any liability on the originator or HCL or its=
 affiliates=2E Any views or opinions presented in 

this email are solely those of the author and may not necessarily reflect=
 the opinions of HCL or its affiliates=2E

Any form of reproduction, dissemination, copying, disclosure, modification,=
 distribution and / or publication of 

this message without the prior written consent of the author of this e-mail=
 is strictly prohibited=2E If you have 

received this email in error please delete it and notify the sender=
 immediately=2E Before opening any mail and 

attachments please check them for viruses and defect=2E



---------------------------------------------------------------------------=
--------------------------------------------



------_=_NextPart_001_01C830C0.57612258--



--===============0044024832==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0044024832==--





From sip-bounces@ietf.org Tue Nov 27 01:51:20 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwuHu-0005N4-CX; Tue, 27 Nov 2007 01:51:18 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwuHt-0005Mz-UR
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 01:51:17 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwuHt-0005Mp-Da
	for sip@ietf.org; Tue, 27 Nov 2007 01:51:17 -0500
Received: from virus-out-st.online.no ([193.212.240.200] helo=scan.telenor.net)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwuHs-0004Ru-65
	for sip@ietf.org; Tue, 27 Nov 2007 01:51:17 -0500
Received: from mail.grameenphone.com ([202.56.4.68] [202.56.4.68]) by
	scan.telenor.net with ESMTP for sip@ietf.org;
	Tue, 27 Nov 2007 07:50:58 +0100
Received: from DHK01EVS01.grameenphone.com ([10.10.20.197])
	by mail.grameenphone.com (8.13.5/8.13.1) with ESMTP id lAR6ovsG022539
	for ; Tue, 27 Nov 2007 12:50:57 +0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] comments
	ondraft-ietf-sip-dtls-framework]
Date: Tue, 27 Nov 2007 12:50:56 +0600
Message-Id: <3DC7F4377777AD49825A1E462718A04201472CCA@DHK01EVS01.grameenphone.com>
In-Reply-To: <134b01c83092$ddee7590$c5f0200a@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SIP E.164 Return Routability Test [was RE: [Sip] comments
	ondraft-ietf-sip-dtls-framework]
Thread-Index: Acgwi07Crf47s/HJTi62Zh6Z781p2QAAYaKwAA0ZnpA=
X-Priority: 5
Priority: Non-Urgent
Importance: low
From: "Shakil Ahmed  Network Advancement Technical"
	
To: "IETF SIP List" 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi all,

I have a question, might be very na=EFve for you guys. Is 'SIP E.164 =
Return Routability' a replacement technology for ENUM/DNS(E.164<>SIP =
URI)?

Regards,

Shakil

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of =
Dan Wing
Sent: Tuesday, November 27, 2007 7:15 AM
To: 'Jonathan Rosenberg'
Cc: 'Cullen Jennings'; 'IETF SIP List'; 'Paul Kyzivat'; 'Elwell, John'
Subject: SIP E.164 Return Routability Test [was RE: [Sip] comments =
ondraft-ietf-sip-dtls-framework]

In one message, Jonathan Rosenberg wrote:

> My current view, unfortunately, is that, in environments that=20
> use phone numbers as identifiers, 4474 and DTLS-SRTP add no=20
> security whatsoever above their "weaker" cousins - 3325 and=20
> sdescriptions. If we all agree this is in fact true, that=20
> better be amazingly clear in documents we are=20
> producing. Since right now it isn't.

This is not a defect or deficiency of DTLS-SRTP, as Eric=20
pointed out.  Rather, it is a deficiency caused by SIP's
use of the E.164 namespace (which humans understand) in=20
conjunction with domain names; mixing them doesn't work
well.  It comes down to the question:  are these=20
equivalent:

  +1-408-555-1234@att.net
  +1-408-555-1234@toms-pizza.sj.ca.us


In another message, Jonathan Rosenberg wrote:

> The root issue is that FUNDAMENTALLY, phone numbers are not scoped=20
> within a domain. For this reason, the mapping that exists in peoples=20
> heads from identifiers to users is of one of two forms:
>=20
> "user@domain" --> some person
> "1 (408) 902-5000" ---> some person
>
> so, even if you user interface could render the fact that,=20
> the call was from sip:14089025000@somedomain.com, I believe=20
> that users would anyway ignore the domain part since there is=20
> no domain part for phone numbers.

Right.  The problem is mixing E.164 namespace with SIP namespace.

But for SIP identity, we need to decide if an entity
that signed an E.164 is authorized, by our own domain's view
of 'authorized', to sign for it.

Cullen suggests that the RFC4474 Verifier have a list of=20
domains that the Verifier will trust to sign any E.164.  That
is the best that can be done with RFC4474 by itself.  As you
stated, this allows that trusted entity to violate that
trust (insert their own a=3Dfingerprint, and do their own
DTLS handshake).

As Paul and Francois suggested, using ENUM could provide a way
to determine if the signer was authorized to sign for a certain
E.164.  However, ENUM is not widely deployed and is mired in
non-technical issues.  Furthermore, even if the non-technical
issues were resolved, and we had ENUM available everywhere,
operators that use SBCs and use RFC4474 would have to re-sign
SIP requests, destroying the original signature in the process.
So ENUM is not a viable path (unless we also invent a way to
do end-to-end identity, along the lines of=20
-wing-sip-identity-media).


Another approach that I have considered is a SIP return-
routability test.  This provides better flexibility and
does not require a priori configuration of policy for which
domains you trust to sign or to resign; of course, if you=20
do trust  certain domains to resign certain things, you can=20
short-cut this return-routability (because it will always=20
return the same information you already have).  Thus, you=20
can consider the SIP return-routability an additional=20
enhancement for a SIP network where you don't already=20
know which domains are going to send you Invites.

I have written this up, but it is still immature.  However,
there seems to be interest in this thanks to Jonathan's
good analysis of how RFC4474 and today's use of E.164=20
collide to reduce the value of RFC4474 signatures (and,
thus, DTLS-SRTP that relies on RFC4474 signatures to
prevent active MitM attacks).

Please consider this a straw-man idea.


SIP E.164 Return Routability Test
---------------------------------

Introduction:

On today's Internet, many protocols have had to protect themselves from
malicious traffic with spoofed identites. As most IP protocols use IP
addresses as the identity, the protection has involved source IP address
verification using a cookie (TCP cookies, [PHOTURIS], [IKE]). SIP =
[RFC3261]
itself uses cookies, but only for its Digest authentication.


Overview of Operation:

Upon receipt of an INVITE where the From: address contains a SIP URI =
with an
E.164, a Verifier (as defined in RFC4474 and in SIP-Identity-Media) =
needs to
verify if the signer is authorized to sign for that domain. This =
verification
is done by sending an out of dialogue SIP message to that E.164, using =
the
Verifier's default SIP routing rules for routing an E.164 address. If =
this
routes to the same domain as the originating Invite, the cookie will be
returned.

To do this, the Verifier sends an out-of-dialogue SIP message to the =
identity
in the From: address, using the Verifier's normal SIP message routing. =
This
out-of-diaglogue SIP message is a SUBSCRIBE to an event that causes the
calling UA to send one NOTIFY. The SUBSCRIBE also contains a cookie. The
calling UA's NOTIFY contains the originating UA's DTLS fingerprint and =
the
SUBSCRIBE's cookie. Upon receiving the NOTIFY, the Verifier ensures
fingerprints in the NOTIFY and INVITE match, and then passes the INVITE =
to the
called UA.=20

Following SIP-Identity-Media, the called UA performs a DTLS-SRTP =
handshake
with the calling UA, and via the DTLS-SRTP handshake the called UA =
proves
possession of the private key associated with its public key (and =
certificate
fingerprint).=20


Message Flow:

Calling    Auth.     SBCs and               Called
  UA      Service     B2BUAs    Verifier      UA
-------   -------    --------   --------    ------
  |          |          |          |          |
  | Invite   |          |          |          |
  |--------->|          |          |          |
  |          |          |          |          |
  |    (signs request)  |          |          |
  |          |          |          |          |
  |          | Invite   |          |          |
  |          |--------->| Invite   |          |
  |100       |          |--------->|          |
  |<---------|100       |          |          |
  |          |<---------|100       |          |
  |          |          |<---------|          |
  |          |          |          |          |
  |          |          |    (validates       |
  |          |          |     signature)      |
  |          |          |          |          |
  |          |          |Subscribe |          |
  |          |Subscribe |<---------|          |
  |Subscribe |<---------|          |          |
  |<---------|          |          |          |
  |          |          |          |          |
  |200 Ok    |          |          |          |
  |--------->|200 Ok    |          |          |
  |          |--------->|200 Ok    |          |
  |Notify    |          |--------->|          |
  |--------->|          |          |          |
  |          |          |          |          |
  |    (signs request)  |          |          |
  |          |          |          |          |
  |          |Notify    |          |          |
  |          |--------->|Notify    |          |
  |          |          |--------->|          |
  |          |          |          |          |
  |          |          |200 Ok    |          |
  |          |200 Ok    |<---------|          |
  |200 Ok    |<---------|          |          |
  |<---------|          |          |          |
  |          |          |     (a=3Dfingerprint  |
  |          |          |       matches)      |
  |          |          |          |          |
  |          |          |          | Invite   |
  |          |          |          |--------->|
  |          |          |          |          |
  |          | DTLS-SRTP Handshake |          |
  =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D...=3D=3D=3D=3D=3D=3D=3D>|<=3D=3D...=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
  |          |          |          |          |
  |          |          |          |     (handshake=20
  |          |          |          |      successful)
  |          |          |          |          |
  |          |          |          |          |display e.164
  |          |          |          |          |------------>
=20

-d


_______________________________________________
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


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 02:38:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwv1X-0000CL-1z; Tue, 27 Nov 2007 02:38:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwv1V-0000CE-UT
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 02:38:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwv1V-0000C5-6B
	for sip@ietf.org; Tue, 27 Nov 2007 02:38:25 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwv1Q-0005mP-M5
	for sip@ietf.org; Tue, 27 Nov 2007 02:38:25 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JS500F4XM2TKZ@siemenscomms.co.uk> for sip@ietf.org; Tue,
	27 Nov 2007 07:28:05 +0000 (GMT)
Date: Tue, 27 Nov 2007 07:28:04 +0000
From: "Elwell, John" 
Subject: RE: [Sip] comments on draft-ietf-sip-dtls-framework
In-reply-to: <474B62C7.6050604@cisco.com>
To: Jonathan Rosenberg , Paul Kyzivat 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441C01@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [Sip] comments on draft-ietf-sip-dtls-framework
Thread-Index: AcgwjjE/xG0ycWBPQfKElbRX+tVfNwAN+naA
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
	<474AC204.9080606@cisco.com> <474B62C7.6050604@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: Cullen Jennings , IETF SIP List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

The point is, when showing the padlock icon to say that a call's media
are secured, it needs to accompanied by a display of the domain to which
it has been verified to be secure. The same way that when I go to a
secure web site I can see the URL and, if I desire, view the
certificate. For SIP, this should be true whether the user-ID within
that domain is a phone number or not.

So if I make a call to somebody in example1.com, I would expect that to
be shown and not something like MitM.net.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20
> Sent: 27 November 2007 00:20
> To: Paul Kyzivat
> Cc: Cullen Jennings; IETF SIP List; Elwell, John
> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
>=20
> inline:
>=20
> Paul Kyzivat wrote:
> > John,
> >=20
> > I agree with your analysis. And yet in many contexts there=20
> is a strong=20
> > desire to display "phone numbers", because of custom and=20
> limitations of=20
> > protocols and devices. So there is a tendency to coerce a=20
> sip URI into a=20
> > phone number whenever it looks like that can be done.
>=20
> Its more than a rendering problem. The identifier is meaningful for=20
> security because the person on the receiving end of the call=20
> can tie it=20
> to user - the one that they know has been assigned this=20
> identifier. And=20
> thus, they can be assured that, when they answer the phone, they know=20
> the user that is calling (let us put aside issues when=20
> someone else uses=20
>   my phone to make calls).
>=20
> The root issue is that FUNDAMENTALLY, phone numbers are not scoped=20
> within a domain. For this reason, the mapping that exists in peoples=20
> heads from identifiers to users is of one of two forms:
>=20
> "user@domain" --> some person
> "1 (408) 902-5000" ---> some person
>=20
> so, even if you user interface could render the fact that,=20
> the call was=20
> from sip:14089025000@somedomain.com, I believe that users=20
> would anyway=20
> ignore the domain part since there is no domain part for=20
> phone numbers.
>=20
> -Jonathan R.
>=20
> --=20
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> jdrosen@cisco.com
> http://www.jdrosen.net                         PHONE: (408) 902-3084
> http://www.cisco.com
>=20
>=20
> _______________________________________________
> 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
>=20


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 03:05:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwvRW-0007E1-Ik; Tue, 27 Nov 2007 03:05:18 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwvRV-0007Du-A5
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 03:05:17 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwvRU-0007Dm-U6
	for sip@ietf.org; Tue, 27 Nov 2007 03:05:17 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwvRT-0002aW-Tz
	for sip@ietf.org; Tue, 27 Nov 2007 03:05:16 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JS500H0LNSRYQ@siemenscomms.co.uk> for sip@ietf.org; Tue,
	27 Nov 2007 08:05:15 +0000 (GMT)
Date: Tue, 27 Nov 2007 08:05:14 +0000
From: "Elwell, John" 
Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] comments on
	draft-ietf-sip-dtls-framework]
In-reply-to: <134b01c83092$ddee7590$c5f0200a@cisco.com>
To: Dan Wing , Jonathan Rosenberg 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441C03@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: SIP E.164 Return Routability Test [was RE: [Sip] comments on
	draft-ietf-sip-dtls-framework]
Thread-Index: Acgwi07Crf47s/HJTi62Zh6Z781p2QAAYaKwAA+s6FA=
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
	<474AC204.9080606@cisco.com> <474B62C7.6050604@cisco.com>
	<134b01c83092$ddee7590$c5f0200a@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1
Cc: Cullen Jennings , IETF SIP List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dan,

What prevents an intermediate domain saving a copy of the cookie and the
fingerprint and using them to construct the NOTIFY? For scenarios where
the return routing goes through an intermediate domain that the INVITE
came through, this would appear to eliminate the usefulness of this
technique. Perhaps the calling UA needs to sign something in the NOTIFY
to prove ownership of the private key whose certificate fingerprint has
been sent.

John

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]=20
> Sent: 27 November 2007 01:15
> To: 'Jonathan Rosenberg'
> Cc: 'Cullen Jennings'; 'IETF SIP List'; Elwell, John; 'Paul Kyzivat'
> Subject: SIP E.164 Return Routability Test [was RE: [Sip]=20
> comments on draft-ietf-sip-dtls-framework]
>=20
> In one message, Jonathan Rosenberg wrote:
>=20
> > My current view, unfortunately, is that, in environments that=20
> > use phone numbers as identifiers, 4474 and DTLS-SRTP add no=20
> > security whatsoever above their "weaker" cousins - 3325 and=20
> > sdescriptions. If we all agree this is in fact true, that=20
> > better be amazingly clear in documents we are=20
> > producing. Since right now it isn't.
>=20
> This is not a defect or deficiency of DTLS-SRTP, as Eric=20
> pointed out.  Rather, it is a deficiency caused by SIP's
> use of the E.164 namespace (which humans understand) in=20
> conjunction with domain names; mixing them doesn't work
> well.  It comes down to the question:  are these=20
> equivalent:
>=20
>   +1-408-555-1234@att.net
>   +1-408-555-1234@toms-pizza.sj.ca.us
>=20
>=20
> In another message, Jonathan Rosenberg wrote:
>=20
> > The root issue is that FUNDAMENTALLY, phone numbers are not scoped=20
> > within a domain. For this reason, the mapping that exists=20
> in peoples=20
> > heads from identifiers to users is of one of two forms:
> >=20
> > "user@domain" --> some person
> > "1 (408) 902-5000" ---> some person
> >
> > so, even if you user interface could render the fact that,=20
> > the call was from sip:14089025000@somedomain.com, I believe=20
> > that users would anyway ignore the domain part since there is=20
> > no domain part for phone numbers.
>=20
> Right.  The problem is mixing E.164 namespace with SIP namespace.
>=20
> But for SIP identity, we need to decide if an entity
> that signed an E.164 is authorized, by our own domain's view
> of 'authorized', to sign for it.
>=20
> Cullen suggests that the RFC4474 Verifier have a list of=20
> domains that the Verifier will trust to sign any E.164.  That
> is the best that can be done with RFC4474 by itself.  As you
> stated, this allows that trusted entity to violate that
> trust (insert their own a=3Dfingerprint, and do their own
> DTLS handshake).
>=20
> As Paul and Francois suggested, using ENUM could provide a way
> to determine if the signer was authorized to sign for a certain
> E.164.  However, ENUM is not widely deployed and is mired in
> non-technical issues.  Furthermore, even if the non-technical
> issues were resolved, and we had ENUM available everywhere,
> operators that use SBCs and use RFC4474 would have to re-sign
> SIP requests, destroying the original signature in the process.
> So ENUM is not a viable path (unless we also invent a way to
> do end-to-end identity, along the lines of=20
> -wing-sip-identity-media).
>=20
>=20
> Another approach that I have considered is a SIP return-
> routability test.  This provides better flexibility and
> does not require a priori configuration of policy for which
> domains you trust to sign or to resign; of course, if you=20
> do trust  certain domains to resign certain things, you can=20
> short-cut this return-routability (because it will always=20
> return the same information you already have).  Thus, you=20
> can consider the SIP return-routability an additional=20
> enhancement for a SIP network where you don't already=20
> know which domains are going to send you Invites.
>=20
> I have written this up, but it is still immature.  However,
> there seems to be interest in this thanks to Jonathan's
> good analysis of how RFC4474 and today's use of E.164=20
> collide to reduce the value of RFC4474 signatures (and,
> thus, DTLS-SRTP that relies on RFC4474 signatures to
> prevent active MitM attacks).
>=20
> Please consider this a straw-man idea.
>=20
>=20
> SIP E.164 Return Routability Test
> ---------------------------------
>=20
> Introduction:
>=20
> On today's Internet, many protocols have had to protect=20
> themselves from
> malicious traffic with spoofed identites. As most IP protocols use IP
> addresses as the identity, the protection has involved source=20
> IP address
> verification using a cookie (TCP cookies, [PHOTURIS], [IKE]).=20
> SIP [RFC3261]
> itself uses cookies, but only for its Digest authentication.
>=20
>=20
> Overview of Operation:
>=20
> Upon receipt of an INVITE where the From: address contains a=20
> SIP URI with an
> E.164, a Verifier (as defined in RFC4474 and in=20
> SIP-Identity-Media) needs to
> verify if the signer is authorized to sign for that domain.=20
> This verification
> is done by sending an out of dialogue SIP message to that=20
> E.164, using the
> Verifier's default SIP routing rules for routing an E.164=20
> address. If this
> routes to the same domain as the originating Invite, the=20
> cookie will be
> returned.
>=20
> To do this, the Verifier sends an out-of-dialogue SIP message=20
> to the identity
> in the From: address, using the Verifier's normal SIP message=20
> routing. This
> out-of-diaglogue SIP message is a SUBSCRIBE to an event that=20
> causes the
> calling UA to send one NOTIFY. The SUBSCRIBE also contains a=20
> cookie. The
> calling UA's NOTIFY contains the originating UA's DTLS=20
> fingerprint and the
> SUBSCRIBE's cookie. Upon receiving the NOTIFY, the Verifier ensures
> fingerprints in the NOTIFY and INVITE match, and then passes=20
> the INVITE to the
> called UA.=20
>=20
> Following SIP-Identity-Media, the called UA performs a=20
> DTLS-SRTP handshake
> with the calling UA, and via the DTLS-SRTP handshake the=20
> called UA proves
> possession of the private key associated with its public key=20
> (and certificate
> fingerprint).=20
>=20
>=20
> Message Flow:
>=20
> Calling    Auth.     SBCs and               Called
>   UA      Service     B2BUAs    Verifier      UA
> -------   -------    --------   --------    ------
>   |          |          |          |          |
>   | Invite   |          |          |          |
>   |--------->|          |          |          |
>   |          |          |          |          |
>   |    (signs request)  |          |          |
>   |          |          |          |          |
>   |          | Invite   |          |          |
>   |          |--------->| Invite   |          |
>   |100       |          |--------->|          |
>   |<---------|100       |          |          |
>   |          |<---------|100       |          |
>   |          |          |<---------|          |
>   |          |          |          |          |
>   |          |          |    (validates       |
>   |          |          |     signature)      |
>   |          |          |          |          |
>   |          |          |Subscribe |          |
>   |          |Subscribe |<---------|          |
>   |Subscribe |<---------|          |          |
>   |<---------|          |          |          |
>   |          |          |          |          |
>   |200 Ok    |          |          |          |
>   |--------->|200 Ok    |          |          |
>   |          |--------->|200 Ok    |          |
>   |Notify    |          |--------->|          |
>   |--------->|          |          |          |
>   |          |          |          |          |
>   |    (signs request)  |          |          |
>   |          |          |          |          |
>   |          |Notify    |          |          |
>   |          |--------->|Notify    |          |
>   |          |          |--------->|          |
>   |          |          |          |          |
>   |          |          |200 Ok    |          |
>   |          |200 Ok    |<---------|          |
>   |200 Ok    |<---------|          |          |
>   |<---------|          |          |          |
>   |          |          |     (a=3Dfingerprint  |
>   |          |          |       matches)      |
>   |          |          |          |          |
>   |          |          |          | Invite   |
>   |          |          |          |--------->|
>   |          |          |          |          |
>   |          | DTLS-SRTP Handshake |          |
>   =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D...=3D=3D=3D=3D=3D=3D=3D>|<=3D=3D...=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
>   |          |          |          |          |
>   |          |          |          |     (handshake=20
>   |          |          |          |      successful)
>   |          |          |          |          |
>   |          |          |          |          |display e.164
>   |          |          |          |          |------------>
> =20
>=20
> -d
>=20


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 03:29:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwvpA-0006T6-JJ; Tue, 27 Nov 2007 03:29:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwvp9-0006Sl-0b
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 03:29:43 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwvp8-0006SX-Kh
	for sip@ietf.org; Tue, 27 Nov 2007 03:29:42 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwvp7-0004yK-C8
	for sip@ietf.org; Tue, 27 Nov 2007 03:29:42 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-2.cisco.com with ESMTP; 27 Nov 2007 00:29:41 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAR8Tetv012425; 
	Tue, 27 Nov 2007 00:29:40 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAR8Tdb4004477;
	Tue, 27 Nov 2007 08:29:39 GMT
From: "Dan Wing" 
To: "'Elwell, John'" ,
	"'Jonathan Rosenberg'" 
References: <4741BB94.80202@cisco.com><4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net><474AC204.9080606@cisco.com>
	<474B62C7.6050604@cisco.com><134b01c83092$ddee7590$c5f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441C03@GBNTHT12009MSX.gb002.siemens.net>
Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] comments
	ondraft-ietf-sip-dtls-framework]
Date: Tue, 27 Nov 2007 00:29:38 -0800
Message-ID: <159501c830cf$a67d4450$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441C03@GBNTHT12009MSX.gb002.siemens.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acgwi07Crf47s/HJTi62Zh6Z781p2QAAYaKwAA+s6FAAAOfC0A==
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10317; t=1196152180;
	x=1197016180; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20SIP=20E.164=20Return=20Routability=20Test=20[was=20RE
	=3A=20[Sip]=20comments=20ondraft-ietf-sip-dtls-framework]
	|Sender:=20; bh=rK43+rTuovUTUNxNeq/8j7XoM07biSTbH6pB+E+FbLc=;
	b=Opg9ZLMjWORmHiFMo9Guh2F3lEldLrTehR4+itZtLnA2h+23wmgEquOWO46Jv964eRGeiEa9
	Sk0W029nh/3MorBH2QR7c03DDUqezMe//W0V4XId9x/pOndMtebWjzM8QQse+ZlZBFgPLyQ75k
	sx+8bGGdu/wRhHdg/E5lusV+s=;
Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027
Cc: 'Cullen Jennings' , 'IETF SIP List' ,
	'Paul Kyzivat' 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com] 
> Sent: Tuesday, November 27, 2007 12:05 AM
> To: Dan Wing; Jonathan Rosenberg
> Cc: Cullen Jennings; IETF SIP List; Paul Kyzivat
> Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] 
> comments ondraft-ietf-sip-dtls-framework]
> 
> Dan,
> 
> What prevents an intermediate domain saving a copy of the 
> cookie and the fingerprint and using them to construct the 
> NOTIFY?

I used a Notify is a SIP request, and would be signed (using 
RFC4474 or SIP-Identity-Media) by the originating domain.

-d

> For 
> scenarios where
> the return routing goes through an intermediate domain that the INVITE
> came through, this would appear to eliminate the usefulness of this
> technique. Perhaps the calling UA needs to sign something in 
> the NOTIFY
> to prove ownership of the private key whose certificate 
> fingerprint has
> been sent.
> 
> John
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@cisco.com] 
> > Sent: 27 November 2007 01:15
> > To: 'Jonathan Rosenberg'
> > Cc: 'Cullen Jennings'; 'IETF SIP List'; Elwell, John; 'Paul Kyzivat'
> > Subject: SIP E.164 Return Routability Test [was RE: [Sip] 
> > comments on draft-ietf-sip-dtls-framework]
> > 
> > In one message, Jonathan Rosenberg wrote:
> > 
> > > My current view, unfortunately, is that, in environments that 
> > > use phone numbers as identifiers, 4474 and DTLS-SRTP add no 
> > > security whatsoever above their "weaker" cousins - 3325 and 
> > > sdescriptions. If we all agree this is in fact true, that 
> > > better be amazingly clear in documents we are 
> > > producing. Since right now it isn't.
> > 
> > This is not a defect or deficiency of DTLS-SRTP, as Eric 
> > pointed out.  Rather, it is a deficiency caused by SIP's
> > use of the E.164 namespace (which humans understand) in 
> > conjunction with domain names; mixing them doesn't work
> > well.  It comes down to the question:  are these 
> > equivalent:
> > 
> >   +1-408-555-1234@att.net
> >   +1-408-555-1234@toms-pizza.sj.ca.us
> > 
> > 
> > In another message, Jonathan Rosenberg wrote:
> > 
> > > The root issue is that FUNDAMENTALLY, phone numbers are 
> not scoped 
> > > within a domain. For this reason, the mapping that exists 
> > in peoples 
> > > heads from identifiers to users is of one of two forms:
> > > 
> > > "user@domain" --> some person
> > > "1 (408) 902-5000" ---> some person
> > >
> > > so, even if you user interface could render the fact that, 
> > > the call was from sip:14089025000@somedomain.com, I believe 
> > > that users would anyway ignore the domain part since there is 
> > > no domain part for phone numbers.
> > 
> > Right.  The problem is mixing E.164 namespace with SIP namespace.
> > 
> > But for SIP identity, we need to decide if an entity
> > that signed an E.164 is authorized, by our own domain's view
> > of 'authorized', to sign for it.
> > 
> > Cullen suggests that the RFC4474 Verifier have a list of 
> > domains that the Verifier will trust to sign any E.164.  That
> > is the best that can be done with RFC4474 by itself.  As you
> > stated, this allows that trusted entity to violate that
> > trust (insert their own a=fingerprint, and do their own
> > DTLS handshake).
> > 
> > As Paul and Francois suggested, using ENUM could provide a way
> > to determine if the signer was authorized to sign for a certain
> > E.164.  However, ENUM is not widely deployed and is mired in
> > non-technical issues.  Furthermore, even if the non-technical
> > issues were resolved, and we had ENUM available everywhere,
> > operators that use SBCs and use RFC4474 would have to re-sign
> > SIP requests, destroying the original signature in the process.
> > So ENUM is not a viable path (unless we also invent a way to
> > do end-to-end identity, along the lines of 
> > -wing-sip-identity-media).
> > 
> > 
> > Another approach that I have considered is a SIP return-
> > routability test.  This provides better flexibility and
> > does not require a priori configuration of policy for which
> > domains you trust to sign or to resign; of course, if you 
> > do trust  certain domains to resign certain things, you can 
> > short-cut this return-routability (because it will always 
> > return the same information you already have).  Thus, you 
> > can consider the SIP return-routability an additional 
> > enhancement for a SIP network where you don't already 
> > know which domains are going to send you Invites.
> > 
> > I have written this up, but it is still immature.  However,
> > there seems to be interest in this thanks to Jonathan's
> > good analysis of how RFC4474 and today's use of E.164 
> > collide to reduce the value of RFC4474 signatures (and,
> > thus, DTLS-SRTP that relies on RFC4474 signatures to
> > prevent active MitM attacks).
> > 
> > Please consider this a straw-man idea.
> > 
> > 
> > SIP E.164 Return Routability Test
> > ---------------------------------
> > 
> > Introduction:
> > 
> > On today's Internet, many protocols have had to protect 
> > themselves from
> > malicious traffic with spoofed identites. As most IP 
> protocols use IP
> > addresses as the identity, the protection has involved source 
> > IP address
> > verification using a cookie (TCP cookies, [PHOTURIS], [IKE]). 
> > SIP [RFC3261]
> > itself uses cookies, but only for its Digest authentication.
> > 
> > 
> > Overview of Operation:
> > 
> > Upon receipt of an INVITE where the From: address contains a 
> > SIP URI with an
> > E.164, a Verifier (as defined in RFC4474 and in 
> > SIP-Identity-Media) needs to
> > verify if the signer is authorized to sign for that domain. 
> > This verification
> > is done by sending an out of dialogue SIP message to that 
> > E.164, using the
> > Verifier's default SIP routing rules for routing an E.164 
> > address. If this
> > routes to the same domain as the originating Invite, the 
> > cookie will be
> > returned.
> > 
> > To do this, the Verifier sends an out-of-dialogue SIP message 
> > to the identity
> > in the From: address, using the Verifier's normal SIP message 
> > routing. This
> > out-of-diaglogue SIP message is a SUBSCRIBE to an event that 
> > causes the
> > calling UA to send one NOTIFY. The SUBSCRIBE also contains a 
> > cookie. The
> > calling UA's NOTIFY contains the originating UA's DTLS 
> > fingerprint and the
> > SUBSCRIBE's cookie. Upon receiving the NOTIFY, the Verifier ensures
> > fingerprints in the NOTIFY and INVITE match, and then passes 
> > the INVITE to the
> > called UA. 
> > 
> > Following SIP-Identity-Media, the called UA performs a 
> > DTLS-SRTP handshake
> > with the calling UA, and via the DTLS-SRTP handshake the 
> > called UA proves
> > possession of the private key associated with its public key 
> > (and certificate
> > fingerprint). 
> > 
> > 
> > Message Flow:
> > 
> > Calling    Auth.     SBCs and               Called
> >   UA      Service     B2BUAs    Verifier      UA
> > -------   -------    --------   --------    ------
> >   |          |          |          |          |
> >   | Invite   |          |          |          |
> >   |--------->|          |          |          |
> >   |          |          |          |          |
> >   |    (signs request)  |          |          |
> >   |          |          |          |          |
> >   |          | Invite   |          |          |
> >   |          |--------->| Invite   |          |
> >   |100       |          |--------->|          |
> >   |<---------|100       |          |          |
> >   |          |<---------|100       |          |
> >   |          |          |<---------|          |
> >   |          |          |          |          |
> >   |          |          |    (validates       |
> >   |          |          |     signature)      |
> >   |          |          |          |          |
> >   |          |          |Subscribe |          |
> >   |          |Subscribe |<---------|          |
> >   |Subscribe |<---------|          |          |
> >   |<---------|          |          |          |
> >   |          |          |          |          |
> >   |200 Ok    |          |          |          |
> >   |--------->|200 Ok    |          |          |
> >   |          |--------->|200 Ok    |          |
> >   |Notify    |          |--------->|          |
> >   |--------->|          |          |          |
> >   |          |          |          |          |
> >   |    (signs request)  |          |          |
> >   |          |          |          |          |
> >   |          |Notify    |          |          |
> >   |          |--------->|Notify    |          |
> >   |          |          |--------->|          |
> >   |          |          |          |          |
> >   |          |          |200 Ok    |          |
> >   |          |200 Ok    |<---------|          |
> >   |200 Ok    |<---------|          |          |
> >   |<---------|          |          |          |
> >   |          |          |     (a=fingerprint  |
> >   |          |          |       matches)      |
> >   |          |          |          |          |
> >   |          |          |          | Invite   |
> >   |          |          |          |--------->|
> >   |          |          |          |          |
> >   |          | DTLS-SRTP Handshake |          |
> >   |<=========...=======>|<==...==============>|
> >   |          |          |          |          |
> >   |          |          |          |     (handshake 
> >   |          |          |          |      successful)
> >   |          |          |          |          |
> >   |          |          |          |          |display e.164
> >   |          |          |          |          |------------>
> >  
> > 
> > -d
> > 
> 
> 
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 03:46:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iww5h-0002jt-2i; Tue, 27 Nov 2007 03:46:49 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iww5f-0002jg-2a
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 03:46:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iww5e-0002jW-P7
	for sip@ietf.org; Tue, 27 Nov 2007 03:46:46 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iww5X-0003vA-Ff
	for sip@ietf.org; Tue, 27 Nov 2007 03:46:46 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	CD6C620B7A; Tue, 27 Nov 2007 09:43:55 +0100 (CET)
X-AuditID: c1b4fb3c-af796bb0000030cf-d0-474bd8cb4219
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	B06BC20B8C; Tue, 27 Nov 2007 09:43:55 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 27 Nov 2007 09:43:55 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Summary of "what answerer can send" thread (was Re: [Sip] SIPit
	21 :Topics that attendees argued about)
Date: Tue, 27 Nov 2007 09:43:53 +0100
Message-ID: 
In-Reply-To: <0D9987D7-DB05-4231-86B6-DDB62B0F760E@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Summary of "what answerer can send" thread (was Re: [Sip] SIPit
	21 :Topics that attendees argued about)
Thread-Index: AcgwaWOHown9TxI6TqqZ3wmyY34ShAAaBnig
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>			<200711231731.lANHVE4Z028135@dragon.ariadne.com><474B03A3.2040406@cisco.com>
	<0D9987D7-DB05-4231-86B6-DDB62B0F760E@nostrum.com>
From: "Christer Holmberg" 
To: "Robert Sparks" , "Paul Kyzivat" 
X-OriginalArrivalTime: 27 Nov 2007 08:43:55.0534 (UTC)
	FILETIME=[A50B52E0:01C830D1]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

I also think it would be useful to add some text about the importance of
providing an answer as soon as possible, since some implementations will
not accept any media before they have received an answer (or, at least a
preview of an answer).

Regards,

Christer=20

> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
> Sent: 26. marraskuuta 2007 22:17
> To: Paul Kyzivat
> Cc: sip@ietf.org
> Subject: Summary of "what answerer can send" thread (was Re:=20
> [Sip] SIPit 21 :Topics that attendees argued about)
>=20
> Ok - I think we've found the necessary chunks of text needed=20
> to put this part of the thread down.
>=20
> My introduction of the thread had a wrong conclusion in it=20
> (per 3254 6.1).
>=20
> To re-summarize:
>=20
> If an m-line in the offer offers codecs A, B, and C then=20
> until all possible answers are received (think forking), the=20
> offerer must be prepared to receive RTP containing A, B, or C. =20
> After each answer (again remember forking), that answerer=20
> MUST only send RTP packets using the codecs that are in the=20
> intersection of the offer and the answer for that m-line. So,=20
> for instance, if that m-line in the answer contained only B,=20
> the answerer can only send B. Once it's received the answer,=20
> the offerer can decide to only render B, but due to race=20
> conditions it should anticipate seeing some A or C coded=20
> packets, but nobody should expect it to do anything useful with them.
>=20
> Now we need to find where to put pointers to this so that it =20
> isn't so hard for implementers in the future to find.
>=20
> RjS
>=20
> On Nov 26, 2007, at 11:34 AM, Paul Kyzivat wrote:
>=20
> >
> >
> > Robert Sparks wrote:
> >> Dale -
> >> What you quoted talks about what the offer can _send_.
> >
> > The second sentence says what format the offerer MUST use when=20
> > sending. A corollary of that is that it MUST NOT use some other=20
> > format. And a corollary of *that* is that the answerer MUST be=20
> > prepared to receive any of the formats listed in the=20
> answer, and MAY=20
> > NOT be prepared to receive any other format.
> >
> > Note that this apparently includes formats listed in the answer but=20
> > not in the offer! So if the offerer is capable of using any of the=20
> > "extra" formats listed in the answer (which the answerer=20
> has no way of=20
> > knowing) then it may go ahead and use those.
> >
> >> It doesn't talk about what the offerer must be willing to receive=20
> >> (nor does it constrain what the answerer can send).
> >
> > Yes, you are right - it doesn't.
> >
> > Section 5.1 says:
> >
> >    ... If multiple formats are listed, it
> >    means that the offerer is capable of making use of any of those
> >    formats during the session.  In other words, the answerer MAY=20
> > change
> >    formats in the middle of the session, making use of any of the
> >    formats listed, without sending a new offer. ...
> >
> > That certainly at least *implies* that the offerer MUST=20
> initially be=20
> > capable of receiving any format listed in the offer.
> >
> > Then Section 6.1 says:
> >
> >    Once the answerer has sent the answer, it MUST be prepared to=20
> > receive
> >    media for any recvonly streams described by that answer.=20
>  It MUST=20
> > be
> >    prepared to send and receive media for any sendrecv=20
> streams in the
> >    answer, and it MAY send media immediately.  The answerer MUST be
> >    prepared to receive media for recvonly or sendrecv streams using=20
> > any
> >    media formats listed for those streams in the answer, and it MAY=20
> > send
> >    media immediately.  When sending media, it SHOULD use a=20
> > packetization
> >    interval equal to the value of the ptime attribute in=20
> the offer, if
> >    any was present.  It SHOULD send media using a bandwidth=20
> no higher
> >    than the value of the bandwidth attribute in the offer,=20
> if any was
> >    present.  The answerer MUST send using a media format in=20
> the offer
> >    that is also listed in the answer, and SHOULD send using the most
> >    preferred media format in the offer that is also listed in the
> >    answer.  In the case of RTP, it MUST use the payload type numbers
> >    from the offer, even if they differ from those in the answer.
> >
> > *This* says that the answerer is constrained to send on a format in=20
> > the intersection of the offer and the answer. So the=20
> offerer must be=20
> > prepared to receive everything it offers initially, and then it can=20
> > *reduce* what it expects and is capable of receiving once=20
> it receives=20
> > the answer.
> >
> > 	Thanks,
> > 	Paul
> >
> >
> >> RjS
> >> On Nov 23, 2007, at 11:31 AM, Dale.Worley@comcast.net wrote:
> >>>    From: Robert Sparks 
> >>>
> >>>    On Nov 23, 2007, at 5:12 AM, Christer Holmberg wrote:
> >>>> AFTER he has received the answer he may accept only what both=20
> >>>> parties have indicated support for.
> >>>
> >>>    I don't think that's right. Can you show me the text that=20
> >>> supports
> >>>    that claim?
> >>>
> >>> Here's section 7 of RFC 3264 (found by Ernst Horvath):
> >>>
> >>> 7 Offerer Processing of the Answer
> >>>
> >>>    When the offerer receives the answer, it MAY send media on the
> >>>    accepted stream(s) (assuming it is listed as sendrecv=20
> or recvonly=20
> >>> in
> >>>    the answer).  It MUST send using a media format listed in the=20
> >>> answer,
> >>>    and it SHOULD use the first media format listed in the answer=20
> >>> when it
> >>>    does send.
> >>>
> >>>       The reason this is a SHOULD, and not a MUST (its also a=20
> >>> SHOULD,
> >>>       and not a MUST, for the answerer), is because there will
> >>>       oftentimes be a need to change codecs on the fly.  For=20
> >>> example,
> >>>       during silence periods, an agent might like to switch to a=20
> >>> comfort
> >>>       noise codec.  Or, if the user presses a number on=20
> the keypad,=20
> >>> the
> >>>       agent might like to send that using RFC 2833 [9]. =20
> Congestion
> >>>       control might necessitate changing to a lower rate=20
> codec based=20
> >>> on
> >>>       feedback.
> >>>
> >>>    The offerer SHOULD send media according to the value=20
> of any ptime=20
> >>> and
> >>>    bandwidth attribute in the answer.
> >>>
> >>>    The offerer MAY immediately cease listening for media formats=20
> >>> that
> >>>    were listed in the initial offer, but not present in=20
> the answer.
> >>>
> >>> I skimmed draft-ietf-sipping-sip-offeranswer-04 and I see=20
> nothing in=20
> >>> it that would alter the interpretation of this section.
> >>>
> >>> Dale
> >>>
> >>>
> >>> _______________________________________________
> >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the core SIP Protocol Use=20
> >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >>> sipping@ietf.org for new developments on the application of sip
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use=20
> >> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >> sipping@ietf.org for new developments on the application of sip
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 05:46:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwxx4-000408-LK; Tue, 27 Nov 2007 05:46:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iwxx2-0003zq-Ei
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 05:46:00 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwxx2-0003ze-2S
	for sip@ietf.org; Tue, 27 Nov 2007 05:46:00 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwxx0-0001JT-P2
	for sip@ietf.org; Tue, 27 Nov 2007 05:45:59 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JS5003AEV8KYO@siemenscomms.co.uk> for sip@ietf.org; Tue,
	27 Nov 2007 10:45:57 +0000 (GMT)
Date: Tue, 27 Nov 2007 10:45:56 +0000
From: "Elwell, John" 
Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] comments
	ondraft-ietf-sip-dtls-framework]
In-reply-to: <159501c830cf$a67d4450$c5f0200a@cisco.com>
To: Dan Wing , Jonathan Rosenberg 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441C76@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: SIP E.164 Return Routability Test [was RE: [Sip] comments
	ondraft-ietf-sip-dtls-framework]
Thread-Index: Acgwi07Crf47s/HJTi62Zh6Z781p2QAAYaKwAA+s6FAAAOfC0AAEPTBA
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
	<474AC204.9080606@cisco.com> <474B62C7.6050604@cisco.com>
	<134b01c83092$ddee7590$c5f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441C03@GBNTHT12009MSX.gb002.siemens.net>
	<159501c830cf$a67d4450$c5f0200a@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478
Cc: Cullen Jennings , IETF SIP List ,
	Paul Kyzivat 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dan,

I am missing something here. Let me try to explain my concern.

Suppose I have an INVITE request from +123456789@example1.com, which
goes through domains example2.com and example3.com before arriving at
example4.com, where the signature (according to RFC 4474 or
draft-wing-sip-identity-media) is verified. Domain example2.com or
example3.com remembers information from the INVITE request (e.g., the
cookie, the certificate fingerprint). Domain example4.com issues a
SUBSCRIBE request, which let's assume gets routed through domain
example3.com or example2.com, which terminates the SUBSCRIBE request and
sends a NOTIFY request, using the saved cookie and fingerprint. In this
case, the verifier should see that the RFC 4474 or
draft-wing-sip-identity-media signature is from domain example2.com or
example3.com, i.e., a different domain from that of the original INVITE
request. On this basis the verifier could decide not to trust it.

But this still requires draft-wing-sip-identity-media, because with RFC
4474, if example2.com or example3.com resigns the original INVITE
request using +123456789@example2/3.com, the INVITE and NOTIFY requests
will still be signed by the same domain, so the verifier in example4.com
still has no evidence that the INVITE request originated in
example1.com.

John

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]=20
> Sent: 27 November 2007 08:30
> To: Elwell, John; 'Jonathan Rosenberg'
> Cc: 'Cullen Jennings'; 'IETF SIP List'; 'Paul Kyzivat'
> Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip]=20
> comments ondraft-ietf-sip-dtls-framework]
>=20
>=20
> =20
>=20
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens.com]=20
> > Sent: Tuesday, November 27, 2007 12:05 AM
> > To: Dan Wing; Jonathan Rosenberg
> > Cc: Cullen Jennings; IETF SIP List; Paul Kyzivat
> > Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip]=20
> > comments ondraft-ietf-sip-dtls-framework]
> >=20
> > Dan,
> >=20
> > What prevents an intermediate domain saving a copy of the=20
> > cookie and the fingerprint and using them to construct the=20
> > NOTIFY?
>=20
> I used a Notify is a SIP request, and would be signed (using=20
> RFC4474 or SIP-Identity-Media) by the originating domain.
>=20
> -d
>=20
> > For=20
> > scenarios where
> > the return routing goes through an intermediate domain that=20
> the INVITE
> > came through, this would appear to eliminate the usefulness of this
> > technique. Perhaps the calling UA needs to sign something in=20
> > the NOTIFY
> > to prove ownership of the private key whose certificate=20
> > fingerprint has
> > been sent.
> >=20
> > John
> >=20
> > > -----Original Message-----
> > > From: Dan Wing [mailto:dwing@cisco.com]=20
> > > Sent: 27 November 2007 01:15
> > > To: 'Jonathan Rosenberg'
> > > Cc: 'Cullen Jennings'; 'IETF SIP List'; Elwell, John;=20
> 'Paul Kyzivat'
> > > Subject: SIP E.164 Return Routability Test [was RE: [Sip]=20
> > > comments on draft-ietf-sip-dtls-framework]
> > >=20
> > > In one message, Jonathan Rosenberg wrote:
> > >=20
> > > > My current view, unfortunately, is that, in environments that=20
> > > > use phone numbers as identifiers, 4474 and DTLS-SRTP add no=20
> > > > security whatsoever above their "weaker" cousins - 3325 and=20
> > > > sdescriptions. If we all agree this is in fact true, that=20
> > > > better be amazingly clear in documents we are=20
> > > > producing. Since right now it isn't.
> > >=20
> > > This is not a defect or deficiency of DTLS-SRTP, as Eric=20
> > > pointed out.  Rather, it is a deficiency caused by SIP's
> > > use of the E.164 namespace (which humans understand) in=20
> > > conjunction with domain names; mixing them doesn't work
> > > well.  It comes down to the question:  are these=20
> > > equivalent:
> > >=20
> > >   +1-408-555-1234@att.net
> > >   +1-408-555-1234@toms-pizza.sj.ca.us
> > >=20
> > >=20
> > > In another message, Jonathan Rosenberg wrote:
> > >=20
> > > > The root issue is that FUNDAMENTALLY, phone numbers are=20
> > not scoped=20
> > > > within a domain. For this reason, the mapping that exists=20
> > > in peoples=20
> > > > heads from identifiers to users is of one of two forms:
> > > >=20
> > > > "user@domain" --> some person
> > > > "1 (408) 902-5000" ---> some person
> > > >
> > > > so, even if you user interface could render the fact that,=20
> > > > the call was from sip:14089025000@somedomain.com, I believe=20
> > > > that users would anyway ignore the domain part since there is=20
> > > > no domain part for phone numbers.
> > >=20
> > > Right.  The problem is mixing E.164 namespace with SIP namespace.
> > >=20
> > > But for SIP identity, we need to decide if an entity
> > > that signed an E.164 is authorized, by our own domain's view
> > > of 'authorized', to sign for it.
> > >=20
> > > Cullen suggests that the RFC4474 Verifier have a list of=20
> > > domains that the Verifier will trust to sign any E.164.  That
> > > is the best that can be done with RFC4474 by itself.  As you
> > > stated, this allows that trusted entity to violate that
> > > trust (insert their own a=3Dfingerprint, and do their own
> > > DTLS handshake).
> > >=20
> > > As Paul and Francois suggested, using ENUM could provide a way
> > > to determine if the signer was authorized to sign for a certain
> > > E.164.  However, ENUM is not widely deployed and is mired in
> > > non-technical issues.  Furthermore, even if the non-technical
> > > issues were resolved, and we had ENUM available everywhere,
> > > operators that use SBCs and use RFC4474 would have to re-sign
> > > SIP requests, destroying the original signature in the process.
> > > So ENUM is not a viable path (unless we also invent a way to
> > > do end-to-end identity, along the lines of=20
> > > -wing-sip-identity-media).
> > >=20
> > >=20
> > > Another approach that I have considered is a SIP return-
> > > routability test.  This provides better flexibility and
> > > does not require a priori configuration of policy for which
> > > domains you trust to sign or to resign; of course, if you=20
> > > do trust  certain domains to resign certain things, you can=20
> > > short-cut this return-routability (because it will always=20
> > > return the same information you already have).  Thus, you=20
> > > can consider the SIP return-routability an additional=20
> > > enhancement for a SIP network where you don't already=20
> > > know which domains are going to send you Invites.
> > >=20
> > > I have written this up, but it is still immature.  However,
> > > there seems to be interest in this thanks to Jonathan's
> > > good analysis of how RFC4474 and today's use of E.164=20
> > > collide to reduce the value of RFC4474 signatures (and,
> > > thus, DTLS-SRTP that relies on RFC4474 signatures to
> > > prevent active MitM attacks).
> > >=20
> > > Please consider this a straw-man idea.
> > >=20
> > >=20
> > > SIP E.164 Return Routability Test
> > > ---------------------------------
> > >=20
> > > Introduction:
> > >=20
> > > On today's Internet, many protocols have had to protect=20
> > > themselves from
> > > malicious traffic with spoofed identites. As most IP=20
> > protocols use IP
> > > addresses as the identity, the protection has involved source=20
> > > IP address
> > > verification using a cookie (TCP cookies, [PHOTURIS], [IKE]).=20
> > > SIP [RFC3261]
> > > itself uses cookies, but only for its Digest authentication.
> > >=20
> > >=20
> > > Overview of Operation:
> > >=20
> > > Upon receipt of an INVITE where the From: address contains a=20
> > > SIP URI with an
> > > E.164, a Verifier (as defined in RFC4474 and in=20
> > > SIP-Identity-Media) needs to
> > > verify if the signer is authorized to sign for that domain.=20
> > > This verification
> > > is done by sending an out of dialogue SIP message to that=20
> > > E.164, using the
> > > Verifier's default SIP routing rules for routing an E.164=20
> > > address. If this
> > > routes to the same domain as the originating Invite, the=20
> > > cookie will be
> > > returned.
> > >=20
> > > To do this, the Verifier sends an out-of-dialogue SIP message=20
> > > to the identity
> > > in the From: address, using the Verifier's normal SIP message=20
> > > routing. This
> > > out-of-diaglogue SIP message is a SUBSCRIBE to an event that=20
> > > causes the
> > > calling UA to send one NOTIFY. The SUBSCRIBE also contains a=20
> > > cookie. The
> > > calling UA's NOTIFY contains the originating UA's DTLS=20
> > > fingerprint and the
> > > SUBSCRIBE's cookie. Upon receiving the NOTIFY, the=20
> Verifier ensures
> > > fingerprints in the NOTIFY and INVITE match, and then passes=20
> > > the INVITE to the
> > > called UA.=20
> > >=20
> > > Following SIP-Identity-Media, the called UA performs a=20
> > > DTLS-SRTP handshake
> > > with the calling UA, and via the DTLS-SRTP handshake the=20
> > > called UA proves
> > > possession of the private key associated with its public key=20
> > > (and certificate
> > > fingerprint).=20
> > >=20
> > >=20
> > > Message Flow:
> > >=20
> > > Calling    Auth.     SBCs and               Called
> > >   UA      Service     B2BUAs    Verifier      UA
> > > -------   -------    --------   --------    ------
> > >   |          |          |          |          |
> > >   | Invite   |          |          |          |
> > >   |--------->|          |          |          |
> > >   |          |          |          |          |
> > >   |    (signs request)  |          |          |
> > >   |          |          |          |          |
> > >   |          | Invite   |          |          |
> > >   |          |--------->| Invite   |          |
> > >   |100       |          |--------->|          |
> > >   |<---------|100       |          |          |
> > >   |          |<---------|100       |          |
> > >   |          |          |<---------|          |
> > >   |          |          |          |          |
> > >   |          |          |    (validates       |
> > >   |          |          |     signature)      |
> > >   |          |          |          |          |
> > >   |          |          |Subscribe |          |
> > >   |          |Subscribe |<---------|          |
> > >   |Subscribe |<---------|          |          |
> > >   |<---------|          |          |          |
> > >   |          |          |          |          |
> > >   |200 Ok    |          |          |          |
> > >   |--------->|200 Ok    |          |          |
> > >   |          |--------->|200 Ok    |          |
> > >   |Notify    |          |--------->|          |
> > >   |--------->|          |          |          |
> > >   |          |          |          |          |
> > >   |    (signs request)  |          |          |
> > >   |          |          |          |          |
> > >   |          |Notify    |          |          |
> > >   |          |--------->|Notify    |          |
> > >   |          |          |--------->|          |
> > >   |          |          |          |          |
> > >   |          |          |200 Ok    |          |
> > >   |          |200 Ok    |<---------|          |
> > >   |200 Ok    |<---------|          |          |
> > >   |<---------|          |          |          |
> > >   |          |          |     (a=3Dfingerprint  |
> > >   |          |          |       matches)      |
> > >   |          |          |          |          |
> > >   |          |          |          | Invite   |
> > >   |          |          |          |--------->|
> > >   |          |          |          |          |
> > >   |          | DTLS-SRTP Handshake |          |
> > >   =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D...=3D=3D=3D=3D=3D=3D=3D>|<=3D=3D...=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
> > >   |          |          |          |          |
> > >   |          |          |          |     (handshake=20
> > >   |          |          |          |      successful)
> > >   |          |          |          |          |
> > >   |          |          |          |          |display e.164
> > >   |          |          |          |          |------------>
> > > =20
> > >=20
> > > -d
> > >=20
> >=20
> >=20
> > _______________________________________________
> > 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
>=20


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 07:11:36 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwzHh-00077n-GW; Tue, 27 Nov 2007 07:11:25 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IwzHf-0006yj-3N
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 07:11:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwzHF-0005jG-Dk
	for sip@ietf.org; Tue, 27 Nov 2007 07:10:57 -0500
Received: from mtagate4.de.ibm.com ([195.212.29.153])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwzDL-0001fT-R2
	for sip@ietf.org; Tue, 27 Nov 2007 07:06:56 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id lARC6tU3090970
	for ; Tue, 27 Nov 2007 12:06:55 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with
	ESMTP id lARC6sQT2744572
	for ; Tue, 27 Nov 2007 13:06:55 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP
	id lARC6s0W012890 for ; Tue, 27 Nov 2007 13:06:54 +0100
Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com
	[9.149.167.114])
	by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP
	id lARC6sdg012884 for ; Tue, 27 Nov 2007 13:06:54 +0100
To: sip List 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.0NP August 02, 2007
From: Avshalom Houri 
Message-ID: 
Date: Tue, 27 Nov 2007 14:06:54 +0200
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 |
	November 3, 2006) at 27/11/2007 14:06:54,
	Serialize complete at 27/11/2007 14:06:54
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Subject: [Sip] Question on draft-urpalainen-sip-xcap-diff-event-03
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0135279467=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0135279467==
Content-Type: multipart/alternative;
	boundary="=_alternative 00428E1EC22573A0_="

This is a multipart message in MIME format.
--=_alternative 00428E1EC22573A0_=
Content-Type: text/plain; charset="US-ASCII"

Suppose that the subscribe request contains only a single node
selector (a  with only one  with a node selector URI).
Is the server always expected to respond with an 
document that contains an  showing the full content of the
subscribed node?

Also, when there is a change in the subscribed node, what would
the  in the NOTIFY look like?

--Avshalom





--=_alternative 00428E1EC22573A0_=
Content-Type: text/html; charset="US-ASCII"



Suppose that the subscribe request
contains only a single node

selector (a <list> with only
one <entry> with a node selector URI).

Is the server always expected to respond
with an <xcap-diff>

document that contains an <element>
showing the full content of the

subscribed node?



Also, when there is a change in the
subscribed node, what would

the <xcap-diff> in the NOTIFY
look like?



--Avshalom










--=_alternative 00428E1EC22573A0_=--



--===============0135279467==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0135279467==--





From sip-bounces@ietf.org Tue Nov 27 11:05:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix2vX-0002mK-Eh; Tue, 27 Nov 2007 11:04:47 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix2vV-0002m8-Nz
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:04:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2vV-0002lz-Dk
	for sip@ietf.org; Tue, 27 Nov 2007 11:04:45 -0500
Received: from qmta09.westchester.pa.mail.comcast.net ([76.96.62.96])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix2vV-0007NV-2j
	for sip@ietf.org; Tue, 27 Nov 2007 11:04:45 -0500
Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28])
	by QMTA09.westchester.pa.mail.comcast.net with comcast
	id HrqN1Y0090cZkys0501n00; Tue, 27 Nov 2007 16:04:44 +0000
Received: from [192.168.1.120] ([69.250.217.141])
	by OMTA10.westchester.pa.mail.comcast.net with comcast
	id Hs4k1Y00833dvnH0300000; Tue, 27 Nov 2007 16:04:44 +0000
X-Authority-Analysis: v=1.0 c=1 a=j2sJoBdzzCDz_eK3kPAA:9
	a=WG0yntsa8VNs3pzxUoIA:7 a=GgrNABb6MPYRS5opdjXOvcPSp_IA:4
	a=Mz_smNXqyOQA:10
Message-Id: 
From: ken carlberg 
To: Janet Gunn 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [Sip] Need for RPH in SIP Responses
Date: Tue, 27 Nov 2007 11:04:44 -0500
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Janet,

sorry for the tardy comments on the thread.  when I read the draft, a  
couple of other use cases outside of the GETS model came to mind that  
would seem to prompt a need for an R-P header in a SIP response.  In  
the land mobile radio arena, we have bridging architectures/ 
technologies like the ISSI that use SIP as a foundation to bridge  
autonomous subnets of P25 systems.  These tend to be resource  
constrained systems of multi-level precedence, and so having a  
corresponding R-P header in SIP responses would fold in nicely with  
what is being built today and planned for the near future.

outside of that, there are also some efforts to bridge ISSI with Push- 
to-talk over Cellular (PoC) with SIP, though this is quite preliminary  
so I don't know if I'd list this as another use case.  But in any  
event, I think it would be helpful if you could broaden the problem  
statement in your draft so that it is not strictly focused to just  
GETS.  Subsequent to this broader statement, you could then provide a  
more in-depth discussion of the GETS *example*.

also, is it your plan to progress your draft in the SIPPING WG given  
that it deals with a requirement?  I see its on the SIP agenda along  
with James' related draft, which is helpful, but I assume that further  
progress would be shifted to SIPPING.

-ken



_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 11:35:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix3Oh-0002gM-S9; Tue, 27 Nov 2007 11:34:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix3Oh-0002g8-2B
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:34:55 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3Og-0002fy-LE
	for sip@ietf.org; Tue, 27 Nov 2007 11:34:54 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix3Of-0005kr-2G
	for sip@ietf.org; Tue, 27 Nov 2007 11:34:54 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-2.cisco.com with ESMTP; 27 Nov 2007 08:34:52 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lARGYqQW032204; 
	Tue, 27 Nov 2007 08:34:52 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lARGYp75009864;
	Tue, 27 Nov 2007 16:34:51 GMT
From: "Dan Wing" 
To: "'Elwell, John'" ,
	"'Jonathan Rosenberg'" 
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net>
	<474AC204.9080606@cisco.com> <474B62C7.6050604@cisco.com>
	<134b01c83092$ddee7590$c5f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441C03@GBNTHT12009MSX.gb002.siemens.net>
	<159501c830cf$a67d4450$c5f0200a@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441C76@GBNTHT12009MSX.gb002.siemens.net>
Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] comments
	ondraft-ietf-sip-dtls-framework]
Date: Tue, 27 Nov 2007 08:34:51 -0800
Message-ID: <16d901c83113$6f22a420$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441C76@GBNTHT12009MSX.gb002.siemens.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acgwi07Crf47s/HJTi62Zh6Z781p2QAAYaKwAA+s6FAAAOfC0AAEPTBAAAyaDuA=
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14335; t=1196181292;
	x=1197045292; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20SIP=20E.164=20Return=20Routability=20Test=20[was=20RE
	=3A=20[Sip]=20comments=20ondraft-ietf-sip-dtls-framework]
	|Sender:=20; bh=N/TfGeaMA5glPSIKZ9pCh/s5dOunaFi3YSyJ4lG5gIg=;
	b=EZC3IkgKouHd5JcfRbo2o9xJ1cxDkQixg1heTfoJNsqV68m0MzZyCcZEes3L+AQ2AmEl8Fmd
	NnsuXTjLTy1/mypCrPRR4rortcJkvtR94wgQMA42pxP+UHUpbPuSfHRz;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd
Cc: 'Cullen Jennings' , 'IETF SIP List' ,
	'Paul Kyzivat' 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com] 
> Sent: Tuesday, November 27, 2007 2:46 AM
> To: Dan Wing; Jonathan Rosenberg
> Cc: Cullen Jennings; IETF SIP List; Paul Kyzivat
> Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] 
> comments ondraft-ietf-sip-dtls-framework]
> 
> Dan,
> 
> I am missing something here. Let me try to explain my concern.
> 
> Suppose I have an INVITE request from +123456789@example1.com, which
> goes through domains example2.com and example3.com before arriving at
> example4.com, where the signature (according to RFC 4474 or
> draft-wing-sip-identity-media) is verified. Domain example2.com or
> example3.com remembers information from the INVITE request (e.g., the
> cookie, the certificate fingerprint). Domain example4.com issues a
> SUBSCRIBE request, which let's assume gets routed through domain
> example3.com or example2.com, which terminates the SUBSCRIBE 
> request and
> sends a NOTIFY request, using the saved cookie and 
> fingerprint. In this
> case, the verifier should see that the RFC 4474 or
> draft-wing-sip-identity-media signature is from domain example2.com or
> example3.com, i.e., a different domain from that of the 
> original INVITE
> request. On this basis the verifier could decide not to trust it.
> 
> But this still requires draft-wing-sip-identity-media, 
> because with RFC
> 4474, if example2.com or example3.com resigns the original INVITE
> request using +123456789@example2/3.com, the INVITE and 
> NOTIFY requests
> will still be signed by the same domain, so the verifier in 
> example4.com
> still has no evidence that the INVITE request originated in
> example1.com.

Right.  But, what the verifier in example4.com now knows is
that SIP routing towards that E.164 gets routed through
example2/3.  The verifier in example4.com knows and trusts
his own forward routing; the verifier in example4.com has
no idea how other SIP nodes are routing SIP messages towards
example4.com.

My strawman is akin to a TCP SYN cookie, and akin to the 
nonce in SIP's Digest authentication.  Neither my strawman,
nor TCP SYN cookies, nor SIP's Digest authentication nonce,
prove that you're really talking to the same source that
sent you the original message (SIP INVITE, TCP SYN,
SIP REGISTER).  Rather, they prove you have return routability
to an attacker (who now needs to be on the forward and 
reverse paths) or to the originating endpoint.

It's a strawman idea to provide additional identity; perhaps 
it has insufficient value for the problem at hand.  

-d


> John
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@cisco.com] 
> > Sent: 27 November 2007 08:30
> > To: Elwell, John; 'Jonathan Rosenberg'
> > Cc: 'Cullen Jennings'; 'IETF SIP List'; 'Paul Kyzivat'
> > Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] 
> > comments ondraft-ietf-sip-dtls-framework]
> > 
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Elwell, John [mailto:john.elwell@siemens.com] 
> > > Sent: Tuesday, November 27, 2007 12:05 AM
> > > To: Dan Wing; Jonathan Rosenberg
> > > Cc: Cullen Jennings; IETF SIP List; Paul Kyzivat
> > > Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] 
> > > comments ondraft-ietf-sip-dtls-framework]
> > > 
> > > Dan,
> > > 
> > > What prevents an intermediate domain saving a copy of the 
> > > cookie and the fingerprint and using them to construct the 
> > > NOTIFY?
> > 
> > I used a Notify is a SIP request, and would be signed (using 
> > RFC4474 or SIP-Identity-Media) by the originating domain.
> > 
> > -d
> > 
> > > For 
> > > scenarios where
> > > the return routing goes through an intermediate domain that 
> > the INVITE
> > > came through, this would appear to eliminate the 
> usefulness of this
> > > technique. Perhaps the calling UA needs to sign something in 
> > > the NOTIFY
> > > to prove ownership of the private key whose certificate 
> > > fingerprint has
> > > been sent.
> > > 
> > > John
> > > 
> > > > -----Original Message-----
> > > > From: Dan Wing [mailto:dwing@cisco.com] 
> > > > Sent: 27 November 2007 01:15
> > > > To: 'Jonathan Rosenberg'
> > > > Cc: 'Cullen Jennings'; 'IETF SIP List'; Elwell, John; 
> > 'Paul Kyzivat'
> > > > Subject: SIP E.164 Return Routability Test [was RE: [Sip] 
> > > > comments on draft-ietf-sip-dtls-framework]
> > > > 
> > > > In one message, Jonathan Rosenberg wrote:
> > > > 
> > > > > My current view, unfortunately, is that, in environments that 
> > > > > use phone numbers as identifiers, 4474 and DTLS-SRTP add no 
> > > > > security whatsoever above their "weaker" cousins - 3325 and 
> > > > > sdescriptions. If we all agree this is in fact true, that 
> > > > > better be amazingly clear in documents we are 
> > > > > producing. Since right now it isn't.
> > > > 
> > > > This is not a defect or deficiency of DTLS-SRTP, as Eric 
> > > > pointed out.  Rather, it is a deficiency caused by SIP's
> > > > use of the E.164 namespace (which humans understand) in 
> > > > conjunction with domain names; mixing them doesn't work
> > > > well.  It comes down to the question:  are these 
> > > > equivalent:
> > > > 
> > > >   +1-408-555-1234@att.net
> > > >   +1-408-555-1234@toms-pizza.sj.ca.us
> > > > 
> > > > 
> > > > In another message, Jonathan Rosenberg wrote:
> > > > 
> > > > > The root issue is that FUNDAMENTALLY, phone numbers are 
> > > not scoped 
> > > > > within a domain. For this reason, the mapping that exists 
> > > > in peoples 
> > > > > heads from identifiers to users is of one of two forms:
> > > > > 
> > > > > "user@domain" --> some person
> > > > > "1 (408) 902-5000" ---> some person
> > > > >
> > > > > so, even if you user interface could render the fact that, 
> > > > > the call was from sip:14089025000@somedomain.com, I believe 
> > > > > that users would anyway ignore the domain part since there is 
> > > > > no domain part for phone numbers.
> > > > 
> > > > Right.  The problem is mixing E.164 namespace with SIP 
> namespace.
> > > > 
> > > > But for SIP identity, we need to decide if an entity
> > > > that signed an E.164 is authorized, by our own domain's view
> > > > of 'authorized', to sign for it.
> > > > 
> > > > Cullen suggests that the RFC4474 Verifier have a list of 
> > > > domains that the Verifier will trust to sign any E.164.  That
> > > > is the best that can be done with RFC4474 by itself.  As you
> > > > stated, this allows that trusted entity to violate that
> > > > trust (insert their own a=fingerprint, and do their own
> > > > DTLS handshake).
> > > > 
> > > > As Paul and Francois suggested, using ENUM could provide a way
> > > > to determine if the signer was authorized to sign for a certain
> > > > E.164.  However, ENUM is not widely deployed and is mired in
> > > > non-technical issues.  Furthermore, even if the non-technical
> > > > issues were resolved, and we had ENUM available everywhere,
> > > > operators that use SBCs and use RFC4474 would have to re-sign
> > > > SIP requests, destroying the original signature in the process.
> > > > So ENUM is not a viable path (unless we also invent a way to
> > > > do end-to-end identity, along the lines of 
> > > > -wing-sip-identity-media).
> > > > 
> > > > 
> > > > Another approach that I have considered is a SIP return-
> > > > routability test.  This provides better flexibility and
> > > > does not require a priori configuration of policy for which
> > > > domains you trust to sign or to resign; of course, if you 
> > > > do trust  certain domains to resign certain things, you can 
> > > > short-cut this return-routability (because it will always 
> > > > return the same information you already have).  Thus, you 
> > > > can consider the SIP return-routability an additional 
> > > > enhancement for a SIP network where you don't already 
> > > > know which domains are going to send you Invites.
> > > > 
> > > > I have written this up, but it is still immature.  However,
> > > > there seems to be interest in this thanks to Jonathan's
> > > > good analysis of how RFC4474 and today's use of E.164 
> > > > collide to reduce the value of RFC4474 signatures (and,
> > > > thus, DTLS-SRTP that relies on RFC4474 signatures to
> > > > prevent active MitM attacks).
> > > > 
> > > > Please consider this a straw-man idea.
> > > > 
> > > > 
> > > > SIP E.164 Return Routability Test
> > > > ---------------------------------
> > > > 
> > > > Introduction:
> > > > 
> > > > On today's Internet, many protocols have had to protect 
> > > > themselves from
> > > > malicious traffic with spoofed identites. As most IP 
> > > protocols use IP
> > > > addresses as the identity, the protection has involved source 
> > > > IP address
> > > > verification using a cookie (TCP cookies, [PHOTURIS], [IKE]). 
> > > > SIP [RFC3261]
> > > > itself uses cookies, but only for its Digest authentication.
> > > > 
> > > > 
> > > > Overview of Operation:
> > > > 
> > > > Upon receipt of an INVITE where the From: address contains a 
> > > > SIP URI with an
> > > > E.164, a Verifier (as defined in RFC4474 and in 
> > > > SIP-Identity-Media) needs to
> > > > verify if the signer is authorized to sign for that domain. 
> > > > This verification
> > > > is done by sending an out of dialogue SIP message to that 
> > > > E.164, using the
> > > > Verifier's default SIP routing rules for routing an E.164 
> > > > address. If this
> > > > routes to the same domain as the originating Invite, the 
> > > > cookie will be
> > > > returned.
> > > > 
> > > > To do this, the Verifier sends an out-of-dialogue SIP message 
> > > > to the identity
> > > > in the From: address, using the Verifier's normal SIP message 
> > > > routing. This
> > > > out-of-diaglogue SIP message is a SUBSCRIBE to an event that 
> > > > causes the
> > > > calling UA to send one NOTIFY. The SUBSCRIBE also contains a 
> > > > cookie. The
> > > > calling UA's NOTIFY contains the originating UA's DTLS 
> > > > fingerprint and the
> > > > SUBSCRIBE's cookie. Upon receiving the NOTIFY, the 
> > Verifier ensures
> > > > fingerprints in the NOTIFY and INVITE match, and then passes 
> > > > the INVITE to the
> > > > called UA. 
> > > > 
> > > > Following SIP-Identity-Media, the called UA performs a 
> > > > DTLS-SRTP handshake
> > > > with the calling UA, and via the DTLS-SRTP handshake the 
> > > > called UA proves
> > > > possession of the private key associated with its public key 
> > > > (and certificate
> > > > fingerprint). 
> > > > 
> > > > 
> > > > Message Flow:
> > > > 
> > > > Calling    Auth.     SBCs and               Called
> > > >   UA      Service     B2BUAs    Verifier      UA
> > > > -------   -------    --------   --------    ------
> > > >   |          |          |          |          |
> > > >   | Invite   |          |          |          |
> > > >   |--------->|          |          |          |
> > > >   |          |          |          |          |
> > > >   |    (signs request)  |          |          |
> > > >   |          |          |          |          |
> > > >   |          | Invite   |          |          |
> > > >   |          |--------->| Invite   |          |
> > > >   |100       |          |--------->|          |
> > > >   |<---------|100       |          |          |
> > > >   |          |<---------|100       |          |
> > > >   |          |          |<---------|          |
> > > >   |          |          |          |          |
> > > >   |          |          |    (validates       |
> > > >   |          |          |     signature)      |
> > > >   |          |          |          |          |
> > > >   |          |          |Subscribe |          |
> > > >   |          |Subscribe |<---------|          |
> > > >   |Subscribe |<---------|          |          |
> > > >   |<---------|          |          |          |
> > > >   |          |          |          |          |
> > > >   |200 Ok    |          |          |          |
> > > >   |--------->|200 Ok    |          |          |
> > > >   |          |--------->|200 Ok    |          |
> > > >   |Notify    |          |--------->|          |
> > > >   |--------->|          |          |          |
> > > >   |          |          |          |          |
> > > >   |    (signs request)  |          |          |
> > > >   |          |          |          |          |
> > > >   |          |Notify    |          |          |
> > > >   |          |--------->|Notify    |          |
> > > >   |          |          |--------->|          |
> > > >   |          |          |          |          |
> > > >   |          |          |200 Ok    |          |
> > > >   |          |200 Ok    |<---------|          |
> > > >   |200 Ok    |<---------|          |          |
> > > >   |<---------|          |          |          |
> > > >   |          |          |     (a=fingerprint  |
> > > >   |          |          |       matches)      |
> > > >   |          |          |          |          |
> > > >   |          |          |          | Invite   |
> > > >   |          |          |          |--------->|
> > > >   |          |          |          |          |
> > > >   |          | DTLS-SRTP Handshake |          |
> > > >   |<=========...=======>|<==...==============>|
> > > >   |          |          |          |          |
> > > >   |          |          |          |     (handshake 
> > > >   |          |          |          |      successful)
> > > >   |          |          |          |          |
> > > >   |          |          |          |          |display e.164
> > > >   |          |          |          |          |------------>
> > > >  
> > > > 
> > > > -d
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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
> > 


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 12:37:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix4Mp-0000hg-2o; Tue, 27 Nov 2007 12:37:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix4Mo-0000hB-5g
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 12:37:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4Mn-0000gh-Rk
	for sip@ietf.org; Tue, 27 Nov 2007 12:37:01 -0500
Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix4Mn-00082B-Be
	for sip@ietf.org; Tue, 27 Nov 2007 12:37:01 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
	lARHarEQ021138; Tue, 27 Nov 2007 19:36:59 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 27 Nov 2007 15:37:05 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 27 Nov 2007 15:37:05 +0200
Received: from [172.21.41.217] ([172.21.41.217]) by esebe105.NOE.Nokia.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 27 Nov 2007 15:37:05 +0200
Message-ID: <474C1D38.10101@nokia.com>
Date: Tue, 27 Nov 2007 15:35:52 +0200
From: Jari Urpalainen 
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: ext Avshalom Houri 
Subject: Re: [Sip] Question on draft-urpalainen-sip-xcap-diff-event-03
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Nov 2007 13:37:05.0678 (UTC)
	FILETIME=[99964AE0:01C830FA]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: sip List 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

ext Avshalom Houri wrote:
>
> Suppose that the subscribe request contains only a single node
> selector (a  with only one  with a node selector URI).
> Is the server always expected to respond with an 
> document that contains an  showing the full content of the
> subscribed node?
>
Right. If you have read privilege and the node exists the full content 
is shown.
> Also, when there is a change in the subscribed node, what would
> the  in the NOTIFY look like?
>
> --Avshalom
>
The same thing, the full content of the subscribed node (== ~ similar 
content if xcap get with node selector were used). Patching of these 
node contents seems _unnecessary _ complex (i.e. if you were asking 
about it)
br, Jari


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 13:57:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix5bH-0005ci-62; Tue, 27 Nov 2007 13:56:03 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix5bF-0005aB-II
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:56:01 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5bF-0005a3-7u
	for sip@ietf.org; Tue, 27 Nov 2007 13:56:01 -0500
Received: from out002.iad.hostedmail.net ([209.225.56.24])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix5bE-0007Ow-VN
	for sip@ietf.org; Tue, 27 Nov 2007 13:56:01 -0500
Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.32]) by
	out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959);
	Tue, 27 Nov 2007 13:56:02 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21: BNF and DIGEST authentication
Date: Tue, 27 Nov 2007 13:56:00 -0500
Message-ID: 
In-Reply-To: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21: BNF and DIGEST authentication
Thread-Index: Acgq9QK1ZTxcqpi6S4uxV/U0stwCFQGMOQ/w
From: "Brett Tate" 
To: "Robert Sparks" ,
	"sip List" 
X-OriginalArrivalTime: 27 Nov 2007 18:56:02.0913 (UTC)
	FILETIME=[28449D10:01C83127]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


> We are _still_ seeing interoperability problems because of=20
> quotes around the qop parameter value in challenges and responses.
>=20
> What's specified now is that quotes MUST appear in challenges=20
> (it's a list of things) and MUST NOT appear in responses=20
> (it's a choice of one thing).
>=20
> This causes lots of people to write broken code.
>=20
> For the code that does work, this causes people to either=20
> build separate parsers for headers with the same name, using=20
> the knowledge of whether its a challenge or response to=20
> invoke the right parser, or to build parsers that don't=20
> follow the BNF we've provided.
>=20
> Would it make more sense to change the BNF to allow the=20
> quotes optionally in either the challenge or the response?

< snip >

> What would be bad about making this change to the spec?

For backward compatibility reasons, I don't think that the BNF should
change.

However I agree that it is a common problem.  If rfc3261bis or
rfc4475bis gets generated, maybe the problem could be highlighted with a
potential recommendation to accommodate such errant devices.


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 14:10:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix5nc-0006hr-Tn; Tue, 27 Nov 2007 14:08:48 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix5nb-0006hI-NY
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:08:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5nb-0006gz-Dv
	for sip@ietf.org; Tue, 27 Nov 2007 14:08:47 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ix5nY-00065h-LS for sip@ietf.org; Tue, 27 Nov 2007 14:08:47 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-2.cisco.com with ESMTP; 27 Nov 2007 11:08:39 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lARJ8eKB006884; 
	Tue, 27 Nov 2007 11:08:40 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lARJ8YqZ029511;
	Tue, 27 Nov 2007 19:08:39 GMT
From: "Dan Wing" 
To: "'Shakil Ahmed Network Advancement Technical'"
	, "'IETF SIP List'" 
References: <134b01c83092$ddee7590$c5f0200a@cisco.com>
	<3DC7F4377777AD49825A1E462718A04201472CCA@DHK01EVS01.grameenphone.com>
Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip]
	commentsondraft-ietf-sip-dtls-framework]
Date: Tue, 27 Nov 2007 11:08:34 -0800
Message-ID: <194f01c83128$eb312ae0$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <3DC7F4377777AD49825A1E462718A04201472CCA@DHK01EVS01.grameenphone.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acgwi07Crf47s/HJTi62Zh6Z781p2QAAYaKwAA0ZnpAAGU+bwA==
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12001; t=1196190520;
	x=1197054520; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20SIP=20E.164=20Return=20Routability=20Test=20[was=20RE
	=3A=20[Sip]=20commentsondraft-ietf-sip-dtls-framework]
	|Sender:=20; bh=zk/nPzoldhuNeVQMsXzdDJGna43xPtswI9Ua7sWIGM0=;
	b=xzyKW3XFIanxrMB+5zrKQ5SoWLCxR7ZDm7DMpiaejpacDHwMovNY29+V6OxcHag3gr3hGBPI
	iHefu8xbQt7Kc6nymliRcIoS5fTfrmgo2+8lwA7ma426v2rmSkH1s4Hr;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: cbb41f2dbf0f142369614756642005e3
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

=20

> -----Original Message-----
> From: Shakil Ahmed Network Advancement Technical=20
> [mailto:shakil.ahmed@grameenphone.com]=20
> Sent: Monday, November 26, 2007 10:51 PM
> To: IETF SIP List
> Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip]=20
> commentsondraft-ietf-sip-dtls-framework]
> Importance: Low
>=20
> Hi all,
>=20
> I have a question, might be very na=EFve for you guys. Is 'SIP=20
> E.164 Return Routability' a replacement technology for=20
> ENUM/DNS(E.164<>SIP URI)?

No.  Keep in mind it is an immature idea.

The idea of return routability is that if you receive an Invite
with an E.164 of +1-202-456-1414 (which is the Whitehouse
switchboard), and it has a SIP From of:

  "From: +1-202-456-1414@mafia.ru"   (the Russian mafia)

you need a way to discern that is valid (or invalid) compared
to:

  "From: +1-202-456-1414@whitehouse.gov"

or

  "From: +1-202-456-1414@verizon.net" (Verizon is the phone
                                       company for the Washington,
                                       DC area)
or

  "From: +1-202-456-1414@att.net"  (your company's ITSP)

Right now, SIP has no way to determine which of those three is valid.

ENUM, if it were available, could help.  With ENUM, you could,=20
in theory, look up the phone number and see if mafia.ru,
whitehouse.gov, or verizon.net were authorized to sign that
identity.  ENUM does not provide that functionality today,=20
though.

The idea of SIP return routability is to generate a new SIP
request, using your domain's own default SIP routing rules,
and see if it goes to the same place as the just-arrived
INVITE. =20

Using the example above where the INVITE is from mafia.ru, you=20
would take the E.164 address (+1-202-456-1414) from the=20
Invite and build a new SIP request (a SUBSCRIBE) -- like
"sip:+1-202-456-1414@att.net;user=3Dphone" if att.net was your=20
default ITSP.  This SUBSCRIBE would be routed, by att.net,
and eventually arrive at whitehouse.gov.  At whitehouse.gov,=20
that SUBSCRIBE causes them to send one NOTIFY back to you. =20
With SIP-Identity-Media, whitehouse.gov's signature is preserved=20
and your Verifier would see that the SUBSCRIBE is signed by=20
whitehouse.gov.  "whitehouse.gov" is different from "mafia.ru".
Your verifier now knows that mafia.ru is not authorized
to sign for that E.164, and rejects the INVITE.

-d


> Regards,
>=20
> Shakil
>=20
> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20
> Behalf Of Dan Wing
> Sent: Tuesday, November 27, 2007 7:15 AM
> To: 'Jonathan Rosenberg'
> Cc: 'Cullen Jennings'; 'IETF SIP List'; 'Paul Kyzivat'; 'Elwell, John'
> Subject: SIP E.164 Return Routability Test [was RE: [Sip]=20
> comments ondraft-ietf-sip-dtls-framework]
>=20
> In one message, Jonathan Rosenberg wrote:
>=20
> > My current view, unfortunately, is that, in environments that=20
> > use phone numbers as identifiers, 4474 and DTLS-SRTP add no=20
> > security whatsoever above their "weaker" cousins - 3325 and=20
> > sdescriptions. If we all agree this is in fact true, that=20
> > better be amazingly clear in documents we are=20
> > producing. Since right now it isn't.
>=20
> This is not a defect or deficiency of DTLS-SRTP, as Eric=20
> pointed out.  Rather, it is a deficiency caused by SIP's
> use of the E.164 namespace (which humans understand) in=20
> conjunction with domain names; mixing them doesn't work
> well.  It comes down to the question:  are these=20
> equivalent:
>=20
>   +1-408-555-1234@att.net
>   +1-408-555-1234@toms-pizza.sj.ca.us
>=20
>=20
> In another message, Jonathan Rosenberg wrote:
>=20
> > The root issue is that FUNDAMENTALLY, phone numbers are not scoped=20
> > within a domain. For this reason, the mapping that exists=20
> in peoples=20
> > heads from identifiers to users is of one of two forms:
> >=20
> > "user@domain" --> some person
> > "1 (408) 902-5000" ---> some person
> >
> > so, even if you user interface could render the fact that,=20
> > the call was from sip:14089025000@somedomain.com, I believe=20
> > that users would anyway ignore the domain part since there is=20
> > no domain part for phone numbers.
>=20
> Right.  The problem is mixing E.164 namespace with SIP namespace.
>=20
> But for SIP identity, we need to decide if an entity
> that signed an E.164 is authorized, by our own domain's view
> of 'authorized', to sign for it.
>=20
> Cullen suggests that the RFC4474 Verifier have a list of=20
> domains that the Verifier will trust to sign any E.164.  That
> is the best that can be done with RFC4474 by itself.  As you
> stated, this allows that trusted entity to violate that
> trust (insert their own a=3Dfingerprint, and do their own
> DTLS handshake).
>=20
> As Paul and Francois suggested, using ENUM could provide a way
> to determine if the signer was authorized to sign for a certain
> E.164.  However, ENUM is not widely deployed and is mired in
> non-technical issues.  Furthermore, even if the non-technical
> issues were resolved, and we had ENUM available everywhere,
> operators that use SBCs and use RFC4474 would have to re-sign
> SIP requests, destroying the original signature in the process.
> So ENUM is not a viable path (unless we also invent a way to
> do end-to-end identity, along the lines of=20
> -wing-sip-identity-media).
>=20
>=20
> Another approach that I have considered is a SIP return-
> routability test.  This provides better flexibility and
> does not require a priori configuration of policy for which
> domains you trust to sign or to resign; of course, if you=20
> do trust  certain domains to resign certain things, you can=20
> short-cut this return-routability (because it will always=20
> return the same information you already have).  Thus, you=20
> can consider the SIP return-routability an additional=20
> enhancement for a SIP network where you don't already=20
> know which domains are going to send you Invites.
>=20
> I have written this up, but it is still immature.  However,
> there seems to be interest in this thanks to Jonathan's
> good analysis of how RFC4474 and today's use of E.164=20
> collide to reduce the value of RFC4474 signatures (and,
> thus, DTLS-SRTP that relies on RFC4474 signatures to
> prevent active MitM attacks).
>=20
> Please consider this a straw-man idea.
>=20
>=20
> SIP E.164 Return Routability Test
> ---------------------------------
>=20
> Introduction:
>=20
> On today's Internet, many protocols have had to protect=20
> themselves from
> malicious traffic with spoofed identites. As most IP protocols use IP
> addresses as the identity, the protection has involved source=20
> IP address
> verification using a cookie (TCP cookies, [PHOTURIS], [IKE]).=20
> SIP [RFC3261]
> itself uses cookies, but only for its Digest authentication.
>=20
>=20
> Overview of Operation:
>=20
> Upon receipt of an INVITE where the From: address contains a=20
> SIP URI with an
> E.164, a Verifier (as defined in RFC4474 and in=20
> SIP-Identity-Media) needs to
> verify if the signer is authorized to sign for that domain.=20
> This verification
> is done by sending an out of dialogue SIP message to that=20
> E.164, using the
> Verifier's default SIP routing rules for routing an E.164=20
> address. If this
> routes to the same domain as the originating Invite, the=20
> cookie will be
> returned.
>=20
> To do this, the Verifier sends an out-of-dialogue SIP message=20
> to the identity
> in the From: address, using the Verifier's normal SIP message=20
> routing. This
> out-of-diaglogue SIP message is a SUBSCRIBE to an event that=20
> causes the
> calling UA to send one NOTIFY. The SUBSCRIBE also contains a=20
> cookie. The
> calling UA's NOTIFY contains the originating UA's DTLS=20
> fingerprint and the
> SUBSCRIBE's cookie. Upon receiving the NOTIFY, the Verifier ensures
> fingerprints in the NOTIFY and INVITE match, and then passes=20
> the INVITE to the
> called UA.=20
>=20
> Following SIP-Identity-Media, the called UA performs a=20
> DTLS-SRTP handshake
> with the calling UA, and via the DTLS-SRTP handshake the=20
> called UA proves
> possession of the private key associated with its public key=20
> (and certificate
> fingerprint).=20
>=20
>=20
> Message Flow:
>=20
> Calling    Auth.     SBCs and               Called
>   UA      Service     B2BUAs    Verifier      UA
> -------   -------    --------   --------    ------
>   |          |          |          |          |
>   | Invite   |          |          |          |
>   |--------->|          |          |          |
>   |          |          |          |          |
>   |    (signs request)  |          |          |
>   |          |          |          |          |
>   |          | Invite   |          |          |
>   |          |--------->| Invite   |          |
>   |100       |          |--------->|          |
>   |<---------|100       |          |          |
>   |          |<---------|100       |          |
>   |          |          |<---------|          |
>   |          |          |          |          |
>   |          |          |    (validates       |
>   |          |          |     signature)      |
>   |          |          |          |          |
>   |          |          |Subscribe |          |
>   |          |Subscribe |<---------|          |
>   |Subscribe |<---------|          |          |
>   |<---------|          |          |          |
>   |          |          |          |          |
>   |200 Ok    |          |          |          |
>   |--------->|200 Ok    |          |          |
>   |          |--------->|200 Ok    |          |
>   |Notify    |          |--------->|          |
>   |--------->|          |          |          |
>   |          |          |          |          |
>   |    (signs request)  |          |          |
>   |          |          |          |          |
>   |          |Notify    |          |          |
>   |          |--------->|Notify    |          |
>   |          |          |--------->|          |
>   |          |          |          |          |
>   |          |          |200 Ok    |          |
>   |          |200 Ok    |<---------|          |
>   |200 Ok    |<---------|          |          |
>   |<---------|          |          |          |
>   |          |          |     (a=3Dfingerprint  |
>   |          |          |       matches)      |
>   |          |          |          |          |
>   |          |          |          | Invite   |
>   |          |          |          |--------->|
>   |          |          |          |          |
>   |          | DTLS-SRTP Handshake |          |
>   =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D...=3D=3D=3D=3D=3D=3D=3D>|<=3D=3D...=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
>   |          |          |          |          |
>   |          |          |          |     (handshake=20
>   |          |          |          |      successful)
>   |          |          |          |          |
>   |          |          |          |          |display e.164
>   |          |          |          |          |------------>
> =20
>=20
> -d
>=20
>=20
> _______________________________________________
> 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
>=20
>=20
> _______________________________________________
> 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


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 14:44:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix6LS-0006J3-QZ; Tue, 27 Nov 2007 14:43:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix6LR-0006Il-DY
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:43:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6LR-0006Ic-3S
	for sip@ietf.org; Tue, 27 Nov 2007 14:43:45 -0500
Received: from out002.iad.hostedmail.net ([209.225.56.24])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix6LQ-0004oi-Sw
	for sip@ietf.org; Tue, 27 Nov 2007 14:43:45 -0500
Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.32]) by
	out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959);
	Tue, 27 Nov 2007 14:43:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21: Question about offer answer
Date: Tue, 27 Nov 2007 14:43:46 -0500
Message-ID: 
In-Reply-To: <0EB4D4CF-C3C3-46D5-9B10-DD7684391D07@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21: Question about offer answer
Thread-Index: Acgq9sN9LrgPGV1aSJW3ASBQLJ71VgGNW30Q
From: "Brett Tate" 
To: "Robert Sparks" ,
	"sip List" 
X-OriginalArrivalTime: 27 Nov 2007 19:43:49.0106 (UTC)
	FILETIME=[D4A6F520:01C8312D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> However, the specs allow the answer to such a non-changed=20
> offer to be different from the previous answer.
>=20
> What was the motivation?=20

To cause 3PCC headaches if B2BUA refreshing/auditing with re-INVITE. ;)

If I recall correctly, it was mainly to allow for recovery and avoid
exceptions to the rfc3264 rules.


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 15:59:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix7Vi-0000l6-OO; Tue, 27 Nov 2007 15:58:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix7Vh-0000kb-C8
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 15:58:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7Vg-0000kQ-Oh
	for sip@ietf.org; Tue, 27 Nov 2007 15:58:25 -0500
Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
	([2001:470:1f03:267::2] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix7Vd-0001Me-Om
	for sip@ietf.org; Tue, 27 Nov 2007 15:58:24 -0500
Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lARKwFbL054346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 27 Nov 2007 14:58:15 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <474C84F0.7000309@nostrum.com>
Date: Tue, 27 Nov 2007 14:58:24 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: "James M. Polk" , sip@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4933/Tue Nov 27 13:10:57 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: 
Subject: [Sip] NITS: draft-ietf-sip-location-conveyance-09.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

"A 424 (Bad Location Information) response is a final response within a 
transaction, and does not terminate a dialog."

This does a good job in being specific on the effect of the newly 
defined error responses -- however, to be as precise as possible, I 
propose that this sentence should read "...and does not terminate a 
_usage_." (Alternately: "...a usage or a dialog.")


Also -- and I could just be missing something here -- but this document 
appears to have removed a couple of important header field parameters 
from the IANA section. Section 5.2 explains:

   There are 3 Geolocation header parameters,

   o "inserted-by="
   o "used-for-routing"
   o "recipient="

However, the IANA registration contains only "recipient:"

   Geolocation Header parameters

   Header Parameters     Parameter-values      Reference
   ----------------      ----------------      --------------
   recipient             endpoint              RFC XXXX (this document)
   recipient             routing-entity        RFC XXXX (this document)
   recipient             both                  RFC XXXX (this document)


It appears that draft-...-08 _did_ contain the other two parameters. Why 
were they removed?

/a


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 17:07:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix8Zh-00049k-Pd; Tue, 27 Nov 2007 17:06:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix8Zg-00047H-4S
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 17:06:36 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8Zf-000460-73
	for sip@ietf.org; Tue, 27 Nov 2007 17:06:35 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix8Ze-0005PD-FD
	for sip@ietf.org; Tue, 27 Nov 2007 17:06:35 -0500
Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lARM6TJu057749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 27 Nov 2007 16:06:30 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <474C94EF.10905@nostrum.com>
Date: Tue, 27 Nov 2007 16:06:39 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
References: 	<4741F8A7.204@nostrum.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4933/Tue Nov 27 13:10:57 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: "sip@ietf.org" ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

On 11/19/07 3:07 PM, Hadriel Kaplan wrote:
> Yeah my bad for not re-writing that whole thing.  It started out as a "rfc3265 Event Packages for INFO" type thing, but after your emails on the subject we were convinced that was a bad way to go.  I apologize for not cleaning it up better before submission.  Do you want me to re-submit using better terminology?  (unfortunately due to the submission deadlines I don't think I can do so officially?)
>
> I was thinking this was really just a discussion point doc for the Vancouver meeting, and if the concept in general was adopted we'd fix all the terminology.
>
> Sorry 'bout that.  :(
>   

No problem -- I know how hectic things can get before the face-to-face 
meetings. Perhaps a bit more heads-up (either in the document or on the 
mailing list) that the event-package terminology was a known issue would 
have helped.

Comments follow. To prevent my fingers from burning while I type this, I 
will use the terms "Info Package", "Send-Info" and "Recv-Info" instead 
of "Info Event Package," "Send-Event," and "Recv-Event" as currently 
found in the document. I'll also talk about the header field 
"Info-Profile" instead of "Event".

----

General nit: s/header/header field/g

----

      [NOTE: do we need to support the "id" concept as well?  Is there 
   a use case?] 


The "id" concept in 3261 is to support multiple SUBSCRIBE usages in a 
dialog. Because INFO is part of an INVITE dialog, there can be only one. 
You don't need "id" for INFO.

----

The document needs some discussion around grandfathering existing 
standardized usages, similar to what 3265 did for PINT. Specifically, we 
want a way at the beginning of the dialog that one can use to usually 
detect that ISUP or QSIG will be sent, and text specifically indicating 
that ISUP and QSIG payloads without an "Info-Profile" header field can 
be interpreted according to the appropriate legacy RFCs. This impacts 
normative languages elsewhere (like the "MUST NOT" in the first 
paragraph of section 5.1).

I would be careful about grandfathering DTMF, simply because doing so 
would require clear definition of what those INFO messages mean, and 
consensus on that topic would take more than a little work. (A taste of 
what you'll argue about: do they represent tones? Keypresses? Generic 
user stimulus? Are they sent with in-band DTMF or instead of it? If you 
receive both, what does it mean? If they are tones, how do they get 
synced with the RTP stream and re-insterted?)

----

In terms of where the events are negotiated: I think this probably needs 
to follow the general offer/answer rules for greatest flexibility. The 
key reason is 3PCC. If a 3PCC is bringing two parties together to 
communicate, it won't be able to indicate supported Info Packages in the 
initial INVITE. It would be useful, then, for the first party contacted 
to be able to indicate Send-Info and Recv-Info in its 200-class 
response, and get a negotiated set of packages in the ACK.

----

   A Re-INVITE or UPDATE request MUST NOT contain any Send-Event or 
   Recv-Event headers, and such headers MUST be ignored on reception.  
   The info-event package negotiation is performed during the initial 
   INVITE transaction, and there is no re-negotiation. 
    
   [Is that ok?  Is there a need to have re-negotiation? (is there a 
   use case?)  It sure makes it simple not to have things change in the 
   middle of a session] 


I think you run into unsolvable 3PCC interactions here as well, since a 
3PCC can switch out one party of a call -- this could result in a 
completely different set of Info Packages being valid after the switch-out.

It is also remotely conceivable that a reconfiguration of the client may 
result in a change in available packages; for example, a client may 
advertise a video-related Info Package for video calls, but not for 
other kinds of calls; an upgrade to video under such circumstances would 
warrant a change in available packages.

----

   If an Invite usage fails or is terminated, the Info-based 
   event state no longer exists, and an INFO request MUST NOT be sent. 


You probably also want to briefly mention INFO/BYE glare (and similar 
situations) and how it should be handled.

----

   Recv-Event          18x        -   -   -   o   o   -   - 


I think you mean "1xx", not "18x"

----

The document needs to talk about appropriate rates of INFO transmission 
so as to not overwhelm the proxy network. You also need to discuss the 
responsibilities of Info Package definitions (similar to RFC 3265, 
section 4.4 and its subsections).

----

I would also suggest a discussion of Supported/Require as it pertains to 
specific Info Packages, so as to avoid the discussion around, "but what 
if I *want* the call to fail if a specific package isn't supported?"

----

Discussion of handling of the Send-Info and Recv-Info in REGISTER and 
OPTIONS is also warranted. You may think it's intuitive and doesn't need 
explanation, but I promise that people will get it wrong without 
specific language around what these things mean (for example: does the 
Recv-Info header field in an OPTIONS response describe all the Info 
Packages a UA can receive, or only that subset that was indicated in the 
OPTIONS request?).  I _DO_ think the presence of these fields in at 
least OPTIONS (and, to a lesser degree, REGISTER) would be a very useful 
thing.

----

Finally, I would argue that INFO is old enough (it predates 3261!) -- 
and consequently sufficiently out of date -- that it makes more sense to 
incorporate the definition of INFO into this document and aim to 
*replace* RFC 2976 instead of update it. (When you take the tables and 
boilerplate out of 2976, it comes to only a couple pages in length).

/a




_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 17:49:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix9EV-0008NX-L8; Tue, 27 Nov 2007 17:48:47 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix9ET-0008Iv-IR
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 17:48:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9ET-0008I9-88
	for sip@ietf.org; Tue, 27 Nov 2007 17:48:45 -0500
Received: from dnsmx2pya.telcordia.com ([128.96.20.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix9EQ-0005ik-BY
	for sip@ietf.org; Tue, 27 Nov 2007 17:48:45 -0500
Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com
	[128.96.20.21])
	by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id lARMmfP14188
	for ; Tue, 27 Nov 2007 17:48:41 -0500 (EST)
Received: from rrc-dte-exbh02.dte.telcordia.com ([128.96.109.16])
	by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id
	M2007112717483803660
	for ; Tue, 27 Nov 2007 17:48:38 -0500
Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by
	rrc-dte-exbh02.dte.telcordia.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:48:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 27 Nov 2007 17:48:37 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Need for RPH in SIP Responses
thread-index: AcgxR6Xo+opTKDioRVyYpl8WSOkQTQ==
From: "Sandesara, Niranjan B" 
To: 
X-OriginalArrivalTime: 27 Nov 2007 22:48:38.0805 (UTC)
	FILETIME=[A6A0BC50:01C83147]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57
Cc: "Wainberg, Stanley" 
Subject: [Sip] Need for RPH in SIP Responses
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1686328528=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1686328528==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C83147.A63F3272"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C83147.A63F3272
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

It seems to me that the strongest argument for the inclusion of RPH in
SIP responses is illustrated by the following two use cases.

=20

Authentication, authorization and assignment of priority for a GETS/WPS
call happens in the middle of the network, and preceding nodes (between
the caller and the authenticating node)

=20

A)      are initially aware of the GETS/WPS call but they need to know
the priority level assigned to the call after authorization, or

B)      are initially not aware of the GETS/WPS call and they need to
know that the call is authorized as a GETS/WPS call and they also need
to know the priority level assigned to the call after authorization.

=20

The Internet Draft, "Requirements for SIP Resource Priority Header in
SIP Responses" (draft-gunn-sip-req-for-rph-in-responses-00) has
described the use case A).

=20

The Internet Draft, "Allowing SIP Resource Priority Header in SIP
Responses" (draft-polk-sip-rph-in-responses-00) identifies the need for
inclusion of RPH in SIP responses for the benefit of stateless servers
in some environments. This draft proposes that a UAS can optionally
include an RPH in a SIP response. It also proposes that a receiving node
may choose to ignore the RPH. In other words, both the inclusion of the
RPH in responses and processing of the received RPH in responses are
optional capabilities. Nodes and networks can choose not to implement
these capabilities.=20

=20

It is critical to get the RPH with the caller's priority level back to
the originating network node after the GETS/WPS call authorization since
this is needed to reserve access (and possibly other) resources
immediately. Radio access resources are very limited, and during
emergency, they are typically congested and not available to the few
first responders that need to place calls. The operation of GETS/WPS is
dependent on the capability of inclusion of RPH in SIP responses.

=20

Regards,

=20

Niranjan Sandesara


------_=_NextPart_001_01C83147.A63F3272
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
















It seems to me that the strongest argument for the =
inclusion
of RPH in SIP responses is illustrated by the following two use =
cases.



 



Authentication, authorization and assignment of =
priority for
a GETS/WPS call happens in the middle of the network, and preceding =
nodes
(between the caller and the authenticating =
node)



 



A)      =
are
initially aware of the GETS/WPS call but they need to know the priority =
level
assigned to the call after authorization, =
or



B)      =
are
initially not aware of the GETS/WPS call and they need to know that the =
call is
authorized as a GETS/WPS call and they also need to know the priority =
level
assigned to the call after authorization.



 



The Internet Draft, “Requirements for SIP =
Resource
Priority Header in SIP Responses”
(draft-gunn-sip-req-for-rph-in-responses-00) has described the use case =
A).



 



The Internet Draft, “Allowing SIP Resource =
Priority
Header in SIP Responses” (draft-polk-sip-rph-in-responses-00) =
identifies
the need for inclusion of RPH in SIP responses for the benefit of =
stateless
servers in some environments. This draft proposes that a UAS can =
optionally
include an RPH in a SIP response. It also proposes that a receiving node =
may
choose to ignore the RPH. In other words, both the inclusion of the RPH =
in
responses and processing of the received RPH in responses are optional =
capabilities.
Nodes and networks can choose not to implement these capabilities. =




 



It is critical to get the RPH with the caller’s
priority level back to the originating network node after the GETS/WPS =
call
authorization since this is needed to reserve access (and possibly =
other)
resources immediately. Radio access resources are very limited, and =
during
emergency, they are typically congested and not available to the few =
first
responders that need to place calls. The operation of GETS/WPS is =
dependent on
the capability of inclusion of RPH in SIP =
responses.



 



Regards,



 



Niranjan Sandesara









------_=_NextPart_001_01C83147.A63F3272--



--===============1686328528==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1686328528==--





From sip-bounces@ietf.org Tue Nov 27 18:07:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ix9Vh-00028O-JI; Tue, 27 Nov 2007 18:06:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ix9Vg-00028C-I3
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 18:06:32 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9Vg-000284-6O
	for sip@ietf.org; Tue, 27 Nov 2007 18:06:32 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix9Vf-0005Gg-0J
	for sip@ietf.org; Tue, 27 Nov 2007 18:06:32 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-5.cisco.com with ESMTP; 27 Nov 2007 15:06:30 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lARN6UJw024866; 
	Tue, 27 Nov 2007 15:06:30 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lARN687b010421;
	Tue, 27 Nov 2007 23:06:29 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 27 Nov 2007 18:06:21 -0500
Received: from [161.44.174.179] ([161.44.174.179]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 27 Nov 2007 18:06:21 -0500
Message-ID: <474CA2ED.9080005@cisco.com>
Date: Tue, 27 Nov 2007 18:06:21 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Adam Roach 
Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
References: 	<4741F8A7.204@nostrum.com>	
	<474C94EF.10905@nostrum.com>
In-Reply-To: <474C94EF.10905@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Nov 2007 23:06:21.0025 (UTC)
	FILETIME=[1FC2A510:01C8314A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7279; t=1196204790;
	x=1197068790; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20FW=3A=20I-D=20Action=3Adraft-kaplan-sip-info-
	events-00.txt |Sender:=20;
	bh=GjzGEHEKcLlfsEp1EL1eQ+flXjlgHceQB/IeqDjDrv0=;
	b=xvA4pGyzFyWHCjMuW4O5Gu2Eva/Qq/4G2q9SR6d14+uo89hVgvR7qs7oMdnDJre7cbYy1+vY
	kML4NnXlvYHeBfn4QLC41D8250bsS8Nwh2Cqne6lH1ibPiJS6xuhOQ/v;
Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
Cc: "sip@ietf.org" ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I agree with Adam's comments. I've added a small amount of commentary.

	Thanks,
	Paul

Adam Roach wrote:
> On 11/19/07 3:07 PM, Hadriel Kaplan wrote:
>> Yeah my bad for not re-writing that whole thing.  It started out as a 
>> "rfc3265 Event Packages for INFO" type thing, but after your emails on 
>> the subject we were convinced that was a bad way to go.  I apologize 
>> for not cleaning it up better before submission.  Do you want me to 
>> re-submit using better terminology?  (unfortunately due to the 
>> submission deadlines I don't think I can do so officially?)
>>
>> I was thinking this was really just a discussion point doc for the 
>> Vancouver meeting, and if the concept in general was adopted we'd fix 
>> all the terminology.
>>
>> Sorry 'bout that.  :(
>>   
> 
> No problem -- I know how hectic things can get before the face-to-face 
> meetings. Perhaps a bit more heads-up (either in the document or on the 
> mailing list) that the event-package terminology was a known issue would 
> have helped.
> 
> Comments follow. To prevent my fingers from burning while I type this, I 
> will use the terms "Info Package", "Send-Info" and "Recv-Info" instead 
> of "Info Event Package," "Send-Event," and "Recv-Event" as currently 
> found in the document. I'll also talk about the header field 
> "Info-Profile" instead of "Event".
> 
> ----
> 
> General nit: s/header/header field/g
> 
> ----
> 
>      [NOTE: do we need to support the "id" concept as well?  Is there   
> a use case?]
> 
> The "id" concept in 3261 is to support multiple SUBSCRIBE usages in a 
> dialog. Because INFO is part of an INVITE dialog, there can be only one. 
> You don't need "id" for INFO.

I think the id is used to support multiple subscribe usages *of the same 
event type* in a dialog. (Not needed for different event types.)

Presumably more than one of these "Info Packages" can be used in the 
same INVITE dialog. I guess the question remains whether it would ever 
make sense to have more than one of the same type. I guess that depends 
on whether they can be parameterized in some way such that it would make 
sense to have more than one. I suppose the simplest answer is to declare 
that this won't be supported. Then the id isn't needed.

> ----
> 
> The document needs some discussion around grandfathering existing 
> standardized usages, similar to what 3265 did for PINT. Specifically, we 
> want a way at the beginning of the dialog that one can use to usually 
> detect that ISUP or QSIG will be sent, and text specifically indicating 
> that ISUP and QSIG payloads without an "Info-Profile" header field can 
> be interpreted according to the appropriate legacy RFCs. This impacts 
> normative languages elsewhere (like the "MUST NOT" in the first 
> paragraph of section 5.1).
> 
> I would be careful about grandfathering DTMF, simply because doing so 
> would require clear definition of what those INFO messages mean, and 
> consensus on that topic would take more than a little work. (A taste of 
> what you'll argue about: do they represent tones? Keypresses? Generic 
> user stimulus? Are they sent with in-band DTMF or instead of it? If you 
> receive both, what does it mean? If they are tones, how do they get 
> synced with the RTP stream and re-insterted?)
> 
> ----
> 
> In terms of where the events are negotiated: I think this probably needs 
> to follow the general offer/answer rules for greatest flexibility. The 
> key reason is 3PCC. If a 3PCC is bringing two parties together to 
> communicate, it won't be able to indicate supported Info Packages in the 
> initial INVITE. It would be useful, then, for the first party contacted 
> to be able to indicate Send-Info and Recv-Info in its 200-class 
> response, and get a negotiated set of packages in the ACK.

AMEN!

> ----
> 
>   A Re-INVITE or UPDATE request MUST NOT contain any Send-Event or   
> Recv-Event headers, and such headers MUST be ignored on reception.    
> The info-event package negotiation is performed during the initial   
> INVITE transaction, and there is no re-negotiation.      [Is that ok?  
> Is there a need to have re-negotiation? (is there a   use case?)  It 
> sure makes it simple not to have things change in the   middle of a 
> session]
> 
> I think you run into unsolvable 3PCC interactions here as well, since a 
> 3PCC can switch out one party of a call -- this could result in a 
> completely different set of Info Packages being valid after the switch-out.
> 
> It is also remotely conceivable that a reconfiguration of the client may 
> result in a change in available packages; for example, a client may 
> advertise a video-related Info Package for video calls, but not for 
> other kinds of calls; an upgrade to video under such circumstances would 
> warrant a change in available packages.

A hybrid of the two above is a PSTN GW, where a call transfer happens on 
the PSTN side.

> ----
> 
>   If an Invite usage fails or is terminated, the Info-based   event 
> state no longer exists, and an INFO request MUST NOT be sent.
> 
> You probably also want to briefly mention INFO/BYE glare (and similar 
> situations) and how it should be handled.
> 
> ----
> 
>   Recv-Event          18x        -   -   -   o   o   -   -
> 
> I think you mean "1xx", not "18x"
> 
> ----
> 
> The document needs to talk about appropriate rates of INFO transmission 
> so as to not overwhelm the proxy network. You also need to discuss the 
> responsibilities of Info Package definitions (similar to RFC 3265, 
> section 4.4 and its subsections).
> 
> ----
> 
> I would also suggest a discussion of Supported/Require as it pertains to 
> specific Info Packages, so as to avoid the discussion around, "but what 
> if I *want* the call to fail if a specific package isn't supported?"
> 
> ----
> 
> Discussion of handling of the Send-Info and Recv-Info in REGISTER and 
> OPTIONS is also warranted. You may think it's intuitive and doesn't need 
> explanation, but I promise that people will get it wrong without 
> specific language around what these things mean (for example: does the 
> Recv-Info header field in an OPTIONS response describe all the Info 
> Packages a UA can receive, or only that subset that was indicated in the 
> OPTIONS request?).  I _DO_ think the presence of these fields in at 
> least OPTIONS (and, to a lesser degree, REGISTER) would be a very useful 
> thing.
> 
> ----
> 
> Finally, I would argue that INFO is old enough (it predates 3261!) -- 
> and consequently sufficiently out of date -- that it makes more sense to 
> incorporate the definition of INFO into this document and aim to 
> *replace* RFC 2976 instead of update it. (When you take the tables and 
> boilerplate out of 2976, it comes to only a couple pages in length).
> 
> /a
> 
> 
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Tue Nov 27 20:35:20 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxBov-00030y-7i; Tue, 27 Nov 2007 20:34:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxBot-00030q-R4
	for sip-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 20:34:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxBot-00030U-HQ
	for sip@ietf.org; Tue, 27 Nov 2007 20:34:31 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxBot-0001Z0-2A
	for sip@ietf.org; Tue, 27 Nov 2007 20:34:31 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 5C84F33C21
	for ; Tue, 27 Nov 2007 17:29:31 -0800 (PST)
Date: Tue, 27 Nov 2007 17:29:30 -0800
From: Eric Rescorla 
To: sip@ietf.org
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071128012931.5C84F33C21@delta.rtfm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: [Sip] Comments on draft-wing-sip-identity-media-01
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

$Id: draft-wing-sip-identity-media-01-rev.txt,v 1.1 2007/11/28 01:26:28 ekr Exp $

This draft seems to do two distinct things:

- One specify a variant of RFC 4474 which signs a lot fewer headers.
- Specify a set of mechanisms to cryptographically prove that a given media
  stream corresponds to a given SDP offer/answer.

As I understand it, the rationale for the first of these is that
SBCs will break RFC 4474 signatures and won't have the public
keys required to generate new ones. I'm not really a SIP expert,
but I thought that the party line was the SBCs were B2BUAs
and so whatever the identity of the SBC was was the UAC,
so if that SBC doesn't have the right credentials to sign
an RFC 4474 identity for "alice@example.com" then it shouldn't
be attesting to it. But again, I could be totally misunderstanding
3261, etc.

That said, as I read S 3.1.3, the SBC signs
"alice%example.com@sbc.com". I don't really understand
what the recipient of such an identity is to make of this,
since surely we wouldn't want anyone to be able to attest
to other people's identities like this. So, this means
that the relying party needs to have some list of the
form "the following SBC cert can sign for the following 
domains". How does this get communicated? Is this really
easier than giving the SBC the private key?


With regard to the second issue, I agree this is important,
but this is an orthogonal issue to which headers get signed,
right? In general, we certainly do want a way to tie media
to keying cryptographically, but as you note, DTLS-SRTP
already provides this. I don't quite see why you *always*
need this proof. What about requests that don't come
with media? Anyway, are you claiming this is also a problem
for RFC 4474?

-Ekr


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 00:58:24 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxFvR-00082S-7w; Wed, 28 Nov 2007 00:57:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxFvP-0007zI-Mh
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 00:57:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxFvP-0007z6-Bm
	for sip@ietf.org; Wed, 28 Nov 2007 00:57:31 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxFvO-0000TQ-RO
	for sip@ietf.org; Wed, 28 Nov 2007 00:57:31 -0500
Received: from [206.176.144.210] (206-176-144-210.waymark.net
	[206.176.144.210]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAS5v8fJ032602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 27 Nov 2007 23:57:10 -0600
Message-ID: <474D032F.7000902@softarmor.com>
Date: Tue, 27 Nov 2007 23:57:03 -0600
From: Dean Willis 
User-Agent: Icedove 1.5.0.14pre (X11/20071018)
MIME-Version: 1.0
To: Matt Lepinski 
Subject: Re: R: R: [Sip] a question about IETF draft location  conveyance
 09
References: <4742BDF5.9040302@unibo.it>								<4745BDC7.30003@gmx.net>				<5D1A7985295922448D5550C94DE2918001974BEC@DEEXC1U01.de.lucent.com>	
	<474B4364.60609@bbn.com>
In-Reply-To: <474B4364.60609@bbn.com>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: IETF SIP List , "James M. Polk" , "DRAGE,
	Keith \(Keith\)" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Matt Lepinski wrote:
> James,
> 
> I do believe that the intent of Ted (as well as others in the GEOPRIV
> working group, including myself) is that if a UAC specifies
> "recipient=endpoint" then a compliant proxy will not 'read' the location
> body. In particular, "recipient=endpoint" indicates that a SIP proxy in
> the signaling path does not have permission to store the location (or
> any derived information) for longer than is necessary to forward the SIP
> message and does not have permission to send the location to any third
> party (for any reason including location-based routing) other than the
> next-hop SIP proxy. That is, the intent of "recipient=endpoint" that if
> a call requires location-based routing in order to succeed, then the
> call should fail.

RFC 2119 defines MUST NOT. It says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with security
   implications.  The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification

I can't see any failure of interoperability that results if a proxy
"reads" the location body in violation of the user's preference
described by "recipient=endpoint". I can also see application scenarios
(ex: emergency) where applications can be assured of not operating
unless the proxy violates this prohibition. So we've missed the #6
guidance on "MUST NOT".

Can we justify a "MUST NOT" based on security considerations? Given (as
in emergency) that there are applications in which the application MUST
read the location, I don't think so.

What we really have is guidance that says, in normal operation, proxies
don't include the location in application logic when recipient=endpoint
is specified by the user, because in general this indicator means that
the user is asking the proy to NOT include the location in application
logic by attaching this modifier.

So we're at the level of a "SHOULD NOT", not a "MUST NOT" as described
by RFC 2119. And even then I suspect the discussion of this requirement
needs careful elucidation as to the problems resulting (or likely to
result) if a proxy violates this requirement.

--
Dean



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 02:34:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxHQG-0002TJ-Su; Wed, 28 Nov 2007 02:33:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxHQD-0002Rj-Jw
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 02:33:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxHQD-0002RD-09
	for sip@ietf.org; Wed, 28 Nov 2007 02:33:25 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxHQC-00033B-Jl
	for sip@ietf.org; Wed, 28 Nov 2007 02:33:24 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Wed, 28 Nov 2007 02:33:24 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Wed, 28 Nov 2007 02:33:24 -0500
From: Hadriel Kaplan 
To: Dan Wing , 'Jonathan Rosenberg' 
Date: Wed, 28 Nov 2007 02:33:19 -0500
Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] comments on
	draft-ietf-sip-dtls-framework]
Thread-Topic: SIP E.164 Return Routability Test [was RE: [Sip] comments on
	draft-ietf-sip-dtls-framework]
Thread-Index: Acgwi07Crf47s/HJTi62Zh6Z781p2QAAYaKwAC5ewqA=
Message-ID: 
References: <4741BB94.80202@cisco.com>
	<4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net><474AC204.9080606@cisco.com>
	<474B62C7.6050604@cisco.com> <134b01c83092$ddee7590$c5f0200a@cisco.com>
In-Reply-To: <134b01c83092$ddee7590$c5f0200a@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: 'Cullen Jennings' , 'IETF SIP List' ,
	'Paul Kyzivat' , "'Elwell,
	John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Monday, November 26, 2007 8:15 PM
>
> As Paul and Francois suggested, using ENUM could provide a way
> to determine if the signer was authorized to sign for a certain
> E.164.  However, ENUM is not widely deployed and is mired in
> non-technical issues.

ENUM is widely deployed, IMO, it's just not public ENUM. ;)


> Another approach that I have considered is a SIP return-
> routability test.  This provides better flexibility and
> does not require a priori configuration of policy for which
> domains you trust to sign or to resign; of course, if you
> do trust  certain domains to resign certain things, you can
> short-cut this return-routability (because it will always
> return the same information you already have).  Thus, you
> can consider the SIP return-routability an additional
> enhancement for a SIP network where you don't already
> know which domains are going to send you Invites.

Clever idea!  Sorta emulates what some people do for PSTN calls already (e.=
g., Bank calls you, and you call them at their public number to verify).  O=
r what web systems and mail-list servers do by sending an email with a cook=
ie to verify new users.

But it demands symmetric origination+termination, which doesn't always happ=
en.  For example, your call to me may well go through the PSTN before reach=
ing me on SIP, but my Subscribe to you will go pure SIP - maybe due to leas=
t-cost routing, different route policies, etc.  So while your Invite-based =
call to me may come in "legitimately" as From: , my Subscribe to sip:+14088675309@mybell.com may be received/answered b=
y cisco.com.  Even if there were a public ENUM DB this problem would happen=
.

Of course you could just take the username portion of the From and send a n=
ew Invite for a new dialog (maybe even with a Replaces header concept) out =
instead of Subscribe, and really emulate what people do on the PSTN... but =
I'm not advocating that. :)

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 07:09:38 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxLik-00036Z-08; Wed, 28 Nov 2007 07:08:50 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxLii-000369-3s
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 07:08:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxLih-000360-NK
	for sip@ietf.org; Wed, 28 Nov 2007 07:08:47 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxLih-0002hx-6C
	for sip@ietf.org; Wed, 28 Nov 2007 07:08:47 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Wed, 28 Nov 2007 07:08:46 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Wed, 28 Nov 2007 07:08:46 -0500
From: Hadriel Kaplan 
To: Eric Rescorla , "sip@ietf.org" 
Date: Wed, 28 Nov 2007 07:07:29 -0500
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Topic: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Index: AcgxXuG9NwDhn8kkTrKFLz11kdNm7AARZ2qw
Message-ID: 
References: <20071128012931.5C84F33C21@delta.rtfm.com>
In-Reply-To: <20071128012931.5C84F33C21@delta.rtfm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]
> Sent: Tuesday, November 27, 2007 8:30 PM
>
> This draft seems to do two distinct things:
>
> - One specify a variant of RFC 4474 which signs a lot fewer headers.

Yup, and thereby increase its chance of success.


> - Specify a set of mechanisms to cryptographically prove that a given
> media
>   stream corresponds to a given SDP offer/answer.

Yup, but it may need this second part to compensate for the first part. (fo=
r some cases)


> As I understand it, the rationale for the first of these is that
> SBCs will break RFC 4474 signatures and won't have the public
> keys required to generate new ones. I'm not really a SIP expert,
> but I thought that the party line was the SBCs were B2BUAs
> and so whatever the identity of the SBC was was the UAC,
> so if that SBC doesn't have the right credentials to sign
> an RFC 4474 identity for "alice@example.com" then it shouldn't
> be attesting to it. But again, I could be totally misunderstanding
> 3261, etc.

Yeah so this is going to go into a big black hole methinks, and like all go=
od black holes, trying to shed light on it won't make things clearer. :)  I=
 mean we would get into some philosophical debate about the meaning of "ide=
ntity" and what "attesting to it" means.

I don't think we need to talk about this in the context of B2BUA's and the =
identity they do or don't represent, though.  Maybe we can just talk about =
the draft's mechanism as being palatable or not based on whether it address=
es the same issues 4474 did, with similar benefits, in a reasonably secure =
a fashion, albeit in a different way?

So for example, comparing this mechanism to 4474, is it as legit?  What add=
itional weaknesses does it create, and are they untenable? (I can think of =
a few, mostly MITM related of course)


> That said, as I read S 3.1.3, the SBC signs
> "alice%example.com@sbc.com". I don't really understand
> what the recipient of such an identity is to make of this,
> since surely we wouldn't want anyone to be able to attest
> to other people's identities like this. So, this means
> that the relying party needs to have some list of the
> form "the following SBC cert can sign for the following
> domains". How does this get communicated? Is this really
> easier than giving the SBC the private key?

Actually that example was meant to demonstrate the unpalatable way to addre=
ss the problem without this draft.  In other words, it's a "this is how cra=
zy 4474 would become" type thing.  It wasn't about how the draft's proposed=
 mechanism would work, nor how 4474 should work.  :)


> With regard to the second issue, I agree this is important,
> but this is an orthogonal issue to which headers get signed,
> right?

I'll leave that to Dan, but I think you need this second issue addressed to=
 explain why not signing the c=3D/m=3D is ok.


> In general, we certainly do want a way to tie media
> to keying cryptographically, but as you note, DTLS-SRTP
> already provides this. I don't quite see why you *always*
> need this proof. What about requests that don't come
> with media? Anyway, are you claiming this is also a problem
> for RFC 4474?

You mean offer-less Invites?  Yes, that's already a problem for 4474.  If y=
ou mean for non-SDP requests (e.g., MESSAGE or SUB/NOT), the mechanism in t=
his draft would sign that whole MIME body as 4474 did, except still sign fe=
wer headers.

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 08:16:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxMlm-0006X1-Ej; Wed, 28 Nov 2007 08:16:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxMlk-0006Vr-7W
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:16:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMlj-0006VZ-6f
	for sip@ietf.org; Wed, 28 Nov 2007 08:15:59 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxMlh-0007lb-G0
	for sip@ietf.org; Wed, 28 Nov 2007 08:15:59 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Wed, 28 Nov 2007 08:15:57 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Wed, 28 Nov 2007 08:15:54 -0500
From: Hadriel Kaplan 
To: Adam Roach 
Date: Wed, 28 Nov 2007 08:14:31 -0500
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Thread-Index: AcgxQcTJJy5pUX1uQ9GyO0O5y6nvdAAWzGEQ
Message-ID: 
References: 
	<4741F8A7.204@nostrum.com>
	
	<474C94EF.10905@nostrum.com>
In-Reply-To: <474C94EF.10905@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: "sip@ietf.org" ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Thanks for the great feedback Adam - comments inline...


> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Tuesday, November 27, 2007 5:07 PM
>
> General nit: s/header/header field/g
# that statement is su-perl-ative
print "will do\n";

> The document needs some discussion around grandfathering existing
> standardized usages, similar to what 3265 did for PINT. Specifically, we
> want a way at the beginning of the dialog that one can use to usually
> detect that ISUP or QSIG will be sent, and text specifically indicating
> that ISUP and QSIG payloads without an "Info-Profile" header field can
> be interpreted according to the appropriate legacy RFCs. This impacts
> normative languages elsewhere (like the "MUST NOT" in the first
> paragraph of section 5.1).

My take on this is that ISUP/QSIG use of INFO is not Info-Package use, and =
so follows its own rules (though we should have said so).  If this draft be=
comes a replacement for 2976, however, then that's a bigger deal.  So yeah =
I agree, regardless.


> I would be careful about grandfathering DTMF, simply because doing so
> would require clear definition of what those INFO messages mean, and
> consensus on that topic would take more than a little work. [...snip]

What do you mean about "grandfathering DTMF"?  (are you reading that in the=
 draft somewhere?)  I'm confused.


> In terms of where the events are negotiated: I think this probably needs
> to follow the general offer/answer rules for greatest flexibility. The
> key reason is 3PCC. If a 3PCC is bringing two parties together to
> communicate, it won't be able to indicate supported Info Packages in the
> initial INVITE. It would be useful, then, for the first party contacted
> to be able to indicate Send-Info and Recv-Info in its 200-class
> response, and get a negotiated set of packages in the ACK.

I'm trying to understand some specific scenarios you're worried about.  Can=
 you describe the scenarios with examples why the 3PCC model breaks here? (=
I don't doubt they exist - I just don't see it)


> I think you run into unsolvable 3PCC interactions here as well, since a
> 3PCC can switch out one party of a call -- this could result in a
> completely different set of Info Packages being valid after the switch-
> out.
>
> It is also remotely conceivable that a reconfiguration of the client may
> result in a change in available packages; for example, a client may
> advertise a video-related Info Package for video calls, but not for
> other kinds of calls; an upgrade to video under such circumstances would
> warrant a change in available packages.

Yeah for those I can see re-Invite really should re-negotiate Info-package =
support.  (But still not clear on why we need delayed indications of suppor=
ted Info-packages.)


> You probably also want to briefly mention INFO/BYE glare (and similar
> situations) and how it should be handled.

Yeah good point.

>    Recv-Event          18x        -   -   -   o   o   -   -
> I think you mean "1xx", not "18x"

Yup.

> The document needs to talk about appropriate rates of INFO transmission
> so as to not overwhelm the proxy network. You also need to discuss the
> responsibilities of Info Package definitions (similar to RFC 3265,
> section 4.4 and its subsections).

Is there any such "appropriate rates" discussion in other Request Method RF=
Cs? (other than specific mechanisms such as session-expires)  I mean wouldn=
't that be part of the package definition to deal with, if at all?


> I would also suggest a discussion of Supported/Require as it pertains to
> specific Info Packages, so as to avoid the discussion around, "but what
> if I *want* the call to fail if a specific package isn't supported?"

Yeah, so I think that begs the question if we should care about that case. =
 Like there is no real way to signal such for many media-related items.  Fo=
r example you can offer 2833, but you can't do "reject this request if you'=
re not going to answer me 2833", and no one's complained this was needed (r=
ight?).


> Discussion of handling of the Send-Info and Recv-Info in REGISTER and
> OPTIONS is also warranted. You may think it's intuitive and doesn't need
> explanation, but I promise that people will get it wrong without
> specific language around what these things mean (for example: does the
> Recv-Info header field in an OPTIONS response describe all the Info
> Packages a UA can receive, or only that subset that was indicated in the
> OPTIONS request?).  I _DO_ think the presence of these fields in at
> least OPTIONS (and, to a lesser degree, REGISTER) would be a very useful
> thing.

That last sentence was the big question - assuming that holds, we would def=
initely put in explicit wording around it.


> Finally, I would argue that INFO is old enough (it predates 3261!) --
> and consequently sufficiently out of date -- that it makes more sense to
> incorporate the definition of INFO into this document and aim to
> *replace* RFC 2976 instead of update it. (When you take the tables and
> boilerplate out of 2976, it comes to only a couple pages in length).

Agreed.

-hadriel


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 08:38:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxN6H-00038b-HC; Wed, 28 Nov 2007 08:37:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxN6G-00038E-6P
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:37:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxN6F-00037J-SW
	for sip@ietf.org; Wed, 28 Nov 2007 08:37:11 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxN6E-0001Gv-3E
	for sip@ietf.org; Wed, 28 Nov 2007 08:37:11 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2007 08:37:09 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lASDb9dq031172; 
	Wed, 28 Nov 2007 08:37:09 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lASDb80k023140; 
	Wed, 28 Nov 2007 13:37:09 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Nov 2007 08:37:04 -0500
Received: from [10.86.241.205] ([10.86.241.205]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Nov 2007 08:37:04 -0500
Message-ID: <474D6EFF.9010407@cisco.com>
Date: Wed, 28 Nov 2007 08:37:03 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] Comments on draft-wing-sip-identity-media-01
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Nov 2007 13:37:04.0376 (UTC)
	FILETIME=[C3395F80:01C831C3]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4302; t=1196257029;
	x=1197121029; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20Comments=20on=20draft-wing-sip-identity-media
	-01 |Sender:=20
	|To:=20Hadriel=20Kaplan=20;
	bh=rV+A9skAdkxIGA5IgdmmoB7qw/5M6w+IGpoqyuHLQcE=;
	b=kMW8ufN6pqZGQvHoEnSOLY4zeSaFDqSK3a8lyNu9czTkEI5ElocpZVpApehrs2Vnas3F5953
	HFu3K4iBJGkTZ1h8HS1NFXe0KiHTlJiE0vXKBMmevHulGpjX8zucgL5c;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: "sip@ietf.org" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Eric Rescorla [mailto:ekr@networkresonance.com]
>> Sent: Tuesday, November 27, 2007 8:30 PM
>>
>> This draft seems to do two distinct things:
>>
>> - One specify a variant of RFC 4474 which signs a lot fewer headers.
> 
> Yup, and thereby increase its chance of success.
> 
> 
>> - Specify a set of mechanisms to cryptographically prove that a given
>> media
>>   stream corresponds to a given SDP offer/answer.
> 
> Yup, but it may need this second part to compensate for the first part. (for some cases)
> 
> 
>> As I understand it, the rationale for the first of these is that
>> SBCs will break RFC 4474 signatures and won't have the public
>> keys required to generate new ones. I'm not really a SIP expert,
>> but I thought that the party line was the SBCs were B2BUAs
>> and so whatever the identity of the SBC was was the UAC,
>> so if that SBC doesn't have the right credentials to sign
>> an RFC 4474 identity for "alice@example.com" then it shouldn't
>> be attesting to it. But again, I could be totally misunderstanding
>> 3261, etc.
> 
> Yeah so this is going to go into a big black hole methinks, and like all good black holes, trying to shed light on it won't make things clearer. :)  I mean we would get into some philosophical debate about the meaning of "identity" and what "attesting to it" means.

I hope that isn't a black hole, because I think those issued *need* to 
be worked out.

This is like the elephant in the living room that nobody is willing to 
mention.

There may indeed be value in signing a set of headers that can survive 
passing through an SBC. But the pros and cons of that need to be discussed.

	Thanks,
	Paul

> I don't think we need to talk about this in the context of B2BUA's and the identity they do or don't represent, though.  Maybe we can just talk about the draft's mechanism as being palatable or not based on whether it addresses the same issues 4474 did, with similar benefits, in a reasonably secure a fashion, albeit in a different way?
> 
> So for example, comparing this mechanism to 4474, is it as legit?  What additional weaknesses does it create, and are they untenable? (I can think of a few, mostly MITM related of course)
> 
> 
>> That said, as I read S 3.1.3, the SBC signs
>> "alice%example.com@sbc.com". I don't really understand
>> what the recipient of such an identity is to make of this,
>> since surely we wouldn't want anyone to be able to attest
>> to other people's identities like this. So, this means
>> that the relying party needs to have some list of the
>> form "the following SBC cert can sign for the following
>> domains". How does this get communicated? Is this really
>> easier than giving the SBC the private key?
> 
> Actually that example was meant to demonstrate the unpalatable way to address the problem without this draft.  In other words, it's a "this is how crazy 4474 would become" type thing.  It wasn't about how the draft's proposed mechanism would work, nor how 4474 should work.  :)
> 
> 
>> With regard to the second issue, I agree this is important,
>> but this is an orthogonal issue to which headers get signed,
>> right?
> 
> I'll leave that to Dan, but I think you need this second issue addressed to explain why not signing the c=/m= is ok.
> 
> 
>> In general, we certainly do want a way to tie media
>> to keying cryptographically, but as you note, DTLS-SRTP
>> already provides this. I don't quite see why you *always*
>> need this proof. What about requests that don't come
>> with media? Anyway, are you claiming this is also a problem
>> for RFC 4474?
> 
> You mean offer-less Invites?  Yes, that's already a problem for 4474.  If you mean for non-SDP requests (e.g., MESSAGE or SUB/NOT), the mechanism in this draft would sign that whole MIME body as 4474 did, except still sign fewer headers.
> 
> -hadriel
> 
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 11:59:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxQFh-0005VG-HW; Wed, 28 Nov 2007 11:59:09 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxQFf-0005Uo-Pr
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 11:59:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxQFf-0005Ue-Df
	for sip@ietf.org; Wed, 28 Nov 2007 11:59:07 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxQFe-0008K8-GG
	for sip@ietf.org; Wed, 28 Nov 2007 11:59:07 -0500
Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lASGx1rt013703
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 28 Nov 2007 10:59:01 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <474D9E60.4000105@nostrum.com>
Date: Wed, 28 Nov 2007 10:59:12 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
References: 	<4741F8A7.204@nostrum.com>		<474C94EF.10905@nostrum.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4942/Wed Nov 28 10:19:48 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: "sip@ietf.org" ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

On 11/28/07 7:14 AM, Hadriel Kaplan wrote:
>> I would be careful about grandfathering DTMF, simply because doing so
>> would require clear definition of what those INFO messages mean, and
>> consensus on that topic would take more than a little work. [...snip]
>>     
>
> What do you mean about "grandfathering DTMF"?  (are you reading that in the draft somewhere?)  I'm confused.
>   

The comment was meant in the context of grandfathering existing uses of 
INFO, and DTMF is the elephant in the room. The more general advice 
would be: "be careful in discussion of grandfathering existing INFO uses 
that you only include well-defined uses -- otherwise, you'll find 
yourself having to provide the detailed definition of such uses."

>> In terms of where the events are negotiated: I think this probably needs
>> to follow the general offer/answer rules for greatest flexibility. The
>> key reason is 3PCC. If a 3PCC is bringing two parties together to
>> communicate, it won't be able to indicate supported Info Packages in the
>> initial INVITE. It would be useful, then, for the first party contacted
>> to be able to indicate Send-Info and Recv-Info in its 200-class
>> response, and get a negotiated set of packages in the ACK.
>>     
>
> I'm trying to understand some specific scenarios you're worried about.  Can you describe the scenarios with examples why the 3PCC model breaks here? (I don't doubt they exist - I just don't see it)
>   

Basically, I think you'll run into problems if you can't support a 
scenario like this:


          A                 3PCC                  B
          |(1) INVITE         |                   |
          |(no Recv-Info)     |                   |
          |<------------------|                   |
          |(2) 200            |                   |
          |(Recv-Info A)      |                   |
          |------------------>|                   |
          |                   |(3) INVITE         |
          |                   |(Recv-Info A)      |
          |                   |------------------>|
          |                   |(4) 200            |
          |                   |(Send-Info A)      |
          |                   |<------------------|
          |                   |(5) ACK            |
          |                   |------------------>|
          |(6) ACK            |                   |
          |(Send-Info A)      |                   |
          |<------------------|                   |
          |(7) Media          |                   |
          |.......................................|
          |                   |(8) INFO           |
          |                   |<------------------|
          |(9) INFO           |                   |
          |<------------------|                   |



Without the ability to negotiate Info Packages in messages (2) and (5), 
you run into the basic inability to support this kind of thing.

>   
>> I think you run into unsolvable 3PCC interactions here as well, since a
>> 3PCC can switch out one party of a call -- this could result in a
>> completely different set of Info Packages being valid after the switch-
>> out.
>>
>> It is also remotely conceivable that a reconfiguration of the client may
>> result in a change in available packages; for example, a client may
>> advertise a video-related Info Package for video calls, but not for
>> other kinds of calls; an upgrade to video under such circumstances would
>> warrant a change in available packages.
>>     
>
> Yeah for those I can see re-Invite really should re-negotiate Info-package support.  (But still not clear on why we need delayed indications of supported Info-packages.)
>   

Beyond those use cases, you should keep the following flow in mind as 
well, which requires the ability to renegotiate Info Packages in re-INVITEs:


          A                 3PCC                  B
          |(1) INVITE         |                   |
          |(no Recv-Info)     |                   |
          |<------------------|                   |
          |(2) 200            |                   |
          |(Recv-Info A)      |                   |
          |------------------>|                   |
          |(3) ACK            |                   |
          |(no Send-Info)     |                   |
          |<------------------|                   |
          |                   |(4) INVITE         |
          |                   |(Recv-Info A)      |
          |                   |------------------>|
          |                   |(5) 200            |
          |                   |(Send-Info A)      |
          |                   |<------------------|
          |(6) INVITE         |                   |
          |(Send-Info A)      |                   |
          |<------------------|                   |
          |(7) 200            |                   |
          |(Recv-Info A)      |                   |
          |------------------>|                   |
          |                   |(8) ACK            |
          |                   |------------------>|
          |(9) ACK            |                   |
          |<------------------|                   |
          |(10) Media         |                   |
          |.......................................|
          |                   |(11) INFO          |
          |                   |<------------------|
          |(12) INFO          |                   |
          |<------------------|                   |


This actually highlights another very interesting point -- to make this 
flow work at all, A needs to indicate the Info Packages it is willing to 
send and receive in message (2), regardless of whether such packages 
appeared in message (1) at all. In other words, what appears in a 200 
can't be a subset of what was in the INVITE -- it should be a statement 
of absolute capabilities.

>
>> The document needs to talk about appropriate rates of INFO transmission
>> so as to not overwhelm the proxy network. You also need to discuss the
>> responsibilities of Info Package definitions (similar to RFC 3265,
>> section 4.4 and its subsections).
>>     
>
> Is there any such "appropriate rates" discussion in other Request Method RFCs? (other than specific mechanisms such as session-expires)  I mean wouldn't that be part of the package definition to deal with, if at all?
>
>
>   

If you plan for that to be the case, say so in the document. I suggest 
copying the first paragraph of RFC 3265, section 4.4.10, and the final 
paragraph of section 4.1, with appropriate changes in terminology.

>> I would also suggest a discussion of Supported/Require as it pertains to
>> specific Info Packages, so as to avoid the discussion around, "but what
>> if I *want* the call to fail if a specific package isn't supported?"
>>     
>
> Yeah, so I think that begs the question if we should care about that case.  Like there is no real way to signal such for many media-related items.  For example you can offer 2833, but you can't do "reject this request if you're not going to answer me 2833", and no one's complained this was needed (right?).
>   

I won't object one way or the other. I'm trying to make your life easier 
-- the arguments here are predictable, and my suggestion is an attempt 
to ward them off. You can ignore mu suggestion and I'll stay out of the 
way, but I doubt others will. I'll close by quoting an example already 
being given in this area (from Eric's draft):

  "Some uses of INFO can tolerate this fate sharing of the INFO message
   over the entire dialog.  For example, in the SIP-T usage, it may be
   acceptable for a call to fail, or to tear down the call, if one
   cannot deliver the associated SS7 information."


>> Discussion of handling of the Send-Info and Recv-Info in REGISTER and
>> OPTIONS is also warranted. You may think it's intuitive and doesn't need
>> explanation, but I promise that people will get it wrong without
>> specific language around what these things mean (for example: does the
>> Recv-Info header field in an OPTIONS response describe all the Info
>> Packages a UA can receive, or only that subset that was indicated in the
>> OPTIONS request?).  I _DO_ think the presence of these fields in at
>> least OPTIONS (and, to a lesser degree, REGISTER) would be a very useful
>> thing.
>>     
>
> That last sentence was the big question - assuming that holds, we would definitely put in explicit wording around it.
>   

I think we'd be muddling things up pretty badly if we suddenly started 
defining aspects of the protocol that are not discoverable via OPTIONS, 
but could be discovered via alternate means (e.g. INVITE). It's kind of 
changing the meaning of "OPTIONS".

The REGISTER usage isn't as clear cut. The reason I think it would be 
nice to have is that it allows me to come along later and define a 
caller-prefs that says, "I'm trying to reach Hadriel, and I'd prefer if 
I could reach him on a device that supports event package foo."


/a


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 13:10:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxRLj-0001EI-42; Wed, 28 Nov 2007 13:09:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxRLh-0001D9-DF
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 13:09:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRLh-0001Cl-1P
	for sip@ietf.org; Wed, 28 Nov 2007 13:09:25 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxRLg-00012i-LH
	for sip@ietf.org; Wed, 28 Nov 2007 13:09:24 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-2.cisco.com with ESMTP; 28 Nov 2007 10:09:24 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lASI9Ovr004450; 
	Wed, 28 Nov 2007 10:09:24 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lASI9J75003972;
	Wed, 28 Nov 2007 18:09:19 GMT
From: "Dan Wing" 
To: "'Hadriel Kaplan'" ,
	"'Eric Rescorla'" , 
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Date: Wed, 28 Nov 2007 10:09:18 -0800
Message-ID: <015b01c831e9$ce000d30$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgxXuG9NwDhn8kkTrKFLz11kdNm7AARZ2qwABEPiWA=
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1490; t=1196273364;
	x=1197137364; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20Comments=20on=20draft-wing-sip-identity-media
	-01 |Sender:=20;
	bh=tlYqBXdDlXgLzWy9/tPilY/7Lgjayt+0W0fvf7v6QEI=;
	b=JbjbUzQjPzFsviU4G1LqCQDKAoQ30x6N1eE83nM0Qxll2sCo7aqnHRqYY98sqGhqeIqeDBjs
	Xc+q38bCdAoKwHa1QgYAElOapAvBZJLj4wsyDXw5XH12oorUvOUEIpNV;
Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

...
> > With regard to the second issue, I agree this is important,
> > but this is an orthogonal issue to which headers get signed,
> > right?
> 
> I'll leave that to Dan, but I think you need this second 
> issue addressed to explain why not signing the c=/m= is ok.

RFC4474 signs the SIP body (containing the SDP and 
containing the c=/m= lines) because RFC4474 ties the IP 
address and UDP port to the identifier (From: dwing@cisco.com).

SIP-Identity-Media doesn't use the IP address and UDP port
as the identifier.  SIP-Identity-Media uses the DTLS-SRTP 
certificate as the identifier (or HIP, or an ICE extension,
or TLS).

> > In general, we certainly do want a way to tie media
> > to keying cryptographically, but as you note, DTLS-SRTP
> > already provides this. I don't quite see why you *always*
> > need this proof. What about requests that don't come
> > with media? Anyway, are you claiming this is also a problem
> > for RFC 4474?
> 
> You mean offer-less Invites?  Yes, that's already a problem 
> for 4474. 

Right.  

(Perhaps sip-connected-identity can help with offerless 
Invites; I don't know.)

> If you mean for non-SDP requests (e.g., MESSAGE or 
> SUB/NOT), the mechanism in this draft would sign that whole 
> MIME body as 4474 did, except still sign fewer headers.

Right; this was a problem Paul Kyzivat pointed out in his
review of sip-identity-media-00.  sip-identity-media-01 will
sign the non-SDP body parts.

-d


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 13:15:30 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxRR2-0002J3-7U; Wed, 28 Nov 2007 13:14:56 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxRR0-0002Io-TK
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 13:14:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRR0-0002Ig-Jm
	for sip@ietf.org; Wed, 28 Nov 2007 13:14:54 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxRR0-0006N8-9j
	for sip@ietf.org; Wed, 28 Nov 2007 13:14:54 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 28 Nov 2007 10:14:53 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASIErk5008988; 
	Wed, 28 Nov 2007 10:14:53 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lASIEi75010209;
	Wed, 28 Nov 2007 18:14:53 GMT
From: "Dan Wing" 
To: "'Paul Kyzivat'" 
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	<474D6EFF.9010407@cisco.com>
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Date: Wed, 28 Nov 2007 10:14:43 -0800
Message-ID: <016201c831ea$9267bec0$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acgxw9J/lautuoBLSqur3LQ64OAElgAJhOyA
In-Reply-To: <474D6EFF.9010407@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=830; t=1196273693;
	x=1197137693; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20Comments=20on=20draft-wing-sip-identity-media
	-01 |Sender:=20;
	bh=Aq0nD917ZKWJ1rrj4t4WMty4yUqcjXfMVdva3LleQiA=;
	b=qhXmRUjaioffHM7/ulzdrSWA+2uF+n7KIymKk47SPtfKKrzzevfY4q9P0YGRKhA+h6XqatDS
	yl+xMaWzaZMjGfnsKmeNUsC70T6ELiooOdFGiLpYs0I2g9wfrGvjuTFU;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

...
> There may indeed be value in signing a set of headers that 
> can survive passing through an SBC. But the pros and cons 
> of that need to be discussed.

With SBCs, RFC4474 requires the SBC to create a new identity
and sign that.  sip-identity-media shows how this would work
with E.164s (it works alright if each hop is entrusted to 
validate and then re-sign the E.164 address with their own domain 
name) and how this would work with email-style addresses (it 
doesn't work at all).


Before we talk about SIP headers I think we need to decide if:

  *  re-creating E.164 identities at each hop okay

  *  we need email-style SIP identities to survive through SBCs?

as this is how RFC4474 operates with today's SBCs.


(Please see draft-wing-sip-identity-media-01, section 3, for
details.)

-d


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 13:38:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxRnH-0002Mm-HF; Wed, 28 Nov 2007 13:37:55 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxRnF-0002KX-Kz
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 13:37:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRnF-0002Js-91
	for sip@ietf.org; Wed, 28 Nov 2007 13:37:53 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxRnD-0000cA-3Z
	for sip@ietf.org; Wed, 28 Nov 2007 13:37:53 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 0B73533C57
	for ; Wed, 28 Nov 2007 10:25:34 -0800 (PST)
Date: Wed, 28 Nov 2007 10:25:33 -0800
From: Eric Rescorla 
To: sip@ietf.org
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071128182534.0B73533C57@delta.rtfm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Subject: [Sip] draft-burger-sip-info-02
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I just finished reading this draft. I don't have any technical
comments but I wanted to say that I found it unusually
readable and clear. 

Thanks,
-Ekr



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 13:38:30 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxRnF-0002Jo-3G; Wed, 28 Nov 2007 13:37:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxRnD-0002JK-Vu
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 13:37:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRnD-0002JA-LX
	for sip@ietf.org; Wed, 28 Nov 2007 13:37:51 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxRnD-0004IY-95
	for sip@ietf.org; Wed, 28 Nov 2007 13:37:51 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id E212C33C3D;
	Wed, 28 Nov 2007 10:22:53 -0800 (PST)
Date: Wed, 28 Nov 2007 10:22:53 -0800
From: Eric Rescorla 
To: "Dan Wing" 
Subject: Re: [Sip] Comments on draft-wing-sip-identity-media-01
In-Reply-To: <015b01c831e9$ce000d30$c5f0200a@cisco.com>
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	
	<015b01c831e9$ce000d30$c5f0200a@cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071128182253.E212C33C3D@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At Wed, 28 Nov 2007 10:09:18 -0800,
Dan Wing wrote:
> 
> ...
> > > With regard to the second issue, I agree this is important,
> > > but this is an orthogonal issue to which headers get signed,
> > > right?
> > 
> > I'll leave that to Dan, but I think you need this second 
> > issue addressed to explain why not signing the c=/m= is ok.
> 
> RFC4474 signs the SIP body (containing the SDP and 
> containing the c=/m= lines) because RFC4474 ties the IP 
> address and UDP port to the identifier (From: dwing@cisco.com).

Hmm... That's necessarily a pretty weak binding compared
to the digital signature, right? 


> SIP-Identity-Media doesn't use the IP address and UDP port
> as the identifier.  SIP-Identity-Media uses the DTLS-SRTP 
> certificate as the identifier (or HIP, or an ICE extension,
> or TLS).

Sorry, I'm still not getting why this is necessary.

I get an INVITE and then I establish an RTP stream. If I care about
data origin authentication for the media , I should be using SRTP.
If I'm not, then I don't care much. That's true with both this
draft and RFC 4474. I still don't understand why this draft
always needs a cryptographic identity proof and RFC 4474 does 
not.

-Ekr




_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 14:20:06 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxSRU-0008BB-Qu; Wed, 28 Nov 2007 14:19:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxSRT-00087j-3E
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 14:19:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSRQ-00083w-K6
	for sip@ietf.org; Wed, 28 Nov 2007 14:19:26 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSRQ-0004HI-6w
	for sip@ietf.org; Wed, 28 Nov 2007 14:19:24 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Wed, 28 Nov 2007 14:19:23 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Wed, 28 Nov 2007 14:19:23 -0500
From: Hadriel Kaplan 
To: Adam Roach 
Date: Wed, 28 Nov 2007 14:18:06 -0500
Thread-Topic: 3PCC and draft-kaplan-sip-info-events-00.txt
Thread-Index: Acgx3/tKLqdAKYQWTDe2p9/mrLnqZwABhvpA
Message-ID: 
References: 
	<4741F8A7.204@nostrum.com>
	
	<474C94EF.10905@nostrum.com>
	
	<474D9E60.4000105@nostrum.com>
In-Reply-To: <474D9E60.4000105@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: "sip@ietf.org" ,
	Christer Holmberg 
Subject: [Sip] RE: 3PCC and draft-kaplan-sip-info-events-00.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Wednesday, November 28, 2007 11:59 AM
>
> Basically, I think you'll run into problems if you can't support a
> scenario like this:
>
>
>           A                 3PCC                  B
>           |(1) INVITE         |                   |
>           |(no Recv-Info)     |                   |
>           |<------------------|                   |
>           |(2) 200            |                   |
>           |(Recv-Info A)      |                   |
>           |------------------>|                   |
>           |                   |(3) INVITE         |
>           |                   |(Recv-Info A)      |
>           |                   |------------------>|
>           |                   |(4) 200            |
>           |                   |(Send-Info A)      |
>           |                   |<------------------|
>           |                   |(5) ACK            |
>           |                   |------------------>|
>           |(6) ACK            |                   |
>           |(Send-Info A)      |                   |
>           |<------------------|                   |
>           |(7) Media          |                   |
>           |.......................................|
>           |                   |(8) INFO           |
>           |                   |<------------------|
>           |(9) INFO           |                   |
>           |<------------------|                   |
>
>
>
> Without the ability to negotiate Info Packages in messages (2) and (5),
> you run into the basic inability to support this kind of thing.

I apologize, I didn't mean I didn't get the call flow - I just didn't get w=
hy it should work that way for info-packages.  But I think I understand now=
.  I was thinking info-package requires the UA to understand the package, a=
nd a 3PCC is a B2BUA, hence a UA - and so would need to know them a priori =
and thus be able to indicate what packages it supports in Invite-1.  Somewh=
at akin to Supported/Require usage.  But clearly that no workie. (duh)

But, I do think there are multiple options for dealing with this:

Option 1) support the basic model of offer/answer a la SDP.

Option 2) since we'll support re-negotiation in re-Invite anyway, force 3PC=
C or any such blind Invite initiator to offer all in the invite, and re-neg=
otiate in a re-Invite when it knows more.

Option 3) do what you basically said later in your email: make send-info/re=
cv-info purely an announcement not a negotiation.  It can be changed at wil=
l, sent in any message, etc.  Someone actually raised this model before (ma=
ybe Dean?).

The reason I'm even suggesting Option 2 is it (a) seems simpler to me from =
a KISS/high-level-logic perspective (and thus hopefully easier for implemen=
ters and fewer "bugs"), (b) I've seen numerous issues with SDP delayed offe=
rs in the field, and (c) I'm thinking the burden of handling 3PCC cases sho=
uld be placed on 3PCC controllers, not by complicating the logic for all ot=
hers.  But I'm not sure how "offering all" would really work.  I mean you c=
ould define some token/syntax that means it, but I would think that would b=
e dangerous.  Option 3 seems to have these same properties to me as well an=
d more, without this last problem.

But Option 3 I thought had some issue but I can't remember what it is now. =
(probably related to DTMF use?)

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 15:36:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxTcn-0008P0-NU; Wed, 28 Nov 2007 15:35:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxTcm-0008ME-DS
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 15:35:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTcl-0008LX-SP
	for sip@ietf.org; Wed, 28 Nov 2007 15:35:11 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxTcj-0001WL-KX
	for sip@ietf.org; Wed, 28 Nov 2007 15:35:11 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JS800CAUH6K1I@siemenscomms.co.uk> for sip@ietf.org; Wed,
	28 Nov 2007 20:35:08 +0000 (GMT)
Date: Wed, 28 Nov 2007 20:35:07 +0000
From: "Elwell, John" 
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
In-reply-to: <20071128182253.E212C33C3D@delta.rtfm.com>
To: Eric Rescorla , Dan Wing 
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Index: Acgx7ejfLofjwLUERVqMh/mG7dVvKgAD4K7g
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	
	<015b01c831e9$ce000d30$c5f0200a@cisco.com>
	<20071128182253.E212C33C3D@delta.rtfm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Ekr,

The point is, the Wing draft only helps if media is secured with SRTP.
The Identity-Media header field basically signs the fingerprint of the
UA certificate that will be used to negotiate the key for SRTP. So if
the Identity-Media header field provides cryptographic evidence that the
remote party is Alice@example.com, then any SRTP using a key derived
from the certificate whose fingerprint is signed by the Identity-Media
header field must be from Alice@example.com (assuming you trust the
example.com domain - an assumption applicable equally to RFC 4474 and
Identity-Media).

John=20

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]=20
> Sent: 28 November 2007 18:23
> To: Dan Wing
> Cc: sip@ietf.org
> Subject: Re: [Sip] Comments on draft-wing-sip-identity-media-01
>=20
> At Wed, 28 Nov 2007 10:09:18 -0800,
> Dan Wing wrote:
> >=20
> > ...
> > > > With regard to the second issue, I agree this is important,
> > > > but this is an orthogonal issue to which headers get signed,
> > > > right?
> > >=20
> > > I'll leave that to Dan, but I think you need this second=20
> > > issue addressed to explain why not signing the c=3D/m=3D is ok.
> >=20
> > RFC4474 signs the SIP body (containing the SDP and=20
> > containing the c=3D/m=3D lines) because RFC4474 ties the IP=20
> > address and UDP port to the identifier (From: dwing@cisco.com).
>=20
> Hmm... That's necessarily a pretty weak binding compared
> to the digital signature, right?=20
>=20
>=20
> > SIP-Identity-Media doesn't use the IP address and UDP port
> > as the identifier.  SIP-Identity-Media uses the DTLS-SRTP=20
> > certificate as the identifier (or HIP, or an ICE extension,
> > or TLS).
>=20
> Sorry, I'm still not getting why this is necessary.
>=20
> I get an INVITE and then I establish an RTP stream. If I care about
> data origin authentication for the media , I should be using SRTP.
> If I'm not, then I don't care much. That's true with both this
> draft and RFC 4474. I still don't understand why this draft
> always needs a cryptographic identity proof and RFC 4474 does=20
> not.
>=20
> -Ekr
>=20
>=20
>=20
>=20
> _______________________________________________
> 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
>=20


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 16:03:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxU3X-0005QH-Gb; Wed, 28 Nov 2007 16:02:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxU3W-0005Nd-4W
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 16:02:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxU3V-0005NH-Qu
	for sip@ietf.org; Wed, 28 Nov 2007 16:02:49 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxU3U-00086R-9j
	for sip@ietf.org; Wed, 28 Nov 2007 16:02:49 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2007 16:02:47 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASL2lJF023222; 
	Wed, 28 Nov 2007 16:02:47 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lASL2G16002090; 
	Wed, 28 Nov 2007 21:02:38 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Nov 2007 16:02:30 -0500
Received: from [161.44.174.179] ([161.44.174.179]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Nov 2007 16:02:29 -0500
Message-ID: <474DD766.1060809@cisco.com>
Date: Wed, 28 Nov 2007 16:02:30 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] RE: 3PCC and draft-kaplan-sip-info-events-00.txt
References: 	<4741F8A7.204@nostrum.com>		<474C94EF.10905@nostrum.com>		<474D9E60.4000105@nostrum.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Nov 2007 21:02:29.0858 (UTC)
	FILETIME=[FCDA4C20:01C83201]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4373; t=1196283767;
	x=1197147767; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20RE=3A=203PCC=20and=20draft-kaplan-sip-info-ev
	ents-00.txt |Sender:=20
	|To:=20Hadriel=20Kaplan=20;
	bh=K1+qtWfseP9ySIMJPYAE1jsa82W40zVMykUBzDyc1KA=;
	b=s502Od+3B/nZkJtyGxYzaKG4TcNwTuuRlQzqxZwdcK5IsQowo+vCPXsRUa7CDnVcXb17Dxhd
	oaq8DAodUeZlKaxrT9Pjb4VtjvvwQHaWxU/rnDQboMFaMTpKgdTCCsv9;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: "sip@ietf.org" , Adam Roach ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Inline...

Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Adam Roach [mailto:adam@nostrum.com]
>> Sent: Wednesday, November 28, 2007 11:59 AM
>>
>> Basically, I think you'll run into problems if you can't support a
>> scenario like this:
>>
>>
>>           A                 3PCC                  B
>>           |(1) INVITE         |                   |
>>           |(no Recv-Info)     |                   |
>>           |<------------------|                   |
>>           |(2) 200            |                   |
>>           |(Recv-Info A)      |                   |
>>           |------------------>|                   |
>>           |                   |(3) INVITE         |
>>           |                   |(Recv-Info A)      |
>>           |                   |------------------>|
>>           |                   |(4) 200            |
>>           |                   |(Send-Info A)      |
>>           |                   |<------------------|
>>           |                   |(5) ACK            |
>>           |                   |------------------>|
>>           |(6) ACK            |                   |
>>           |(Send-Info A)      |                   |
>>           |<------------------|                   |
>>           |(7) Media          |                   |
>>           |.......................................|
>>           |                   |(8) INFO           |
>>           |                   |<------------------|
>>           |(9) INFO           |                   |
>>           |<------------------|                   |
>>
>>
>>
>> Without the ability to negotiate Info Packages in messages (2) and (5),
>> you run into the basic inability to support this kind of thing.
> 
> I apologize, I didn't mean I didn't get the call flow - I just didn't get why it should work that way for info-packages.  But I think I understand now.  I was thinking info-package requires the UA to understand the package, and a 3PCC is a B2BUA, hence a UA - and so would need to know them a priori and thus be able to indicate what packages it supports in Invite-1.  Somewhat akin to Supported/Require usage.  But clearly that no workie. (duh)
> 
> But, I do think there are multiple options for dealing with this:
> 
> Option 1) support the basic model of offer/answer a la SDP.

Don't get stuck on the analogy to SDP O/A. There are relationships but 
they are not the same thing. The specification of O/A in 3264 doesn't 
even map it to SIP messages.

Its the basic notion of being able to make an offer in the invite or 
solicit an offer in the invite that provides both the power and the pain.

> Option 2) since we'll support re-negotiation in re-Invite anyway, force 3PCC or any such blind Invite initiator to offer all in the invite, and re-negotiate in a re-Invite when it knows more.

For 3pcc, where the existing mechanism must be handled for SDP, a 
mechanism that requires additional messages would at least be annoying 
and inconvenient if it can be accomplished with the existing messages.

> Option 3) do what you basically said later in your email: make send-info/recv-info purely an announcement not a negotiation.  It can be changed at will, sent in any message, etc.  Someone actually raised this model before (maybe Dean?).

> The reason I'm even suggesting Option 2 is it (a) seems simpler to me from a KISS/high-level-logic perspective (and thus hopefully easier for implementers and fewer "bugs"), (b) I've seen numerous issues with SDP delayed offers in the field, and (c) I'm thinking the burden of handling 3PCC cases should be placed on 3PCC controllers, not by complicating the logic for all others.  But I'm not sure how "offering all" would really work.  I mean you could define some token/syntax that means it, but I would think that would be dangerous.  Option 3 seems to have these same properties to me as well and more, without this last problem.
> 
> But Option 3 I thought had some issue but I can't remember what it is now. (probably related to DTMF use?)

It seems to me that there is a need to know what *will* be used as well 
as what *could* be used. This is especially the case when there are 
multiple possible mechanisms to accomplish the same thing and one is 
being chosen. That is the situation with DTMF.

	Paul


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 16:59:15 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxUvO-0002vn-38; Wed, 28 Nov 2007 16:58:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxUvL-0002jT-NZ
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 16:58:27 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUvL-0002gy-C4
	for sip@ietf.org; Wed, 28 Nov 2007 16:58:27 -0500
Received: from smtp1.versatel.nl ([62.58.50.88])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxUvK-0001rA-UM
	for sip@ietf.org; Wed, 28 Nov 2007 16:58:27 -0500
Received: (qmail 25582 invoked by uid 0); 28 Nov 2007 21:59:30 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6])
	([87.212.11.198]) (envelope-sender )
	by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 28 Nov 2007 21:59:30 -0000
Message-ID: <474DE476.4000907@zonnet.nl>
Date: Wed, 28 Nov 2007 22:58:14 +0100
From: Jeroen van Bemmel 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: IETF SIP List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Subject: [Sip] Should OK response for deregister include deregistered
 Contacts (with expires=0)?
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

All,

A question on the interpretation of the text in RFC3261 section 10.3 
point 8:

8. The registrar returns a 200 (OK) response.  The response MUST
         contain Contact header field values enumerating all current
         bindings.  Each Contact value MUST feature an "expires"
         parameter indicating its expiration interval chosen by the
         registrar.  The response SHOULD include a Date header field.

For a deregistration, does the above mean that the registrar should (or may) include a Contact that is being unregistered, adding 'expires=0' to reflect this?
In other words, is the deregistered Contact included in "all current bindings"?

If not, should this say "The registrar MUST NOT include deregistered Contacts"?

Regards,
Jeroen





_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 17:01:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxUy2-0004h3-Hc; Wed, 28 Nov 2007 17:01:14 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxUy0-0004gh-Tj
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:01:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUy0-0004gZ-Jn
	for sip@ietf.org; Wed, 28 Nov 2007 17:01:12 -0500
Received: from mail171.messagelabs.com ([216.82.253.243])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxUxz-0005zi-CI
	for sip@ietf.org; Wed, 28 Nov 2007 17:01:12 -0500
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-7.tower-171.messagelabs.com!1196287266!12961543!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 22210 invoked from network); 28 Nov 2007 22:01:07 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88)
	by server-7.tower-171.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Nov 2007 22:01:07 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta102.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id
	lASM1K6I010952; Wed, 28 Nov 2007 17:01:20 -0500
In-Reply-To: 
To: ken carlberg 
Subject: Re: [Sip] Need for RPH in SIP Responses
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn 
Message-ID: 
Date: Wed, 28 Nov 2007 17:01:03 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF180|March 29, 2007) at 11/28/2007 05:01:23 PM,
	Serialize complete at 11/28/2007 05:01:23 PM
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1140227858=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============1140227858==
Content-Type: multipart/alternative;
	boundary="=_alternative 0078F231852573A1_="

This is a multipart message in MIME format.
--=_alternative 0078F231852573A1_=
Content-Type: text/plain; charset="US-ASCII"

Ken,

Could you expand on these other use cases, and how they would benefit from 
RPH in responses?

Thanks

Janet


ken carlberg  wrote on 11/27/2007 11:04:44 AM:

> Janet,
> 
> sorry for the tardy comments on the thread.  when I read the draft, a 
> couple of other use cases outside of the GETS model came to mind that 
> would seem to prompt a need for an R-P header in a SIP response.  In 
> the land mobile radio arena, we have bridging architectures/ 
> technologies like the ISSI that use SIP as a foundation to bridge 
> autonomous subnets of P25 systems.  These tend to be resource 
> constrained systems of multi-level precedence, and so having a 
> corresponding R-P header in SIP responses would fold in nicely with 
> what is being built today and planned for the near future.
> 
> outside of that, there are also some efforts to bridge ISSI with Push- 
> to-talk over Cellular (PoC) with SIP, though this is quite preliminary 
> so I don't know if I'd list this as another use case.  But in any 
> event, I think it would be helpful if you could broaden the problem 
> statement in your draft so that it is not strictly focused to just 
> GETS.  Subsequent to this broader statement, you could then provide a 
> more in-depth discussion of the GETS *example*.
> 
> also, is it your plan to progress your draft in the SIPPING WG given 
> that it deals with a requirement?  I see its on the SIP agenda along 
> with James' related draft, which is helpful, but I assume that further 
> progress would be shifted to SIPPING.
> 
> -ken
> 

--=_alternative 0078F231852573A1_=
Content-Type: text/html; charset="US-ASCII"



Ken,



Could you expand on these other use
cases, and how they would benefit from RPH in responses?



Thanks



Janet





ken carlberg <carlberg@g11.org.uk> wrote on
11/27/2007 11:04:44 AM:



> Janet,

> 

> sorry for the tardy comments on the thread.  when I read the
draft, a  

> couple of other use cases outside of the GETS model came to mind that
 

> would seem to prompt a need for an R-P header in a SIP response.  In
 

> the land mobile radio arena, we have bridging architectures/ 

> technologies like the ISSI that use SIP as a foundation to bridge
 

> autonomous subnets of P25 systems.  These tend to be resource
 

> constrained systems of multi-level precedence, and so having a  

> corresponding R-P header in SIP responses would fold in nicely with
 

> what is being built today and planned for the near future.

> 

> outside of that, there are also some efforts to bridge ISSI with Push-


> to-talk over Cellular (PoC) with SIP, though this is quite preliminary
 

> so I don't know if I'd list this as another use case.  But in
any  

> event, I think it would be helpful if you could broaden the problem
 

> statement in your draft so that it is not strictly focused to just
 

> GETS.  Subsequent to this broader statement, you could then provide
a  

> more in-depth discussion of the GETS *example*.

> 

> also, is it your plan to progress your draft in the SIPPING WG given
 

> that it deals with a requirement?  I see its on the SIP agenda
along  

> with James' related draft, which is helpful, but I assume that further
 

> progress would be shifted to SIPPING.

> 

> -ken

> 


--=_alternative 0078F231852573A1_=--



--===============1140227858==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1140227858==--





From sip-bounces@ietf.org Wed Nov 28 17:03:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxUzc-0005NY-Pl; Wed, 28 Nov 2007 17:02:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxUzb-0005NJ-Dv
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:02:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUzb-0005N5-3X
	for sip@ietf.org; Wed, 28 Nov 2007 17:02:51 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxUza-00027C-NW
	for sip@ietf.org; Wed, 28 Nov 2007 17:02:51 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 0B50D33C41;
	Wed, 28 Nov 2007 13:19:06 -0800 (PST)
Date: Wed, 28 Nov 2007 13:19:06 -0800
From: Eric Rescorla 
To: "Elwell, John" 
Subject: Re: [Sip] Comments on draft-wing-sip-identity-media-01
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net>
	<0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net>
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	
	<015b01c831e9$ce000d30$c5f0200a@cisco.com>
	<20071128182253.E212C33C3D@delta.rtfm.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071128211907.0B50D33C41@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: sip@ietf.org, Dan Wing 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At Wed, 28 Nov 2007 20:35:07 +0000,
Elwell, John wrote:
> 
> Ekr,
> 
> The point is, the Wing draft only helps if media is secured with SRTP.
> The Identity-Media header field basically signs the fingerprint of the
> UA certificate that will be used to negotiate the key for SRTP. So if
> the Identity-Media header field provides cryptographic evidence that the
> remote party is Alice@example.com, then any SRTP using a key derived
> from the certificate whose fingerprint is signed by the Identity-Media
> header field must be from Alice@example.com (assuming you trust the
> example.com domain - an assumption applicable equally to RFC 4474 and
> Identity-Media).

But it seems to me that the same argument applies to RFC 4474, right?

I.e., the semantics of 4474 are: Here is a bunch of message data
sent by X. The semantics of Identity-media are: here is somewhat
less message data sent by X. Why does one need a proof of identity
and the other not?

-Ekr


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 17:11:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxV7h-000662-Cv; Wed, 28 Nov 2007 17:11:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxV7f-0005w6-No
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:11:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxV7f-0005qz-7H
	for sip@ietf.org; Wed, 28 Nov 2007 17:11:11 -0500
Received: from out003.iad.hostedmail.net ([209.225.56.66])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxV7e-0006PV-WD
	for sip@ietf.org; Wed, 28 Nov 2007 17:11:11 -0500
Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.32]) by
	out003.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959);
	Wed, 28 Nov 2007 17:11:15 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Should OK response for deregister include deregistered
	Contacts (with expires=0)?
Date: Wed, 28 Nov 2007 17:11:10 -0500
Message-ID: 
In-Reply-To: <474DE476.4000907@zonnet.nl>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Should OK response for deregister include deregistered
	Contacts (with expires=0)?
Thread-Index: AcgyCdX0Iuqxp9nQQj2hLWww1IZW/gAALrVA
From: "Brett Tate" 
To: "Jeroen van Bemmel" ,
	"IETF SIP List" 
X-OriginalArrivalTime: 28 Nov 2007 22:11:15.0119 (UTC)
	FILETIME=[97B32BF0:01C8320B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

The wording does not appear to need modification.  Since the binding no
longer exists, section 8 basically does not apply to the binding(s)
being deregistered.


> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20
> Sent: Wednesday, November 28, 2007 4:58 PM
> To: IETF SIP List
> Subject: [Sip] Should OK response for deregister include=20
> deregistered Contacts (with expires=3D0)?
>=20
> All,
>=20
> A question on the interpretation of the text in RFC3261=20
> section 10.3 point 8:
>=20
> 8. The registrar returns a 200 (OK) response.  The response MUST
>          contain Contact header field values enumerating all current
>          bindings.  Each Contact value MUST feature an "expires"
>          parameter indicating its expiration interval chosen by the
>          registrar.  The response SHOULD include a Date header field.
>=20
> For a deregistration, does the above mean that the registrar=20
> should (or may) include a Contact that is being unregistered,=20
> adding 'expires=3D0' to reflect this?
> In other words, is the deregistered Contact included in "all=20
> current bindings"?
>=20
> If not, should this say "The registrar MUST NOT include=20
> deregistered Contacts"?
>=20
> Regards,
> Jeroen


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 17:29:16 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxVOb-00078J-Ff; Wed, 28 Nov 2007 17:28:41 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxVOZ-00077v-CS
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:28:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVOZ-00077i-2A
	for sip@ietf.org; Wed, 28 Nov 2007 17:28:39 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVOY-00079f-Jc
	for sip@ietf.org; Wed, 28 Nov 2007 17:28:39 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113] (may be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lASMSPhR004161
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 28 Nov 2007 16:28:26 -0600
In-Reply-To: <474DD766.1060809@cisco.com>
References: 	<4741F8A7.204@nostrum.com>		<474C94EF.10905@nostrum.com>		<474D9E60.4000105@nostrum.com>
	
	<474DD766.1060809@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <599BF5C0-88B0-47A8-94C4-F452033EEBBE@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] RE: 3PCC and draft-kaplan-sip-info-events-00.txt
Date: Wed, 28 Nov 2007 16:28:19 -0600
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: "sip@ietf.org" , Adam Roach ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 28, 2007, at 3:02 PM, Paul Kyzivat wrote:
>
> It seems to me that there is a need to know what *will* be used as  
> well as what *could* be used. This is especially the case when  
> there are multiple possible mechanisms to accomplish the same thing  
> and one is being chosen. That is the situation with DTMF.
>
>

I'm still thinking at the level of what "MAY" be used. We don't know  
what "will" be used until it happens. Sometimes those decisions  
aren't made until runtime -- and sometimes, they never get made at all.

As Douglas Adams points out, the invention of time travel will have  
caused a change to human language, eliminating the future perfect  
tense, as the future will have been found not to have been perfect.  
Or something like that.

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 17:47:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxVgL-00084j-3U; Wed, 28 Nov 2007 17:47:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxVgJ-00084d-GB
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:46:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVgJ-00084V-5O
	for sip@ietf.org; Wed, 28 Nov 2007 17:46:59 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxVgI-0003wT-QC
	for sip@ietf.org; Wed, 28 Nov 2007 17:46:59 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2007 17:47:00 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASMkwZI013675; 
	Wed, 28 Nov 2007 17:46:58 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lASMkoBa023312; 
	Wed, 28 Nov 2007 22:46:50 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Nov 2007 17:46:50 -0500
Received: from [161.44.174.179] ([161.44.174.179]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Nov 2007 17:46:49 -0500
Message-ID: <474DEFDA.80804@cisco.com>
Date: Wed, 28 Nov 2007 17:46:50 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Dean Willis 
Subject: Re: [Sip] RE: 3PCC and draft-kaplan-sip-info-events-00.txt
References: 	<4741F8A7.204@nostrum.com>		<474C94EF.10905@nostrum.com>		<474D9E60.4000105@nostrum.com>
	
	<474DD766.1060809@cisco.com>
	<599BF5C0-88B0-47A8-94C4-F452033EEBBE@softarmor.com>
In-Reply-To: <599BF5C0-88B0-47A8-94C4-F452033EEBBE@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Nov 2007 22:46:49.0893 (UTC)
	FILETIME=[901FD550:01C83210]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1744; t=1196290018;
	x=1197154018; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20RE=3A=203PCC=20and=20draft-kaplan-sip-info-ev
	ents-00.txt |Sender:=20
	|To:=20Dean=20Willis=20;
	bh=oK9GliwXv+ROsr3M8R/N4BcbiNm5q+cBQzDZmph+gKI=;
	b=Y7+j2b8UDpVo9Lb/vmq1ajzT1a6ApuJ0PktmwlitX0Ow+lXUH7d2BpOMFlRkxVj/LgqXtglW
	gXiE8JnmVG7G1VKx207T72S1S0RQa24q2CADOhjIbPE66UKlJJk04GGZ;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: "sip@ietf.org" , Adam Roach ,
	Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Dean,

I agree that "will" is problematic, but I was having trouble coming up 
with a suitable word. Maybe I can just use a lot of words instead:

Instead of *could* be used, perhaps "capable of using" is better. 
Equivalent to Supported.

By *may* I meant that if there is a need to signal this sort of thing, 
then this mechanism MUST be used to do it.

So, Alice says:

   I am capable of sending and receiving DTMF via this INFO technique.
   (And at the same time may also be offering the telephone-events
   payload type in the SDP.)

And then Bob says:

   I am capable of sending DTMF via this INFO technique.
   I select that this INFO technique will be the technique I use to
   send DTMF to you. I don't receive DTMF this way, so don't send it
   to me.
   (And at the same time rejects the telephone-events
   payload type in the SDP answer.)


	Paul

Dean Willis wrote:
> 
> On Nov 28, 2007, at 3:02 PM, Paul Kyzivat wrote:
>>
>> It seems to me that there is a need to know what *will* be used as 
>> well as what *could* be used. This is especially the case when there 
>> are multiple possible mechanisms to accomplish the same thing and one 
>> is being chosen. That is the situation with DTMF.
>>
>>
> 
> I'm still thinking at the level of what "MAY" be used. We don't know 
> what "will" be used until it happens. Sometimes those decisions aren't 
> made until runtime -- and sometimes, they never get made at all.
> 
> As Douglas Adams points out, the invention of time travel will have 
> caused a change to human language, eliminating the future perfect tense, 
> as the future will have been found not to have been perfect. Or 
> something like that.
> 
> -- 
> Dean
> 


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 17:52:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxVkm-0000hv-G1; Wed, 28 Nov 2007 17:51:36 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxVkk-0000h9-So
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:51:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVkk-0000gG-Hb
	for sip@ietf.org; Wed, 28 Nov 2007 17:51:34 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxVkk-00049W-40
	for sip@ietf.org; Wed, 28 Nov 2007 17:51:34 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 28 Nov 2007 14:51:33 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASMpXcM001294; 
	Wed, 28 Nov 2007 14:51:33 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lASMpW75022361;
	Wed, 28 Nov 2007 22:51:33 GMT
From: "Dan Wing" 
To: "'Eric Rescorla'" 
References: <20071128012931.5C84F33C21@delta.rtfm.com><015b01c831e9$ce000d30$c5f0200a@cisco.com>
	<20071128182253.E212C33C3D@delta.rtfm.com>
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Date: Wed, 28 Nov 2007 14:51:32 -0800
Message-ID: <069b01c83211$39390490$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acgx7crU+RIJeT0mTJWLH8yY4Ac0uAAAm9wA
In-Reply-To: <20071128182253.E212C33C3D@delta.rtfm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2005; t=1196290293;
	x=1197154293; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20Comments=20on=20draft-wing-sip-identity-media
	-01 |Sender:=20;
	bh=YXyKcKtiw9ATvstnzXe7Kz7/AVTvxc0zE6O5CaCrGwY=;
	b=kslT/eQJxFVGiN8qCyB7per8iBwELeGfyUr/Q+ru1ujgIdTgX3xIeFy7S7gvX2eIEbQNBTFi
	WpJ/H9fpakrX5BFOgibnm0UMS/TtT5K6z2LQYxgGXvWKBK65gE69bOF3;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> > > > With regard to the second issue, I agree this is important,
> > > > but this is an orthogonal issue to which headers get signed,
> > > > right?
> > > 
> > > I'll leave that to Dan, but I think you need this second 
> > > issue addressed to explain why not signing the c=/m= is ok.
> > 
> > RFC4474 signs the SIP body (containing the SDP and 
> > containing the c=/m= lines) because RFC4474 ties the IP 
> > address and UDP port to the identifier (From: dwing@cisco.com).
> 
> Hmm... That's necessarily a pretty weak binding compared
> to the digital signature, right? 

I concur.
 
> > SIP-Identity-Media doesn't use the IP address and UDP port
> > as the identifier.  SIP-Identity-Media uses the DTLS-SRTP 
> > certificate as the identifier (or HIP, or an ICE extension,
> > or TLS).
> 
> Sorry, I'm still not getting why this is necessary.
> 
> I get an INVITE and then I establish an RTP stream. If I care about
> data origin authentication for the media , I should be using SRTP.
> If I'm not, then I don't care much. That's true with both this
> draft and RFC 4474. I still don't understand why this draft
> always needs a cryptographic identity proof and RFC 4474 does 
> not.

Because SIP-Identity-Media is validating the identity of the
remote party, by making the remote party prove it knows the
private key associated with its DTLS/TLS certificate or
ICE/HIP public key.

RFC4474 doesn't.  RFC4474 only requires symmetric RTP, and 
only requires RTP packets arrive from the same IP address 
and UDP port as signed by RFC4474.  It is using the source
IP address to provide the identity.  With SBCs, which are
continually modifying the source IP address (when they
rewrite the m/c lines), you can only get a signature from
the closest SBC.  Which means you're trusting it.  It
trusted the SBC one hop away, which trusted the SBC the
next hop away, and so on, until we finally get back to
the real user agent that generated in the Invite.

-d


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 17:56:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxVoZ-0002CO-DW; Wed, 28 Nov 2007 17:55:31 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxVoX-00028n-PX
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:55:29 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVoX-00028f-Ek
	for sip@ietf.org; Wed, 28 Nov 2007 17:55:29 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxVoX-0004IC-4D
	for sip@ietf.org; Wed, 28 Nov 2007 17:55:29 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 28 Nov 2007 14:55:28 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASMtSiE007553; 
	Wed, 28 Nov 2007 14:55:28 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lASMtRqZ014483;
	Wed, 28 Nov 2007 22:55:28 GMT
From: "Dan Wing" 
To: "'Eric Rescorla'" ,
	"'Elwell, John'" 
References: <20071128012931.5C84F33C21@delta.rtfm.com><015b01c831e9$ce000d30$c5f0200a@cisco.com><20071128182253.E212C33C3D@delta.rtfm.com><0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net>
	<20071128211907.0B50D33C41@delta.rtfm.com>
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Date: Wed, 28 Nov 2007 14:55:27 -0800
Message-ID: <069f01c83211$c5467120$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgyCm7MfHYga9KPT7m6/dKmJcXyiAABtHZQ
In-Reply-To: <20071128211907.0B50D33C41@delta.rtfm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=863; t=1196290528;
	x=1197154528; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20Comments=20on=20draft-wing-sip-identity-media
	-01 |Sender:=20;
	bh=pm19n6s0guhEpHR1uNS/wVIcXL+8+1CFb0yHx3+51WY=;
	b=tmmaXEdFSJD96aiLRkP8pq7/bn3ZCNPy5Go3RV/WTj+umL6WnPv1yT4M4QMQCWFLOvVUCWi6
	mASLrmMtKRSoZXLysMtsvKmtt25p9V9bEmfhBxk2EmmxXLOojeev8s7a;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> But it seems to me that the same argument applies to RFC 4474, right?
> 
> I.e., the semantics of 4474 are: Here is a bunch of message data
> sent by X.

RFC4474 also says that any RTP packets with the source address
in the RFC4474-signed SDP is from X.

> The semantics of Identity-media are: here is somewhat
> less message data sent by X.

Identity-Media also says that you can do a DTLS-SRTP, TLS,
HIP, or ICE (with extensions) handshake with the source address
in the SDP, and you can validate the certificate (or public
key) exchanged in that DTLS-SRTP/TLS/HIP/ICE exchange matches
the Identity-Media-signed a=fingerprint of X.

> Why does one need a proof of identity and the other not?

RFC4474 uses source transport address for proof of identity.
Identity-Media uses certificates (DTLS-SRTP/TLS) or public
keys (HIP/ICE).  

-d


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 18:19:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxWAl-0000IM-Mh; Wed, 28 Nov 2007 18:18:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxWAj-0000I5-Un
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 18:18:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWAj-0000Hx-L1
	for sip@ietf.org; Wed, 28 Nov 2007 18:18:25 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWAj-0000gg-2P
	for sip@ietf.org; Wed, 28 Nov 2007 18:18:25 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 89D9F33C3D;
	Wed, 28 Nov 2007 15:13:12 -0800 (PST)
Date: Wed, 28 Nov 2007 15:13:11 -0800
From: Eric Rescorla 
To: "Dan Wing" 
Subject: Re: [Sip] Comments on draft-wing-sip-identity-media-01
In-Reply-To: <069f01c83211$c5467120$c5f0200a@cisco.com>
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	
	<015b01c831e9$ce000d30$c5f0200a@cisco.com>
	<20071128182253.E212C33C3D@delta.rtfm.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net>
	<20071128211907.0B50D33C41@delta.rtfm.com>
	<069f01c83211$c5467120$c5f0200a@cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071128231312.89D9F33C3D@delta.rtfm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: sip@ietf.org, "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At Wed, 28 Nov 2007 14:55:27 -0800,
Dan Wing wrote:
> 
> > But it seems to me that the same argument applies to RFC 4474, right?
> > 
> > I.e., the semantics of 4474 are: Here is a bunch of message data
> > sent by X.
> 
> RFC4474 also says that any RTP packets with the source address
> in the RFC4474-signed SDP is from X.

Does it?

That's not my reading of the claimed security guarantees
offered by RFC 4474. Rather, I read them as saying
"whatever is in this message was said by the person
in whose name it was signed". Any conclusions one draws
after that seem separate to me. You could do something
useful with RFC 4474 even if no media was ever sent.

Indeed, when I read RFC 4474, you can use it for requests
which don't contain SDP at all, such as OPT. Am I just
smoking crack here?


> > The semantics of Identity-media are: here is somewhat
> > less message data sent by X.
> 
> Identity-Media also says that you can do a DTLS-SRTP, TLS,
> HIP, or ICE (with extensions) handshake with the source address
> in the SDP, and you can validate the certificate (or public
> key) exchanged in that DTLS-SRTP/TLS/HIP/ICE exchange matches
> the Identity-Media-signed a=fingerprint of X.
> 
> > Why does one need a proof of identity and the other not?
> 
> RFC4474 uses source transport address for proof of identity.
> Identity-Media uses certificates (DTLS-SRTP/TLS) or public
> keys (HIP/ICE).  

Well, I understand that that's what you're doing. My point
is that i think that whether this service is valuable is
an independent question of whether one should trim the
set of headers and body values that gets signed.

I.e., if we think it's important to provide a cryptographic
binding of a media stream independent of SRTP (and I'm still
trying to work out what the semantics of that would be),
then we should do that in a way that's equally applicable to
RFC 4474.

But maybe I'm just confused.

-Ekr




_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 18:30:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxWMJ-0004Bc-FM; Wed, 28 Nov 2007 18:30:23 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxWMH-0004BF-Qd
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 18:30:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWMH-0004B7-Gp
	for sip@ietf.org; Wed, 28 Nov 2007 18:30:21 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxWMF-00015r-Ti
	for sip@ietf.org; Wed, 28 Nov 2007 18:30:21 -0500
Received: (qmail invoked by alias); 28 Nov 2007 23:30:18 -0000
Received: from p54984A75.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.74.117]
	by mail.gmx.net (mp017) with SMTP; 29 Nov 2007 00:30:18 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+nV+ZB8Uina0mWbiyKW9j+dg6jXPlYPsgh/Yqjac
	ZD+yc2gVQOZ64R
Message-ID: <474DFA05.7030201@gmx.net>
Date: Thu, 29 Nov 2007 00:30:13 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: IETF SIP List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Subject: [Sip] Feedback for draft-wing-sip-identity-media-01
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi all,

I read through the document and I believe it addresses an important 
problem. I am obviously open to reflect deployment constraints for the 
protocols we develop.
Thanks for writing the document.

Needless to say that the document requires a lot of work. Hence, only 
some high-level comments.

Ekr pointed it already out that the document tries to provide two 
functions.
The first part limits the number of fields that are signed. This concept 
is already known from DKIM and we should re-use it.

Now, my problems start with the second part of the document and the way 
how it is tied to this specific problem. In some cases it is useful to 
tie the SIP signaling exchange with the subsequent exchange along the 
media path. That's why we did that with SIP and HIP 
([I-D.tschofenig-hiprg-host-identities]), DTLS-SRTP 
([I-D.ietf-sip-dtls-srtp-framework]) and SIP IKE 
[I-D.saito-mmusic-sdp-ike]. However, I see these aspects as a largely 
orthogonal issue. I think that these are two independent problems (with 
only a minimal relationship, see below).

In an abstract sense (keeping the work on SIP SAML in mind) the identity 
assertion you are conveying to the recipient has constraints attached 
that limit it's scope.
In case of SIP identity the the assertion is very closely tight to the 
specific SIP session. With SIP SAML there was also the possibility to 
tie the assertion to a separate key and to use an independent protocol 
to proof possession of that key. We documented that stuff in an earlier 
version of the SIP SAML document; obviously nobody was too much excited 
about it since it introduces dependencies to other protocols.

Often, it is not really desired to accomplish such a tight binding 
between the assertion and the subsequent message. In some cases you 
would rather want to keep the binding quite loose in order to reuse the 
assertion (intentionally) over multiple sessions. The best examples can 
be found with the usage of SAML (SAML independently of SIP).

Conclusion: I believe it is sufficient to limit the number of fields 
that are being signed (in the same fashion as DKIM does it). The binding 
between signaling and media traffic should be treated independently. 
Thereby you can still limit the scope of the assertion and prevent 
replay attacks.

Ciao
Hannes



_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 18:32:24 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxWNl-00053C-Om; Wed, 28 Nov 2007 18:31:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxWNk-000535-NX
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 18:31:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWNk-00052v-E1
	for sip@ietf.org; Wed, 28 Nov 2007 18:31:52 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IxWNj-00019S-VR for sip@ietf.org; Wed, 28 Nov 2007 18:31:52 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-2.cisco.com with ESMTP; 28 Nov 2007 15:31:43 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASNVhwJ001563; 
	Wed, 28 Nov 2007 15:31:43 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lASNVg1f018318;
	Wed, 28 Nov 2007 23:31:43 GMT
From: "Dan Wing" 
To: "'Eric Rescorla'" 
References: <20071128012931.5C84F33C21@delta.rtfm.com><015b01c831e9$ce000d30$c5f0200a@cisco.com><20071128182253.E212C33C3D@delta.rtfm.com><0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net><20071128211907.0B50D33C41@delta.rtfm.com><069f01c83211$c5467120$c5f0200a@cisco.com>
	<20071128231312.89D9F33C3D@delta.rtfm.com>
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Date: Wed, 28 Nov 2007 15:31:42 -0800
Message-ID: <06a901c83216$d59091f0$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgyFQDZCWuoDarHRMG7y+B1x5jjywAALjRw
In-Reply-To: <20071128231312.89D9F33C3D@delta.rtfm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2796; t=1196292703;
	x=1197156703; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20Comments=20on=20draft-wing-sip-identity-media
	-01 |Sender:=20;
	bh=06TtxbqYSPRIgF7KunMN4naSFZksPaDEJSIr0o3cDs0=;
	b=Jvmaa3IAtB6MhY8GBVyTeH0vE+fviDdl6+e0Pg/0NCWQz+Y6EMmL2qvuT8LY1L2HOORf8g03
	Uu7jHdj/CjgJpYVCBhki9mRPtITqgNGaDGbbgeAzMF/qsupxPuO+K+T5;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: sip@ietf.org, "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

> At Wed, 28 Nov 2007 14:55:27 -0800,
> Dan Wing wrote:
> > 
> > > But it seems to me that the same argument applies to RFC 
> > > 4474, right?
> > > 
> > > I.e., the semantics of 4474 are: Here is a bunch of message data
> > > sent by X.
> > 
> > RFC4474 also says that any RTP packets with the source address
> > in the RFC4474-signed SDP is from X.
> 
> Does it?
> 
> That's not my reading of the claimed security guarantees
> offered by RFC 4474. Rather, I read them as saying
> "whatever is in this message was said by the person
> in whose name it was signed". Any conclusions one draws
> after that seem separate to me. You could do something
> useful with RFC 4474 even if no media was ever sent.

Sure.  But that would be silly.  Why would you go through
the effort of validating an RFC4474 signature, only to 
then accept RTP packets willy-nilly from some different
IP address and UDP port?

> Indeed, when I read RFC 4474, you can use it for requests
> which don't contain SDP at all, such as OPT. Am I just
> smoking crack here?

You are correct, RFC4474 signs the body no matter what the
body contains.  I don't know what OPT is.

Identity-Media signs non-SDP bodies, too.
 
> > > The semantics of Identity-media are: here is somewhat
> > > less message data sent by X.
> > 
> > Identity-Media also says that you can do a DTLS-SRTP, TLS,
> > HIP, or ICE (with extensions) handshake with the source address
> > in the SDP, and you can validate the certificate (or public
> > key) exchanged in that DTLS-SRTP/TLS/HIP/ICE exchange matches
> > the Identity-Media-signed a=fingerprint of X.
> > 
> > > Why does one need a proof of identity and the other not?
> > 
> > RFC4474 uses source transport address for proof of identity.
> > Identity-Media uses certificates (DTLS-SRTP/TLS) or public
> > keys (HIP/ICE).  
> 
> Well, I understand that that's what you're doing. My point
> is that i think that whether this service is valuable is
> an independent question of whether one should trim the
> set of headers and body values that gets signed.
> 
> I.e., if we think it's important to provide a cryptographic
> binding of a media stream independent of SRTP (and I'm still
> trying to work out what the semantics of that would be),

My goal was not to create a cryptographic binding.  Rather,
that's the solution I came up with.  My goal was to allow 
"From: dwing@cisco.com" to persist across SBCs, which RFC4474 
doesn't allow.

> then we should do that in a way that's equally applicable to
> RFC 4474.

I don't know how to accomplish that with SBCs, other than
via my proposal.

> But maybe I'm just confused.

Email and a 10 minute presentation in SIP might not be the 
best way to explain things, too.

-d


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 19:16:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxX4a-0004dn-0V; Wed, 28 Nov 2007 19:16:08 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxX4Y-0004di-Vm
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 19:16:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX4Y-0004da-MJ
	for sip@ietf.org; Wed, 28 Nov 2007 19:16:06 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxX4W-0002cG-CI
	for sip@ietf.org; Wed, 28 Nov 2007 19:16:06 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 083F533C3D;
	Wed, 28 Nov 2007 16:10:50 -0800 (PST)
Date: Wed, 28 Nov 2007 16:10:50 -0800
From: Eric Rescorla 
To: "Dan Wing" 
Subject: Re: [Sip] Comments on draft-wing-sip-identity-media-01
In-Reply-To: <06a901c83216$d59091f0$c5f0200a@cisco.com>
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	
	<015b01c831e9$ce000d30$c5f0200a@cisco.com>
	<20071128182253.E212C33C3D@delta.rtfm.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net>
	<20071128211907.0B50D33C41@delta.rtfm.com>
	<069f01c83211$c5467120$c5f0200a@cisco.com>
	<20071128231312.89D9F33C3D@delta.rtfm.com>
	<06a901c83216$d59091f0$c5f0200a@cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071129001051.083F533C3D@delta.rtfm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: sip@ietf.org, "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At Wed, 28 Nov 2007 15:31:42 -0800,
Dan Wing wrote:
> 
> > At Wed, 28 Nov 2007 14:55:27 -0800,
> > Dan Wing wrote:
> > > 
> > > > But it seems to me that the same argument applies to RFC 
> > > > 4474, right?
> > > > 
> > > > I.e., the semantics of 4474 are: Here is a bunch of message data
> > > > sent by X.
> > > 
> > > RFC4474 also says that any RTP packets with the source address
> > > in the RFC4474-signed SDP is from X.
> > 
> > Does it?
> > 
> > That's not my reading of the claimed security guarantees
> > offered by RFC 4474. Rather, I read them as saying
> > "whatever is in this message was said by the person
> > in whose name it was signed". Any conclusions one draws
> > after that seem separate to me. You could do something
> > useful with RFC 4474 even if no media was ever sent.
> 
> Sure.  But that would be silly.  Why would you go through
> the effort of validating an RFC4474 signature, only to 
> then accept RTP packets willy-nilly from some different
> IP address and UDP port?

Well, that's not quite what I meant. 

Let me try to work through my reasoning, so we can see where
we disagree. 

The general purpose of RFC 4744 is to give the UAS confidence
that whatever requests it received came from the claimed
UAC. What it does with that information then depends on the
request type.

Let's not talk about INVITE for a second, but rather
BYE. Alice and Bob have a phone call in progress and Alice
sends Bob a BYE. Now, in order to avoid DoS attacks where
the attacker terminates connections in progress, Bob wants
Alice's BYE to have an RFC 4474 Identity and will reject
it without. Note that in this case, there's no requirement
to correlate anything with an RTP stream, and in fact
Alice may not send any RTP data after sending the BYE.
Bob just verifies it and shuts down the call. Do we agree
so far?

Now, let's address INVITE. Bob gets an RFC 4474 INVITE with
an SDP and before he's done anything else, he knows that
Alice wants to talk to him. Or rather, Bob's UAS does.
His phone starts ringing and Alice's name shows up in his
caller-id display. So, RFC 4474 has added value even before
we've received the first RTP packet. 

Assuming Bob decides to answer, his UAS sends an SDP answer to
Alice. If ICE isn't in play, then he's expecting to receive packets at
the address he specified in his answer, and if it's symmetric RTP,
then from Alice's claimed address.  And yes, I agree, that then he
should reject packets from other addresses, but I don't think that's
the same as saying that packets from that address *are* from Alice.
If you want that service, you need to use cryptography. 


> > Indeed, when I read RFC 4474, you can use it for requests
> > which don't contain SDP at all, such as OPT. Am I just
> > smoking crack here?
> 
> You are correct, RFC4474 signs the body no matter what the
> body contains.  I don't know what OPT is.

My bad, OPTION.


> Identity-Media signs non-SDP bodies, too.

Agreed. 


> > Well, I understand that that's what you're doing. My point
> > is that i think that whether this service is valuable is
> > an independent question of whether one should trim the
> > set of headers and body values that gets signed.
> > 
> > I.e., if we think it's important to provide a cryptographic
> > binding of a media stream independent of SRTP (and I'm still
> > trying to work out what the semantics of that would be),
> 
> My goal was not to create a cryptographic binding.  Rather,
> that's the solution I came up with.  My goal was to allow 
> "From: dwing@cisco.com" to persist across SBCs, which RFC4474 
> doesn't allow.

Right. But it seems to me that that goal is accomplished
simply by trimming the list of headers and SDP lines which
are signed and that the cryptographic binding solves something
different.


> > But maybe I'm just confused.
> 
> Email and a 10 minute presentation in SIP might not be the 
> best way to explain things, too.

Quite probably.

-Ekr


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 20:04:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxXoS-0002Ii-SW; Wed, 28 Nov 2007 20:03:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxXoQ-0002IY-VW
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 20:03:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXoQ-0002IM-Lp
	for sip@ietf.org; Wed, 28 Nov 2007 20:03:30 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IxXoP-0004J2-JQ for sip@ietf.org; Wed, 28 Nov 2007 20:03:30 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-2.cisco.com with ESMTP; 28 Nov 2007 17:03:19 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAT13IZ5001143; 
	Wed, 28 Nov 2007 17:03:18 -0800
Received: from dwingwxp01 ([10.32.240.197])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAT13I75020554;
	Thu, 29 Nov 2007 01:03:18 GMT
From: "Dan Wing" 
To: "'Eric Rescorla'" 
References: <20071128012931.5C84F33C21@delta.rtfm.com><015b01c831e9$ce000d30$c5f0200a@cisco.com><20071128182253.E212C33C3D@delta.rtfm.com><0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net><20071128211907.0B50D33C41@delta.rtfm.com><069f01c83211$c5467120$c5f0200a@cisco.com><20071128231312.89D9F33C3D@delta.rtfm.com><06a901c83216$d59091f0$c5f0200a@cisco.com>
	<20071129001051.083F533C3D@delta.rtfm.com>
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Date: Wed, 28 Nov 2007 17:03:18 -0800
Message-ID: <00eb01c83223$a11e70b0$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <20071129001051.083F533C3D@delta.rtfm.com>
Thread-Index: AcgyHQnOeNwg44tiS5+cBox7j7NMEAAA0hwg
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5473; t=1196298198;
	x=1197162198; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20
	|Subject:=20RE=3A=20[Sip]=20Comments=20on=20draft-wing-sip-identity-media
	-01 |Sender:=20;
	bh=Sjs+EMNRw7vLmLucSQzP33Qhy+UzeptV2LJsYUVD5yY=;
	b=i1O7hJ5/9pCeTMbutDyatBBMQCwWpft9CmvvxuDsgPm18MRmWEi5Mg7nZJBSrSTwGRNbfDhX
	hgznxXhtRrdVvQvR9mBoW33mS2smxoYSkfWCnqnrh/Pu8cSpj1pyXssW;
Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: sip@ietf.org, "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

EKR wrote:

> At Wed, 28 Nov 2007 15:31:42 -0800,
> Dan Wing wrote:
> > 
> > > At Wed, 28 Nov 2007 14:55:27 -0800,
> > > Dan Wing wrote:
> > > > 
> > > > > But it seems to me that the same argument applies to RFC 
> > > > > 4474, right?
> > > > > 
> > > > > I.e., the semantics of 4474 are: Here is a bunch of 
> message data
> > > > > sent by X.
> > > > 
> > > > RFC4474 also says that any RTP packets with the source address
> > > > in the RFC4474-signed SDP is from X.
> > > 
> > > Does it?
> > > 
> > > That's not my reading of the claimed security guarantees
> > > offered by RFC 4474. Rather, I read them as saying
> > > "whatever is in this message was said by the person
> > > in whose name it was signed". Any conclusions one draws
> > > after that seem separate to me. You could do something
> > > useful with RFC 4474 even if no media was ever sent.
> > 
> > Sure.  But that would be silly.  Why would you go through
> > the effort of validating an RFC4474 signature, only to 
> > then accept RTP packets willy-nilly from some different
> > IP address and UDP port?
> 
> Well, that's not quite what I meant. 
> 
> Let me try to work through my reasoning, so we can see where
> we disagree. 
> 
> The general purpose of RFC 4744 is to give the UAS confidence
> that whatever requests it received came from the claimed
> UAC. What it does with that information then depends on the
> request type.
> 
> Let's not talk about INVITE for a second, but rather
> BYE. Alice and Bob have a phone call in progress and Alice
> sends Bob a BYE. Now, in order to avoid DoS attacks where
> the attacker terminates connections in progress, Bob wants
> Alice's BYE to have an RFC 4474 Identity and will reject
> it without. Note that in this case, there's no requirement
> to correlate anything with an RTP stream, and in fact
> Alice may not send any RTP data after sending the BYE.
> Bob just verifies it and shuts down the call. Do we agree
> so far?

Agreed, RFC4474 provides additional protection for a BYE.

(RFC3261 section 15.1.2 requires the dialog of the BYE 
matches the dialog of the INVITE, which means an attacker
already needs to have collected the Call-ID, local tag,
and remote tag from the INVITE).

> Now, let's address INVITE. Bob gets an RFC 4474 INVITE with
> an SDP and before he's done anything else, he knows that
> Alice wants to talk to him. Or rather, Bob's UAS does.
> His phone starts ringing and Alice's name shows up in his
> caller-id display. So, RFC 4474 has added value even before
> we've received the first RTP packet. 
> 
> Assuming Bob decides to answer, his UAS sends an SDP answer to
> Alice. If ICE isn't in play, then he's expecting to receive packets at
> the address he specified in his answer, and if it's symmetric RTP,
> then from Alice's claimed address.  And yes, I agree, that then he
> should reject packets from other addresses, but I don't think that's
> the same as saying that packets from that address *are* from Alice.
> If you want that service, you need to use cryptography. 

Ok.
 
> > > Indeed, when I read RFC 4474, you can use it for requests
> > > which don't contain SDP at all, such as OPT. Am I just
> > > smoking crack here?
> > 
> > You are correct, RFC4474 signs the body no matter what the
> > body contains.  I don't know what OPT is.
> 
> My bad, OPTION.
> 
> 
> > Identity-Media signs non-SDP bodies, too.
> 
> Agreed. 
> 
> 
> > > Well, I understand that that's what you're doing. My point
> > > is that i think that whether this service is valuable is
> > > an independent question of whether one should trim the
> > > set of headers and body values that gets signed.
> > > 
> > > I.e., if we think it's important to provide a cryptographic
> > > binding of a media stream independent of SRTP (and I'm still
> > > trying to work out what the semantics of that would be),
> > 
> > My goal was not to create a cryptographic binding.  Rather,
> > that's the solution I came up with.  My goal was to allow 
> > "From: dwing@cisco.com" to persist across SBCs, which RFC4474 
> > doesn't allow.
> 
> Right. But it seems to me that that goal is accomplished
> simply by trimming the list of headers and SDP lines which
> are signed and that the cryptographic binding solves something
> different.

This gets to 'why' RFC4474 decided to sign the SDP.  The
authors and SIP WG participants that decided on this might be 
able to better explain than me -- I wasn't involved in it.

But from my current understanding, it RFC4474 signs the
body to provide additional replay attack protection.  
Specifically, if an attacker could get a valid, signed Invite
from a victim, the attacker could replay it.  By including 
the SDP in the RFC4474 signature, the attacker would also 
need to obtain the same IP address and UDP port as the 
victim.  This is considered difficult to obtain; however, 
with NAPTs and TURN, it may be easier than hoped.  RFC4474
was also devised before Security Descriptions (RFC4568) or 
key-mgmt (RFC4567) were available, and certainly long 
before DTLS-SRTP.  At the time RFC4474 was written, the
signing the SDP to provide additional replay protection 
made good sense.  

-d

> > > But maybe I'm just confused.
> > 
> > Email and a 10 minute presentation in SIP might not be the 
> > best way to explain things, too.
> 
> Quite probably.
> 
> -Ekr


_______________________________________________
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



From sip-bounces@ietf.org Wed Nov 28 22:58:55 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxaXY-0000lo-5o; Wed, 28 Nov 2007 22:58:16 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxaXW-0000lJ-Fk
	for sip-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 22:58:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxaXW-0000l6-69
	for sip@ietf.org; Wed, 28 Nov 2007 22:58:14 -0500
Received: from chn-hclin-gws02.hcl.in ([203.105.186.20] helo=gws04.hcl.in)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxaXT-0008O1-Qw
	for sip@ietf.org; Wed, 28 Nov 2007 22:58:14 -0500
Received: from gws04.hcl.in (gws04 [10.249.64.135])
	by localhost.hcl.in (Postfix) with ESMTP
	id 0B4E33671A5; Thu, 29 Nov 2007 09:28:09 +0530 (IST)
Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by 
	gws04.hcl.in (Postfix) with ESMTPid EDD6E3671A0;
	Thu, 29 Nov 2007 09:28:08 +0530 (IST)
Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by 
	chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830);
	Thu, 29 Nov 2007 09:28:08 +0530
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Nov 2007 09:28:07 +0530
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: querry regarding outbound
Thread-Index: AcgtGC3e/0I2m0bXQ+6admDlLHrZUwAAFtSwAAB+31AAsT/P4ACW7/RA
From: "Karthikeyan Gopal , TLS-Chennai" 
To: 
X-OriginalArrivalTime: 29 Nov 2007 03:58:08.0816 (UTC) 
	FILETIME=[0DA14B00:01C8323C]
X-imss-version: 2.049
X-imss-result: Passed
X-imss-scanInfo: M:T L:E SM:1
X-imss-tmaseResult: TT:1 TS:-3.3395 TC:1F TRN:17 TV:5.0.1023(15574.002)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: sip@ietf.org
Subject: [Sip] querry regarding outbound
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



Hi All,
	Registrar, presence server and proxy are co-located=2E
Registration is done with Registrar as per the outbound draft=2E
Binding will be created in Registrar based on instance_id and AOR=2E

If we send SUBSCRIBE how the Presence Server will send Notify back?
Bcoz, the Presence Server will try to send NOTIFY based on the contact
header of SUBSCRIBE=2E But this contact has NO info about the instance-id=
=2E


But the fd is stored against the instance-id=2E=20

How will the NOTIFY be sent out?

Thanks & Regards,
Karthikeyan


DISCLAIMER:
---------------------------------------------------------------------------=
--------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and=
 intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its=
 affiliates=2E Any views or opinions presented in=20
this email are solely those of the author and may not necessarily reflect=
 the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,=
 distribution and / or publication of=20
this message without the prior written consent of the author of this e-mail=
 is strictly prohibited=2E If you have=20
received this email in error please delete it and notify the sender=
 immediately=2E Before opening any mail and=20
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------=
--------------------------------------------


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 02:01:30 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxdO7-0005nw-F6; Thu, 29 Nov 2007 02:00:43 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxdO6-0005ni-Es
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 02:00:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdO5-0005na-VM
	for sip@ietf.org; Thu, 29 Nov 2007 02:00:41 -0500
Received: from nz-out-0506.google.com ([64.233.162.229])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxdO2-0000Ul-Ua
	for sip@ietf.org; Thu, 29 Nov 2007 02:00:41 -0500
Received: by nz-out-0506.google.com with SMTP id n1so1330621nzf
	for ; Wed, 28 Nov 2007 23:00:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=4rbDluae6Ysg4APnmO+nvFS/YZDxjWsTQt9BjBg5JJk=;
	b=Ni9rcS7fsJsBOnCQGplFxZERC1JVNggWQRL7cAETNEJu+G7eeVtpZ0iThg5Gk/Xxp79S674BnqHtHdeLKFeo7wyA1cIPGY6VyXWo4CsY+JMphaWh8dLpk5aV1r0yR7pQm+ZMvsUMbVAuEKj0FvFJCtS28c7jss4NOAI9ptuXSf8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=Rl9UmaBvyOCkP2TYCYSgnM9MVxCcUzEZFveMhxGRbPDG/KMOGZMqE1Y8WpV5f1/A7rymJr3mn5Oq9aZEHMWPnKLlJd7QuSQElNfhtsi/SmqDvKCd0xbji1s55s+oIUS4DbFXGW0bXPVkkhAL/7TUPex2dm+Ejttm4HuDaNXTHCQ=
Received: by 10.142.49.4 with SMTP id w4mr879081wfw.1196319637504;
	Wed, 28 Nov 2007 23:00:37 -0800 (PST)
Received: by 10.142.214.15 with HTTP; Wed, 28 Nov 2007 23:00:37 -0800 (PST)
Message-ID: <953beacc0711282300m2f394e72v4513df0b318de564@mail.gmail.com>
Date: Wed, 28 Nov 2007 23:00:37 -0800
From: "Rohan Mahy" 
To: "Karthikeyan Gopal , TLS-Chennai" 
Subject: Re: [Sip] querry regarding outbound
In-Reply-To: 
MIME-Version: 1.0
References: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: SIP 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0421541697=="
Errors-To: sip-bounces@ietf.org

--===============0421541697==
Content-Type: multipart/alternative; 
	boundary="----=_Part_8120_17512284.1196319637491"

------=_Part_8120_17512284.1196319637491
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

The first hop will add a Record-Route with a flow token if the UAC puts an
'ob' parameter in the Contact header of a dialog-forming request.

thanks,
-rohan

On Nov 28, 2007 7:58 PM, Karthikeyan Gopal , TLS-Chennai <
g_karthikeyan@hcl.in> wrote:

>
>
> Hi All,
>        Registrar, presence server and proxy are co-located.
> Registration is done with Registrar as per the outbound draft.
> Binding will be created in Registrar based on instance_id and AOR.
>
> If we send SUBSCRIBE how the Presence Server will send Notify back?
> Bcoz, the Presence Server will try to send NOTIFY based on the contact
> header of SUBSCRIBE. But this contact has NO info about the instance-id.
>
>
> But the fd is stored against the instance-id.
>
> How will the NOTIFY be sent out?
>
> Thanks & Regards,
> Karthikeyan
>
>
> DISCLAIMER:
>
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect
> the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of
> this message without the prior written consent of the author of this
> e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
>
> -----------------------------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> 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
>

------=_Part_8120_17512284.1196319637491
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

The first hop will add a Record-Route with a flow token if the UAC puts an 'ob' parameter in the Contact header of a dialog-forming request.

thanks,
-rohan

On Nov 28, 2007 7:58 PM, Karthikeyan Gopal , TLS-Chennai <
g_karthikeyan@hcl.in> wrote:


Hi All,

        Registrar, presence server and proxy are co-located.
Registration is done with Registrar as per the outbound draft.
Binding will be created in Registrar based on instance_id and AOR.

If we send SUBSCRIBE how the Presence Server will send Notify back?

Bcoz, the Presence Server will try to send NOTIFY based on the contact
header of SUBSCRIBE. But this contact has NO info about the instance-id.


But the fd is stored against the instance-id.

How will the NOTIFY be sent out?


Thanks & Regards,
Karthikeyan


DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have

received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

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



_______________________________________________
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




------=_Part_8120_17512284.1196319637491--



--===============0421541697==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0421541697==--





From sip-bounces@ietf.org Thu Nov 29 03:40:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxewD-0001XI-Sw; Thu, 29 Nov 2007 03:40:01 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxewB-0001Sr-OZ
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 03:39:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxewB-0001Sh-6R
	for sip@ietf.org; Thu, 29 Nov 2007 03:39:59 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxewA-00087S-Qe
	for sip@ietf.org; Thu, 29 Nov 2007 03:39:59 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Thu, 29 Nov 2007 03:39:58 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Thu, 29 Nov 2007 03:39:58 -0500
From: Hadriel Kaplan 
To: Dan Wing , 'Eric Rescorla' 
Date: Thu, 29 Nov 2007 03:38:39 -0500
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Topic: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Index: AcgyHQnOeNwg44tiS5+cBox7j7NMEAAA0hwgAA+iXuA=
Message-ID: 
References: <20071128012931.5C84F33C21@delta.rtfm.com><015b01c831e9$ce000d30$c5f0200a@cisco.com><20071128182253.E212C33C3D@delta.rtfm.com><0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net><20071128211907.0B50D33C41@delta.rtfm.com><069f01c83211$c5467120$c5f0200a@cisco.com><20071128231312.89D9F33C3D@delta.rtfm.com><06a901c83216$d59091f0$c5f0200a@cisco.com>
	<20071129001051.083F533C3D@delta.rtfm.com>
	<00eb01c83223$a11e70b0$c5f0200a@cisco.com>
In-Reply-To: <00eb01c83223$a11e70b0$c5f0200a@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: "sip@ietf.org" , "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Wednesday, November 28, 2007 8:03 PM
>
> > Right. But it seems to me that that goal is accomplished
> > simply by trimming the list of headers and SDP lines which
> > are signed and that the cryptographic binding solves something
> > different.
>
> This gets to 'why' RFC4474 decided to sign the SDP.  The
> authors and SIP WG participants that decided on this might be
> able to better explain than me -- I wasn't involved in it.

There was an email exchange and discussion in San Diego on this when Jonath=
an's identity-coexistence draft came out.
I believe the argument was it prevents a SIP MITM from very easily becoming=
 a media MITM (or an end) by simply changing the m=3D/c=3D lines.  In other=
 words it's better than not signing the SDP.

There was strong fear that allowing MITM to change m=3D/c=3D lines is signi=
ficantly less secure than not, under the assumption that it's much harder t=
o become a media MITM otherwise.  I agree with that sentiment in general I =
guess, though I personally think the value of identity signing is in From i=
mpersonation prevention, not media MITM prevention.  And I think if the ext=
ra signing fails the request then this thing won't be used and it loses any=
 value. (The counter-argument was in such a case it really should fail or e=
lse it has no value)


> But from my current understanding, it RFC4474 signs the
> body to provide additional replay attack protection.
> Specifically, if an attacker could get a valid, signed Invite
> from a victim, the attacker could replay it.
[...snip]
> At the time RFC4474 was written, the
> signing the SDP to provide additional replay protection
> made good sense.

You don't need to sign the body to prevent replay - just 4474's signing of =
the SIP headers: To+From, Date, call-id and CSeq makes replay highly improb=
able.  It's one of the things that worries me a little about identity-media=
 not signing the call-id and cseq.  It allows replay during the Date's wind=
ow, against the same target.  So we said in section 8 that since the DTLS f=
ingerprint is signed, then replaying isn't actually very useful anyway.

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 03:57:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxfC8-0003Fv-Oq; Thu, 29 Nov 2007 03:56:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxfC6-0003Do-P7
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 03:56:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxfC5-00032c-AB
	for sip@ietf.org; Thu, 29 Nov 2007 03:56:25 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxfC4-0000OX-Tv
	for sip@ietf.org; Thu, 29 Nov 2007 03:56:25 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Thu, 29 Nov 2007 03:56:24 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Thu, 29 Nov 2007 03:56:24 -0500
From: Hadriel Kaplan 
To: Eric Rescorla , Dan Wing 
Date: Thu, 29 Nov 2007 03:55:06 -0500
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Topic: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Index: AcgyHQ/b74CQastTSxq6jiJaQrvu2wARlYUQ
Message-ID: 
References: <20071128012931.5C84F33C21@delta.rtfm.com>
	
	<015b01c831e9$ce000d30$c5f0200a@cisco.com>
	<20071128182253.E212C33C3D@delta.rtfm.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net>
	<20071128211907.0B50D33C41@delta.rtfm.com>
	<069f01c83211$c5467120$c5f0200a@cisco.com>
	<20071128231312.89D9F33C3D@delta.rtfm.com>
	<06a901c83216$d59091f0$c5f0200a@cisco.com>
	<20071129001051.083F533C3D@delta.rtfm.com>
In-Reply-To: <20071129001051.083F533C3D@delta.rtfm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: "sip@ietf.org" , "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]
> Sent: Wednesday, November 28, 2007 7:11 PM
>
> Now, let's address INVITE. Bob gets an RFC 4474 INVITE with
> an SDP and before he's done anything else, he knows that
> Alice wants to talk to him. Or rather, Bob's UAS does.
> His phone starts ringing and Alice's name shows up in his
> caller-id display. So, RFC 4474 has added value even before
> we've received the first RTP packet.

Yes, and I agree identity-media would provide that same value, even if the =
SDP contained no DTLS and SRTP wasn't used at all.

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 05:22:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxgWy-0000gE-SY; Thu, 29 Nov 2007 05:22:04 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxgWw-0000fV-UL
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 05:22:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgWw-0000f3-6k
	for sip@ietf.org; Thu, 29 Nov 2007 05:22:02 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxgWv-0000Ko-Jz
	for sip@ietf.org; Thu, 29 Nov 2007 05:22:01 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Thu, 29 Nov 2007 05:22:01 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Thu, 29 Nov 2007 05:22:01 -0500
From: Hadriel Kaplan 
To: Dan Wing , 'Eric Rescorla' 
Date: Thu, 29 Nov 2007 05:20:43 -0500
Subject: RE: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Topic: [Sip] Comments on draft-wing-sip-identity-media-01
Thread-Index: AcgyFQDZCWuoDarHRMG7y+B1x5jjywAALjRwABP3scA=
Message-ID: 
References: <20071128012931.5C84F33C21@delta.rtfm.com><015b01c831e9$ce000d30$c5f0200a@cisco.com><20071128182253.E212C33C3D@delta.rtfm.com><0D5F89FAC29E2C41B98A6A762007F5D0490D93@GBNTHT12009MSX.gb002.siemens.net><20071128211907.0B50D33C41@delta.rtfm.com><069f01c83211$c5467120$c5f0200a@cisco.com>
	<20071128231312.89D9F33C3D@delta.rtfm.com>
	<06a901c83216$d59091f0$c5f0200a@cisco.com>
In-Reply-To: <06a901c83216$d59091f0$c5f0200a@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: "sip@ietf.org" , "'Elwell, John'" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Wednesday, November 28, 2007 6:32 PM
>
> > That's not my reading of the claimed security guarantees
> > offered by RFC 4474. Rather, I read them as saying
> > "whatever is in this message was said by the person
> > in whose name it was signed". Any conclusions one draws
> > after that seem separate to me. You could do something
> > useful with RFC 4474 even if no media was ever sent.
>
> Sure.  But that would be silly.  Why would you go through
> the effort of validating an RFC4474 signature, only to
> then accept RTP packets willy-nilly from some different
> IP address and UDP port?

A minor note that only accepting RTP packets from the address in the signed=
 SDP does not do much to stop a SIP MITM from easily becoming a media MITM,=
 for at least one side.

Assume the following call flow:

          A                   B                   C
          |(1) INVITE         |                   |
          |(SDP c/m=3DA)        |                   |
          |------------------>|                   |
          |                   |(2) INVITE         |
          |                   |(SDP c/m=3DA)        |
          |                   |------------------>|
          |                   |           (3) 200 |
          |                   |        (SDP c/m=3DC)|
          |                   |<------------------|
          |           (4) 200 |                   |
          |        (SDP c/m=3DB)|                   |
          |<------------------|                   |
          |(5) ACK            |(6) ACK            |
          |------------------>|------------------>|
          |                   |                   |
          | Media A->B        | Media 'A'->C      |
          |..................>|..................>|
          |                   |                   |
          |        Media B->A |                   |
          |<..................|        Media C->A |
          |X<.....................................|

A sent a signed Invite through B to C.  B couldn't change it, but can easil=
y change the 200 response's SDP.  So A ends up thinking B is the called par=
ty. When C sends media direct to A, A will ignore it for the reason you sai=
d and render B's media instead.  Meanwhile A also sends media to B, not C, =
leaving B free to send source-spoofed RTP to C and it's able to do that bec=
ause it was able to read A's signed Invite and thus knows what to spoof wit=
h. (assuming no uRPF checking routers block such)

Of course B may have a hard time getting hold of C's media, but for spam pu=
rposes all that has to happen is for B to successfully get its media to be =
rendered by C.

And what's more, connected-identity RFC4916 does not stop this; if A is Ali=
ce calling C for Citibank, and B the Bad-guy in the middle, Citibank will s=
end a signed UPDATE without SDP to Alice, and the Bad-guy can do the above =
attack and end up being the one talking to Alice.  Even if Citibank hangs u=
p due to lack of media, Bad-guy will simply block the Bye and keep talking =
to Alice.

This isn't a biggie - just pointing out that 4474+4916 ain't perfect for MI=
TM protection, even with SDP signing.  (It's really unfortunate responses c=
ouldn't be signed)

-hadriel



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 09:07:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ixk2V-0003do-UY; Thu, 29 Nov 2007 09:06:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ixk2U-0003Yd-4W
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 09:06:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixk2T-0003YH-D9
	for sip@ietf.org; Thu, 29 Nov 2007 09:06:49 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ixk2S-0008GY-M5
	for sip@ietf.org; Thu, 29 Nov 2007 09:06:49 -0500
Received: (qmail invoked by alias); 29 Nov 2007 14:06:47 -0000
Received: from p54986E15.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.110.21]
	by mail.gmx.net (mp047) with SMTP; 29 Nov 2007 15:06:47 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19N3bklApNN0UyTish1aqpwx9cSJGvHp1Vo0QmrN9
	GEevh/pIQAVUcq
Message-ID: <474EC776.2050007@gmx.net>
Date: Thu, 29 Nov 2007 15:06:46 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: IETF SIP List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Subject: [Sip] Milestone Change for Media Security Requirements
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Hi Keith,

you made a proposal for milestone updates.
The milestone draft-ietf-sip-media-security-requirements-01 got modified.

Here are the details:
-----------------------------------------------------------------
draft-ietf-sip-media-security-requirements-01
Candidate: Best Current Practice
(we may downgrade / upgrade this based on discussion of the contents)
Milestone for WGLC May 2008
Milestone for submission to IESG July 2008
Needs discussion of what we really need to say in such a document
-----------------------------------------------------------------

I got the impression that we do not have too many open issues.
* lawful interception
* traversal of middleboxes

We could give the first item a last chance (let's say within a few 
weeks) and then we make a final decision.
Regarding the second item: I believe that we can deal with it fairly 
independently. There is a separate draft
about this story, namely draft-sipping-stucker-media-path-middleboxes-00

Hence, I believe that there is no reason to move the milestone for that 
document.

Ciao
Hannes


PS: draft-ietf-sip-media-security-requirements-01 should become an 
Informational RFC (not a BCP).



_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 09:28:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxkMx-0005WH-OQ; Thu, 29 Nov 2007 09:27:59 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxkMv-0005Rz-Ry
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 09:27:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxkMu-0005Mp-Qq
	for sip@ietf.org; Thu, 29 Nov 2007 09:27:56 -0500
Received: from sea02-mxf01.citel.com ([205.234.66.116])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxkMu-0007MD-GG
	for sip@ietf.org; Thu, 29 Nov 2007 09:27:56 -0500
Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com)
	by sea02-mxf01.citel.com with smtp (Exim 4.43)
	id 1IxkMr-0008Td-Vg; Thu, 29 Nov 2007 06:27:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Date: Thu, 29 Nov 2007 06:27:47 -0800
Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C0E5A42@sea02-mxc01.citel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
thread-index: AcgxQcTJJy5pUX1uQ9GyO0O5y6nvdAAWzGEQAD0jY68=
References: <4741F8A7.204@nostrum.com><474C94EF.10905@nostrum.com>
	
From: "Michael Procter" 
To: "Hadriel Kaplan" , "Adam Roach" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org, Christer Holmberg 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Just to pick up on one of the comments:

Hadriel Kaplan wrote:
> From: Adam Roach [mailto:adam@nostrum.com]
>>    Recv-Event          18x        -   -   -   o   o   -   -
>> I think you mean "1xx", not "18x"
>
> Yup.

Can this be extended to permit Send-Event and Recv-Event to be optional =
in non-2xx final responses too?  The reason is simple: OPTIONS can be =
rejected with a 486 simply because the UA is on a call.  Under those =
circumstances, I think it would still be useful to know what the UA =
supports.  (There are probably other responses where it would be useful =
- I am simply trying to make the point, rather than list all relevant =
responses at this stage.)
=20
I know that a proxy consolidating responses from a forked OPTIONS might =
seem to make this less useful, but an OPTIONS sent to a gruu wouldn't =
suffer from this problem, and so would remain useful.
=20
Regards,
=20
Michael


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 09:46:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ixkef-0001eA-EP; Thu, 29 Nov 2007 09:46:17 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ixked-0001dX-W2
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 09:46:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixked-0001dM-M8
	for sip@ietf.org; Thu, 29 Nov 2007 09:46:15 -0500
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixkeb-0006uW-FQ
	for sip@ietf.org; Thu, 29 Nov 2007 09:46:15 -0500
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lATEkB6w020049; 
	Thu, 29 Nov 2007 08:46:11 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 29 Nov 2007 08:45:45 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 29 Nov 2007 15:45:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Milestone Change for Media Security Requirements
Date: Thu, 29 Nov 2007 15:45:41 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019B72ED@DEEXC1U01.de.lucent.com>
In-Reply-To: <474EC776.2050007@gmx.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Milestone Change for Media Security Requirements
Thread-Index: AcgykTJjRqbXnlTQQteIGOLG592Q3AABK56Q
References: <474EC776.2050007@gmx.net>
From: "DRAGE, Keith \(Keith\)" 
To: "Hannes Tschofenig" ,
	"IETF SIP List" 
X-OriginalArrivalTime: 29 Nov 2007 14:45:43.0170 (UTC)
	FILETIME=[84A13620:01C83296]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

No this is a copy / paste error on my part which lost some lines such =
that two items got conflated. The two entries should correctly read:

draft-ietf-sip-ua-privacy-00
Candidate: Best Current Practice (we may downgrade / upgrade this based =
on discussion of the contents)
Milestone for WGLC May 2008
Milestone for submission to IESG July 2008
Needs discussion of what we really need to say in such a document

draft-ietf-sip-media-security-requirements-01
Candidate: Informational
Milestone for WGLC September 2007
Dean Willis is PROTO document shepherd
Milestone for submission to IESG November 2007

So I am not currently proposing changing the milestones, even though we =
have missed them (slightly). We have a number of documents to WGLC =
following the IETF#70 meeting and media security requirements is one of =
them. Therefore any comments at this stage on the contents are entirely =
appropriate.

I will try and post a corrected set of status later.

Regards

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Sent: Thursday, November 29, 2007 2:07 PM
> To: IETF SIP List
> Subject: [Sip] Milestone Change for Media Security Requirements
>=20
> Hi Keith,
>=20
> you made a proposal for milestone updates.
> The milestone draft-ietf-sip-media-security-requirements-01=20
> got modified.
>=20
> Here are the details:
> -----------------------------------------------------------------
> draft-ietf-sip-media-security-requirements-01
> Candidate: Best Current Practice
> (we may downgrade / upgrade this based on discussion of the=20
> contents) Milestone for WGLC May 2008 Milestone for=20
> submission to IESG July 2008 Needs discussion of what we=20
> really need to say in such a document
> -----------------------------------------------------------------
>=20
> I got the impression that we do not have too many open issues.
> * lawful interception
> * traversal of middleboxes
>=20
> We could give the first item a last chance (let's say within a few
> weeks) and then we make a final decision.
> Regarding the second item: I believe that we can deal with it=20
> fairly independently. There is a separate draft about this=20
> story, namely draft-sipping-stucker-media-path-middleboxes-00
>=20
> Hence, I believe that there is no reason to move the=20
> milestone for that document.
>=20
> Ciao
> Hannes
>=20
>=20
> PS: draft-ietf-sip-media-security-requirements-01 should=20
> become an Informational RFC (not a BCP).
>=20
>=20
>=20
> _______________________________________________
> 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
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 11:47:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxmWv-0007mS-Mx; Thu, 29 Nov 2007 11:46:25 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxmWt-0007m3-KK
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:46:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmWt-0007lr-9C
	for sip@ietf.org; Thu, 29 Nov 2007 11:46:23 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxmWs-0004O1-K7
	for sip@ietf.org; Thu, 29 Nov 2007 11:46:23 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	01BDB204E6; Thu, 29 Nov 2007 17:46:22 +0100 (CET)
X-AuditID: c1b4fb3e-aee9fbb00000459d-e3-474eecddf11c
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	DF9D120192; Thu, 29 Nov 2007 17:46:21 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 29 Nov 2007 17:46:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Date: Thu, 29 Nov 2007 17:40:46 +0100
Message-ID: 
In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011C0E5A42@sea02-mxc01.citel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
Thread-Index: AcgxQcTJJy5pUX1uQ9GyO0O5y6nvdAAWzGEQAD0jY68ABT9SwA==
References: <4741F8A7.204@nostrum.com><474C94EF.10905@nostrum.com>
	
	<0D4E483A0E6E0A46861409E5D6C2011C0E5A42@sea02-mxc01.citel.com>
From: "Christer Holmberg" 
To: "Michael Procter" ,
	"Hadriel Kaplan" , "Adam Roach" 
X-OriginalArrivalTime: 29 Nov 2007 16:46:21.0765 (UTC)
	FILETIME=[5F2B2750:01C832A7]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


Hi,

I don't think it would harm to allow the headers in pretty much any
response - in case we come up with use-cases (like the one you just
presented) in future where it is needed.

Regards,

Christer=20

> -----Original Message-----
> From: Michael Procter [mailto:michael.procter@citel.com]=20
> Sent: 29. marraskuuta 2007 16:28
> To: Hadriel Kaplan; Adam Roach
> Cc: sip@ietf.org; Christer Holmberg
> Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
>=20
> Just to pick up on one of the comments:
>=20
> Hadriel Kaplan wrote:
> > From: Adam Roach [mailto:adam@nostrum.com]
> >>    Recv-Event          18x        -   -   -   o   o   -   -
> >> I think you mean "1xx", not "18x"
> >
> > Yup.
>=20
> Can this be extended to permit Send-Event and Recv-Event to=20
> be optional in non-2xx final responses too?  The reason is=20
> simple: OPTIONS can be rejected with a 486 simply because the=20
> UA is on a call.  Under those circumstances, I think it would=20
> still be useful to know what the UA supports.  (There are=20
> probably other responses where it would be useful - I am=20
> simply trying to make the point, rather than list all=20
> relevant responses at this stage.)
> =20
> I know that a proxy consolidating responses from a forked=20
> OPTIONS might seem to make this less useful, but an OPTIONS=20
> sent to a gruu wouldn't suffer from this problem, and so=20
> would remain useful.
> =20
> Regards,
> =20
> Michael
>=20


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 12:44:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxnQF-0005K3-Lk; Thu, 29 Nov 2007 12:43:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxnQD-000566-Q9
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:43:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnQD-00052M-8i
	for sip@ietf.org; Thu, 29 Nov 2007 12:43:33 -0500
Received: from qmta06.emeryville.ca.mail.comcast.net ([76.96.30.56])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxnQC-0005ls-7W
	for sip@ietf.org; Thu, 29 Nov 2007 12:43:33 -0500
Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11])
	by QMTA06.emeryville.ca.mail.comcast.net with comcast
	id Je8J1Y0040EPcho0A0HQ00; Thu, 29 Nov 2007 17:43:35 +0000
Received: from [192.168.1.120] ([69.250.217.141])
	by OMTA01.emeryville.ca.mail.comcast.net with comcast
	id Jhja1Y00833dvnH0800000; Thu, 29 Nov 2007 17:43:35 +0000
X-Authority-Analysis: v=1.0 c=1 a=NB0-aqk6ZOAyhI9NVOYA:9
	a=Uo2Lq1cd1z8LT_NbL7IA:7 a=zmB4Hn1efmlzgeasyJGSlBo5_RIA:4
	a=Mz_smNXqyOQA:10 a=Gz6z9c4GMJ6R6DWLn0EA:9
	a=m4eu7VL9qe7QoxkO1ZsA:7 a=44OYTlWQJSkQ8lvLfLCmq86DoYgA:4
	a=37WNUvjkh6kA:10
Message-Id: <1D490040-CE58-486A-A42D-72E898A39031@g11.org.uk>
From: ken carlberg 
To: Janet P Gunn 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [Sip] Need for RPH in SIP Responses
Date: Thu, 29 Nov 2007 12:43:29 -0500
References: 
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2073574638=="
Errors-To: sip-bounces@ietf.org


--===============2073574638==
Content-Type: multipart/alternative; boundary=Apple-Mail-6--992322338


--Apple-Mail-6--992322338
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Janet,

I'll expand a bit, but I think anything more would probably be best in  
the form of text+references,  and an offline discussion if needed.

land mobile radio, commonly used by police/ambulance/first- 
responders,  has been the poster child for NON-interoperable systems.   
They operate within Radio Frequency Sub Systems (RFSS) using a common  
air interface (CAI) and the fixed station interface (FSI) -- using TIA  
as an example.  The inter sub-system interface (ISSI) is used to  
extend interoperability between RFSSs, and here is where SIP is being  
incorporated  for call control between RFSSs.  Initially, the system  
uses stateful SIP proxies, but later on stateless proxies are expected  
to be incorporated in the architecture.  In addition, there is a  
desire to incorporate RPH and replace TIA's current approach of  
overloading the SIP Priority value with TIA-specific values (this is  
very aggravating, but hopefully reason will win out).  Hence, adding  
RPH to responses would be constructive given the potential for  
stateless proxies in the sample calling segments below

Calling <------->Calling <-------->Called <------>Called
serving            home                 home             serving
RFSS              RFSS                 RFSS             RFSS


with respect to PoC, there are efforts to build bridging architectures  
that provide interoperability between the ISSI/RFSS and PoC systems  
using SIP in order to seamlessly extend the push-to-talk feature of  
the different architectures.  Some designs for these bridges advocate  
stateless SIP proxies that just map calls of one system to the next.

-ken


On Nov 28, 2007, at 5:01 PM, Janet P Gunn wrote:

>
> Ken,
>
> Could you expand on these other use cases, and how they would  
> benefit from RPH in responses?
>
> Thanks
>
> Janet
>
>
> ken carlberg  wrote on 11/27/2007 11:04:44 AM:
>
> > Janet,
> >
> > sorry for the tardy comments on the thread.  when I read the  
> draft, a
> > couple of other use cases outside of the GETS model came to mind  
> that
> > would seem to prompt a need for an R-P header in a SIP response.  In
> > the land mobile radio arena, we have bridging architectures/
> > technologies like the ISSI that use SIP as a foundation to bridge
> > autonomous subnets of P25 systems.  These tend to be resource
> > constrained systems of multi-level precedence, and so having a
> > corresponding R-P header in SIP responses would fold in nicely with
> > what is being built today and planned for the near future.
> >
> > outside of that, there are also some efforts to bridge ISSI with  
> Push-
> > to-talk over Cellular (PoC) with SIP, though this is quite  
> preliminary
> > so I don't know if I'd list this as another use case.  But in any
> > event, I think it would be helpful if you could broaden the problem
> > statement in your draft so that it is not strictly focused to just
> > GETS.  Subsequent to this broader statement, you could then  
> provide a
> > more in-depth discussion of the GETS *example*.
> >
> > also, is it your plan to progress your draft in the SIPPING WG given
> > that it deals with a requirement?  I see its on the SIP agenda along
> > with James' related draft, which is helpful, but I assume that  
> further
> > progress would be shifted to SIPPING.
> >
> > -ken
> >


--Apple-Mail-6--992322338
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Janet,

I'll expand a bit, but I =
think anything more would probably be best in the form of =
text+references,  and an offline discussion if =
needed.

land =
mobile radio, commonly used by police/ambulance/first-responders, =
 has been the poster child for NON-interoperable systems. =
 They operate within Radio Frequency Sub Systems (RFSS) using a =
common air interface (CAI) and the fixed station interface (FSI) -- =
using TIA as an example.  The inter sub-system interface (ISSI) is =
used to extend interoperability between RFSSs, and here is where SIP is =
being incorporated  for call control between RFSSs. =
 Initially, the system uses stateful SIP proxies, but later on =
stateless proxies are expected to be incorporated in the architecture. =
 In addition, there is a desire to incorporate RPH and replace =
TIA's current approach of overloading the SIP Priority value with =
TIA-specific values (this is very aggravating, but hopefully reason will =
win out).  Hence, adding RPH to responses would be constructive =
given the potential for stateless proxies in the sample calling segments =
below

Calling =
<------->Calling <-------->Called =
<------>Called
serving         =
   home               =
  home             =
serving
RFSS             =
 RFSS                 RFSS =
            RFSS


with respect to PoC, there =
are efforts to build bridging architectures that provide =
interoperability between the ISSI/RFSS and PoC systems using SIP in =
order to seamlessly extend the push-to-talk feature of the different =
architectures.  Some designs for these bridges advocate stateless =
SIP proxies that just map calls of one system to the next.

-ken


On Nov 28, =
2007, at 5:01 PM, Janet P Gunn wrote:


Ken, 
 
Could you expand on these other use cases, and how =
they would benefit from RPH in responses? 
 
Thanks 
 
Janet
  
 
ken =
carlberg <carlberg@g11.org.uk> wrote on =
11/27/2007 11:04:44 AM:
 
 > Janet,
 > 
 > sorry =
for the tardy comments on the thread.  when I read the draft, a =
 
 > couple of other use cases outside of the GETS model came =
to mind that  
 > would seem to prompt a need for an R-P =
header in a SIP response.  In  
 > the land mobile radio =
arena, we have bridging architectures/ 
 > technologies like the =
ISSI that use SIP as a foundation to bridge  
 > autonomous =
subnets of P25 systems.  These tend to be resource  
 > =
constrained systems of multi-level precedence, and so having a =
 
 > corresponding R-P header in SIP responses would fold in =
nicely with  
 > what is being built today and planned for =
the near future.
 > 
 > outside of that, there are also some =
efforts to bridge ISSI with Push- 
 > to-talk over Cellular (PoC) =
with SIP, though this is quite preliminary  
 > so I don't =
know if I'd list this as another use case.  But in any  
 =
> event, I think it would be helpful if you could broaden the problem =
 
 > statement in your draft so that it is not strictly =
focused to just  
 > GETS.  Subsequent to this broader =
statement, you could then provide a  
 > more in-depth =
discussion of the GETS *example*.
 > 
 > also, is it your =
plan to progress your draft in the SIPPING WG given  
 > that =
it deals with a requirement?  I see its on the SIP agenda along =
 
 > with James' related draft, which is helpful, but I =
assume that further  
 > progress would be shifted to =
SIPPING.
 > 
 > -ken
 > 
 =


=

--Apple-Mail-6--992322338--



--===============2073574638==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============2073574638==--





From sip-bounces@ietf.org Thu Nov 29 15:35:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ixq6J-0005Tu-Cz; Thu, 29 Nov 2007 15:35:11 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ixq6I-0005Tm-0X
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 15:35:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixq6H-0005Tc-Mm
	for sip@ietf.org; Thu, 29 Nov 2007 15:35:09 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixq6F-0008EH-Kd
	for sip@ietf.org; Thu, 29 Nov 2007 15:35:09 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113] (may be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lATKYw5N012608
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Thu, 29 Nov 2007 14:35:00 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
To: "sip@ietf.org List" 
Message-Id: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>
From: Dean Willis 
Date: Thu, 29 Nov 2007 14:34:52 -0600
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596
Cc: Cullen Jennings , Keith Drage 
Subject: [Sip] Hopefully final agenda for SIP at IETF 70
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0158253178=="
Errors-To: sip-bounces@ietf.org


--===============0158253178==
Content-Type: multipart/alternative; boundary=Apple-Mail-1--982039458


--Apple-Mail-1--982039458
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


Agenda revised again. Since Vijay won't be there to talk about  
connect-reuse, we'll tackle the candidates for the essential  
corrections process.


Session 1, Monday December 3, 1740-1950 Salon A/B
Start Time
Topic
Discussion Lead
Reading List
1740
Agenda Bash and Status
Chairs
This document
1800
Location Conveyance
Brian Rosen
James Polk
draft-ietf-sip-location-conveyance-09
1830
INFO Harmful
Eric Burger
draft-burger-sip-info-02
1900
INFO Events
Hadriel Kaplan
draft-kaplan-sip-info-events-00
1930
Essential corrections
Keith Drage
draft-ietf-sip-record-route-fix-01
draft-gurbani-sip-ipv6-abnf-fix-00
draft-hilt-sip-correction-503-01
draft-dotson-sip-mutual-auth-00
draft-sparks-sip-invfix-00

1950
End



Session 2, Wednesday December 5, 0900-1130, Salon A/B
Start Time
Topic
Discussion Lead
Reading List
0900
Agenda Bash
Chairs
This Document
0910
Outbound
Rohan Mahy
draft-ietf-sip-outbound-11
1000
RPH In Responses
James Polk
Janet Gunn
draft-polk-sip-rph-in-responses-00
draft-gunn-sip-req-for-rph-in-responses-00.txt

1030
Media Identity
Dan Wing
draft-wing-sip-identity-media-01
1055
DTLS Framework
Eric Rescorla
Jason Fischl
draft-ietf-sip-dtls-srtp-framework-00
1130
End



--Apple-Mail-1--982039458
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1




Agenda revised =
again. Since Vijay won't be there to talk about connect-reuse, we'll =
tackle the candidates for the essential corrections =
process.


Session 1, Monday =
December 3, 1740-1950 Salon A/B
  =
 =
 =
 =
 =
 =

  
Start Time
 		 
Topic
 		 
Discussion Lead
 		 
Reading List
 		 
 
 
1740
 		 
Agenda Bash and Status
 =
 
Chairs
 		 
This document
 		 
 
1800
 		 
Location Conveyance
 
Brian =
Rosen
James =
Polk
 		   
 
1830
 		 
INFO Harmful
 		 
Eric =
Burger
 		   
 
 
1900
 		 
INFO =
Events
 		 
Hadriel Kaplan
 		   
 
1930
 		 
Essential corrections
 =
 
Keith =
Drage
 		 
draft-gurbani-sip-ipv6-abnf-fix-00
 draft-hilt-sip-correction-503-01
 =
draft-dotson-sip-mutual-auth-00
 draft-sparks-sip-invfix-00
 		 
 
1950
 		 
End
 		 

 =
 

 =
 
  

Session 2, Wednesday =
December 5, 0900-1130, Salon A/B
  =
 =
 =
 =

  
Start Time
 		 
Topic
 		 
Discussion Lead
 		 
Reading List
 		 
 
 
0900
 		 
Agenda Bash
 		 
Chairs
 		 
This Document
 		 
 
0910
 		 
Outbound
 		 
Rohan =
Mahy
 		   
 
 
1000
 		 
RPH In =
Responses
 		 
James Polk
Janet Gunn
 		 
draft-gunn-sip-req-for-rph-in-responses-00.txt
 =
 
 
 
1030
 		 
Media Identity
 		 
Dan =
Wing
 		   
 
1055
 		 
DTLS Framework
 		 
Eric =
Rescorla
Jason =
Fischl
 		   
 
1130
 		 
End
 		 

 =
 

 =
 
  
=

--Apple-Mail-1--982039458--



--===============0158253178==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0158253178==--





From sip-bounces@ietf.org Thu Nov 29 16:53:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxrJj-0000qb-C4; Thu, 29 Nov 2007 16:53:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxrJh-0000qD-ER
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 16:53:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrJh-0000q3-2G
	for sip@ietf.org; Thu, 29 Nov 2007 16:53:05 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrJg-0005r8-NU
	for sip@ietf.org; Thu, 29 Nov 2007 16:53:04 -0500
Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id lATLqwm9000907
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 29 Nov 2007 15:52:58 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <474F34C8.1000009@nostrum.com>
Date: Thu, 29 Nov 2007 15:53:12 -0600
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Dean Willis 
References: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>
In-Reply-To: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4954/Thu Nov 29 11:46:26 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: "sip@ietf.org List" , Cullen Jennings ,
	Keith Drage 
Subject: [Sip] Mutual Auth: Enhancement, not correction
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On 11/29/07 2:34 PM, Dean Willis wrote:
> 1930
> 	
> Essential corrections
> 	
> Keith Drage
> 	
> draft-ietf-sip-record-route-fix-01 
> 
>
> draft-gurbani-sip-ipv6-abnf-fix-00 
> 
> draft-hilt-sip-correction-503-01 
> 
> draft-dotson-sip-mutual-auth-00 
> 
> draft-sparks-sip-invfix-00 
> 
>
>
*
*Why are we considering draft-dotson-sip-mutual-auth for inclusion in 
the essential corrections process? Don't get me wrong -- the mechanism 
described in the document seems like a useful _extension_ to SIP, but 
it's hardly correcting something that's broken. I think things will get 
very confusing if we start couching _enhancements_ in terms of deltas to 
RFC 3261.

/a


_______________________________________________
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



From sip-bounces@ietf.org Thu Nov 29 22:41:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxwiE-00014c-Rn; Thu, 29 Nov 2007 22:38:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxwiD-00014G-Mq
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 22:38:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwiD-000141-Ce
	for sip@ietf.org; Thu, 29 Nov 2007 22:38:45 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IxwiC-0006pB-1S for sip@ietf.org; Thu, 29 Nov 2007 22:38:45 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-3.cisco.com with ESMTP; 29 Nov 2007 19:38:43 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3chaI026145
	for ; Thu, 29 Nov 2007 19:38:43 -0800
Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3bH7B006022
	for ; Fri, 30 Nov 2007 03:38:42 GMT
Mime-Version: 1.0 (Apple Message framework v752.3)
Impp: xmpp:cullenfluffyjennings@jabber.org
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <86C7B711-6067-4C5F-90D3-41D5C2EBB0B4@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings 
Date: Thu, 29 Nov 2007 19:38:08 -0800
To: SIP 
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1376; t=1196393923;
	x=1197257923; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20
	|Subject:=20draft-gunn-sip-req-for-rph-in-responses-00=20and=20draft-polk
	-sip-rph-in-responses-00 |Sender:=20;
	bh=dJcEe4JDJeqkhtc2WBgN6+LOzpC1m/OK1mhk2ujY8v8=;
	b=vJkoQSXM+M8SEA4a1gAlchVkBXxmVc7HQlxNC9RdaVSGlc1kV3oCoeo6Ggje3vqxJXmTbJIy
	g3AVTbH0heErkUFO4Q8Gr4ScBVTkqtqjvakcmAmzMmeyVyZnWpsP+K8F;
Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Sip] draft-gunn-sip-req-for-rph-in-responses-00 and
	draft-polk-sip-rph-in-responses-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


First thank you Janet and others for writing this up as draft - it  
makes the whole thing easier to discuss and get to resolution on.

Let me expand the example in figure 2 a bit. Same call flow but  
imagine there was an additional proxy, called P,  between A and the  
GETS AS and this proxy controlled some policy enforcement point that  
in the end impacted the reservation.

Few questions

1) is B required to copy the value from the INVITE to the 183

2) how does P decide if will use the value in the 183 or not

3) is A required to use the value in the 183 for the reservation

What I am trying to get at here is if we need a value in the response  
that is just a hint on what value would be good to use and  
reservation system will enforce it if the wrong value is used, or if  
we need something that is not a hint and more of a command to the  
policy system that a particular value is being used. If all that is  
needed is a hint of what will work, then that is much like the port  
number the UAS puts in an SDP and does not need any security  
properties other than integrity.From sip-bounces@ietf.org Thu Nov 29 22:41:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxwiE-00014c-Rn; Thu, 29 Nov 2007 22:38:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxwiD-00014G-Mq
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 22:38:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwiD-000141-Ce
	for sip@ietf.org; Thu, 29 Nov 2007 22:38:45 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IxwiC-0006pB-1S for sip@ietf.org; Thu, 29 Nov 2007 22:38:45 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-3.cisco.com with ESMTP; 29 Nov 2007 19:38:43 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3chaI026145
	for ; Thu, 29 Nov 2007 19:38:43 -0800
Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3bH7B006022
	for ; Fri, 30 Nov 2007 03:38:42 GMT
Mime-Version: 1.0 (Apple Message framework v752.3)
Impp: xmpp:cullenfluffyjennings@jabber.org
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <86C7B711-6067-4C5F-90D3-41D5C2EBB0B4@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings 
Date: Thu, 29 Nov 2007 19:38:08 -0800
To: SIP 
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1376; t=1196393923;
	x=1197257923; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20
	|Subject:=20draft-gunn-sip-req-for-rph-in-responses-00=20and=20draft-polk
	-sip-rph-in-responses-00 |Sender:=20;
	bh=dJcEe4JDJeqkhtc2WBgN6+LOzpC1m/OK1mhk2ujY8v8=;
	b=vJkoQSXM+M8SEA4a1gAlchVkBXxmVc7HQlxNC9RdaVSGlc1kV3oCoeo6Ggje3vqxJXmTbJIy
	g3AVTbH0heErkUFO4Q8Gr4ScBVTkqtqjvakcmAmzMmeyVyZnWpsP+K8F;
Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Sip] draft-gunn-sip-req-for-rph-in-responses-00 and
	draft-polk-sip-rph-in-responses-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


First thank you Janet and others for writing this up as draft - it  
makes the whole thing easier to discuss and get to resolution on.

Let me expand the example in figure 2 a bit. Same call flow but  
imagine there was an additional proxy, called P,  between A and the  
GETS AS and this proxy controlled some policy enforcement point that  
in the end impacted the reservation.

Few questions

1) is B required to copy the value from the INVITE to the 183

2) how does P decide if will use the value in the 183 or not

3) is A required to use the value in the 183 for the reservation

What I am trying to get at here is if we need a value in the response  
that is just a hint on what value would be good to use and  
reservation system will enforce it if the wrong value is used, or if  
we need something that is not a hint and more of a command to the  
policy system that a particular value is being used. If all that is  
needed is a hint of what will work, then that is much like the port  
number the UAS puts in an SDP and does not need any security  
properties other than integrity. If on the other hand this is  
something that tell the policy system what to do, it would need a  
good explanation around what the authorization process was that A and  
P used when receiving the 183.

Cullen 


_______________________________________________
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

From sip-bounces@ietf.org Thu Nov 29 22:41:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxwiP-0001Eu-So; Thu, 29 Nov 2007 22:38:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxwiN-0001DC-PJ
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 22:38:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwiN-0001Cg-Df
	for sip@ietf.org; Thu, 29 Nov 2007 22:38:55 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxwiL-0006rX-85
	for sip@ietf.org; Thu, 29 Nov 2007 22:38:55 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 19:38:52 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3cqgL026388; 
	Thu, 29 Nov 2007 19:38:52 -0800
Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3bH7C006022;
	Fri, 30 Nov 2007 03:38:52 GMT
In-Reply-To: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
References: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
Impp: xmpp:cullenfluffyjennings@jabber.org
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <34987C2B-5799-49CC-BD9F-037920392E47@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings 
Subject: Re: [Sip] SIPit 21: BNF and DIGEST authentication
Date: Thu, 29 Nov 2007 19:38:18 -0800
To: sip List 
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1686; t=1196393932;
	x=1197257932; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20
	|Subject:=20Re=3A=20[Sip]=20SIPit=2021=3A=20BNF=20and=20DIGEST=20authenti
	cation |Sender:=20;
	bh=uznHHgNHPkLiiVI6qexUr7409swM4zPbCJ/WIJiHQTk=;
	b=NFXlwJi3ikKHX/Bs+0+gEFI5Y2CD7G3lJzalnmpHm71S64ahaavJc8qaIhwWpbuBF6cFYHnK
	zeupZTXkEuzuBwVj1RAP+oFw/gDfi48++j4F2VhClcwgdbgvyAgPKAGK;
Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


I'm worried that any change would break the things that currently  
work. Any idea of how existing equipment would react?

(yah, yah, with my individual contribute hat on - I hate typing this  
more than you hate reading it)

On Nov 19, 2007, at 1:40 PM, Robert Sparks wrote:

> We are _still_ seeing interoperability problems because of quotes  
> around the qop parameter value in challenges and responses.
>
> What's specified now is that quotes MUST appear in challenges (it's  
> a list of things) and MUST NOT appear i If on the other hand this is  
something that tell the policy system what to do, it would need a  
good explanation around what the authorization process was that A and  
P used when receiving the 183.

Cullen 


_______________________________________________
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

From sip-bounces@ietf.org Thu Nov 29 22:41:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxwiP-0001Eu-So; Thu, 29 Nov 2007 22:38:57 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxwiN-0001DC-PJ
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 22:38:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwiN-0001Cg-Df
	for sip@ietf.org; Thu, 29 Nov 2007 22:38:55 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxwiL-0006rX-85
	for sip@ietf.org; Thu, 29 Nov 2007 22:38:55 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 19:38:52 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3cqgL026388; 
	Thu, 29 Nov 2007 19:38:52 -0800
Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3bH7C006022;
	Fri, 30 Nov 2007 03:38:52 GMT
In-Reply-To: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
References: <686DE810-C161-41FD-BEC8-DB48B841604F@nostrum.com>
Impp: xmpp:cullenfluffyjennings@jabber.org
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <34987C2B-5799-49CC-BD9F-037920392E47@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings 
Subject: Re: [Sip] SIPit 21: BNF and DIGEST authentication
Date: Thu, 29 Nov 2007 19:38:18 -0800
To: sip List 
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1686; t=1196393932;
	x=1197257932; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20
	|Subject:=20Re=3A=20[Sip]=20SIPit=2021=3A=20BNF=20and=20DIGEST=20authenti
	cation |Sender:=20;
	bh=uznHHgNHPkLiiVI6qexUr7409swM4zPbCJ/WIJiHQTk=;
	b=NFXlwJi3ikKHX/Bs+0+gEFI5Y2CD7G3lJzalnmpHm71S64ahaavJc8qaIhwWpbuBF6cFYHnK
	zeupZTXkEuzuBwVj1RAP+oFw/gDfi48++j4F2VhClcwgdbgvyAgPKAGK;
Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


I'm worried that any change would break the things that currently  
work. Any idea of how existing equipment would react?

(yah, yah, with my individual contribute hat on - I hate typing this  
more than you hate reading it)

On Nov 19, 2007, at 1:40 PM, Robert Sparks wrote:

> We are _still_ seeing interoperability problems because of quotes  
> around the qop parameter value in challenges and responses.
>
> What's specified now is that quotes MUST appear in challenges (it's  
> a list of things) and MUST NOT appear in responses (it's a choice  
> of one thing).
>
> This causes lots of people to write broken code.
>
> For the code that does work, this causes people to either build  
> separate parsers for headers with the same name, using the  
> knowledge of whether its a challenge or response to invoke the  
> right parser, or to build parsers that don't follow the BNF we've  
> provided.
>
> Would it make more sense to change the BNF to allow the quotes  
> optionally in either the challenge or the response?
>
> Nobody that I've asked is actually re-using an HTTP parser for  
> this, and nobody seems to be getting the number of values for the  
> parameter wrong. Most of the folks I ask are building their parsers  
> this way anyhow
>
> What would be bad about making this change to the spec?
>
> RjS
>
>
>
> _______________________________________________
> 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


_______________________________________________
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





n responses (it's a choice  
> of one thing).
>
> This causes lots of people to write broken code.
>
> For the code that does work, this causes people to either build  
> separate parsers for headers with the same name, using the  
> knowledge of whether its a challenge or response to invoke the  
> right parser, or to build parsers that don't follow the BNF we've  
> provided.
>
> Would it make more sense to change the BNF to allow the quotes  
> optionally in either the challenge or the response?
>
> Nobody that I've asked is actually re-using an HTTP parser for  
> this, and nobody seems to be getting the number of values for the  
> parameter wrong. Most of the folks I ask are building their parsers  
> this way anyhow
>
> What would be bad about making this change to the spec?
>
> RjS
>
>
>
> _______________________________________________
> 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


_______________________________________________
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





From sip-bounces@ietf.org Thu Nov 29 23:14:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxxE5-0003z6-2t; Thu, 29 Nov 2007 23:11:41 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxxE3-0003yq-6n
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 23:11:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxxE2-0003yi-T8
	for sip@ietf.org; Thu, 29 Nov 2007 23:11:38 -0500
Received: from nz-out-0506.google.com ([64.233.162.236])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxxE2-0005Wm-Jx
	for sip@ietf.org; Thu, 29 Nov 2007 23:11:38 -0500
Received: by nz-out-0506.google.com with SMTP id n1so1700241nzf
	for ; Thu, 29 Nov 2007 20:11:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=1M29vxU8uXWDp2m7YuxESo7Lx1EtfCrVlErbFQaErRo=;
	b=ocYuAxcXmg2ax7rSrDsKWfEfmTV99e30ZjxIFqj6Ggd8v3/Ep3nryL76AgI5U3If3/Yt7C3m391uk7iMEq1ID/BrcWIzo4Z0u4b0X/+w5ulF2zjPzyDDFukJ+K+HVzDlGzUWQx+utoClel0YxTdQ2YeSgLcgNqvMagHwx27XSpk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=PF97eyydguTQVGFm8nof9/07pH+kvO2R48rgqc8hApogIthh3LykTtLxHmN0/KQOAv7hNjrCs2UvzywiNjR3zWRAwGbb/lVIQdNijTC9ct6hjOalaZKvRd/ekYzLW1tzP2BtWoLgZNNgdBwBdlMjeNSPGbf6lGmtO+ZFHxuxlh8=
Received: by 10.64.179.12 with SMTP id b12mr17231752qbf.1196395898118;
	Thu, 29 Nov 2007 20:11:38 -0800 (PST)
Received: by 10.64.76.18 with HTTP; Thu, 29 Nov 2007 20:11:38 -0800 (PST)
Message-ID: <66cd252f0711292011w47e49565n783c59e29e64d2d3@mail.gmail.com>
Date: Fri, 30 Nov 2007 15:11:38 +1100
From: "Hisham Khartabil" 
To: "Robert Sparks" 
Subject: Re: [Sip] SIPit 21 : Topics that attendees argued about
In-Reply-To: 
MIME-Version: 1.0
References: <144ED8561CE90C41A3E5908EDECE315C051D0A42@IsrExch01.israel.polycom.com>
	
	
	<200711231731.lANHVE4Z028135@dragon.ariadne.com>
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2040917410=="
Errors-To: sip-bounces@ietf.org

--===============2040917410==
Content-Type: multipart/alternative; 
	boundary="----=_Part_12804_31379602.1196395898103"

------=_Part_12804_31379602.1196395898103
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 27/11/2007, Robert Sparks  wrote:
>
> Dale -
>
> What you quoted talks about what the offer can _send_.
> It doesn't talk about what the offerer must be willing to receive
> (nor does it constrain what the answerer can send).


The last sentence from dale's quote says:

"The offerer MAY immediately cease listening for media formats that
  were listed in the initial offer, but not present in the answer"

Isn't that good enough to suggest that the offerer may accept only what both
have negotiated in the offer/answer exchange?

Hisham

------=_Part_12804_31379602.1196395898103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline





On 27/11/2007, Robert Sparks <rjsparks@nostrum.com> wrote:

Dale -

What you quoted talks about what the offer can _send_.
It doesn't talk about what the offerer must be willing to receive

(nor does it constrain what the answerer can send).


 


The last sentence from dale's quote says:


 


"The offerer MAY immediately cease listening for media formats that
  were listed in the initial offer, but not present in the answer"


 


Isn't that good enough to suggest that the offerer may accept only what both have negotiated in the offer/answer exchange?






 


Hisham
 

 


------=_Part_12804_31379602.1196395898103--



--===============2040917410==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============2040917410==--





From sip-bounces@ietf.org Thu Nov 29 23:32:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxxWN-0008PR-F9; Thu, 29 Nov 2007 23:30:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IxxWL-0008PK-Q4
	for sip-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 23:30:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxxWL-0008PA-Ep
	for sip@ietf.org; Thu, 29 Nov 2007 23:30:33 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxxWL-0001g0-1r
	for sip@ietf.org; Thu, 29 Nov 2007 23:30:33 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2007 23:30:32 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU4UW6T009224
	for ; Thu, 29 Nov 2007 23:30:32 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAU4UW0i018055
	for ; Fri, 30 Nov 2007 04:30:32 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 29 Nov 2007 23:30:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 21: BNF and DIGEST authentication
Date: Thu, 29 Nov 2007 23:30:30 -0500
Message-ID: <8983EC086A9D954BA74D9763E853CF3E0446871E@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <34987C2B-5799-49CC-BD9F-037920392E47@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 21: BNF and DIGEST authentication
Thread-Index: AcgzAo422llJX/CbRsSUONuW9lZiIgABu8Ew
From: "Sanjay Sinha (sanjsinh)" 
To: "Cullen Jennings (fluffy)" , "sip List" 
X-OriginalArrivalTime: 30 Nov 2007 04:30:32.0636 (UTC)
	FILETIME=[BEA66FC0:01C83309]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2414; t=1196397032;
	x=1197261032; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20
	|Subject:=20RE=3A=20[Sip]=20SIPit=2021=3A=20BNF=20and=20DIGEST=20authenti
	cation |Sender:=20
	|To:=20=22Cullen=20Jennings=20(fluffy)=22=20,
	=20=22sip= 20List=22=20;
	bh=UgAb9zXNzNCf0wyUxVitDi8Z2SV4pqQ5psRBP0SfGAM=;
	b=0tjdlj0tWaZY2NG0ZonUEpBkVQIMJsl9Q1l2KQMcZe7K8vEPi0VW8hCyfOUsAX0+z3ynviuC
	tuH182EqA1FPANgoIwI6K2lKGe5oMpFtn+/MBomG58IIjkIBZMJVbH3Z;
Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

Equipments which are liberal in what they receive and strict in what
they send should not have problem with this change.

Sanjay=20

>-----Original Message-----
>From: Cullen Jennings (fluffy)=20
>Sent: Thursday, November 29, 2007 10:38 PM
>To: sip List
>Subject: Re: [Sip] SIPit 21: BNF and DIGEST authentication
>
>
>I'm worried that any change would break the things that=20
>currently work. Any idea of how existing equipment would react?
>
>(yah, yah, with my individual contribute hat on - I hate=20
>typing this more than you hate reading it)
>
>On Nov 19, 2007, at 1:40 PM, Robert Sparks wrote:
>
>> We are _still_ seeing interoperability problems because of quotes=20
>> around the qop parameter value in challenges and responses.
>>
>> What's specified now is that quotes MUST appear in=20
>challenges (it's a=20
>> list of things) and MUST NOT appear in responses (it's a=20
>choice of one=20
>> thing).
>>
>> This causes lots of people to write broken code.
>>
>> For the code that does work, this causes people to either build=20
>> separate parsers for headers with the same name, using the knowledge=20
>> of whether its a challenge or response to invoke the right=20
>parser, or=20
>> to build parsers that don't follow the BNF we've provided.
>>
>> Would it make more sense to change the BNF to allow the quotes=20
>> optionally in either the challenge or the response?
>>
>> Nobody that I've asked is actually re-using an HTTP parser for this,=20
>> and nobody seems to be getting the number of values for the=20
>parameter=20
>> wrong. Most of the folks I ask are building their parsers this way=20
>> anyhow
>>
>> What would be bad about making this change to the spec?
>>
>> RjS
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 01:06:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ixz0m-0000PV-GW; Fri, 30 Nov 2007 01:06:04 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Ixz0l-0000EM-1i
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 01:06:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixz0k-0000EE-O7
	for sip@ietf.org; Fri, 30 Nov 2007 01:06:02 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixz0k-0002KY-8s
	for sip@ietf.org; Fri, 30 Nov 2007 01:06:02 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113] (may be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAU65r5l015456
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 30 Nov 2007 00:05:54 -0600
In-Reply-To: <474F34C8.1000009@nostrum.com>
References: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>
	<474F34C8.1000009@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] Mutual Auth: Enhancement, not correction
Date: Fri, 30 Nov 2007 00:05:46 -0600
To: Adam Roach 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: "sip@ietf.org List" , Cullen Jennings ,
	Keith Drage 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 29, 2007, at 3:53 PM, Adam Roach wrote:

>> *
> *Why are we considering draft-dotson-sip-mutual-auth for inclusion  
> in the essential corrections process? Don't get me wrong -- the  
> mechanism described in the document seems like a useful _extension_  
> to SIP, but it's hardly correcting something that's broken. I think  
> things will get very confusing if we start couching _enhancements_  
> in terms of deltas to RFC 3261.
>

the argument goes that this was a bug in RFC 3261:

RFC 2543 had this to say about the Authentication-Info headers:

14.3 Digest Authentication

    The rules for digest authentication follow those defined in [36],
    with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following
    differences:
         4.   The Authentication-Info and Proxy-Authentication-Info
              fields are not used in SIP.

But by the time we did RFC 3261, we had decided that mutual  
authentication using digest was important, so we added:

20.6 Authentication-Info

    The Authentication-Info header field provides for mutual
    authentication with HTTP Digest.  A UAS MAY include this header  
field
    in a 2xx response to a request that was successfully authenticated
    using digest based on the Authorization header field.

    Syntax and semantics follow those specified in RFC 2617 [17].

    Example:

       Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

But for some currently unknown reason, we forgot to add the also- 
important Proxy-Authentication-Info header back in.

Now, is that a bug in the spec that needs correction, or is it an  
enhancement? Enquiring minds want to know.

--
Dean




_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 06:14:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iy3oo-00006Y-NS; Fri, 30 Nov 2007 06:14:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iy3om-00005u-GF
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 06:14:00 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3om-00005j-5a
	for sip@ietf.org; Fri, 30 Nov 2007 06:14:00 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy3ol-0007ow-CA
	for sip@ietf.org; Fri, 30 Nov 2007 06:13:59 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAUBDgvo027278;
	Fri, 30 Nov 2007 05:13:53 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 30 Nov 2007 05:13:29 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 30 Nov 2007 12:13:27 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Mutual Auth: Enhancement, not correction
Date: Fri, 30 Nov 2007 12:13:26 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019B7577@DEEXC1U01.de.lucent.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Mutual Auth: Enhancement, not correction
Thread-Index: AcgzFxl1veu7Sc/WRAuGCbgadFc7gAAKiN3Q
References: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>
	<474F34C8.1000009@nostrum.com>
	
From: "DRAGE, Keith \(Keith\)" 
To: "Dean Willis" , "Adam Roach" 
X-OriginalArrivalTime: 30 Nov 2007 11:13:27.0659 (UTC)
	FILETIME=[081633B0:01C83342]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: sip@ietf.org, Cullen Jennings 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I got halfway through my answer to Adam, and discovered Dean had got
there first.=20

Dean has answered all the technical issues, although feedback would be
useful from the large number of people that got involved in the final
delivery of RFC 3261 on how Proxy-Authentication-Info was omitted at the
time that the Authentication-Info header was added (we've asked the key
people who supposedly did this section and not got any input).=20

That leads me only to add:

The SIP WG does it, whether it is an bugfix or not, so the progression
will not be so different, one way or the other. (In security issues SIP
does both the requirements and the protocol).

But the floor is open on all these to indicate:

-	progress rapidly
-	reject
-	more discussion needed
-	treat as a normal extension

And we would welcome such input to the list - if time permits in
Vancouver we will also be asking this at the end of one of the sessions.

Regards

Keith

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Friday, November 30, 2007 6:06 AM
> To: Adam Roach
> Cc: sip@ietf.org List; Cullen Jennings; DRAGE, Keith (Keith)
> Subject: Re: [Sip] Mutual Auth: Enhancement, not correction
>=20
>=20
> On Nov 29, 2007, at 3:53 PM, Adam Roach wrote:
>=20
> >> *
> > *Why are we considering draft-dotson-sip-mutual-auth for=20
> inclusion in=20
> > the essential corrections process? Don't get me wrong --=20
> the mechanism=20
> > described in the document seems like a useful _extension_=20
> to SIP, but=20
> > it's hardly correcting something that's broken. I think things will=20
> > get very confusing if we start couching _enhancements_ in terms of=20
> > deltas to RFC 3261.
> >
>=20
> the argument goes that this was a bug in RFC 3261:
>=20
> RFC 2543 had this to say about the Authentication-Info headers:
>=20
> 14.3 Digest Authentication
>=20
>     The rules for digest authentication follow those defined in [36],
>     with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following
>     differences:
>          4.   The Authentication-Info and Proxy-Authentication-Info
>               fields are not used in SIP.
>=20
> But by the time we did RFC 3261, we had decided that mutual=20
> authentication using digest was important, so we added:
>=20
> 20.6 Authentication-Info
>=20
>     The Authentication-Info header field provides for mutual
>     authentication with HTTP Digest.  A UAS MAY include this=20
> header field
>     in a 2xx response to a request that was successfully authenticated
>     using digest based on the Authorization header field.
>=20
>     Syntax and semantics follow those specified in RFC 2617 [17].
>=20
>     Example:
>=20
>        Authentication-Info: nextnonce=3D"47364c23432d2e131a5fb210812c"
>=20
> But for some currently unknown reason, we forgot to add the=20
> also- important Proxy-Authentication-Info header back in.
>=20
> Now, is that a bug in the spec that needs correction, or is=20
> it an enhancement? Enquiring minds want to know.
>=20
> --
> Dean
>=20
>=20
>=20


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 10:58:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iy8FV-0006I8-BB; Fri, 30 Nov 2007 10:57:53 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iy8FU-0006Hu-Pz
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 10:57:52 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8FU-0006He-E0
	for sip@ietf.org; Fri, 30 Nov 2007 10:57:52 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy8FT-000778-Ns
	for sip@ietf.org; Fri, 30 Nov 2007 10:57:52 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-3.cisco.com with ESMTP; 30 Nov 2007 07:57:39 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAUFvd66000807; 
	Fri, 30 Nov 2007 07:57:39 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAUFvV75009715;
	Fri, 30 Nov 2007 15:57:31 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 30 Nov 2007 07:57:31 -0800
Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 30 Nov 2007 07:57:30 -0800
Message-ID: <4750330C.207@cisco.com>
Date: Fri, 30 Nov 2007 10:58:04 -0500
From: Jonathan Rosenberg 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "DRAGE, Keith \(Keith\)" 
Subject: Re: [Sip] Mutual Auth: Enhancement, not correction
References: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>	<474F34C8.1000009@nostrum.com>	
	<5D1A7985295922448D5550C94DE29180019B7577@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180019B7577@DEEXC1U01.de.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Nov 2007 15:57:30.0596 (UTC)
	FILETIME=[B6780240:01C83369]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4370; t=1196438259;
	x=1197302259; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20
	|Subject:=20Re=3A=20[Sip]=20Mutual=20Auth=3A=20Enhancement,
	=20not=20corre ction |Sender:=20;
	bh=/lvHkCwXIasEYDvzAH1CW9RtKY3kwrjr27tuJuvhehQ=;
	b=djjWfKEjq8C1KzZ/C6oFP4id9VA6iB4lj14SKutbkKU/PtXvam9jXX3k4DwBW7fTlyYHNLk6
	YtQqXzilp62C+Wda1Fn2GbiVypW1Zv4U/vKYhW2SpmVYKXDJYXhlbECR;
Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: sip@ietf.org, Cullen Jennings ,
	Adam Roach , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I don't actually recall explicitly deciding to reject 
Proxy-Authentication-Info; however it was a long time ago. But anyway, 
its water under the bridge. Clearly its not there.

That said, I agree with Adam and do not think this is an essential 
correction. Its a new feature. It adds proxy to user authentication. 
Indeed, I think its clearly the case that there are differing 
requirements driving user to proxy authentication than there are driving 
the reverse (one is for protecting against fraud, the other against 
malicious proxies).

-Jonathan R.

DRAGE, Keith (Keith) wrote:
> I got halfway through my answer to Adam, and discovered Dean had got
> there first. 
> 
> Dean has answered all the technical issues, although feedback would be
> useful from the large number of people that got involved in the final
> delivery of RFC 3261 on how Proxy-Authentication-Info was omitted at the
> time that the Authentication-Info header was added (we've asked the key
> people who supposedly did this section and not got any input). 
> 
> That leads me only to add:
> 
> The SIP WG does it, whether it is an bugfix or not, so the progression
> will not be so different, one way or the other. (In security issues SIP
> does both the requirements and the protocol).
> 
> But the floor is open on all these to indicate:
> 
> -	progress rapidly
> -	reject
> -	more discussion needed
> -	treat as a normal extension
> 
> And we would welcome such input to the list - if time permits in
> Vancouver we will also be asking this at the end of one of the sessions.
> 
> Regards
> 
> Keith
> 
>> -----Original Message-----
>> From: Dean Willis [mailto:dean.willis@softarmor.com] 
>> Sent: Friday, November 30, 2007 6:06 AM
>> To: Adam Roach
>> Cc: sip@ietf.org List; Cullen Jennings; DRAGE, Keith (Keith)
>> Subject: Re: [Sip] Mutual Auth: Enhancement, not correction
>>
>>
>> On Nov 29, 2007, at 3:53 PM, Adam Roach wrote:
>>
>>>> *
>>> *Why are we considering draft-dotson-sip-mutual-auth for 
>> inclusion in 
>>> the essential corrections process? Don't get me wrong -- 
>> the mechanism 
>>> described in the document seems like a useful _extension_ 
>> to SIP, but 
>>> it's hardly correcting something that's broken. I think things will 
>>> get very confusing if we start couching _enhancements_ in terms of 
>>> deltas to RFC 3261.
>>>
>> the argument goes that this was a bug in RFC 3261:
>>
>> RFC 2543 had this to say about the Authentication-Info headers:
>>
>> 14.3 Digest Authentication
>>
>>     The rules for digest authentication follow those defined in [36],
>>     with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following
>>     differences:
>>          4.   The Authentication-Info and Proxy-Authentication-Info
>>               fields are not used in SIP.
>>
>> But by the time we did RFC 3261, we had decided that mutual 
>> authentication using digest was important, so we added:
>>
>> 20.6 Authentication-Info
>>
>>     The Authentication-Info header field provides for mutual
>>     authentication with HTTP Digest.  A UAS MAY include this 
>> header field
>>     in a 2xx response to a request that was successfully authenticated
>>     using digest based on the Authorization header field.
>>
>>     Syntax and semantics follow those specified in RFC 2617 [17].
>>
>>     Example:
>>
>>        Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
>>
>> But for some currently unknown reason, we forgot to add the 
>> also- important Proxy-Authentication-Info header back in.
>>
>> Now, is that a bug in the spec that needs correction, or is 
>> it an enhancement? Enquiring minds want to know.
>>
>> --
>> Dean
>>
>>
>>
> 
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 11:32:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iy8mp-0004Ae-DS; Fri, 30 Nov 2007 11:32:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iy8mo-0004AK-Ct
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 11:32:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8mo-0004A8-36
	for sip@ietf.org; Fri, 30 Nov 2007 11:32:18 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy8mm-0003KW-KR
	for sip@ietf.org; Fri, 30 Nov 2007 11:32:18 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAUGW72l019300
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 30 Nov 2007 10:32:09 -0600
In-Reply-To: <4750330C.207@cisco.com>
References: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>	<474F34C8.1000009@nostrum.com>	
	<5D1A7985295922448D5550C94DE29180019B7577@DEEXC1U01.de.lucent.com>
	<4750330C.207@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <19C2338F-C857-45F6-9E6E-AC4A04729D94@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Subject: Re: [Sip] Mutual Auth: Enhancement, not correction
Date: Fri, 30 Nov 2007 10:31:59 -0600
To: Jonathan Rosenberg 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: sip@ietf.org, Cullen Jennings , "DRAGE,
	Keith \(Keith\)" , Adam Roach 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org


On Nov 30, 2007, at 9:58 AM, Jonathan Rosenberg wrote:


> That said, I agree with Adam and do not think this is an essential  
> correction. Its a new feature. It adds proxy to user  
> authentication. Indeed, I think its clearly the case that there are  
> differing requirements driving user to proxy authentication than  
> there are driving the reverse (one is for protecting against fraud,  
> the other against malicious proxies).
>

I don't disagree with the result (progress the draft outside the  
essential corrections process) but I think the use-case is really the  
same: SIP nodes protecting themselves from other SIP nodes that may  
be impostors.

It doesn't really matter whether the nodes in question are proxies or  
user agents -- after all, some nodes will be proxies for some request  
and UAs for other requests. The way you have it worded makes it sound  
as if the proxies are trustworthy and the user agents aren't, which  
is classic "telco" mentality and not particularly valid in an  
Internet scenario. In the real world, I expect to see both hostile  
proxies and hostile user agents.

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 12:04:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iy9HM-0002Ob-91; Fri, 30 Nov 2007 12:03:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Iy9HL-0002NA-5I
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 12:03:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9HK-0002Mr-RK
	for sip@ietf.org; Fri, 30 Nov 2007 12:03:50 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy9HK-0000wV-Dw
	for sip@ietf.org; Fri, 30 Nov 2007 12:03:50 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lAUH3m1F019462
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for ; Fri, 30 Nov 2007 11:03:50 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <1EC35A41-BC3F-4EE1-80C1-07BE038519A3@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: "sip@ietf.org List" 
From: Dean Willis 
Date: Fri, 30 Nov 2007 11:03:40 -0600
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: [Sip] Repeat: announcement of SIP interop workshop at IETF 70
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

I'm posting this for Eric Burger, acting in his role at the SIP  
Forum. If you have questions, ask Eric. Like one of my favorite  
television characters of the 70s, "I know nothing!"

---------

The First SIP Forum SIP Interoperability Workshop will be held Monday,
December 3, from 11:30am - 1pm in Salon B at the Westin Bayshore Hotel
in Vancouver, British Columbia, Canada.

The agenda and papers will be posted shortly.

Note the session is open to the community.  However, making
presentations and lunch are only available to those individuals who, per
the Call for Papers and Participation, submitted a position paper.


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 13:13:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IyALp-0005b2-Pn; Fri, 30 Nov 2007 13:12:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IyALp-0005al-2Y
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 13:12:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IyALo-0005a4-4J
	for sip@ietf.org; Fri, 30 Nov 2007 13:12:32 -0500
Received: from ondar.cablelabs.com ([192.160.73.61])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyALn-0002ZW-32
	for sip@ietf.org; Fri, 30 Nov 2007 13:12:31 -0500
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lAUICNlJ022601;
	Fri, 30 Nov 2007 11:12:23 -0700
Received: from srvxchg3.cablelabs.com (10.5.0.25)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com);
	Fri, 30 Nov 2007 11:12:22 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Mutual Auth: Enhancement, not correction
Date: Fri, 30 Nov 2007 11:12:23 -0700
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C64BAC2D@srvxchg3.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Mutual Auth: Enhancement, not correction
Thread-Index: Acgzbps8rHGTMWrUQB+vF2fW64ZdDgADLEnR
References: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>	<474F34C8.1000009@nostrum.com>	
	<5D1A7985295922448D5550C94DE29180019B7577@DEEXC1U01.de.lucent.com>
	<4750330C.207@cisco.com>
	<19C2338F-C857-45F6-9E6E-AC4A04729D94@softarmor.com>
From: "Sumanth Channabasappa" 
To: "Dean Willis" ,
	"Jonathan Rosenberg" 
X-Approved: ondar
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: sip@ietf.org, Cullen Jennings , "DRAGE,
	Keith \(Keith\)" , Adam Roach 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0987049715=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0987049715==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8337C.8DFD9931"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8337C.8DFD9931
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Agree with Dean (w.r.t. technical details and the scenarios to protect =
the client from),=20
That said, I think it was felt that this was left out as an oversight, =
as opposed=20
to a conscious decision (need  verification of this, as Keith indicated =
earlier).=20
=20
In any case it would be nice to progress the I-D within the WG =
(irrespective of
the path chosen) and see if there is something amiss in what is being=20
proposed.=20
=20
- S

________________________________

From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Fri 11/30/2007 9:31 AM
To: Jonathan Rosenberg
Cc: sip@ietf.org; Cullen Jennings; DRAGE,Keith (Keith); Adam Roach
Subject: Re: [Sip] Mutual Auth: Enhancement, not correction




On Nov 30, 2007, at 9:58 AM, Jonathan Rosenberg wrote:


> That said, I agree with Adam and do not think this is an essential=20
> correction. Its a new feature. It adds proxy to user=20
> authentication. Indeed, I think its clearly the case that there are=20
> differing requirements driving user to proxy authentication than=20
> there are driving the reverse (one is for protecting against fraud,=20
> the other against malicious proxies).
>

I don't disagree with the result (progress the draft outside the=20
essential corrections process) but I think the use-case is really the=20
same: SIP nodes protecting themselves from other SIP nodes that may=20
be impostors.

It doesn't really matter whether the nodes in question are proxies or=20
user agents -- after all, some nodes will be proxies for some request=20
and UAs for other requests. The way you have it worded makes it sound=20
as if the proxies are trustworthy and the user agents aren't, which=20
is classic "telco" mentality and not particularly valid in an=20
Internet scenario. In the real world, I expect to see both hostile=20
proxies and hostile user agents.

--
Dean


_______________________________________________
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




------_=_NextPart_001_01C8337C.8DFD9931
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: [Sip] Mutual Auth: Enhancement, not =
correction=0A=
=0A=
=0A=
=0A=

=0A=

Agree with =
Dean (w.r.t. technical details and the scenarios to protect the client =
from), 
=0A=

That said, I think it was felt that =
this =
was left out as an oversight, as opposed 
=0A=

to =
a conscious =
decision (need  verification of =
this, as Keith indicated earlier). 
=0A=

 
=0A=

In any case it would be nice to progress the I-D within the WG (irrespective =
of
=0A=

the path chosen) and see if =
there is something amiss in what is =
being 
=0A=

proposed. 
=0A=

 
=0A=

- S
=0A=


=0A=

=0A=
From: Dean Willis =
[mailto:dean.willis@softarmor.com]
Sent: Fri 11/30/2007 9:31 =
AM
To: Jonathan Rosenberg
Cc: sip@ietf.org; Cullen =
Jennings; DRAGE,Keith (Keith); Adam Roach
Subject: Re: [Sip] =
Mutual Auth: Enhancement, not correction

=0A=


=0A=

On Nov 30, 2007, at 9:58 AM, Jonathan Rosenberg =
wrote:


> That said, I agree with Adam and do not think =
this is an essential 
> correction. Its a new feature. It =
adds proxy to user 
> authentication. Indeed, I think its =
clearly the case that there are 
> differing requirements =
driving user to proxy authentication than 
> there are =
driving the reverse (one is for protecting against fraud, 
> =
the other against malicious proxies).
>

I don't disagree =
with the result (progress the draft outside the 
essential =
corrections process) but I think the use-case is really =
the 
same: SIP nodes protecting themselves from other SIP nodes =
that may 
be impostors.

It doesn't really matter whether =
the nodes in question are proxies or 
user agents -- after all, =
some nodes will be proxies for some request 
and UAs for other =
requests. The way you have it worded makes it sound 
as if the =
proxies are trustworthy and the user agents aren't, which 
is =
classic "telco" mentality and not particularly valid in =
an 
Internet scenario. In the real world, I expect to see both =
hostile 
proxies and hostile user =
agents.

--
Dean


____________________________________=
___________
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


------_=_NextPart_001_01C8337C.8DFD9931--



--===============0987049715==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0987049715==--





From sip-bounces@ietf.org Fri Nov 30 13:39:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IyAlA-0007Y6-En; Fri, 30 Nov 2007 13:38:44 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IyAl8-0007XK-Ob
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 13:38:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAl8-0007X8-EX
	for sip@ietf.org; Fri, 30 Nov 2007 13:38:42 -0500
Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyAl8-0001Mx-1s
	for sip@ietf.org; Fri, 30 Nov 2007 13:38:42 -0500
Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74])
	by mail.iptel.org (Postfix) with ESMTP id BB2A01810C1A;
	Fri, 30 Nov 2007 19:38:40 +0100 (CET)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 30 Nov 2007 19:31:47 +0100
To: Jonathan Rosenberg ,
	"DRAGE, Keith \(Keith\)" 
From: Jiri Kuthan 
Subject: Re: [Sip] Mutual Auth: Enhancement, not correction
In-Reply-To: <4750330C.207@cisco.com>
References: <7043BEF2-D7CF-41AC-8D55-3FB2C08D5644@softarmor.com>
	<474F34C8.1000009@nostrum.com>
	
	<5D1A7985295922448D5550C94DE29180019B7577@DEEXC1U01.de.lucent.com>
	<4750330C.207@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20071130183840.BB2A01810C1A@mail.iptel.org>
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: sip@ietf.org, Cullen Jennings ,
	Adam Roach , Dean Willis 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

At 16:58 30/11/2007, Jonathan Rosenberg wrote:
>I don't actually recall explicitly deciding to reject Proxy-Authentication-Info; however it was a long time ago. But anyway, its water under the bridge. Clearly its not there.
>
>That said, I agree with Adam and do not think this is an essential correction. Its a new feature. It adds proxy to user authentication. 

However, the capability to authenticate proxy servers can help to address an ugly security gap: 
relay attacks. Such can be orchestrated fairly easily (e.g., without eavesdropping
capability) now and allow impersonation of a user. That said, it appears a piece of work to
me which deserves appropriate attention. 

-jiri

>Indeed, I think its clearly the case that there are differing requirements driving user to proxy authentication than there are driving the reverse (one is for protecting against fraud, the other against malicious proxies).
>
>-Jonathan R.



--
Jiri Kuthan            http://iptel.org/~jiri/



_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 20:49:20 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IyHT4-0001OF-Gs; Fri, 30 Nov 2007 20:48:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IyHT3-0001FV-Eo
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 20:48:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IyHT2-00018E-SI
	for sip@ietf.org; Fri, 30 Nov 2007 20:48:28 -0500
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyHT2-00041k-52
	for sip@ietf.org; Fri, 30 Nov 2007 20:48:28 -0500
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113] (may be forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	lB11mQph022512
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for ; Fri, 30 Nov 2007 19:48:27 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
References: 
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <00036582-6B50-4127-9F35-3F05CFD3CAAA@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis 
Date: Fri, 30 Nov 2007 19:48:18 -0600
To: "sip@ietf.org List" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Subject: [Sip] SIP Interop Workshop Materials Posted
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

On behalf of the SIP Interop Workshop organizers:

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

The submitted position papers for the First SIP Interoperability
Workshop can be found here:


Some mailers may break the above line.  Remember to reassemble it.
Otherwise, here is a TinyURL link to the same page.
http://tinyurl.com/2mq5cz




_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 23:48:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IyKGm-0005ja-VT; Fri, 30 Nov 2007 23:48:00 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IyKGl-0005jN-8f
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 23:47:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IyKGk-0005jC-VH
	for sip@ietf.org; Fri, 30 Nov 2007 23:47:58 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyKGj-0003wF-Jl
	for sip@ietf.org; Fri, 30 Nov 2007 23:47:58 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lB14lsKw001816
	for ; Fri, 30 Nov 2007 22:47:57 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 30 Nov 2007 22:47:56 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 1 Dec 2007 05:47:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 1 Dec 2007 05:47:54 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-kaplan-sip-info-events-00
Thread-Index: Acgzuk+a2GmMeISUSMaNHxawZYGAPQ==
From: "DRAGE, Keith \(Keith\)" 
To: 
X-OriginalArrivalTime: 01 Dec 2007 04:47:54.0203 (UTC)
	FILETIME=[55E2B2B0:01C833D5]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Subject: [Sip] Comments on draft-kaplan-sip-info-events-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

If we go with this approach, then I would note that there are a number
of additional issues we need to address, for which material is not yet
on the table:

1)	We should provide guidance as to when it is appropriate to
define an INFO package and when some other mechanism should be used.
draft-burger-sip-info-02.txt is one extreme of this which says NEVER.
This guidance will need to be taken account of by any review process
(whatever it is) for IANA registration.

2)	The registry of packages has to exist. Need to define the review
requirements for adding to the registry.

3)	There should be a template associated with such packages. This
should prompt the definer of a new package to specify all issues that
should be covered. In particular, one area which needs to be covered is
how the embedded information tranfer caters for out of sequence
delivery, given that the carriage mechanism does not guarantee order of
delivery in all circumstances of SIP usage.

4)	RFC 2976 still references the obsolete SIP RFC, and therefore
presumably operates to the state machine defined in that RFC, rather
than the one in RFC 3261. If we are going to resurrect INFO, then
presumably we need to replace RFC 2976 with either this draft, or a
companion draft, rather than just update it.

5)	Do we define packages for ISUP and QSIG?

We will need to understand how each of these issues needs to be
addressed before we can charter WG deliverables.

Regards

Keith


_______________________________________________
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



From sip-bounces@ietf.org Fri Nov 30 23:48:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IyKGm-0005jT-B1; Fri, 30 Nov 2007 23:48:00 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1IyKGk-0005jA-U8
	for sip-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 23:47:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IyKGk-0005j2-KD
	for sip@ietf.org; Fri, 30 Nov 2007 23:47:58 -0500
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyKGj-0003wC-7q
	for sip@ietf.org; Fri, 30 Nov 2007 23:47:58 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lB14lsKu001816
	for ; Fri, 30 Nov 2007 22:47:56 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 30 Nov 2007 22:47:54 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 1 Dec 2007 05:47:52 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 1 Dec 2007 05:47:52 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019B7773@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft-ietf-sip-hitchhikers-guide-04
Thread-Index: Acgzqd9WllETIqGlRraO7PJOAjjt6w==
From: "DRAGE, Keith \(Keith\)" 
To: 
X-OriginalArrivalTime: 01 Dec 2007 04:47:52.0547 (UTC)
	FILETIME=[54E60330:01C833D5]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: [Sip] Draft-ietf-sip-hitchhikers-guide-04
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: sip-bounces@ietf.org

(As SIP WG chair)

I have checked this through, and it appears that all the WGLC comments
have been addressed. I have noted two comments (from Avshalom and Vijay)
that have not yet been responded to. In performing my review, I have
also identified a number of questions that I am discussing with the
editor, primarily relating to specific inclusions or exclusions.

Once these two comments are addressed, I am assuming the working group
is ready to submit this document to the IESG. I solicit responses from
the SIP WG from anyone who believes this is not the case.

Regards

Keith


_______________________________________________
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