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 17:00:25 -0600

Hi Jonathan,

  Thx for detailed reply. My replies in line prefixed with SS>>

Thx
Samir

Samir Srivastava wrote:

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

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

SS>> Agreed

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

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:

SS>> Agreed. It's my mistake regarding term proxy. Gernally Edge Proxies
are B2BUA. 
     We need to take care of both. Refer Later comments for Proxy case.

<<< Removed the quotes >>>

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.

SS>> Fine. As you suggest use PING with Max-Forwards with zero.

> And if proxy is good
> enough, to have a configuration rule saying UnImplmented Methods are 
> not authenticated, then we 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.

SS>> Fine. Client resubmits the request with Credentials and with
MAX-FORWARDS equal to 0. It should
     not trigger any other issue.

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

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

SS>> We are still in the process to arrive at conclusion.

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

> Methods ?

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.

SS>> Okay. I was thinking in terms of Edge Proxy as B2BUA
implementation. We can use MAX-FORWARWDS equal to 0 trick, for it not to
be proxied.

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.

SS>> Fine. We can add this to PING specification, it should honour 503.
This will require more processing at client. We are fine with this. New
Server with PING needs to check for overload variable, and Send 503
Retry After. This is not the case most of the time. We can still shunt
the parser. BTW if server is overloaded with CRLF, what we will be doing
?

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.

SS>> This is problem with the client due to name space collision. Client
should fix it. It can happen with any new specification. If it is widely
deployed and IETF wants to honour it, we can
name method differently.

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.

SS>> We can do similar for PING. We can have the similar flags for PING
support in URI if we
     don't want to use Require/Proxy-Require. 
     The old Proxy will honour the PING request with Tag for PING
extension in Proxy Require with 420 Bad Extension, As I missing
something here ? While the Proxy with PING specification will honour
with 200 OK etc. 

     If there is any SIP traffic going on (Chatty IM Session, Register,
Presenece and different Event Package notification etc ), we don't need
to send the KEEP ALIVE. For STUN CRLF case, there needs to be additional
coupling between SIP and STUN modules. This is an implementation issue,
but needs to be taken into account.     

-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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 7 Mar 2006 08:21:20 +0200

> from my proxy network if its not authenticated.

this goes too far.  you must have lived to long in bell-head world.  as
i told before, proxies route sip requests.  if you want to charge for
that, it doesn't matter if request is INVITE or NON-INVITE.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Tue, 7 Mar 2006 11:27:57 -0600

> that, it doesn't matter if request is INVITE or NON-INVITE.

I will note, I think I've seen a correlation between people who  
believe you can bill from signaling as seen by proxies, people who  
think edge proxies are all b2buas and/or SBCs, people who think we  
should specify a finite set of standardized services, and people who  
worked in traditional PSTN environments long enough to get comfy  
there. Not 100%, but still a high correlation.

I think this does point at a very deep philosophical divide within  
our community.

--
Dean