Subject: RE: [Sipping] Session Border Control Deployment Scenario

From: "Khan, Sohel Q [NTK]" <[email-masked]>
Date: Thu, 21 Jul 2005 10:08:37 -0500

While we are internally reviewing your suggestions, I have few
questions:

1. Are you proposing to eliminate Session Border Controller (SBC)?

2. The draft draft-sohel-sipping-s-bc-concept-arch-00.txt depicts
various conceptual architectures that distribute SBC functions in
standard entities such as CSCF, MGCF, BGCF, PDF, and MGW .... what is
your view on this.

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2005 4:47 PM
To: Khan, Sohel Q [NTK]; [email-masked]
Subject: RE: [Sipping] Session Border Control Deployment Scenario

>Please review various conceptual deployment scenarios presented in the
>draft-sohel-sipping-s-bc-concept-arch-00.txt and provide feedback.

Thanks for sharing and here is some feedback:

The I-D needs to make it clear where the e2e Internet and SIP
architecture
is broken or non-compliant and what the security considerations need to
be
adressed in this memo, item by item. The concerns are (A) SIP may just
not
work properly in the standard way, (B) applications in the endpoints
will be
broken and last but not least (C) what are the security exposures from a
compromised SBC?

A. Transparency

1. SIP dialog transparency: Is the call ID the same on the various
interfaces?

2. Identity transparency: Will a user have the same identity on the
various
interfaces?

3. Cseq transparency: Will the SBC not change the Cseq numbers?

4. Body transparency: Will the SBC not change the MIME bodies required
for
e2e security?

5. Header transparency: Will the SBC change the SIP headers?

6. Media transparency: Similar to the above. Usage examples where
applicable.

7. Topology transparency: Will the Via, Record-Route, Path and other
headers
that reveal the topology be changed by the SBC, and if yes, how?

8. Security transparency: Will the SBC change security aspects such as
authorization headers, encrytion, etc.?

9. Accounting transparency: Will the SBC change data required for
accounting?

10. Functional transparency: How transparent is the SBC to applications
that
it does not understand?

(These items are taken from a note by Dean Willis in previous
discussions).

B. Breaking of Applications

1. How can the SBC prevent breaking applications it does not understand?

2. How does the SBC in the middle know to keep state of the apllications
at
the edge or hidden in customer private networks?

C. Security Considerations

1. What happens if a SBC is compromised? 

2. Discussion on 1. about theft of service, loss of privacy
(eavesdropping),
impersonation and revealing the internal IP addresses of customer
private
networks.

Comment: The task of the IETF is to make things interwork across the
Internet. It seems to me that the proposed architecture will lead to
exactly
the opposite. If this is true, this I-D should not be a WG item nor
should
it be accepted as an individual contribution.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf
Of Khan, Sohel Q [NTK]
Sent: Tuesday, July 19, 2005 8:45 AM
To: [email-masked]
Subject: [Sipping] Session Border Control Deployment Scenario

Please review various conceptual deployment scenarios presented in the
draft-sohel-sipping-s-bc-concept-arch-00.txt and provide feedback. We
would appreciate discussion on SIP extensions as interfaces between
these devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sohel-sipping-s-bc-concept-arc
h-00.txt

Abstract: This document illustrates various conceptual deployment
scenarios of Session/Border Controller (S/BC). The objective is to
depict a provider's 
architectural requirements of S/BC function deployment. The document
will help the IETF community to understand that S/BC functions can be
deployed in the network in scalable approach.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 21 Jul 2005 22:25:09 -0500

>Are you proposing to eliminate Session Border Controller (SBC)?

Definitely yes, and for the reasons in the attached.

> standard entities such as CSCF, MGCF, BGCF, PDF, and MGW .... 
> what is your view on this. 

The IMS-TISPAN is a broken architecture that adds nothing but constraints,
complexity and cost. Skype has proven that one can run the biggest VoIP
service in the world with no or only minimal "VoIP/IM/Presence
infrastructure" (but with better sound :->), and what there is should be as
self-organizing as P2P overlay networks are and this eliminates most of the
infrastructure cost. It is not only the capital cost, but the huge
operational cost for such complex networks. There will be a P2P BOF at the
IETF...See also www.p2psip.org , but please do not forget
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-sip-arch-00.txt
for network based services done in the spirit of the SIP architecture.

Users will just avoid all these IMS-TISPAN constraints and "services"
(sounds like a re-incarnation of the ISDN, too much for voice and to little
for data) IMHO, avoid these constraining but expensive networks and just go
straight to Google, e-Bay, Amazon, Yahoo, MSN, their bank, shopping, FWD,
Skype, Vonage, etc. That's where all the valuable applications are - a huge
Internet economy that's already here and everywhere. 

Carriers may finally understand that _"The Internet Is The Service"_
(quoting Jon Peterson), wired and wireless, and that's a nice revenue stream
for something just as vital as water, electricity, and gas (though carriers
may first loose their shirts trying to compete with lowest cost voice and
other lowest cost Internet communications and applications). It's the dumb
network (http://www.isen.com/papers/paradigm.html ) that enables innovation
at the edge and creates all the lasting value.

My two cents. Actually I am only the humble messenger...

Thanks for reviewing these comments!

Henry

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2005 4:47 PM
To: Khan, Sohel Q [NTK]; [email-masked]
Subject: RE: [Sipping] Session Border Control Deployment Scenario

A. Transparency

(eavesdropping, 
private networks.

Thanks, Henry

---

From: Richard Shockey <[email-masked]>
Date: Fri, 22 Jul 2005 13:06:57 -0400

>for network based services done in the spirit of the SIP architecture.
add to this

Ths Systems Standards Stockholm Syndrome

http://www.bcr.com/bcrmag/2005/07/p62.php

and

http://www.bcr.com/bcrmag/2005/06/p18.php 
 
IMS 101: What you Need to Know

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:[email-masked]
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1
815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<