Re: [Sipping] draft-camarillo-sipping-sbc-funcs-02.txt

Arjun Roychowdhury <arjunrc@gmail.com> Fri, 21 October 2005 03:33 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnek-0001Pk-KP; Thu, 20 Oct 2005 23:33:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnei-0001PZ-VF for sipping@megatron.ietf.org; Thu, 20 Oct 2005 23:33:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20642 for <sipping@ietf.org>; Thu, 20 Oct 2005 23:33:09 -0400 (EDT)
Received: from qproxy.gmail.com ([72.14.204.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESnqn-0006AB-9W for sipping@ietf.org; Thu, 20 Oct 2005 23:45:49 -0400
Received: by qproxy.gmail.com with SMTP id p35so480826qbb for <sipping@ietf.org>; Thu, 20 Oct 2005 20:33:19 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KT2mP660EurVgOds6Jdxqzuf186cVAdHwxK3wtZ+9suk/YMQqAy45zLpLPuMDHEWd6emMrXT4OmSr0SLP13QkojjaDg7KP+1Me/iML1wJua5OwDowQ0Lr934d/5QgnMuuEscELGd2bCFUQbnAiXCZ6EW1wX+rKJiY6pVjS8CeI8=
Received: by 10.65.81.1 with SMTP id i1mr1855155qbl; Thu, 20 Oct 2005 20:33:19 -0700 (PDT)
Received: by 10.65.113.2 with HTTP; Thu, 20 Oct 2005 20:33:19 -0700 (PDT)
Message-ID: <a9994e940510202033i1ae13fe3he662630004cb9ca0@mail.gmail.com>
Date: Thu, 20 Oct 2005 23:33:19 -0400
From: Arjun Roychowdhury <arjunrc@gmail.com>
To: "henry@sinnreich.net" <henry@sinnreich.net>
Subject: Re: [Sipping] draft-camarillo-sipping-sbc-funcs-02.txt
In-Reply-To: <200510202234.SAA19256@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <200510111545.LAA10366@ietf.org> <200510202234.SAA19256@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: quoted-printable
Cc: sipping <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

I really feel like playing devils' advocate, since I know, deep
inside, you really think SBCs are nice kids who just need to be 'wired
right'. So here goes ....

It seems the only unfriendly thing an SBC does is that it modifies
messages without the knowledge of the UAs - though this is not the
concern - the concern is that this in turn breaks end-end protection,
if it is used (that is the one consistent reason in all the sections).

In all fairness, I have a hard time understanding why the SBC is
turning out to be the 'Anti-Internet'. The end-end principle of the
Internet has always been challenged at the network layer (which has
nothing to do with the application layer) for a long time, including
technologies like NAT, Firewalls,ALGs, relays, split DNS and similar.
Several RFCs talk about the realistic challenge of e-e and actually
discuss realistic scenarios where e-e may not work (The Rise of the
Middle and the Future of End-End - 3724)

The biggest issue seems to be 'done without knowledge' and 'end-end
encryption' seems secondary, at least at the network layer of the
Internet (as an example, the NAT WG suggested RSIP as an adjunct to
NAT to make it 'friendly'). If this is the biggest problem, then the
solution is easier - let the SBC 'tell' the UAs via some SIP mechanism
that it is playing 'big brother'. That information could be used to
inform the UAs 'legally' that due to network policies the outside
world is not seeing what they are sending - and if the SBC tells them
what the change is, then maybe the UAs can get 'smarter' in operation
for that session. (Sorry, I am not smart enough to figure out what
'smarter' really means, at least for now)


>
> - If the SBC is compromised (it happens on the Internet) then what are the
> vulnerabilities for (1) SIP signaling and (2) RTP media streams?

This is a problem not specific to SBCs. What if the mailserver of a
corporate domain gets compromised ? What if the backend datastore of a
credit card company gets compromised by a web server exploit ? Same
story.

regds
arjun
--
Arjun Roychowdhury

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