Re: [Sip] PING/PONG

[Jonathan Rosenberg <[e-mail]>]

inline.

Christian Stredicke wrote:

> Hi Spencer!
> 
> You just mentioned another way of keeping TCP connections alive. Thats
> good! 
> 
> So far we have:
> 
> - CRLF (frequenly used today, but not indicated by user agent)
> - STUN (same as CRLF)

It is not the same. STUN solicits a response, which allows the client to 
determine if the NAT binding has changed, and if the server is still alive.

> - PING/PONG or whatever (tbd, maybe superflous)

I am very much against SIP-based keepalives. This turns into a huge 
scalability nightmare. It ends up being the dominant processing cost for 
proxies along with the dominant percentage of the signaling bandwidth, 
and it buys you nothing.


> - OPTIONS (big overhead, but compatible)
> - REGISTER (same as OPTIONS, but even bigger overhead)
> - TCP low-level (how can this be addressed by the application?)
> - No refreshing ("legacy device")
> 
> Lets have a way to indicate these options and let the SBC decide what
> method it likes/supports.

Generally speaking, having multiple choices reduces interoperability. I 
think we should pick a solution, and only describe multiple ones if 
there is a compelling reason why multiple ones need to exist.

Its worth pointing out that there are several functions these various 
keepalvies provide:

1. they keep nat bindings fresh
2. they allow the client to detect if its nat binding as seen by the 
server has changed
3. they allow the client to determine if the server is still alive and 
responding to messages
4. they allow the client to determine if the nat has dropped its binding 
altogether, so that packets are just going into the ether

I *think* Bob is proposing another usage:

5. they allow the server to determine that the nat binding for the 
client has changed, so it can update its registration to reflect the new 
address


Using the keepalive to update the binding on the server introduces 
security risks. If the keepalive is not authenticated, an attacker can 
inject the keepalives with a falsified source IP address, and as a 
result force incoming calls to be directed towards it. This is not 
acceptable. Thus, any request which causes the server to update any kind 
  of bindings MUST be authenticated. I would rather not require the 
keepalives to be authenticated, as this substantially increases the cost 
of processing them. If you use unauthenticated STUN packets, the client 
detects that its nat binding has changed, and then it can re-register 
with a proper REGISTER, which can be authenticated and that can be used 
to update the binding, thus avoiding the attack.

It is possible to use different mechanisms to address each of the 4 
different issues above. An empty UDP packet or a CRLF on the TCP 
connection can address the binding keepalive issue but not any of the 
liveness checks. I strongly prefer a single solution that addresses all 
of these.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip