Subject: [SIP] State-of-the art on SIP QOS and security

From: Giuseppe Ricagni <[email-masked]>
Date: Fri, 07 Apr 2000 14:06:03 +0200

Hi,

I' ve heard lots of people and I' ve read many documents (including the
excellent draft presented by Henry in Adealaide)  about QOS in
SIP-signaled networks, as well as about security (encryption of
signalling messages, at least).

Nevertheless I' ve not been able to find any official SIP drafts
tackling these issues: can anyone bief me about the state-of-the-art in
these two areas ?

   * did I miss some relevant WG document
   * or is it an explicit desire by the WG not to restrict the number of
     QOS mechanisms that can be utilized by implementors
   * or is it just a matter of time and we will have something like an
     informational RCF with a taxonomy of possible QOS
     methods/suggestions on how the various policy-based mechanisms can
     be coupled with SIP?

What about security ?

Thank you very much,
and apologies in advance, should this issue have already been
exetensively discussed by the list
Giuseppe Ricagni

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 07 Apr 2000 15:39:51 +0200

Yes, the intention is to keep specific QoS mechanisms
apart from call signaling. The I-D draft-manyfolks-sip-resource-00.txt
desribes how QoS preconditions (regardless of QoS mechanism
being used) can be signaled with SIP/SDP. QoS mechanism
themselves are out of scope of SIP WG.

The I-D draft-sinnreich-interdomain-sip-qos-osp-01.txt is of 
informational nature and documents how to put all the pieces 
(SIP call signaling, RSVP QoS reservation, COPS Policy,
OSP settlement) in a complex commercial service provisioning 
environment together.

Jiri

Giuseppe Ricagni wrote:
> 
> Hi,
> 
> I' ve heard lots of people and I' ve read many documents (including
> the excellent draft presented by Henry in Adealaide)  about QOS in
> tackling these issues: can anyone bief me about the state-of-the-art
> in these two areas ?
> 
> 
>    * or is it an explicit desire by the WG not to restrict the number
>      of QOS mechanisms that can be utilized by implementors
>      methods/suggestions on how the various policy-based mechanisms
>      can be coupled with SIP?
> 
> What about security ?
> 
> Thank you very much,

-- 
Jiri Kuthan		  Phone: +(49) / 30 - 3463 7 271
GMD FOKUS                 Fax  : +(49) / 30 - 3463 8 271
Kaiserin-Augusta-Allee 31 E-Mail : [email-masked]
D-10589 Berlin, Germany   WWW    : http://www.fokus.gmd.de/usr/kuthan

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

---

From: Giuseppe Ricagni <[email-masked]>
Date: Fri, 07 Apr 2000 17:16:45 +0200

> themselves are out of scope of SIP WG.

well, draft-manyfolks-sip-resource-00.txt doesn' t seem to me to be an
official WG I-D anyway.
So I would conclude that the WG is not even  interested in specifying  the
preconditions necessary for QOS mechanism to be applied to SIP-based
networks.

There's still some missing piece, or at least something I don' t understand,
in this picture, since it seems to me that previous discussions have clearly
shown how QOS handling appears to be the real driving force behind an
operator deploying a SIP-based network (without QOS there appear to be
little reason to have equipment in the core of the network: endpoints can
use SIP to call each other e2e)

Do you know anything about the security issue ? (signalling encryption)

Thank you very much
Giuseppe

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 07 Apr 2000 18:49:41 +0200

> Do you know anything about the security issue ? (signalling encryption)

There are two kinds of signaling encryption: end-to-end and hop-by-hop.

E2E is difficult if a SIP proxy in the middle of signaling chain
needs to know a particular message element for call processing.
RFC2543 introduces these header field classes: those which 
1) MUST NOT  be encrypted 2) MAY be encrypted 3) SHOULD be encrypted.

In fact, a caller never knows which of the fields really MAY be
encrypted because a SIP proxy in the middle may still want
to use a "MAY-be-encrypted" field for call processing logic.
The same applies also for SIP bodies. A proxy may want
to examine SDP payload in order to open pinholes in firewalls
or it possibly uses JPEGs in INVITEs to implement
"deny-calls-originating-from-skin-headed-callers" policy.

The most recent suggestion was to let caller encrypt whatever
he wants to and see if it works. If the encrypted message
encounters a SIP proxy which is unable to process it
the proxy sends an appropriate reply to the caller. The
reply may include some some hint on which parts of the message
were needed in plain text. Then, the caller will decide
if he wants to resend the message with indicated fields
in plain text or give up the call.

With HBH encryption, SIP messages are completely encrypted
but  all of the SIP entities along the signaling chain
see the messages (or part of them if E2E encrytion is
also used) in plain text. Which could make someone
who is concerned about privacy of his signaling worried.
To minimize the risk of disclosure of unencrypted signaling 
to untrusted proxies transitive HBH trust may be deployed.
Which means that SIP proxies forward HBH-encrypted SIP 
messages only to trusted adjacent proxies and assume they
will behave the same way.

With the exception of the proposal for "cannot process
encrypted fields" reply, all aforementioned issues are 
already addressed in the SIP RFC.

Jiri

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 07 Apr 2000 13:47:58 -0500

Giuseppe,

I would like to add the responses from Jiri Kuthan and K. K.
Ramakrishnan regarding QoS that for AAA issues: There was
interest in the AAAArch BOF for AAA functions for areas such as
SIP where admission control is depending on application servers
(such as SIP proxies) and there can be more complex models, such
as "the called party pays and admits the call", also using
clearinghouses. There may be some model I-Ds on this topic.

Suggest you may want to attend the AAAARch session at the next
IETF.

Henry

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of
>Giuseppe Ricagni
>Sent: Friday, April 07, 2000 10:17 AM
>To: Jiri Kuthan
>Cc: [email-masked]
>Subject: Re: [SIP] State-of-the art on SIP QOS and security
>
>
>Jiri Kuthan wrote:
>