Subject: RE: [Speermint] NATs and Firewalls

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 5 Apr 2006 11:24:57 -0400

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.

> -----Original Message-----
> From: Peter Macaulay [mailto:[email-masked]]
> Sent: Wednesday, April 05, 2006 9:59 AM
> To: Drage, Keith (Keith); [email-masked]
> Subject: RE: [Speermint] NATs and Firewalls
> 
> Agree.  Let's avoid the term "SBC" in the speermint area.  We don't
> need the history lesson and the term is still evolving.  I just
finished
> a Skype call and did not use a SBC to peer with my one in 6 million
users.
> 
> Yes, let's just define the requirements ... Edge Proxy, NAPT, Media
Proxy,
> Security Firewall and NAT/firewall traversal.
> 
> /PETER MACAULAY
> 
> At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote:
> >And to support Richard on this.
> >
> >Please avoid using the term "SBC" in the speermint area. Please
> >clearly identify the function of these supposed wonder boxes that
> >you are addressing as an area of concern or advantage. Therefore if
> >you mean NAT, say NAT, if you mean firewall, say firewall, if you
> >mean something else, say so. These boxes contain so many features
> >(in the widest sense of the word) that in the absence of specific
> >information we get lost.
> >
> >regards
> >
> >Keith
> >
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[email-masked]]
> > > Sent: 04 April 2006 18:15
> > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
> > > [email-masked]
> > > Subject: [Speermint] NATs and Firewalls
> > >
> > >
> > > I think some people out there either do not understand
> > > the difference between NATs and firewalls or are starting
> > > to believe their own propaganda
> > >
> > > NATs are NATs and firewalls are firewalls
> > >
> > > The worst misconception here is that a NAT is for providing
> > > you security
> > > against the bad Internet
> > >
> > > Private adress spaces have been introduced to save a scarce
ressource
> > > (or what some believed are a scarce ressource at some point of
time)
> > >
> > > You can live very safe behind a properly configured firewall
> > > using only
> > > public IP adresses.
> > >
> > > The basic idea of IPv6 was to give every device on earth and also
> > > within the solar system a unique public IP address
> > >
> > > But the fake security of NATs was already in the minds of
> > > most people, that the first things that were implemented
> > > in IPv6 where NATs for IPv6, which is a perversion
> > >
> > > Geoff Huston had once a nice eleborate on this in an IETF paper
> > >
> > > Richard
> > >
> > > ________________________________
> > >
> > > Von: Hadriel Kaplan [mailto:[email-masked]]
> > > Gesendet: Di 04.04.2006 18:22
> > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';
> > > [email-masked]
> > > Betreff: RE: [Speermint] Reachability
> > >
> > >
> > >
> > > Hi Richard,
> > > And here we get to the fun stuff.  :)
> > >
> > > The idea of every serving proxy/registrar/sip-node needing to
> > > be publicly
> > > addressable is neither an Internet requirement, nor a
> > > requirement of the
> > > IETF.  Entire working groups in the IETF concern themselves
> > > with allowing,
> > > enabling, and inter-working private address spaces and VPNs.
> > > What's missing
> > > is how to join them at the application and transport layer, when
that
> > > application layer embeds addressing in itself.
> > >
> > > Most consumers on the planet Earth are in private address
> > > spaces at this
> > > point I think (i.e., 192.168.x.x), and many Enterprises are
> > > as well.  Entire
> > > networks in some countries are privately addressed, yet they
> > > are members of,
> > > and use, the Internet.  There are also now 2 disjoint address
> > > groups defined
> > > by the IETF, as you know: IPv4 and IPv6.  There are
> > > mechanisms to try to
> > > provide interoperation/migration support for them, but that
typically
> > > requires intermediaries.
> > >
> > > So I agree with you there needs to be an entity providing an
> > > ingress (and
> > > egress) point(s), either on the public network for it to be
> > > public, or for
> > > it to cross into another private address domain.  For this
> > > WG's purpose, I
> > > recommend we allow either model to work, as well as the model
> > > of the private
> > > going to public (and vice-versa) so long as the peering
> > > element of both
> > > sides are in the same public or private space.
> > >
> > > -Hadriel
> > >
> > >
> > > > -----Original Message-----
> > > > From: Stastny Richard [mailto:[email-masked]]
> > > > Sent: Tuesday, April 04, 2006 9:55 AM
> > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan;
> > > [email-masked]
> > > > Subject: Re: [Speermint] Reachability
> > > >
> > > > >The conclusion here -- every endpoint and every serving
> > > proxy/registrar
> > > > >needs to be publicly addressable.
> > > >
> > > > This was my basic assumption, and I seemed not so clear to
> > > everybody.
> > > > This was also why I had a problem with Sohel's presentation
> > > at the IETF,
> > > > because I did not see any public adressable entities AT ALL.
> > > >
> > > > For the avoidance of doubt: I have no problem if the same
peering
> > > > principles we develop here are used between some entities
> > > in a private
> > > > network,
> > > > but it is not out task to consider this separately. Because
> > > if it works
> > > > on the Internet, it also works in a private network
> > > (extranet in this
> > > > case)
> > > > (see DNS). this private network may even use public IP
> > > adresses, but if
> > > > the
> > > > are not routable from the public Internet, they are could as
well be
> > > > private
> > > > (example IPX)
> > > >
> > > > What never can work is a peering between one entity on the
> > > public network
> > > > and one on a private network. The private entities need at
> > > least to have
> > > > one
> > > > ingress element on the public network
> > > >
> > > > Richard
> > > >
> > > > ________________________________
> > > >
> > > > Von: Patrick Melampy [mailto:[email-masked]]
> > > > Gesendet: Di 04.04.2006 15:29
> > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; [email-masked]
> > > > Betreff: RE: [Speermint] Reachability
> > > >
> > > >
> > > >
> > > > Reinaldo -- I agree with your assertions.
> > > >
> > > > But I want to ensure everybody understands what your really
> > > saying here.
> > > >
> > > >   Before somebody mentions it...for a UA behind a NAT to be
> > > reachable,
> > > >   he/she needs a public NAT binding so that a session
> > > _initiated_ from the
> > > >   public side can be made to him/her.
> > > >
> > > > This means that for carrier to carrier peering models, each
> > > and every
> > > > customer of every carrier that wants to inter-connect needs
> > > to have a
> > > > 'public NAT binding'.
> > > >
> > > > I believe by extension, this means that a serving
> > > proxy/registrar for the
> > > > target of a communication must ALSO have either a public
> > > address or a
> > > > public
> > > > NAT binding.
> > > >
> > > > The conclusion here -- every endpoint and every serving
> > > proxy/registrar
> > > > needs to be publicly addressable.
> > > >
> > > > Am I correct?
> > > > -----Original Message-----
> > > > From: Reinaldo Penno [mailto:[email-masked]]
> > > > Sent: Tuesday, April 04, 2006 5:29 AM
> > > > To: Hadriel Kaplan; [email-masked]
> > > > Subject: RE: [Speermint] Reachability
> > > >
> > > > Hello Hadriel,
> > > >
> > > > Comment inline....
> > > >
> > > > > -----Original Message-----
> > > > > From: Hadriel Kaplan [mailto:[email-masked]]
> > > > > Sent: Monday, April 03, 2006 11:01 PM
> > > > > To: Reinaldo Penno; [email-masked]
> > > > > Subject: RE: [Speermint] Reachability
> > > > >
> > > > > Hi Reinaldo,
> > > > > Comments inline...
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Reinaldo Penno [mailto:[email-masked]]
> > > > > >
> > > > > > Maybe I'm missing something, but given that this workgroup
is
> > > > interested
> > > > > > only in call routing (E.164 is out of scope), do we
> > > really need to
> > > > care
> > > > > > about that? An AoR in the end will be translated to an
> > > IP address,
> > > > and
> > > > > > IP addresses have a very good definition of public and
> > > private (in
> > > > IPv4
> > > > > > and IPv6).
> > > > >
> > > > > I don't understand fully what you mean.  An AoR is only fully
> > > > "translated"
> > > > > to an IP Address (and really to a contact URI) by the
> > > AoR's domain.
> > > > So
> > > > > what
> > > > > you're saying is if the AoR's user-part represents a
> > > consumer behind a
> > > > > home
> > > > > NAT (a private IP), then it is a private AoR; but for
> > > those consumers
> > > > who
> > > > > don't use home-NATs then it's a public AoR?
> > > > [[Reinaldo]]
> > > >
> > > > Hello,
> > > >
> > > > Actually I'm trying to understand the whole purpose of the
> > > discussion,
> > > > that's why I gave that example. I was trying to understand why
it
> > > > matters, before getting knee deep into the classification.
> > > Can someone
> > > > refresh that for me?
> > > >
> > > > So, if SIP peering is going to get woven into the fabric of the
> > > > internet, the rules for domains names, DNS resolution, private
vs.
> > > > public IP address, etc should apply, right?
> > > >
> > > > I believe the current model of host to host or email
> > > communication is
> > > > not different for SIP. We could have the following main
> > > > situations...(correct me where I'm wrong).
> > > >
> > > > 1) The AoR (just like a traditional domain name or email),
> > > in the end
> > > > will get resolved into an IP address. Then there are only two
> > > > situations.
> > > >
> > > >    a) the IP address is private (RFC 1918).
> > > >
> > > >    This means the SIP endpoint is unreachable unless you
> > > are also in the
> > > > same private network. Actually I believe a private IP address
cannot
> > > > even be provisioned in a public DNS.
> > > >
> > > >    Before somebody mentions it...for a UA behind a NAT to
> > > be reachable,
> > > > he/she needs a public NAT binding so that a session
> > > _initiated_ from the
> > > > public side can be made to him/her.
> > > >
> > > >    b) the IP address is public.
> > > >
> > > >    The SIP endpoint is theoretically reachable.
> > > >
> > > > 2) The AoR cannot get translated. Again, just like the
> > > Internet we have
> > > > today, this means the domain name/user is private, does not
> > > exist, etc
> > > >
> > > > All this has been happening okay with just a few basic
> > > rules. If an AoR
> > > > is very similar to an email address, why it would not work with
the
> > > > current infrastructure/definitions?
> > > >
> > > > If somebody says that they have a "private" email address or
domain
> > > > name, what is your interpretation of that?
> > > >
> > > > Regards,
> > > >
> > > > Reinaldo
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  And if the AoR gets
> > > > > translated
> > > > > into an IP by a registrar inside a private IP subnet, and
> > > somehow it
> > > > later
> > > > > gets translated into the public IP address space, that's
> > > also private
> > > > > because the AoR was translated to a private IP originally?
> > > > >
> > > > > Or maybe you mean what the domain part of the AoR resolves to?
> > > > >
> > > > > > For you to be "SIP reachable", you need to be IP
> > > reachable first,
> > > > let's
> > > > > > not forget about that. And if you are IP reachable, you
could
> > > > > > potentially be SIP reachable by registering to some
> > > free SIP service
> > > > (or
> > > > > > the SIP "domain" above you in the hierarchy...if this was
the
> > > > email/DNS
> > > > > > model).
> > > > >
> > > > > Actually, to be very specific ultimate target of the AoR
> > > can be "sip
> > > > > reachable" but not IP reachable.  But I think for now we
> > > should ignore
> > > > the
> > > > > implications of that, unless it becomes a problem.
> > > > >
> > > > > -hadriel
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > >
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> >
> >_______________________________________________
> >Speermint mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> --
> 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 12:50:47 -0400

Hi Medhavi,
I must say that is a very interesting statement for you to make.  ;)

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.  

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.

> From: Medhavi Bhatia [mailto:[email-masked]]
> Sent: Wednesday, April 05, 2006 11:25 AM
> To: Peter Macaulay; Drage, Keith (Keith); [email-masked]