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

[[e-mail]]

Arjun,

We need not burden the list again with a new flare-up discussing SBCs all
over again and I apologize if I may have caused this discussion.

Let's trust the authors of the I-D to add more substance to the Security
section and maybe deal with some of the other topics previously discussed.

This is a document that should be quickly advanced on the BCP track, since
the topic is of high interest in the industry.

Thanks, Henry

-----Original Message-----
From: Arjun Roychowdhury [mailto:[e-mail]] 
Sent: Thursday, October 20, 2005 10:33 PM
To: [e-mail]
Cc: sipping
Subject: Re: [Sipping] draft-camarillo-sipping-sbc-funcs-02.txt

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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP