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

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 6 Mar 2006 13:59:37 -0600

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Mar 2006 15:39:13 -0500

> How STUN CLRF is better without changes on the existing Proxy ?

The case that one needs to be concerned about is when the proxy doesn't 
support this mechanism, not when it does.

> Method Not Implemented" we are okay.

Well, my point is, that is not always going to be the case.

Firstly, proxies are not supposed to have to know about new methods. 
Quoting RFC3261:

> This is a model of proxy behavior, not of software.  An
>    implementation is free to take any approach that replicates the
>    external behavior this model defines.
> 
>    For all new requests, including any with unknown methods, an element
>    intending to proxy the request MUST:
> 
>       1. Validate the request (Section 16.3)
> 
>       2. Preprocess routing information (Section 16.4)
> 
>       3. Determine target(s) for the request (Section 16.5)
> 
>             +--------------------+
>             |                    | +---+
>             |                    | | C |
>             |                    | | T |
>             |                    | +---+
>       +---+ |       Proxy        | +---+   CT = Client Transaction
>       | S | |  "Higher" Layer    | | C |
>       | T | |                    | | T |   ST = Server Transaction
>       +---+ |                    | +---+
>             |                    | +---+
>             |                    | | C |
>             |                    | | T |
>             |                    | +---+
>             +--------------------+
> 
>                Figure 3: Stateful Proxy Model
> 
> 
> 
> 
> 
> 
> Rosenberg, et. al.          Standards Track                    [Page 93]
> 
> RFC 3261            SIP: Session Initiation Protocol           June 2002
> 
> 
>       4. Forward the request to each target (Section 16.6)
> 
>       5. Process all responses (Section 16.7)

Note the bit about unknown methods.

So, a normal RFC3261 compliant proxy WILL NOT reject a PING request with 
a 501. You can force it to reject any request, including PING, by 
setting Max-Forwards to zero. But the point is, there is lots of other 
processing in a standard proxy that is going to interfere with your 
assumptions in this PING method.

> And if proxy is good
> we are okay too.

Normally all requests are authenticated. It is a security problem ot not 
authenticate a request just because its method is unknown. Imagine a new 
method NOT-INVITE, which carries SDP around, used to set up calls. Works 
much like invite, but I changed the method name. I can get free service 
from my proxy network if its not authenticated.

> Though it does not offer Performance benefits of the

No. This PING is a recipe for huge operational problems unless the 
proxies all support it.

> May I ask, how many proxies are there which authenticate unimplemented

Unimplemented? Careful here - we're talking about unknown methods. 
Proxies arent supposed to know about methods except for INVITE, CANCEL 
ACK adn then everything else. You make it sounds like its a bug to 
authenticate unknown methods (mine does, btw). Its not.

But let me pick another bad thing that can happen.

Lets say our poor proxy is overloaded, probably from all of these PING 
requests. So, to quench traffic, it sends a 503 with a Retry-After, 
under the assumption that a compliant UAC will properly back off. But, 
the UAC doesn't (since UAC processing violates RFC 3261 for this 
method). The network continues to be overloaded with no recourse. Again, 
the source IP is likely to be blacklisted for non-compliance.

The flip side of this problem is a client which sends a request called 
PING to a server, not realizing that a spec has been produced which 
redefines SIP processing for tihs specific method. As such, this client 
is expecting normal SIP processing for this request. It hits a server 
which supports this "extension". This is a real issue, btw - I am aware 
of implementations which use the method PING. Lets say the client is 
using this ping for a traceroute facility. So, it sends the request with 
a non-zero Max-Forwards. This hits a proxy which immediately rejects it 
since it supports the ping "extension". Now the client is going to get 
incorrect information from its traceroute processing.

Let us not forget that the stun mecahnism can still have a fallback to 
non-stun operation if the server doesnt support it. Stun messages are 
sent to the sip port only when the flag is present in the SIP URI 
indicating that the server can do the demux. We do EXACTLY this same 
thing with sigcomp, btw. So, if a client which supports sip outbound, 
has a URI for its outbound proxy which doesnt have this flag, it can 
resort to plain old OPTIONS with Max-Forwards: 0. No different than what 
happens with PING when the server doesn't support it, except we don't 
have the interop problems that PING will bring.

-Jonathan R.

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 6 Mar 2006 23:18:22 +0200

> May I ask, how many proxies are there which authenticate unimplemented

proxies' job is to route requests, not interpret them.

-- juha

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 6 Mar 2006 18:56:26 -0500

> Let us not forget that the stun mechanism can still 
> have a fallback to non-stun operation if the server 
> doesn't support it. 

<snip>

> So, if a client which supports sip outbound, has 
> a URI for its outbound proxy which doesn't have this 
> flag, it can resort to plain old OPTIONS with 
> Max-Forwards: 0.

Since OPTIONS is frequently sent as a ping (instead of request for options
data), wouldn't it be beneficial to define a new option-tag to indicate when
OPTIONS is really just a ping?  It does sound ridiculous; however it is not
much more so than having to use OPTIONS as a ping.

The option-tag could indicate that the UAC plans to ignore all the options
data typically included within the 200 response.  Thus it indicates a desire
for the UAS to not send such data.

The UAC could include it in supported, proxy-require, and/or require
depending on desired behavior.

The main benefits would be related to capacity and security.  And devices
constantly/mostly receiving OPTIONS as a ping, might start providing more
data in the response when OPTIONS actually used as it was intended.

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 7 Mar 2006 16:20:39 +0100

Just wanted to note that I'm not yet in favour of either mechanism. I'm 
just trying to find the best solution by attacking until one breaks. 
The solution needs to be reasonably simple and fast to deploy. We want 
to make sure that the chosen mechanism is the appropriate one for all 
reasons.

More inline...

> Note the bit about unknown methods.

Note the bit that says "intending to proxy a request". I would assume 
the PING request has a request-uri pointing to that proxy and therefore 
the proxy does not intend to proxy that PING request.

> No. This PING is a recipe for huge operational problems unless the 

Well, I don't think I'm crazy enough to deploy UAs that use PING 
without adding support to it in my network.

> method). The network continues to be overloaded with no recourse. 
> Again, the source IP is likely to be blacklisted for non-compliance.

Maybe others did, but I did not claim that the UAC needs to violate 
RFC3261. The UAC can generate the PING and process the response for it 
like it does for any other request. It is the server performance that 
we worry about.

> redefines SIP processing for tihs specific method. As such, this 
> client is expecting normal SIP processing for this request. It hits a 
> server which supports this "extension". This is a real issue, btw - I 
> am aware of implementations which use the method PING. Lets say the 
> client is using this ping for a traceroute facility. So, it sends the 
> request with a non-zero Max-Forwards. This hits a proxy which 
> immediately rejects it since it supports the ping "extension". Now the 
> client is going to get incorrect information from its traceroute 
> processing.

I do not buy this argument at all. You can argue the same for any other 
SIP request, even INVITE can be sent by a client that does not realise 
there is a spec for it. If a UA sends a request that is standardised in 
an RFC, it better know how to use it. If it doesn't then bad things 
will happen, and we don't protect those clients that implement 
proprietary extensions to sip.

> resort to plain old OPTIONS with Max-Forwards: 0. No different than 
> what happens with PING when the server doesn't support it, except we 
> don't have the interop problems that PING will bring.

Why can't we use the same flag for PING?

And about sigcomp, its uncompairable. sigcomp can be viewed as a 
wrapper. Besides, we have sipcomp and sip muxed already, how big do u 
want your demuxer to be?

Hisham

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 07 Mar 2006 19:17:56 +0200

Jonathan Rosenberg <[email-masked]> writes:
>The flip side of this problem is a client which sends a request called PING
>to a server, not realizing that a spec has been produced which redefines SIP
>processing for tihs specific method. As such, this client is expecting
>normal SIP processing for this request. It hits a server which supports this
>"extension". This is a real issue, btw - I am aware of implementations which
>use the method PING. Lets say the client is using this ping for a traceroute
>facility. So, it sends the request with a non-zero Max-Forwards. This hits a
>proxy which immediately rejects it since it supports the ping "extension". 
>Now the client is going to get incorrect information from its traceroute
>processing.

>non-stun operation if the server doesnt support it. Stun messages are sent
>to the sip port only when the flag is present in the SIP URI indicating that
>the server can do the demux. We do EXACTLY this same thing with sigcomp,
>btw. So, if a client which supports sip outbound, has a URI for its outbound
>proxy which doesnt have this flag, it can resort to plain old OPTIONS with
>Max-Forwards: 0. 

So, you are proposing that (unless it has been provisioned with
outbound proxy URI containing param "sip-stun"), client sends
1) OPTIONS with Max-Forwards: 0, 
2) gets the set of outbound proxy uris in the Contact header of
   the response.,
3a) checks from the URI list if proxy supports sip-stun and/or
    sigcomp or the favourite refresh method of the month, 
    or
3b) if there is no URI in response to OPTIONS, client defaults to
    OPTIONS with Max-Forwards: 0?

BTW, how do you propose we should combine SigComp and STUN over
TCP? I suppose we have to send STUN inside SigComp, because RoHC
people did not want to have protocol interleaving with SigComp,
but could a client just reuse the stun transaction id? That would
mean that neither client nor server have to compress/decompress
each STUN message.

--Pekka