RE: [Speermint] NATs and Firewalls

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

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

 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[e-mail]] 
> Sent: Wednesday, April 05, 2006 5:04 PM
> To: 'Medhavi Bhatia'; [e-mail]
> Subject: RE: [Speermint] NATs and Firewalls
> 
> 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
> 


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