Subject: [Speermint] Re: NATs and Firewalls

From: "Stastny Richard" <[email-masked]>
Date: Tue, 4 Apr 2006 20:12:02 +0200

>I hope you're not referring to me.

No, sorry if you got this impression
 
but I have heard this argument over and over if I asked telcos
(and these are really experts regarding IP ;-), why they implement
10.x.x.x address spaces.
 
I understand your argument about DHCP and consumer LANs,
but this "private" address spaces are not our problem here
 
Richar

________________________________

Von: Hadriel Kaplan [mailto:[email-masked]]
Gesendet: Di 04.04.2006 19:47
An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; [email-masked]
Betreff: RE: NATs and Firewalls

Hi Richard,
I hope you're not referring to me.
Who said anything about NATs providing security?  They don't, plain and
simple. 

Firewalls only provide (some) security if they can be assured they're in the
path of the data.  Such a thing is very difficult in a service-provider IP
network, because there is no constant/default route out, nor a guaranteed
route in, without severely constraining the deployment design and increasing
complexity.  Firewalls have another difficulty with SIP service specifically
for service-providers, and they provide a very false sense of security due
to them, but we need not get into that.  This is not the right forum.

There are many reasons SBCs also do NAT.  One of them is they can bridge the
private address spaces together at a transport and application level.
That's the one which is probably the most beneficial/accepted from the
IETF's perspective today, and why I prefer to stick with it. 

It is also not the case, IMHO, that consumer NATs are popular for "security"
reasons.  I think this is another popular misconception.  In my view,
consumer NATs became popular for another reason which people often ignore:
the integrated DHCP server.  Consumers know nothing of IP Addresses,
subnets, DNS servers, etc.  A NAT providing many IP Addresses was great, but
the DHCP server built in was the key, because it enabled a consumer to plug
in multiple devices without configuring anything, even for the DNS.  It's
all about achieving the goals with the least complexity for the end-user.
(of course the price level didn't hurt :)  Once those goals were reached,
the cost/pain of converting to IPv6 became difficult to justify on a global
basis. 

-hadriel

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 1:15 PM
> To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; [email-masked]
> Subject: 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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 4 Apr 2006 15:07:56 -0400

Hi Richard, comments inline...

> Sent: Tuesday, April 04, 2006 2:12 PM
> Subject: Re: NATs and Firewalls
> 
 
Ahh.  Actually, they're somewhat right from my perspective, but not for the
reasons they probably think.  It's really because of the fact they are an
Internet service-provider; so using a private address space simplifies the
security deployment architecture and avoids some common screw-ups, but it
doesn't "provide" security.  Obfuscation alone has little value, IMHO, and
is not why most SBCs obfuscate I think. 
It all depends on the attack vectors and threats you're trying to protect
against, and how.

But we probably shouldn't get into that on this list - I'm just saying we
should support the case of a private (or non-routable) address space joining
a public or another private one through the peering element(s).  It may have
no implications whatsoever on this WG's work, or it may have some.  That's
TBD.  :)

-Hadriel