i dont understand how a dirty/nasty message can come from a good system. 
Nothing happens on its own.I am not sure about ur nodes, but billing is per 
transactions, i am not asking about just voip call, i am asking about 
services too. For dirty request, its no money. and good clients dont send 
dirty request. its nasty people who send. Dirty messages dont get genrated 
on its own. why should a node tell that other node which is sending dirty 
request that ur request is dirty??
I hope you have seen protos test cases. Do look at 800 series and you will 
get good idea how all of them are potention DOS attack. i dont see reason 
why i should send even 400 Bad Request.
But i agree to disagree.
regards
v.


From: "Sachin" <[EMAIL PROTECTED]>
To: "'vimal srivastava'" 
<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[email protected]>
Subject: RE: [Sip-implementors] sip torture tests
Date: Fri, 5 May 2006 15:14:07 +0530


I somewhat (only somewhat) agree on dropping policy. The thing is that it
should be logged somewhere. Or else all we know is that no response is being
sent. We would never be sure

a) whether the stack has received the response, or
b) whether it is a bug at the stack or
c) whether it is a bug at the application or
d) whether the stack purposefully dropped it.

It always helps if a decent response can be sent explaining the exact reason
for rejection! (I know it is easier said than done). :-)

Vimal,
Nasty guys can always send you well formed request for which you will
respond with 200 OK potentially using more resources both memory/processor
on your system. In other words, syntactic correctness of a message is no
guarantee of its goodness. So that is not an excuse to drop the request :).

In any case, "good" transaction does not bring money, good clients (who will
eventually pay) brings money ;)

Regards,
Sachin

Sachin Shenoy,
Quantaz Networks Pvt Ltd
Corporate Office:
#186/2, Tapasvi Arcade, 1st floor,
Hosur Road, 1st Stage, 1st Phase,
BTM Layout, Bangalore.


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of vimal
srivastava
Sent: Wednesday, May 03, 2006 6:49 AM
To: [EMAIL PROTECTED]; [email protected]
Subject: Re: [Sip-implementors] sip torture tests

drop it buddy. potential risk for DOS. nasty guy will keep sending such
dirty requests and you will be busy responding 400 Bad Request being so
humble. dont be so polite!!! Good transactions bring money not dirty
transactions.
v.


From: Marco Ambu <[EMAIL PROTECTED]>
To: SIP-implementors mailing list <[email protected]>
Subject: [Sip-implementors] sip torture tests
Date: Tue, 02 May 2006 12:13:13 +0200

Hi,
trying to satisfy the tests found in
http://www.ietf.org/internet-drafts/draft-ietf-sipping-torture-tests-09.txt,
I found a problems that I try to summarize here, hoping you can help me.

3.1.2.1.  Extraneous header field separators
torture test: badinv01
...
          Contact: \"Joe\" <sip:[EMAIL PROTECTED]>;;;;    // error: empty
header parameters
          Via: SIP/2.0/UDP 192.0.2.15;;,;,,                // error: empty
header parameters, empty vias
...
The draft says: "This message is syntactically invalid. An element
receiving this request should respond with a 400 Bad Request error."

How can the response be sent if the top via header of the request is
invalid (the response must be sent to the top via)?

A similar problem arises when the 400 response should be created for
missing or multiple mandatory headers (CSeq, Call-ID, To, From) in the
request received.

What should be the response if the Route or Record-Route (not mandatory)
headers are malformed in the received request?

Marco Ambu
Abbeynet s.p.a.


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to