RE: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf]

"Christian Jansson" <christian.jansson@hotsip.com> Thu, 11 November 2004 16:53 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00936 for <sip-web-archive@ietf.org>; Thu, 11 Nov 2004 11:53:22 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIDX-0006ru-3b for sip-web-archive@ietf.org; Thu, 11 Nov 2004 11:54:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSI7H-0007VB-Mz; Thu, 11 Nov 2004 11:48:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSI0W-000684-IR for sip@megatron.ietf.org; Thu, 11 Nov 2004 11:41:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29418 for <sip@ietf.org>; Thu, 11 Nov 2004 11:41:10 -0500 (EST)
Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSI1V-0006Ss-Qz for sip@ietf.org; Thu, 11 Nov 2004 11:42:27 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf]
Date: Thu, 11 Nov 2004 17:40:23 +0100
Message-ID: <B7192C0D8D60754DADA9E22294C57369631661@mailserver.hotsip.com>
Thread-Topic: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf]
Thread-Index: AcTHcMo5CP2b5eryTiy5Nl/L8i5PrAABvRvgABRo7WAABIYsQAAHn+PQ
From: "Christian Jansson" <christian.jansson@hotsip.com>
To: "Christian Stredicke" <Christian.Stredicke@snom.de>, "Spencer Dawkins" <spencer@mcsr-labs.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: quoted-printable

Let's step back and look at the requirements. 

We have a problem that UAs are placed behind NATs and FWs. Those NATs
and FWs give us two big problems:
Problem1. Machines from the outside cannot easily connect/communicate
with the UAs on the inside, at least not without initiative from the UAs
on the inside.
Problem2. Even though the UAs on the inside open up for communication
through the NAT/FW, the NAT/FW doesn't keep the state for as long as we
would wish.

This gives us two requirements:
Req1. Open up for two way communication through the NAT/FW
Req2. Ensure req1 for as long as it is needed for the UA on the inside.

There are also some facts:
Fact1. In almost all normal situations it will only be the UA that can
open up the NAT/FW for two way communication.
Fact2. It is the UA that knows for how long the two way communication
through the NAT/FW is needed.
Fact3. It is generally good to put less work on servers and let the UAs
do as much of the work as possible. 

>From fact1 I draw the conclusion that the UA must open up the two way
communication because it will be the only reliable solution.
Fact2 and fact3 together with the conclusion that the UA must fulfill
fact1 gives me a strong feeling that the UA should be the only one that
should do the job of fulfilling the requirements.

I understand that there could be other solutions where machines on the
outer side of the NAT/FW could partly fulfill req2, that is, they could
try to keep the communication path open. But such a machine cannot be
sure exactly when to stop, and, this is the big one, it can't do
anything if it detects that the communication path fails ... nothing! If
the UA on the other hand fulfilled req2 and detected a problem, it could
open up a new communication path and everything would start working
again.

I do not think we should fool UA implementers into thinking that they
can solve the NAT/FW problem by negotiating with another device on the
outside of the NAT/FW. I think it is better to write down how to open,
use, and maintain a two way SIP signaling path through NATs and FWs.

My suggested solution:
Follow what's in draft-jennings-sipping-outbound-00:
- Keep-alives should be sent by the UA.
- Keep-alives for TCP should be CRLF (default-interval TBD). 
- Keep-alives for UDP could be the SIP methods REGISTER, or a new
light-weight SIP PING method, to be able to get the rport and received
from the response, or STUN. Frequent REGISTERs seems to heavy-weight for
the servers. That leaves us with PING or STUN. PING advantage, it is
SIP, disadvantage, it is new. STUN advantage, have been around for a
while, disadvantage, it is not SIP.

/ Christian Jansson



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip