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

From: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>
Date: Fri, 27 Apr 2007 03:04:51 +0200

Hi, 
 
Inline

Youssef

-----Message d'origine-----
De : Spencer Dawkins [mailto:[email-masked]] 
Envoyé : mercredi 25 avril 2007 15:30
À : sipping
Objet : Re: [SIPPING] Comments on draft-ietf-sipping-overload-reqs-00

Just checking -

From: "David R Oran" <[email-masked]>

>> On Apr 25, 2007, at 5:18 AM, CHADLI Youssef RD-CORE-ISS wrote:
>>
>>> 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. 

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. 

>>> 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".

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
2) the mechanism shall not require front-end servers to open messages sent by applications to insert overload control information 
3) the mechanism shall support aggregating load information from different elements of a server farm

> 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.

> Can someone smarter than I am express an opinion about this?

Thanks,

Spencer 

_______________________________________________
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
_______________________________________________
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: David R Oran <[email-masked]>
Date: Fri, 27 Apr 2007 15:37:43 -0400

On Apr 26, 2007, at 9:04 PM, CHADLI Youssef RD-CORE-ISS wrote:

> > 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.
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  
> malicious elements to detect the server weaknesses. For instance, a  
> server that is 100 % overloaded may be more vulnerable which  
> facilitates malicious attacks.
Why?
> 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.
>
>
But this may be true of ANY information about a server, including its  
very existence. Again, what is special about the load information?

> > 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".
>
> 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
> 2) the mechanism shall not require front-end servers to open  
> 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).
> different elements of a server farm
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.
> 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
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Apr 2007 19:56:28 -0400

inline.

CHADLI Youssef RD-CORE-ISS wrote:

> 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 
> 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.

> 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.

>>  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:
> 

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.

> different elements of a server farm

I think this is implied by the requirement above that I proposed, which 
I prefer.

-Jonathan R.

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