Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 11 Oct 2005 11:13:34 -0400

Henry,

Since this point relies on how one assumes the average person will adopt
new technology and what they do with the old technology when migrating
from one to the other, I'd prefer to leave this "ghost" buried.  This
seems rather a belief of whatever religion one subscribes to.  I prefer
to leave this to be answered by the market as the proof will be in the
adoption rate.  We don't need to discuss that further here.

Mike

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Tuesday, October 11, 2005 10:57 AM
> To: Michael Hammer (mhammer); Paul Kyzivat (pkyzivat); 'Elwell, John'
> Cc: 'sipping'
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> Mike,
> 
> >It is a backward compatibility issue to be able to interoperate with 
> >the
> PSTN.  
> >If we ever expect SIP to become dominant we need to overcome 
> that entropy.
> 
> This statement was the object of many arguments on the list 
> and not everyone agrees with it. Actually, if I remember 
> well, a chair person stated an opposing view and it was also 
> clearly stated in recent Internet Drafts.
> 
> Can someone recall what it was that "SIP services are not an 
> emulation of the PSTN"?
> 
> Sorry, but this ghost seems to come up more frequent than Halloween.
> 
> Thanks, Henry
> 
> 
>  
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Hammer 
> (mhammer)
> Sent: Tuesday, October 11, 2005 9:18 AM
> To: Paul Kyzivat (pkyzivat); Elwell, John
> Cc: sipping
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> Paul, John,
> 
> We like to say that SIP can be feature agnostic, but if we 
> can't do a feature that is widely used, then that is a 
> problem.  So, I think the real question is not what must be 
> supported, but how it is to be supported.
> 
> Although the features in the PSTN are fairly well understood, 
> in many cases they are just describing desired behaviors of the call
> (forwarding) based on the state of users at the time the call 
> arrives (not registered, no answer, busy).  I don't think 
> those are unique to the PSTN as SIP users can be in the same 
> basic states.  It only gets complicated when SIP can produce 
> more possible states.  So, I think the issue here is not so 
> much defining features as it is reacting to state in the SIP 
> network and documenting that state in the signaling.
> 
> It is a backward compatibility issue to be able to 
> interoperate with the PSTN.  If we ever expect SIP to become 
> dominant we need to overcome that entropy.  I think that is a 
> burden we will just have to bear.  It is also a backward 
> compatibility issue to work with various generations of SIP 
> devices.  that is another fact of life we have to deal with.
> 
> I personally like the idea of keeping the redirection reason 
> tied to the redirecting URI added to the History-Info stack, 
> but that doesn't help those UACs that don't understand 
> History-Info.  In the end, the perfect may be the enemy of 
> the good.  Hopefully, we can converge quickly on an answer.
> 
> Mike
> 

_______________________________________________
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, 11 Oct 2005 10:45:53 -0500

> seems rather a belief of whatever religion one subscribes to
> We don't need to discuss that further here.

Then please don't make such statements any more on the list.

Thanks, Henry

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2005 10:14 AM
To: [email-masked]; Paul Kyzivat (pkyzivat); Elwell, John
Cc: sipping
Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

Henry,

Mike

---

From: [email-masked]
Date: Thu, 20 Oct 2005 17:34:10 -0500

The I-D "SIP-Unfriendly Functions in Current
Communication Architectures"
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-sbc-funcs-02.txt

 is both very timely and an excellent piece of work.

The section "4.Security Considerations" needs however to go in some more
detail. For example:

- If the SBC is compromised (it happens on the Internet) then what are the
vulnerabilities for (1) SIP signaling and (2) RTP media streams?

- What possible attacks and vulnerabilities are there for the users and for
the operator of the SBC? (DOS, SPIT, impersonation, telemarketing, MIM,
theft of service, traffic monitoring, privacy, collecting internal IP
addresses, other - if all this may indeed apply.) What are the techniques
for securing an SBC, besides obscurity?

- How are the above vulnerabilities affected from keeping call state in the
SBC?

Maybe a section on interoperability could also be added. If two networks use
SBCs from different vendors, how will the interoperability be tested with
two SBCs in the path? See also the transparency criteria from Dean Willis.

Congratulations again for dealing with this difficult topic with such
clarity!

Thanks, Henry

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 20 Oct 2005 23:33:19 -0400

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)

> 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

---

From: [email-masked]
Date: Fri, 21 Oct 2005 08:57:13 -0500

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:[email-masked]] 
Sent: Thursday, October 20, 2005 10:33 PM
To: [email-masked]
Cc: sipping
Subject: Re: [Sipping] draft-camarillo-sipping-sbc-funcs-02.txt

regds
arjun
--
Arjun Roychowdhury

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 21 Oct 2005 13:34:24 -0400

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.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Sent: Friday, October 21, 2005 9:57 AM
> To: 'Arjun Roychowdhury'
> Cc: 'sipping'
> Subject: RE: [Sipping] draft-camarillo-sipping-sbc-funcs-02.txt
> 
> Arjun,
>

---

From: [email-masked]
Date: Fri, 21 Oct 2005 12:51:55 -0500

> (Consider IMS/TISPAN border elements for example)

It can be argued IMS/TISPAN are much more evil than SBC, but not on this
list :-) 

Thanks, Henry

-----Original Message-----
From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Friday, October 21, 2005 12:34 PM
To: [email-masked]; 'Arjun Roychowdhury'
Cc: 'sipping'
Subject: RE: [Sipping] draft-camarillo-sipping-sbc-funcs-02.txt

BCP track?

-Medhavi.

Of

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 21 Oct 2005 11:47:51 -0700

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

SBCs are a Best Current Practice?

-d

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 21 Oct 2005 14:29:59 -0500

> SBCs are a Best Current Practice?

Sorry, I meant the content: "SIP-Unfriendly Functions" for a BCP.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan Wing
Sent: Friday, October 21, 2005 1:48 PM
To: [email-masked]; 'Arjun Roychowdhury'
Cc: 'sipping'
Subject: RE: [Sipping] draft-camarillo-sipping-sbc-funcs-02.txt

-d

---

From: David R Oran <[email-masked]>
Date: Sat, 22 Oct 2005 11:40:53 -0400

> SBCs are a Best Current Practice?
How about just overloading the acronym to be "Breaks Current Practice".

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 29 Oct 2005 21:46:22 +0300

Hi,

 > It should definitely not

if you read the lattest version of the draft, you will see that it 
focuses on *functions* that break SIP somehow. Those functions may, or 
may not, be performed by an SBC. The draft is not intended to be SBC 
specific.

Cheers,

Gonzalo