Subject: [Sipping] comment on draft-hilt-sipping-overload-01

From: "Xavier Marjou" <[email-masked]>
Date: Wed, 30 May 2007 10:00:24 +0200

I have a general comment related to the security of the distribution
of the overload information.

>From the current draft, I understand that a server generating the Load
header systematically distributes it to any upstream element (proxy or
ua), and simply expects that these upstream elements will remove this
header.
This may not be the case (e.g. an upstream proxy that does not support
this specification "MUST NOT remove other header field values other
than the Via header" as per RFC3261). Therefore this Load header may
reach the user-agent of a regular user who could use it for malicious
purposes.

I think an alternative solution would be better. Let's think about an
analogy with the HTTP protocol: in order to retrieve the load of a web
server, one can use the HTTP protocol, very probably over TLS, use
credentials to authenticate, and then obtain load information in the
body of an HTTP answer. (There is definitely no HTTP header returning
the load of the server to any user).

I'm thus in favor of a similar mechanism with SIP: the example of
dedicated SUBSCRIBE and NOTIFY messages of section 3.7 is a good one
and would fix this issue. Indeed:
- one "upstream element" implements a UA client that subscribes to an
overload package event to a server,
- the server can authenticate the client (requestor of load
information) based on whitelist,
- if successful, the server sends back load information in the body of
a SIP notification.

Cheers,
Xavier

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Volker Hilt <[email-masked]>
Date: Thu, 31 May 2007 00:02:43 -0400

> reach the user-agent of a regular user who could use it for malicious
If you are concerned about hiding overload information, it is certainly 
possible to only send load information to the proxies you trust. These 
proxies would, by definition, support overload control and would 
therefore remove this information.

It would also be possible to add an indication that a proxy supports 
overload control (e.g. to the Via header) to avoid that the header is 
sent to proxies which don't support overload control. In this case, only 
proxies that do support overload control would get this header.

> - if successful, the server sends back load information in the body of
I agree that a better discussion of SUBSCRIBE/NOTIFY is in order. I'll 
try to capture the arguments made here.

The SUB/NOT approach for overload control raises an number of questions:
- the subscription process will take some time. Is a proxy allowed to 
forward traffic to a downstream neighbor before it has set up an 
overload subscription?
   * If no, this has a significant impact on the delay of SIP messages. 
In particular, since a request may go through a chain of proxies and 
each of them may need to subscribe to the downstream neighbor.
   * If yes, overload control is not effective until the subscription is 
set up. But if a proxy is overloaded, setting up the subscription may 
take some time and, in the worst case, may not even be successful. 
During this time, the proxy will receive unthrottled traffic.
- the notify messages that convey load information will add to the 
overall load, which is undesirable in an overload situation.
- each server needs to maintain subscriptions for all its upstream 
neighbors. It needs to spend resources managing these subscriptions, 
which can put a significant burden on the server, in particular, if it 
is dealing with many upstream neighbors.
- each proxy would be required to implement a full UAS/UAC for 
SUBSCRIBE/NOTIFY if the proxy wants to participate in overload control 
(which each proxy should do!).

Overall, I think SUB/NOT is a pretty large-caliber weapon for the 
problem at hand and a lighter-weight solution would be preferable.

Thanks,

Volker

---

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 31 May 2007 17:20:41 +0200

> proxies that do support overload control would get this header.

Relying on the IP address to guess the identity of an upstream proxy
is one possibility in some specific situations. However, in other
situations, the IP address can change over time or be spoofed. With an
upstream element that behaves as a UA for retrieving overload
information, the server can check the identity of this UA with a
standard SIP mechanism.

> problem at hand and a lighter-weight solution would be preferable.

I agree that some resources are needed to "maintain one subscription
per upstream proxy" and that "each proxy needs to implement a UA":
however this is needed in order for the server to be sure of the id of
each upstream proxy to which overload info is sent.

This SUB/NOT mechanism is not necessarily slower. If an upstream
element has not yet subscribed to the overload information, nothing
prevents this upstream proxy from routing regular SIP requests to the
server, and nothing prevents the server to use the 503 answer. Once
the upstream element has decided to subscribe and has succesfully
received load-information, it can route regular SIP requests taking
into account the load of the server.

Xavier

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 31 May 2007 11:20:12 -0400

Please see below for questions/comments.

  Thanks,
  Tolga

> -----Original Message-----
> From: Volker Hilt [mailto:[email-masked]]
> Sent: Thursday, May 31, 2007 12:03 AM
> To: Xavier Marjou
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [Sipping] Re: comment on draft-hilt-sipping-overload-01
> 
> Xavier Marjou wrote:
[TOLGA]Why would that be a significant delay? This would happen only
once. For TCP/SCTP there is already the delay introduced by connection
setup (TLS would add up even more on top of that), would an extra SIP
transaction introduce a huge additional delay?
> take some time and, in the worst case, may not even be successful.
[TOLGA]I believe the answer should be "no", but in any case this second
argument could also be a drawback for a solution, where overload
information is embedded in a response. A response would be delayed if
the proxy is overloaded, and meanwhile other entities would continue to
pump messages. Furthermore, an entity would receive information about
overload status of the proxy only after it sent a request to it; it is
possible that proxy is overloaded by requests sent by other entities.
> overall load, which is undesirable in an overload situation.
[TOLGA]If hysteresis is provided properly, hopefully there won't be many
NOTIFYs. I would think, proxies would inform their neighbors about
getting overloaded, before the load gets extreme. In any case, I agree
that there could be cases, where a notification needs to be sent, while
the proxy is overloaded but again, would that add significant extra
processing to the proxy? Sending notifications probably would be a
higher priority operation in the proxy compared to processing requests. 
> problem at hand and a lighter-weight solution would be preferable.
[TOLGA]IMHO, the advantage of relying on notifications is that it is a
proactive mechanism, whereas utilizing replies is a reactive one. OTOH,
if replies are used in a timely manner, e.g. before extreme overload
happens, we could end up with something quasi-proactive.
One more thing in favor of notifications is that they can convey
information about when the overload level decreases in a proactive way,
rather than waiting for a request.
I am not saying that a notifications based mechanism is definitely the
preferred choice, but I guess shouldn't be eliminated quickly either.