RE: [Sip] PING/PONG

["Christian Stredicke" <[e-mail]>]

So my understanding is:

1. We should use *only* STUN for refreshing bindings (either UDP or TCP,
what about TLS)

2. The user agent indicates if it can do it (no negotiation on
capabilities)

3. Refreshing must be done from the client

Can we agree on that?

Christian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]] 
> Sent: Tuesday, November 16, 2004 2:46 PM
> To: Christian Stredicke
> Cc: Spencer Dawkins; [e-mail]
> Subject: Re: [Sip] PING/PONG
> 
> 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