Subject: [SIP] SIP digest, Vol 1 #21 - 7 msgs

From: "Surinder Ubhi" <[email-masked]>
Date: Tue, 18 Apr 2000 09:37:31 +0100

Send SIP mailing list submissions to
     [email-masked]

To subscribe or unsubscribe via the web, visit
     http://lists.bell-labs.com/mailman/listinfo/sip
or, via email, send a message with subject or body 'help' to
     [email-masked]
You can reach the person managing the list at
     [email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of SIP digest..."

Today's Topics:

  1. Re: Availability of RFC2543bis in ASCII (Rabbe Fogelholm)
  2. Re: SIP and soft hand-off (Faramak Vakil)
  3. Re: Key agreement using SIP/SDP? (Lars Berggren)
  4. Re: Re: Availability of RFC2543bis in ASCII (Henning Schulzrinne)
  5. RE: SIP and soft hand-off (Roy, Radhika R, ALARC)
  6. QoS-Enabled and manyfolks draft (William Marshall)
  7. Proxy behavior for CANCEL (Provin Gurung)

Message: 1
Date: Sat, 15 Apr 2000 23:20:45 +0200
From: Rabbe Fogelholm <[email-masked]>
Organization: Ericsson Utvecklings AB
To: [email-masked]
Sender: [email-masked]
Subject: [SIP] Re: Availability of RFC2543bis in ASCII

> Mark Wisdom wrote:
> >
> > RFC2543bis is available in PDF and PostScript formats, i.e.:
> >
> > But I can't find a plain ASCII version anywhere. If an ASCII version
> > exists, can someone please tell us where we can find it (some of you
> > have been referring to sip_2543bis_00.txt). If not, can one please be
> > made available. I like having an ASCII version for quick grep-style
> > scanning of information.
>
> Since conversion of a document of that size takes some of (my) time, it
> will happen when it is submitted as an Internet draft in a week or two.
> Your patience is appreciated.
>
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

I am quite pleased with the PDF version for its general readability.
However, there is one line in the PDF version of RFC2543bis which has me
confused. The definition of "hexpart" on page 18 goes `hexpart = hexseq
- hexseq 

ö::

ö [ hexseq ] - 

ö::

ö [ hexseq ]', although the hyphens
 are
actually elongated ones (octal code 227, outside the 7-bit ASCII
alphabet). Should there simply be vertical bars here?

--Rabbe Fogelholm, Ericsson Network Core Products

Message: 2
Date: Sun, 16 Apr 2000 21:08:36 -0400
From: Faramak Vakil <[email-masked]>
Organization: Telcordia Technologies
To: James Kempf <[email-masked]>
Cc: [email-masked]
Subject: Re: [SIP] SIP and soft hand-off

James Kempf wrote:

> Given these constraints, I am skeptical about replacing soft handoff
> with either L3 (mobile IP or any of the pre-frame selection
> micromobility proposals) or L7 (SIP) mechanisms. Should the radio
> manufacturers and cellular operators desire it, it would be interesting to
look
> at an Open RAN protocol that would take the current proprietary soft handoff
> mechanisms and standardize them.

The goal is NOT to replace soft hand-off with any L3 or L7 mechanisms,
but to devise L3 and/or L7 mobility mechanisms that utilize the soft hand-off
mechanism correctly (i.e., create multiple streams that satisfy delay jitter
requirements and contain identical information).

> But, for now, I think any IP mobility
> solutions need to be restricted to post frame selection, i.e. hard handoff
> only.

More work is needed before arriving at a conclusion.

Regards, Faramak

>
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

Message: 3
Date: Mon, 17 Apr 2000 11:23:39 +0200 (CEST)
From: Lars Berggren <[email-masked]>
To: Anders Clausen <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [SIP] Key agreement using SIP/SDP?

Anders and Thomas,

I am cc-ing this to the mmusic list since SDP is involved here.

First, I would say that you probably shouldn't say that it is the 180
response that contains the key agreement information, as I think that any
response containing SDP is likely to be suitable. (183 and 200)

Second, I like the mechanism described here regarding agreement on keys
for RTP level encryption. However, as there has been no responses in this
thread from the WG, I would like to bring attention from the WG to this
topic again, hoping for more interest this time.

Does anyone else have comments on this? I really would like to see some
more discussion in this topic. What about the SIP security team, any
thoughts in this direction?

How about writing an ID on this to specify it clearer?

The advantages I can see with the proposal are:
1) Works through NATs.
2) It could be made generic. I believe any need for negotiation between
caller and callee when agreeing on a session key or shared secret (like
diffie-hellman) could be signaled this way.
3) No need to rely on an infra-structure for fetching of public keys.

Disadvantages:
1) Another extension to SIP/SDP ?
2) The same key is used in the streams caller->callee and
callee->caller. There may be applications that need to have different
keys in each stream.

Regards
Lars

On Mon, 10 Apr 2000, Anders Clausen wrote:
> Hello,
>
> We are two students writing on a graduate thesis about VoIP security
> with SIP/SDP/RTP, with focus on encrypting the media stream. We are
> new to this, and would be grateful for help on this subject.
>
> There are some problems transferring or agreeing on a session
> encryption key using the k= field in SDP, if one are to send it in a
> SIP INVITE through a NAT. Since the NAT needs to change some fields in
> the SDP description, the SDP must not be encrypted.
>
> The end user should be oblivious of the FW/NAT and thus should neither
> query it for the adresses to enter into the SDP, nor depend on the FW
> to encrypt anything.
>
> A couple of possible solutions (?).
>
> The simplest (and least secure) way to transfer a symmetric key would
> be that the caller enters his public key (or Diffie-Hellman "A") into
> the k= field of the SDP.
>
> "k=base64:<caller key>"
>
> together with a couple of attributes that could look something like
>
> "a=key-encr-alg:RSA"
> or
> "a=key-encr-alg:D-H"
>
> for describing the algorithm the key in the k= field corresponds to,
> and
>
> "a=media-encr-alg:3DES-CBC"
>
> for describing preferred media encryption algorithm.
>
> In case of RSA, the "callers key" is the public key, corresponding to
> a private key only known by him. In case of Diffie-Hellman the
> "callers key" is the "A"-part of the partly built media key.
>
> The callee then generates a "callee key". In case of RSA, this is the
> symmetric media key, encrypted using the callers public key. In case
> of Diffie-Hellman, the "callee key" is the "B"-part of the partly
> built symmetric media key. The callee sends this back in the k= field
> in the SDP of the 180 response. Should the callee fail to meet the
> specific security wishes of the caller, it could simply omit the k=
> field in the response, and the caller could choose to proceed and not
> encrypt the media or just hang up.
>
>   CALLER                    SIP-PROXY(s)                   CALLEE
>     |                           |                           |
>     | INVITE w/SDP(caller's key)|                           |
>     |-------------------------->| INVITE w/SDP(caller's key)|
>     |                           |-------------------------->|
>     |                           |                           |
>     |                           |   100                     |
>     |   100                     |<--------------------------|
>     |<--------------------------|                      Key generation
>     |                           |   180 w/SDP(callee's key) |
>     |   180 w/SDP(callee's key) |<--------------------------|
>     |<--------------------------|                           |
>
> Another way could be to insert something similar to a TLS handshake
> (or some other more secure way of agreeing on or transferring keys)
> into the Reservation stage in the QoS/security negotiation described
> in draft-manyfolks-sip-resource-00.txt.
>
> This would probably also need a couple of attributes to tell the
> callee which handshake protocol should be used.
>
> Comments?
>
> (After reading RFC 1889 (RTP), 1890 (AVP), 2327 (SDP), 2543 (SIP), and a
> number of drafts, we have not found any solutions to the problems
> described above.)
>
> ---
> Anders Clausen <[email-masked]>
> Thomas Karlsson <[email-masked]>
>
>
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>

Lars Berggren       <mailto:[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

Message: 4
Sender: [email-masked]
Date: Mon, 17 Apr 2000 07:57:28 -0400
From: Henning Schulzrinne <[email-masked]>
Organization: Columbia University, Dept. of Computer Science
To: Rabbe Fogelholm <[email-masked]>
Cc: [email-masked]
Subject: Re: [SIP] Re: Availability of RFC2543bis in ASCII

Rabbe Fogelholm wrote:

> I am quite pleased with the PDF version for its general readability.
> However, there is one line in the PDF version of RFC2543bis which has me
> confused. The definition of "hexpart" on page 18 goes `hexpart = hexseq
> - hexseq ?::? [ hexseq ] - ?::? [ hexseq ]', although the hyphens are
> actually elongated ones (octal code 227, outside the 7-bit ASCII
> alphabet). Should there simply be vertical bars here?

Yes; LaTeX error of omitting $'s...

--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

Message: 5
From: "Roy, Radhika R, ALARC" <[email-masked]>
To: Rohan Mahy <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [SIP] SIP and soft hand-off
Date: Mon, 17 Apr 2000 09:15:09 -0400

Hi, Rohan:

Pl. see my comments below <RRR>.

Thanks,
Radhika R. Roy
AT&T

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Friday, April 14, 2000 11:38 PM
To: Roy, Radhika R, ALARC
Cc: [email-masked]; [email-masked]
Subject: RE: [SIP] SIP and soft hand-off

At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
>Hi, Everyone:
>
>My comments are as follows:
>
>1. We are extending SIP to support mobility in the application layer. So,
>SIP WG is the right place. The SIP WG is the only group that knows what to
>do the SIP protocol in the application layer.

Hi,

Who is the "we" here?  To be specific, has this been formally included as a
topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff
would be considered as part of the scope of "mobility".

<RRR> "We" means the members who are interested for extension of SIP to
support mobility as some discussion was held based on the internet draft in
the last IETF meeting. Yes, "soft-handoff" may not be a part of SIP mobility
if it does not affect the application (i.e., SIP) layer resources.

thanks,
-rohan

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

Message: 6
From: William Marshall <[email-masked]>
Date: Mon, 17 Apr 2000 09:35:26 -0400 (EDT)
To: [email-masked]
Subject: [SIP] QoS-Enabled and manyfolks draft

The following message was sent to the list on April 6,
but I never received it back.  Apologies to all who
got it then, and have to read it again.

Bill Marshall
[email-masked]

> To: [email-masked]
> Subject: QoS-Enabled and manyfolks draft
>
> Henry Sinnreich and I have been looking into whether the
> manyfolks draft covers QoS-Enabled as well as QoS-Assured.
> Our conclusion is that the mechanism described covers it,
> but that some additional text describing the procedures
> is needed.
>
> The procedures for QoS-Enabled would be like this:
>
> The caller sends an INVITE, with a line in SDP that says
> a=qos:optional sendrecv.  UAS gets that and sends back a 183
> (acording to manyfolks draft) that includes an SDP, with a line
> a=qos:optional sendrecv confirm.  Originator tries and fails
> to get qos, but that is OK since qos was only optional, so its
> PRECONDITION-MET message says a=qos:failure sendrecv.  UAC
> obviously made a decision to proceed, in that it sent
> the PRECONDITION-MET message.
>
> Maybe UAC asked the originating user before deciding this, like
> a "can't get QoS.  Proceed? (y or n)?"
>
> UAS then makes the choice of whether to proceed or not, and
> sends either 180-Ringing or 580-Precondition-Failure.  Maybe it
> asked the destination user the same question, but with a
> distinct ringing sequence.  If lack of QoS is accepted, UAS
> sends the 200-OK and call completes with best-effort.
>
> Comments?
>
> Bill Marshall
> [email-masked]

Message: 7
From: "Provin Gurung" <[email-masked]>
To: <[email-masked]>
Date: Mon, 17 Apr 2000 10:57:37 -0400
Importance: Normal
Subject: [SIP] Proxy behavior for CANCEL

Hi,
 I have a question regarding the behavior of proxy on receiving a CANCEL.
Consider, a forking Proxy received an INVITE and it forked and forwarded the
INVITE to multiple servers downstream, Now along comes a CANCEL from an
upstream client.  The proxy is supposed to fork and send the CANCEL to the
branches which have not yet responded.

How should the proxy react,
(a) if it already received a 2xx response from one of the downstream
branches, (This would be if the final response from the proxy to the
upstream client and the CANCEL crossed over each other.)
- I guess it should be 481 (Transaction not found)

(b) The proxy has not received  2xx nor 6xx from any branches.
Should the proxy send back a 2xx for the CANCEL  immediately and not care
how the downstream servers respond to the CANCEL that is forked by this
proxy, or should it wait till the unfinished branches respond to the forked
CANCEL and then depending on this result send back a CANCEL, i.e. the proxy
send back a 200 CANCEL upstream if the proxy receives a 2xx for all the
forked CANCEL from all it's branches, or maybe proxy the 2xx for INVITE, if
one of the branches respond with 200 for INVITE  ( cross over for the forked
INVITE and forked CANCEL in one of the proxy) and resonpond say 481 for the
CANCEL.

If the proxy responds immediately with 2xx for CANCEL, it is possible that
the initiating UAC receive both a 2xx for the CANCEL and 2xx for INVITE
(Taking into consideration , that if a Proxy receives a 2xx for INVITE from
one of the branches, after it has sent a 2xx for CANCEL upstream, it still
forwards the 2xx for the CANCEL to the upstream client). How does the UA
handle this case.

Sorry for not keeping it short, I tried to look up the rfc but could not
find it discussing the above scenario.

Thanks in advance,
Provin

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy, Radhika R, ALARC
> Sent: Monday, April 17, 2000 9:15 AM
> To: Rohan Mahy
> Cc: [email-masked]; [email-masked]
> Subject: RE: [SIP] SIP and soft hand-off
>
>
> Hi, Rohan:
>
> Pl. see my comments below <RRR>.
>
> Thanks,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, April 14, 2000 11:38 PM
> To: Roy, Radhika R, ALARC
> Cc: [email-masked]; [email-masked]
> Subject: RE: [SIP] SIP and soft hand-off
>
>
> At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
> >Hi, Everyone:
> >
> >My comments are as follows:
> >
> >1. We are extending SIP to support mobility in the application layer. So,
> >SIP WG is the right place. The SIP WG is the only group that
> knows what to
> >do the SIP protocol in the application layer.
>
> Hi,
>
> Who is the "we" here?  To be specific, has this been formally
> included as a
> topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff
> would be considered as part of the scope of "mobility".
>
> <RRR> "We" means the members who are interested for extension of SIP to
> support mobility as some discussion was held based on the
> internet draft in
> the last IETF meeting. Yes, "soft-handoff" may not be a part of
> SIP mobility
> if it does not affect the application (i.e., SIP) layer resources.
>
> thanks,
> -rohan
>
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: [email-masked]
Date: Tue, 18 Apr 2000 12:46:47 +0100

I accidentally caused this reply, my apologies.