Subject: RE: [SIPPING] WGLC: draft-ietf-sipping-overload-reqs-00 [was Comments on draft-ietf-sipping-overload-reqs-00]

From: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>
Date: Thu, 3 May 2007 15:13:33 +0200

I renamed this thread to inlucde it in WGLC

> >> >> REQ 17: The overload mechanism must not provide an avenue for   
> >> >> malicious attack.To prevent malicious attacks, it's necessary to
prevent untrusted
> >> >> elements to access load information of the SIP servers.
> >> > I must be dense, so bear with me. Could you explain what new
> >> > malicious attack is opened or existing attack amplified
> by treating
> >> > the load information as confidential?
> >
> >>  I am just as dense as David - please explain...
> >
> > One of the elementary security rules is to provide the minimum
> > information of a given server (e.g. server name, software
> version ...etc):
> > the more information you give, the more the risk of
> malicious attacks
> > increases. In fact, having information about the server can
> be used by
> > malicious elements to detect the server weaknesses. For instance, a
> > server that is 100 % overloaded may be more vulnerable which
> > facilitates malicious attacks.
>
> I, like others, do not see what attack this opens up. I think you need
to give a specific example.

YC:  One of the DOS attacks consists on overloading the server. If you
want to overload a given Server you need to generate more messages than
it can treat. An almost overloaded server has less available resources
(CPU, memory, disk space ...etc): you do not need a very powerful
machine to get such a server completely overloaded.   

Moreover getting load information may allow to malicious elements to
determine whether a SIP server is sensible to  overload attacks or not:
the malicious element starts an "overloading attack" and check the
received load information to know whether or not the server is sensible
to this attack or not. 

Hence, providing load information to malicious elements amplifies the
DoS attacks risks towards SIP servers

> > Another argument in favour of controlling the access to the load
> > information is that for confidentiality reasons, a service provider
> > may do no want that an untrusted service provider  knows the load
> > level of its servers.
>
> I'm OK with a requirement around this point speifically. I do
> understand that service providers view the load on their
> network overall as proprietary. The simple answer, of course,
> is that you are always free to not implement this extension
> towards proxies outside of your domain.
> If you want to capture that in a requirement, how about:
>
> REQ XX: It must be possible to disable the reporting of load
> information towards upstream targets based on the identity of
> those targets. Of course, in such cases, there is no
> expectation that the overload mechanism itself will help
> prevent overload from that upstream target.
>
> I think we'd have a hard time not meeting this requirement, but I'm
fine to make it explicit.

YC: To meet this requirement, the mechanism must guarantee tow things:
  a) The SIP server must be able to identify the server to witch it
sends the load information
  b) The SIP server must have the guarantee that this server will not
forward this information to other elements.

I think that using the Subscribe/Notify mechanism to exchange load
information would be a good solution to allow a) and b).

> >> >> REQ 22: The mechanism should be easily centralised in the
front-end
> >> >> servers in case the SIP server is implemented as a
> cluster of servers
> >> >> running on different machines.
> >> >>
> >> > I'm not sure how you ascertain if this requirement is
> met. I can see
> >> > how you could write a requirement that the scheme allow such
> >> > configurations, just not that it be "easy". Easy
> compared to what?
> >
> >>  I like the requirement (although I agree with David that
> "easily" is a
> > weasel word), but I'm concerned that we may not have a
> basis for judging
> > "can be centralized in the  > front-end servers".
> >
>
> I'd propose:
>
> REQ XX: It must be possible for the overload mechanism to  work in
cases
> where there is a load balancer in front of a farm of proxies, and that
> load balancer tracks the state of the nodes in the cluster, and
actually
> implements the overload mechanism.

> I suspect we'd have a hard time not meeting this requirement, but I am
> OK with adding it.
>
> > What I mean by "can be easily centralised on the front-ends
> servers" is
> > : implementing overload mechanism shall not heavily impact the
> > performance of front-ends servers:
> >
> > 1) the mechanism shall not require front-ends parsing all received
> > messages to look for overload control information
>
> This is impossible to meet. We are going to be doing this as a sip
> extension, and that necesarily requires looking at sip
> messages to process.

> > 2) the mechanism shall not require front-end servers to open
messages
> > sent by applications to insert overload control information
>
> Also impossible to meet. The load balancer will have to insert load
into
> the SIP header somewhere.

YC: Indeed, using a new SIP header within SIP messages to carry load
information will not allow satisfying these requirements.
This is way I think that using a new SIP header is not a good solution.
To satisfy these requirements it is necessary that load information be
exchanged within dedicated SIP messages. Using Subscribe/Notify (with a
new event package) seems to be a good solution.    
Moreover, I think that at this stage we should focus only on
requirements definition.

> > 3) the mechanism shall support aggregating load information from
> > different elements of a server farm
>
> I think this is implied by the requirement above that I proposed,
which I prefer.

Youssef C.

_______________________________________________
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: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>
Date: Thu, 3 May 2007 15:13:42 +0200

> > >>> To prevent malicious attacks, it's necessary to prevent 
> untrusted 
information of a given server (e.g. server name, software version ...
etc): the more information you give, the more the risk of malicious
attacks increases.
> This is proof by emphatic assertion. Please give an existence  proof
of a case where a new attack or an enhanced attack is  enabled. I'm not
claiming one DOESN'T
> exist, I just want  exidence to back up your assertion.

   
> > In fact, having information about the server can be used by

> Why?

YC: An overloaded server has less available resources (CPU, memory ...)
to protect itself against malicious attacks. 

> But this may be true of ANY information about a server, 
> including its very existence. Again, what is special about 
> the load information?

YC: The load information can be considered by service providers as
proprietary and for several reasons they may want to not deliver this
information to third party network or to their clients. For instance, a
service provider may do not want that its clients know that its network
is about to be overloaded

> > >>> REQ 22: The mechanism should be easily centralised in  the
front-  end
> > >>> servers in case the SIP server is implemented as a cluster of
servers
> > >> I'm not sure how you ascertain if this requirement is  met. I can
see how you could write a requirement that the scheme allow such
configurations, just not that it be "easy". Easy  compared to what?
> "easily"  
> > is a weasel word), but I'm concerned that we may not have a basis  
> > for judging "can be centralized in the  > front-end servers".
> >
> > servers" is : implementing overload mechanism shall not heavily  
> > impact the performance of front-ends servers:
> >
> > messages sent by applications to insert overload control information
> These two completely lost me. Either boxes participate in the load  
> control scheme or they don't. If the "front end" doesn't participate  
> then the requirements are moot for them. If they do participate, I  
> don't see how you can mandate these requirements for in a practical  
> scheme with cascaded proxy farms (e.g on entry and exit at the  
> borders of an SP cloud).
   
YC: The overload mechanism can be performed only by the front-end. Let's
take the following examples of a SIP server composed of a farm of
applications:

1) The front-end performs only load balancing for initial SIP requests
between the cluster nodes. In this case, only initial SIP requests go
across the front-end. Then, if the overload mechanism implies that the
front-end server receives and parses all the SIP messages destined
to/coming from the cluster nodes in order to extract/insert load
information, this mechanism will not be possible to implement on such
SIP server:

2) The front-end performs a load balancing and more advanced feature
which implies all SIP messages destined to/ coming from cluster nodes to
go across the front-end. In this case if the overload mechanism implies
that the front-end server parses all the SIP messages destined to/coming
from the cluster nodes in order to extract/insert load information, the
performance of the front-end server will be heavily impacted. 

In order to satisfy these requirements, it is necessary that load
information be exchanged within dedicated SIP messages. Using
Subscribe/Notify (with a new event package) seems to be a good solution.

> This seems like a good requirement.
> > > If things have changed in the past few years, I apologize for my  
> > confusion, but my understanding was that most of the front-end-to- 
> > cluster schemes were proprietary, so > we might be able to say  
> > "works on THIS front-end-to-cluster scheme", but wouldn't know if  
> > it works on ANY front-end-to-cluster scheme.
> >
> > I agree that front-end-to-cluster schemes can be considered as  
> > proprietary. We can assume that the front-end server knows 
> the load  
> > status of the whole cluster.
> If that's the case, then I don't see the need for this discussion or  
> these requirements since the front end is part of the cluster 
> and the  
> internal composition is invisible form the outside.
> > > Can someone smarter than I am express an opinion about this?
> >
> > Thanks,
> >
> > Spencer
> >
> >
> >
> >
> > This list is for NEW development of the application of SIP Use sip- 
> > [email-masked] for questions on current sip Use  
> > [email-masked] for new developments of core SIP
> >
>