Subject: RE: [Speermint] NATs and Firewalls

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 5 Apr 2006 15:21:02 -0400

Hi Hadriel,

See below.

> Hi Medhavi,
> I must say that is a very interesting statement for you to make.  ;)
> 
I presume you are talking about "filling the hole" statement? 

I think there is a vast deal of difference between a requirement and the
implementation. First, most SBCs today look like "point solutions"
(sometimes unattractive but allowed - holes) for "point" requirements.
Second, there is much more awareness and long term vision amongst
service providers now than a few years back. For example, there is a
good deal of understanding of interconnects in general and how security
should be implemented across interconnects in a service agnostic manner
(compare with: block this header, change this etc etc). Solutions are
looking more cleaner, but the existing installed base may ultimately
slow down the opening of networks to new services or other networks.

> Of course boxes and behaviors evolve.  But from my perspective,
vendors
> don't do things because they want to or a standard tells them to.
They do
> it because their customers want them to.  If they don't do what the
> customers want, they get replaced with a box that will.  This is the
> fundamental difficulty with mandating how customers should deploy and
use
> equipment, in a use-agnostic/universal standards forum.
> 

They key is to understand what the right questions and requirements are.
If the customer is not asking them, the vendors should.

More flames welcome ... :) I need a spearmint...

-Medhavi.

> One can either look at what is done today for legitimate,
customer-valued
> reasons, or one can look at it as "filling a hole".  I prefer the
former.
> People thought home-NATs and firewalls were just filling a hole and
would go
> away.  :)
> 
> Regardless, I think this can be accomplished in the IETF if we stick
to BCPs
> which are as broadly applicable as possible, while meeting the
requirements.
> I agree with you the requirements come first, and that is what we
should be
> discussing.  One of those requirements, IMO, is joining disparate L3
> domains, which is a different issue than joining administrative
domains (if
> by administrative you mean SIP domains).  Do you agree?
> 
> Cheers,
> -hadriel
> p.s. that was not meant as a flame whatsoever - simply expressing a
> different viewpoint.
> 
> 
> > -----Original Message-----
> > From: Medhavi Bhatia [mailto:[email-masked]]
> > Sent: Wednesday, April 05, 2006 11:25 AM
> > To: Peter Macaulay; Drage, Keith (Keith); [email-masked]
> > Subject: RE: [Speermint] NATs and Firewalls
> >
> > I'd agree. Lets focus on requirements of peering based on SIP
> > RFCs/drafts, location and address translation mechanisms. The only
> > things which impact any sort of architecture are the administrative
> > domains, P2P domains and federations where subscribers are.
> >
> > As far as the discussion on SBCs, we have had a lengthy one in
SIPPING.
> > It would be fair to say (and I may get flamed for this) that the
reason
> > where we are with SBCs today is primarily because some service
providers
> > were doing "stuff" differently with SIP. SBCs simply capitalized on
open
> > holes in requirements. This will go away with time with more
> > competition, open networks (job of speermint?) and open solutions
from
> > IETF. SBCs will change (or follow the money as some would say...).
> >
> > We need to look forward. SBCs and other infrastructure equipment
vendors
> > (Edge proxies, core proxies etc) will follow these requirements. We
must
> > take care however that we get the right set of SP requirements and
form
> > the right solution.
> >
> > -Medhavi.
> >
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date:
4/4/2006

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 5 Apr 2006 17:03:46 -0400

Hi Medhavi,
Yes I said interesting "filling the hole" statement, because I thought your
company also makes SBCs.  :)  (I mean that in a good way, BTW)
But I don't mean to tread too deeply into marketing or business views.

I think what may be the issue is our definition of SBCs may simply not be
the same.  Maybe you feel all the functions of modern SBCs are all
implemented in a single physical box, which is not the case from my view at
all.  The functions can be broken up, or not.  It does not matter from the
context of this working group, because the peering partner is a single
logical entity and it's the requirements that must be covered, not the
implementations meeting those requirements. (as pointed out to me earlier!
:)  My only point relative to what should be "required", is applicability to
as broad a spectrum of providers as possible, where covering the case of L3
VPNs is probably the broadest approach, and within the IETF's domain.

Or maybe you feel the definition of "SBC" _requires_ media relaying
somewhere?  That is not the case for any of the current physical
implementations of SBCs that I know of in the service-provider market.  It
happens to be that many providers enable them to do that, for many reasons
way beyond "point" requirements.  For example, I consider media-relaying for
the purpose of hosted-nat-traversal a "point" requirement.  Someday it will
fix itself.  But that's not why many providers relay media, and certainly
not in peering applications; and some providers don't relay media with their
SBCs. 

Regardless, in my view even if the SBC does not relay media it's still an
SBC if it performs other functions related to security, inter-working,
policies, etc.  Some of those functions are described in
draft-camarillo-sipping-sbc-funcs-03.txt, which I believe you helped author.
Clearly at some point as you remove those functions it ends up being just a
proxy.  But since a large group of providers appear to want some or all of
those functions (and more) today, at peering points, then a peering BCP for
peering providers would be most successful if it "worked" within the
constraints of those wants while providing BCPs to enable new services or
applications.  

I think the simplest way to do it is to simply also cover the case of L3
VPNs peering with each other.  Do you disagree with that?  Any "services" or
applications which cannot be met by peering L3 VPNs, may be documented as
such in the BCPs, as far as I care.

That's not to say things won't change.  Whether SBCs continue to perform
their role, or all their functions, for ever or not: I don't have a crystal
ball. (else I would be in Kauai right now... ;)

Cheers,
-hadriel

As always, these are the views of me personally and not necessarily those of
my company, in case anyone forgot.

> Sent: Wednesday, April 05, 2006 3:21 PM
> To: Hadriel Kaplan; [email-masked]

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 5 Apr 2006 18:55:02 -0400

Hmmm...
Sorry for going down that rat-hole.

Let me re-focus the question to a requirements topic:
I think the we should also cover the case of L3 VPN peering with providers
in the public Internet.  As others have pointed out, this may not need any
special attention.  
Does anyone disagree with that?  

Any "services" or applications which cannot be met by peering L3 VPNs, may
be documented as such in the BCPs, as far as I'm concerned.

-hadriel

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, April 05, 2006 5:04 PM
> To: 'Medhavi Bhatia'; [email-masked]
> Yes I said interesting "filling the hole" statement, because 
> I thought your company also makes SBCs.  :)  (I mean that in 
> a good way, BTW) But I don't mean to tread too deeply into 
> marketing or business views.
> 
> I think what may be the issue is our definition of SBCs may 
> simply not be the same.  Maybe you feel all the functions of 
> modern SBCs are all implemented in a single physical box, 
> which is not the case from my view at all.  The functions can 
> be broken up, or not.  It does not matter from the context of 
> this working group, because the peering partner is a single 
> logical entity and it's the requirements that must be 
> covered, not the implementations meeting those requirements. 
> (as pointed out to me earlier!
> :)  My only point relative to what should be "required", is 
> applicability to as broad a spectrum of providers as 
> possible, where covering the case of L3 VPNs is probably the 
> broadest approach, and within the IETF's domain.
> 
> Or maybe you feel the definition of "SBC" _requires_ media 
> relaying somewhere?  That is not the case for any of the 
> current physical implementations of SBCs that I know of in 
> the service-provider market.  It happens to be that many 
> providers enable them to do that, for many reasons way beyond 
> "point" requirements.  For example, I consider media-relaying 
> for the purpose of hosted-nat-traversal a "point" 
> requirement.  Someday it will fix itself.  But that's not why 
> many providers relay media, and certainly not in peering 
> applications; and some providers don't relay media with their SBCs. 
> 
> Regardless, in my view even if the SBC does not relay media 
> it's still an SBC if it performs other functions related to 
> security, inter-working, policies, etc.  Some of those 
> functions are described in 
> Clearly at some point as you remove those functions it ends 
> up being just a proxy.  But since a large group of providers 
> appear to want some or all of those functions (and more) 
> today, at peering points, then a peering BCP for peering 
> providers would be most successful if it "worked" within the 
> constraints of those wants while providing BCPs to enable new 
> services or applications.  
> 
> I think the simplest way to do it is to simply also cover the 
> case of L3 VPNs peering with each other.  Do you disagree 
> with that?  Any "services" or applications which cannot be 
> met by peering L3 VPNs, may be documented as such in the 
> BCPs, as far as I care.
> 
> That's not to say things won't change.  Whether SBCs continue 
> to perform their role, or all their functions, for ever or 
> not: I don't have a crystal ball. (else I would be in Kauai 
> right now... ;)
> 
> Cheers,
> -hadriel
> 
> As always, these are the views of me personally and not 
> necessarily those of my company, in case anyone forgot.
> 
> 
> > I think there is a vast deal of difference between a 
> requirement and 
> > the implementation. First, most SBCs today look like "point 
> solutions"
> > good deal of understanding of interconnects in general and how 
> > security should be implemented across interconnects in a service 
> > agnostic manner (compare with: block this header, change this etc 
> > etc). Solutions are looking more cleaner, but the existing 
> installed 
> > base may ultimately slow down the opening of networks to 
> new services or other networks.
> > 
> > 
> > > > things which impact any sort of architecture are the 
> > > > administrative domains, P2P domains and federations 
> where subscribers are.
> > > >
> > > > were doing "stuff" differently with SIP. SBCs simply 
> capitalized 
> > > > on
> > open
> > > > (Edge proxies, core proxies etc) will follow these 
> requirements. 
> > > > We
> > must