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

["Medhavi Bhatia" <[e-mail]>]

BCP track?

I think we still need a major focus change on the draft before it becomes
more generally useful.

The intent of the draft is the right thing to do, however it is really
suggesting requirements on what needs to be done and can't be done using
standardized SIP.

Another case is the existence of similar behavior in other platforms like
prepaid for broadband (which tends to use similar NAT traversal techniques).
The case is that in some closed environments these mechanisms are seen as
valid choices to make (Consider IMS/TISPAN border elements for example).

I think the draft needs to focus on these alternate ways of doing things and
potentially point out the considerations which need to be kept in mind when
the implementers do the analysis and make a choice. It should definitely not
make a case that the analysis needs to be done only for SBCs (which is why I
think it needs a focus change).

-Medhavi.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> [e-mail]
> Sent: Friday, October 21, 2005 9:57 AM
> To: 'Arjun Roychowdhury'
> Cc: 'sipping'
> Subject: RE: [Sipping] draft-camarillo-sipping-sbc-funcs-02.txt
> 
> 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




_______________________________________________
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