Subject: [Sipping] Session Border Control Deployment Scenario

From: "Khan, Sohel Q [NTK]" <[email-masked]>
Date: Tue, 19 Jul 2005 08:44:58 -0500

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 19 Jul 2005 16:46:31 -0500

>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

---

From: [email-masked]
Date: Thu, 21 Jul 2005 14:39:09 -0500

A few thoughts:

- RF appears to be referring to IP routing. How is this L3 function tied into all these other higher layer functions ?

- Hot Potato Routing - Since all IP routing is between S/BCs only, this seems to become a VoIP routing problem. You would ideally need something like TRIP to do the Cold Potato Routing. In the absence of that, Hot Potato is probably the simplest.

- An issue with any of the approaches that use a centralized SF is that if it is on the access side and you are trying to service VPN customers, your centralized SF must participate in all customer VPNs.

- Distributed S/BC - I wouldn't expect any carriers to front-end their routers with FWs, especially not for a peering connection.

- In general I would say that the MF and RF should be in the edge routers. By also placing SF in the edge routers you can deal with VPNs in a more scalable manner, there is no need for new control protocol development on the softswitches etc., and there is an extra layer of control-plane security. A centralized SF in the softswitch may be ok but it would be good to at least have the functionality available in the edge router for certain cases.

- As far as extensions go, would there be any benefit to a standard parameter that allows media release ?

Cheers,
James