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

From: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>
Date: Wed, 25 Apr 2007 11:18:42 +0200

Hi,

I have two comments on draft-ietf-sipping-overload-reqs
<http://www.ietf.org/internet-drafts/draft-ietf-sipping-overload-reqs-00
.txt> :

1) There are two requirements dealing with security aspects: 

REQ 5: The mechanism should not assume that it will only be deployed
      in environments with completely trusted elements.  It should seek
      to operate as effectively as possible in environments where other
      elements are malicious, including preventing malicious elements
      from obtaining more than a fair share of service.

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. Consequently, I
think that it is important to specify explicitly that the overload
mechanism must allow preventing load information to be sent to untrusted
elements. This precision can be added to the text of REQ 17 or can be
added as a separate requirement.
                                
2) Big SIP server are in general implemented as a cluster of servers
with one or more front-end servers. The frond-end server interfaces to
the other SIP nodes and performs load balancing on the different servers
of the cluster. In such a case, the load control mechanism can be
implemented and managed only by front-ends servers as only those servers
can know the overall load of the cluster. It's then important that the
overload mechanism can be easily centralised on the front-ends servers
in this case. Consequently, I propose to add a requirement on this;
something like:

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.  

        +----------+    +----------+      +----------+  
     	  | Server#1 |    | Server#2 |..... | Server#n | 
        +----------+    +----------+      +----------+

 			|         |              | 
                  |         |              |
                  |         |              | 
			|	+----------+       | 
			+-----| Front-End|-------+

              	      | Server   |	
        			+----------+ 

Best regards,

Youssef CHADLI			      

_______________________________________________
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: Wed, 25 Apr 2007 09:06:05 -0400

On Apr 25, 2007, at 5:18 AM, CHADLI Youssef RD-CORE-ISS wrote:

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

> Consequently, I
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?

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 25 Apr 2007 08:29:58 -0500

Just checking -

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

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

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

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.

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

Thanks,

Spencer

---

From: [email-masked]
Date: Wed, 25 Apr 2007 10:44:05 -0400

From: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>

As other have said, this point needs further elaboration.

The fact that the load balancing actions are performed by the
front-end servers does not imply that that the overload mechanism
implementation is "centralised" on those front-end servers.  (And
given that there may be more than one front-end server, in what sense
can anything be "centralised" on them?)

A much better requirement would be to provide the diagram of the
architecture you are concerned with:

and state a requirement that the solution work effectively in such an
architecture.

(Although I would prefer to see the requirment generalized to several
front-end servers feeding one cluster of servers -- the front-end
servers must cooperate in balancing the load they deliver to the
servers.)

Dale