RE: [Speermint] NATs and Firewalls

["Hadriel Kaplan" <[e-mail]>]

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.


> -----Original Message-----
> From: Medhavi Bhatia [mailto:[e-mail]]
> Sent: Wednesday, April 05, 2006 3:21 PM
> To: Hadriel Kaplan; [e-mail]
> Subject: RE: [Speermint] NATs and Firewalls
> 
> 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:[e-mail]]
> > > Sent: Wednesday, April 05, 2006 11:25 AM
> > > To: Peter Macaulay; Drage, Keith (Keith); [e-mail]
> > > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint