Subject: RE: [Sip] PING/PONG

From: "Christian Stredicke" <[email-masked]>
Date: Thu, 11 Nov 2004 00:07:07 +0100

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)
- PING/PONG or whatever (tbd, maybe superflous)
- 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.

CS

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Spencer Dawkins
> Sent: Wednesday, November 10, 2004 5:01 PM
> To: [email-masked]
> Subject: Re: [Sip] PING/PONG
> 
> Call me old-fashioned, but I'm requesting a point of clarification 
> about PING/PONG.
> 
> As I should have said in the working group session when we discussed 
> this, I have no interest in chatting about UDP versus TCP. If you 
> choose UDP, I assume you did it for a reason, and the discussion at 
> the working group session makes sense to me.
> 
> Having said that,
> 
> > With UDP, the PING will create a new NAT binding and the server can 
> > update
> > its mapping for the UA.
> >
> > With TCP, if you want to be able to detect that the NAT binding is 
> > gone on
> > the order of a transaction timeout, you would need to send a PING 
> > every 32
> > seconds or so. Given that NAT bindings for TCP live longer than 
> > that, I
> > don't see what the CRLF buys you.
> 
> it seems to me that if you have chosen to use TCP for some 
> reason, you 
> need to at least consider living with TCP behavior on retries.
> 
> The TCP protocol is extremely persistent, uses exponential backoff 
> (typically to a maximum of 60-64 seconds per retry), and in most 
> vanilla implementations will not declare a connection unusable for 
> something like 10-15 minutes.
> 
> If a path is lost, for any reason, TCP will use this behavior (the 
> behavior that allows the Internet to survive the World Wide Web 
> today).
> 
> If you are using TCP and you don't like this behavior, and you don't 
> get a response back when you wanted to get a response back, the 
> application choices are:
> 
> - sit on your hands and wait for the TCP connection to fail,
> 
> - close the TCP connection and open another one, or
> 
> - close the TCP connection, sit on your hands for some period 
> of time, 
> and open another one.
> 
> The second choice (immediate retry) requires that you reset the TCP 
> connection (one packet), send a SYN to open a second TCP connection 
> (one packet), and potentially ACK an incoming SYN/ACK (one packet), 
> and then resend your application message (could be piggybacked but 
> most TCP stacks will use a separate packet).
> 
> Immediately sending up to four new packets when you detect 
> loss of one 
> packet, with the possibility that the single-packet loss is due to 
> network congestion, seems too aggressive.
> 
> Sitting on your hands and letting TCP retry doesn't seem much worse 
> than sitting on your hands and then setting up a new TCP connection.
> 
> Are we assuming that network congestion is not an issue any more?
> 
> Thanks for any guidance you can provide!
> 
> Spencer 
> 
> 
> 
> _______________________________________________
> 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: Klaus Darilion <[email-masked]>
Date: Mon, 15 Nov 2004 21:46:54 +0100

You should also consider the guidelines in the draft
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-00.txt
which will hopefully soon implemented in NAT routers.

regards,
klaus

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 14:34:29 -0500

inline.

> - CRLF (frequenly used today, but not indicated by user agent)

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.

> 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
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "vikram bhuskute" <[email-masked]>
Date: Wed, 17 Nov 2004 15:21:04 +0530

Hello ,
               I am an active member of this work group. It so happened that
i deleted some old mails.
Earlier i Use to see Old mails on the Archives link. But now if i open ,it
give today's and yesterday's mail.
I am force to go to link
http://www1.ietf.org/mail-archive/web/sip/current/index.html and there is no
other link there :(
Please help !!

Vikram