Re: draft-zourzouvillys-sip-via-cookie-00

"DOLLY, MARTIN C, ATTLABS" <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <14C85D6CCBE92743AF33663BF5D24EBA01239004@gaalpa1msgusr7e.ugd.att.com>
To have a meaningful discussion, you need to discuss architecture. And sorry, E-t-E is wrong

________________________________

From: [email protected] 
To: Theo Zourzouvillys ; Dean Willis 
Cc: Nils Ohlmeier ; SIP WG 
Sent: Fri Feb 20 21:14:20 2009
Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 


Please correct me, but these and previous other discussions on related topics, such as forking, early media and race conditions seem to confirm the fact that no formal and reliable routing protocol has been developed as yet to route between a larger number (more than 2 in the trapezoid model) of SIP proxies and various (Oh so many) other feature and media servers.

If there were a reliable routing protocol between all the SIP network elements these discussions would not take place for so long and there would be just one RFC describing something like “The SIP Network Routing Protocol”. And some open source implementation to prove it.

As is, every SIP network must be manually engineered, for every configuration instance and adding yet another new “network service” requires starting all over again.

Is this view embarrassingly naïve? 
It is only meant to defend the view SIP should be used just as a rendezvous and session setup protocol.

Henry 


On 2/20/09 3:05 PM, "Theo Zourzouvillys" <[email protected]> wrote:



	On Fri, Feb 20, 2009 at 8:28 PM, Dean Willis <[email protected]> wrote:
	
	> Of course, that doesn't help with an attack mode that turns UAs into
	> amplifiers . . .
	
	Well, luckily UAs could more easily remain stateless when rejecting
	responses than proxies, as they don't need to worry about things like
	forking (be it parallel or serial - e.g due to next hop SRV
	processing), so should be able to commonly respond to failure
	responses statelessly.
	
	This specific attack only arises when a there can be a invite server
	transaction created directly by a UDP request that has not been
	authenticated, and doesn't contain a "via cookie"
	
	alas, every UA implementation i've played with to date has almost
	always been stateful for even failure responses sent over UDP that
	havn't required a large amount of processing (or any variance) to
	reach it, except for some very low level induced responses like
	malformed header fields.
	
	 ~ Theo

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.