Session Initiation Proposal Investigation (sipping)

Marc Petit-Huguenin | 1 Mar 2005 01:51

Re: WGLC on RTCP Summary Draft

I sent some questions about this draft some time ago:

http://www1.ietf.org/mail-archive/web/sipping/current/msg07649.html

Dean Willis wrote:
> This should have happened about two months ago. I'm sorry.
> 
> Your friendly but only marginally performant working group chairs were  
> just reminded of the fact that the working group agreed in DC to adopt  
> draft-johnston-sipping-rtcp-summary-06.txt as a working group document  
> and proceed to WGLC. I believe we agreed that this would be an  
> informational track document.
> 
> So, I'd like to announce a working group last call, starting  
> immediately, and closing March 16, 2005.
> 
> The draft under discussion is available at:
> 
> http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp- 
> summary-06.txt
> 
> 
> As usual, please copy your comments to both the list and the authors.
> 
> And if we've forgotten anything else that you have the good fortune to  
> be able to remember, please have pity and remind us gently.
> 
> -- 
> Dean
>

(Continue reading)

headers

Andrew Graydon | 1 Mar 2005 04:47

RE: Draft: Functions of Current SBCs

I fully agree with you that the definition currently being talked about
for an SBC is what you would classify below as a 'device' and not
necessarily a standard. There are many functions that are provided by
the current SBC incarnations and proposed in the Edge Proxy by ourselves
that will further the security aspects of SIP and could be transformed
into a standard, one of the reasons we asked people to look and discuss
the discussion paper we sent, but the current discussion is off the
standards track.

We need to revisit the full SIP message flow between the endpoint and
the variety of topologies that it may pass through, and discuss where
the security points must be and what functionality must be involved, and
then decide on whether this group wants to discuss this as a standard or
a best practice.

Andrew

________________________________________________________________________
Andrew Graydon                                 Phone: 905-804-1855 x289
V.P. Technology                                Fax:   905-804-1865
Borderware Technologies Inc.                   http://www.borderware.com

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of Paul Kyzivat
Sent: February 28, 2005 12:06 PM
To: Gonzalo Camarillo
Cc: 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg (JO/LMF)';
'sipping'; 'Shai Mohaban'; 'David R Oran'
Subject: Re: [Sipping] Draft: Functions of Current SBCs

(Continue reading)

headers

Ben Campbell | 1 Mar 2005 16:20

Re: Draft: Functions of Current SBCs

On Feb 27, 2005, at 9:20 PM, Medhavi Bhatia wrote:

> Radhika,
>
>  
>
> What about entities which are not UAs (or B2BUAs) which modify SDP ? 
> (like ALGs). Guess they fall through the terminology trap door ;) I’d 
> still call them proxies (trusted or malicious) according to Section 
> 26.1.3 in rfc 3261.
>
>

I assume since you refer to the RFC 3261 definition of proxies, you are 
referring to ALGs which otherwise act like SIP proxies, but also modify 
SDP. Regardless of the definition, RFC 3261 says proxies MUST NOT 
modify SDP. I think we have two possible terms for such a beast: B2BUA, 
or "non-compliant proxy". I suspect that most marketing departmets will 
prefer the first 

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

headers

Ben Campbell | 1 Mar 2005 16:12

Re: Draft: Functions of Current SBCs

While I normally hesitate to disagree with Henry, I think this taxonomy 
talks more about business models than anything technical. I have 
personally built out SIP networks where no "carrier" in the sense of a 
VoIP (or other media) provider existed at all. (I assume you are not 
including an IP carrier that is not somehow participating in the VoIP 
stuff other than moving bits around--if this assumption is incorrect 
than disregard my comment).

If we do need to distinguish these two SBC roles, I suggest we examine 
what makes them different, not just what sort of company is deploying 
them.

On Feb 27, 2005, at 3:00 PM, henry <at> sinnreich.net wrote:

> Two names for two very different devices: In the carrier network or at 
> the perimeter of the customer location.
>  
> The location changes many security aspects (we need to specify which) 
> and also the media performance, as well as bandwidth consumption. 
> Multi-homing of customer networks is an issue here as well.
>  
> Henry
>
>
> From: Roy, Radhika [mailto:RoyR <at> saic-abingdon.com]
>  Sent: Sunday, February 27, 2005 2:24 PM
> To: Christer Holmberg (JO/LMF); henry <at> sinnreich.net; Medhavi Bhatia; 
> Brian Rosen; Richard Fogel; sipping <at> ietf.org
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
>

(Continue reading)

headers

Tom Taylor | 1 Mar 2005 16:28

Re: Draft: Functions of Current SBCs

Two possible distinctions that I see, but maybe we could position them in a 
spectrum of classifications of borders:
  (1) Trust models are likely to differ for inter-carrier as opposed to 
subscriber-carrier handoff.
  (2) QOS model is more likely to be governed by SLA when going inter-carrier. 
Here, for sure, the enterprise-carrier boundary falls somewhere between.

Ben Campbell wrote:
> While I normally hesitate to disagree with Henry, I think this taxonomy 
> talks more about business models than anything technical. I have 
> personally built out SIP networks where no "carrier" in the sense of a 
> VoIP (or other media) provider existed at all. (I assume you are not 
> including an IP carrier that is not somehow participating in the VoIP 
> stuff other than moving bits around--if this assumption is incorrect 
> than disregard my comment).
> 
> If we do need to distinguish these two SBC roles, I suggest we examine 
> what makes them different, not just what sort of company is deploying them.
> 
> On Feb 27, 2005, at 3:00 PM, henry <at> sinnreich.net wrote:
> 
>> Two names for two very different devices: In the carrier network or at 
>> the perimeter of the customer location.
>>  
>> The location changes many security aspects (we need to specify which) 
>> and also the media performance, as well as bandwidth consumption. 
>> Multi-homing of customer networks is an issue here as well.
>>  
>> Henry
>>

(Continue reading)

headers

Andrew Graydon | 1 Mar 2005 16:54

RE: Draft: Functions of Current SBCs

This is a point I have made before we need to look at the functionality required for the SIP message across all
the variations of network there may be, even a simple peer to peer (UA to UA) transaction will require
functionality somewhere in the network topology of the relevant ISPs to provide security and other
features, then we work our way up to more complex peering network topologies where there may be multiple
devices providing this functionality across the boundaries of the transport layers.

Currently the discussion is all around business functions and current vendor implementations it seems,
we need to abstract ourselves from this to discuss the required functionality, why it is required, what
standards are needed (or changed) and leave the implementations up to the vendors. We are here to define
standards, to ensure that a compliant device will work and be interoperable.

Andrew
________________________________________________________________________
Andrew Graydon                                 Phone: 905-804-1855 x289
V.P. Technology                                Fax:   905-804-1865
Borderware Technologies Inc.                   http://www.borderware.com

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf Of Ben Campbell
Sent: March 1, 2005 10:12 AM
To: sipping
Subject: Re: [Sipping] Draft: Functions of Current SBCs

While I normally hesitate to disagree with Henry, I think this taxonomy talks more about business models
than anything technical. I have personally built out SIP networks where no "carrier" in the sense of a VoIP
(or other media) provider existed at all. (I assume you are not including an IP carrier that is not somehow
participating in the VoIP stuff other than moving bits around--if this assumption is incorrect than
disregard my comment).

If we do need to distinguish these two SBC roles, I suggest we examine what makes them different, not just

(Continue reading)

headers

Andrew Graydon | 1 Mar 2005 17:05

RE: Draft: Functions of Current SBCs

I think some of the carrier participants to this list can clarify this
point, but my experience is that the inter-carrier trust model is a very
difficult scenario to classify this simply. If we take SS7 and SMS
transport as an example, while companies such as MCI and SBC may have
QOS/SLA relationships, the same could not be said for their respective
relationships with some of the international carriers, i.e. Mozambique
Mobile for a irreverent example :), which means we should try for a
generic set of standards and then let the vendors comply to those
standards and the different entities, carriers, enterprises,
individuals, implement those standards as they see fit.

Andrew

________________________________________________________________________
Andrew Graydon                                 Phone: 905-804-1855 x289
V.P. Technology                                Fax:   905-804-1865
Borderware Technologies Inc.                   http://www.borderware.com

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of Tom Taylor
Sent: March 1, 2005 10:28 AM
To: Ben Campbell
Cc: sipping
Subject: Re: [Sipping] Draft: Functions of Current SBCs

Two possible distinctions that I see, but maybe we could position them
in a spectrum of classifications of borders:
  (1) Trust models are likely to differ for inter-carrier as opposed to
subscriber-carrier handoff.

(Continue reading)

headers

Michael Hammer (mhammer | 1 Mar 2005 17:15

RE: Draft: Functions of Current SBCs

Andrew,

Well said.  Protocols tend to be about what information gets sent or received by a particular function that
ultimately enables a service to be performed.  Here, we are reverse-engineering the opposite.  We are
asking what piece of information enables a dis-service to be performed.  It would be good to have an
itemized list of what SIP or SDP headers/parameters enable miscreants to do bad thing, when sending into
the wild or received from the wild.

Perhaps once the specific threats are enumerated, we can focus on specific counter-measures, where we
have the support of security in the application-layer components and not just the data transport level
security mechanisms.  Each layer will likely have a job to do.

Mike

>-----Original Message-----
>From: sipping-bounces <at> ietf.org 
>[mailto:sipping-bounces <at> ietf.org] On Behalf Of Andrew Graydon
>Sent: Tuesday, March 01, 2005 10:55 AM
>To: Ben Campbell; sipping
>Subject: RE: [Sipping] Draft: Functions of Current SBCs
>
>This is a point I have made before we need to look at the 
>functionality required for the SIP message across all the 
>variations of network there may be, even a simple peer to peer 
>(UA to UA) transaction will require functionality somewhere in 
>the network topology of the relevant ISPs to provide security 
>and other features, then we work our way up to more complex 
>peering network topologies where there may be multiple devices 
>providing this functionality across the boundaries of the 
>transport layers.

(Continue reading)

headers

Medhavi Bhatia | 1 Mar 2005 17:19

RE: Draft: Functions of Current SBCs

I don’t think the SBC is any “SIP entity”. SBC is just a marketing term, providing mostly security functions at this point.

Consider an entity deployed at the security border doing just SPAM detection/prevention, DoS attack prevention etc. These are SBC functions, but they can be done using a SIP Proxy.

If this entity is performing some NAT functions or transcoding like SDP rewriting, then we need a B2B UA (there are non-compliant SIP ALGs which perform SDP re-writing, but lets consider those as a separate problem). For transcoding, the SBC may make the transcoding decision and send the call to a transcoder. In this case, the SBC could be a SIP Proxy and the transcoder a B2BUA. Similarly for QoS borders, SDP inspection may be required rather than rewrites at the SBC. This could be done using a SIP Proxy as well, but requires SDP inspection.

If the SBC is generating new messages on behalf of either endpoints, it needs to be a B2BUA.

-Medhavi.

From: Drage, Keith (Keith) [mailto:drage <at> lucent.com]
Sent: Tuesday, March 01, 2005 8:05 AM
To: 'Medhavi Bhatia'; sipping <at> ietf.org
Subject: RE: [Sipping] Draft: Functions of Current SBCs

I don't think we can go in this direction.

There is currently 2 core SIP entities defined, UA and proxy. They have rigorous definitions with state machines and defined handling of various header and message bodies.

If your entity is conformant to RFC 3261 UA functionality, then call it a UA (or a B2BUA).

If your entity is conformant to RFC 3261 proxy functionality, then call it a proxy.

If your entity is neither, then do not call it a UA or a proxy, or even nearly a UA a proxy. Further, if you need it to be standardised, it needs the same rigorous definitions that are already given in RFC 3261 to UA and proxy. Additionally, in defining such a new role (Paul's "neither fish nor foul" entity), the impact on backward compatibility with the existing RFC 3261 entities needs to be fully investigated. You cannot avoid these issues just be calling it "nearly a proxy".

We still however seem to be getting bogged down in discussions of how we implement these things, rather than the discussion proceeding in identifying the functions that need to be supported, and why existing SIP roles cannot perform these functions. We need that discussion to have completed before someone can start inventing a new SIP role.

regards

Keith

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

headers

rfogel | 1 Mar 2005 18:13

RE: Draft: Functions of Current SBCs

I think you're absolutely right. I don't understand why the current discussion
is getting bogged down in taxonomy questions about B2BUAs, Proxies etc. Let's
first decide that a new architectural piece is needed to solve problems like
NAT, spam, SIP DoS, etc. and then decide what to call it (I've called it an Edge
Proxy, but that's subject to change).
> 
> From: Drage, Keith (Keith) [mailto:drage <at> lucent.com] 
> Sent: Tuesday, March 01, 2005 8:05 AM
> To: 'Medhavi Bhatia'; sipping <at> ietf.org
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
> 
>  
> 
> I don't think we can go in this direction.
> 
>  
> 
> There is currently 2 core SIP entities defined, UA and proxy. They have
> rigorous definitions with state machines and defined handling of
> various
> header and message bodies. 
> 
>  
> 
> If your entity is conformant to RFC 3261 UA functionality, then call it
> a UA
> (or a B2BUA).
> 
>  
> 
> If your entity is conformant to RFC 3261 proxy functionality, then call
> it a
> proxy.
> 
>  
> 
> If your entity is neither, then do not call it a UA or a proxy, or even
> nearly a UA a proxy. Further, if you need it to be standardised, it
> needs
> the same rigorous definitions that are already given in RFC 3261 to UA
> and
> proxy. Additionally, in defining such a new role (Paul's "neither fish
> nor
> foul" entity), the impact on backward compatibility with the existing
> RFC
> 3261 entities needs to be fully investigated. You cannot avoid these
> issues
> just be calling it "nearly a proxy".
> 
>  
> 
> We still however seem to be getting bogged down in discussions of how
> we
> implement these things, rather than the discussion proceeding in
> identifying
> the functions that need to be supported, and why existing SIP roles
> cannot
> perform these functions. We need that discussion to have completed
> before
> someone can start inventing a new SIP role.
> 
>  
> 
> regards
> 
>  
> 
> Keith
> 
> 

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

1	October 2012
1	July 2012
10	December 2011
8	November 2011
8	October 2011
3	September 2011
1	July 2011
2	June 2011
9	May 2011
5	April 2011
5	March 2011
2	February 2011
12	January 2011
17	December 2010
9	October 2010
3	September 2010
11	August 2010
1	July 2010
13	June 2010
19	May 2010
143	April 2010
25	March 2010
19	February 2010
26	January 2010
2	December 2009
2	October 2009
2	September 2009
10	August 2009
27	July 2009
4	June 2009
6	May 2009
143	April 2009
362	March 2009
240	February 2009
44	January 2009
63	December 2008
109	November 2008
151	October 2008
70	September 2008
103	August 2008
186	July 2008
117	June 2008
191	May 2008
107	April 2008
117	March 2008
268	February 2008
52	January 2008
72	December 2007
228	November 2007
99	October 2007
94	September 2007
130	August 2007
295	July 2007
197	June 2007
208	May 2007
252	April 2007
433	March 2007
258	February 2007
107	January 2007
77	December 2006
284	November 2006
200	October 2006
124	September 2006
180	August 2006
434	July 2006
232	June 2006
146	May 2006
163	April 2006
383	March 2006
193	February 2006
134	January 2006
50	December 2005
323	November 2005
354	October 2005
92	September 2005
168	August 2005
368	July 2005
161	June 2005
92	May 2005
161	April 2005
383	March 2005
476	February 2005
111	January 2005
75	December 2004
161	November 2004
136	October 2004
59	September 2004
75	August 2004
223	July 2004
64	June 2004
94	May 2004
87	April 2004
269	March 2004
349	February 2004
40	January 2004
95	December 2003
173	November 2003
135	October 2003
82	September 2003
187	August 2003
308	July 2003
260	June 2003
115	May 2003
161	April 2003
293	March 2003
175	February 2003
225	January 2003
228	December 2002
351	November 2002
160	October 2002
221	September 2002
252	August 2002
213	July 2002
216	June 2002
281	May 2002
268	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31