Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fas terthan a SIP PING requestprocessing?

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 7 Mar 2006 11:12:02 -0000

As Dean has already mentioned, the IMS P-CSCF treats unimplemented methods the same as defined methods as far as authentication is concerned.

Authentication is performed at registration - this creates a security association for that contact, and then all subsequent requests and responses use that security association. Anything outside the security association apart from an initial REGISTER request is therefore discarded before it reaches the SIP transaction processing.

Note that in addition, IMS uses SIGCOMP. After processing the new method two ways through SIGCOMP, do the figures still look the same? While it would be possible to define a dictionary entry for the entirety of such a new method, this would then mean that any such method would have to be implemented character for character exactly the same as in the dictionary.

Therefore in the evaluation of the different mechanisms, please ensure that the impact of SIGCOMP on the efficiency is also taken into account.

regards

Keith

> -----Original Message-----
> From: Samir Srivastava [mailto:[email-masked]]
> Sent: 06 March 2006 20:00
> To: Jonathan Rosenberg; Michael Procter
> Cc: [email-masked]; Bharrat, Shaun; Alan Duric; Dusan Stevanovic
> Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing
> fasterthan a SIP PING requestprocessing?
> 
> 
> 
> Both STUN CRLF and PING require change on the Proxy. We can have for
> PING whatever we want. 
> How STUN CLRF is better without changes on the existing Proxy ?
> 
> To send the response back for STUN CRLF, we need to change the proxies
> too. But for PING, if proxy is not updated, and it is returning "501
> Method Not Implemented" we are okay. And if proxy is good
> enough, to have a configuration rule saying UnImplmented 
> Methods are not
> authenticated, then we
> we are okay too. Though it does not offer Performance benefits of the
> shunting the SIP parser, but it does offer gradual upgrade. 
> Which is not
> the case with STUN CRLF. 
> 
> May I ask, how many proxies are there which authenticate unimplemented
> Methods ? 
> 
> Thx
> Samir 
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 10:59 AM
> To: Michael Procter
> Cc: [email-masked]; Bharrat, Shaun; Alan Duric; Dusan Stevanovic
> Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing
> fasterthan a SIP PING requestprocessing?
> 
> inline.
> 
> Michael Procter wrote:
> 
> > Bharrat, Shaun wrote:
> > 
> >>Now that I understand what is actually being done, I guess 
> my question
> 
> >>is why you would have expected the numbers to be any different?
> > 
> > [...]
> > 
> >>If we are "allowed" to skip the SIP processing (i.e. it's 
> not really a
> 
> >>SIP packet), then I agree that we can make the processing time of a 
> >>PING arbitrarily close to a STUN packet processing. 
> However, if we are
> 
> >>not, I don't agree that this is a valid comparison of a SIP-based 
> >>keepalive versus a STUN based keepalive.
> > 
> > 
> > I think the point is that the message has sufficient SIP 
> headers that 
> > it can be parsed and rejected (501) by a stack that doesn't support 
> > the extension.  A rejection is an acceptable response to the PING 
> > request,
> > 
> > So, the PING request is in some sense backwards-compatible with 
> > existing code.
> 
> Thats my beef with this whole thing. That its "in some sense" 
> backwards
> compatible, but not really.
> 
> You are taking something that LOOKS like SIP, but is fundamentally NOT
> SIP, and sending to a server in the hopes that the right 
> thing happens. 
> However, in the real world, odd things will always happen. Let me give
> some examples.
> 
> UAC sends the PING request to its proxy. Proxy doesnt support 
> the method
> but forwards it on to another proxy, ignorning max-forwards (some
> elements do this, as they serve as 'fronts' to the real proxy). Packet
> is lost. Well, you've changed the retransmit rules for PING 
> from normal
> SIP, and there are no retransmits. So, there is a timeout. 
> We'll have a
> nice race condition, first of all, since the outbound proxy, having
> thought this was normal SIP, will generate a 408 at some point, but
> probably after the UAC gives up. Depends on how you define 
> your new PING
> protocol transaction timers relative to real sip. Assuming though that
> the UAC times out first, the UAC will think that its proxy is 
> down, but
> its not. Seems really bad to me.
> 
> Here's another funny case. PING goes to a proxy, which doesn't know
> about PING, but wants to authenticate the request. So, it 
> responds with
> a 401 and challenges the request. Well, you might say it worked fine -
> nat binding kept alive. However, many proxies will set off alarms with
> their intrusion detection systems on repeated 401 messages 
> from the same
> source IP, so your client may find itself banned from the 
> network pretty
> quickly.
> 
> Both of these problems can be fixed by putting Proxy-Require 
> and Require
> in. However, that defeats the whole point of this mechanism, to be
> "backwards compatible" with existing SIP. So, if you do that, may as
> well use STUN.
> 
> So, to be clear, I think that this whole idea of something that looks
> like SIP, but isn't, in the supposed hopes of being "backwards
> compatible" with existing equipment, is a big, big mistake, and will
> result in all kinds of unpredicable and really hard to debug 
> problems in
> the real world.
> 
> 
> 
>   Of course, newer implementations may choose to
> > optimise the processing for it, so that they can get 
> performance that 
> > is equivalent to STUN, but there is no need to do so for 
> the feature 
> > to work.  Implementing the fast-path processing is 
> therefore purely an
> 
> > implementation issue, not a protocol compliance issue.
> 
> Wrong, as I have pointed out. As soon as you make a change that alters
> MUST-strength processing in clients (as the PING method has), you have
> introduced interoperability problems.
> 
> -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
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip