***SPAM*** Re: IPv6 support in firewalls

[Dave Piscitello <dave () corecom com>]

Patrick, you make some valid points.

- yes, it's true that social engineering and leaks will undermine
attempts to keep internal topology details private. If someone's willing 
to leak this sort of confidential information I suspect they will reveal 
other details that put you at risk whether you are using private or 
public space.

- Yes, double NAT'ing is not a pretty thing.

- My crystal ball only says that if I'm building inter-organizational 
tunnels to connect parties outside my operational control directly to 
assets on my internal network I probably have much worse security 
problems to fret about than IP addresses. I'm not a fan of site-to-site 
VPNs and "you authenticated using IKE so welcome to my subnet" 
implementations but that takes us down another nasty rathole. IMO there 
are alternatives to admitting hosts as IP addressable peers to your 
network. However if this is the poison you choose to drink, you're right 
that having unique IP addresses makes it easier to swallow.

- I'm happy to hear a large scale IPv6 success story.

- I wish I could feel as confident about IPv6.  Nearly 14 years have 
lapsed and I confess that my perspective is jaded. I think it may be 
another 5 before we see measurable IPv6 penetration and at least a 
decade beyond of 4-to-6 and 6-to-4 tunneling (and NAT).

We will have a 20 year old protocol with little innovation and only 
unique addresses to show for our efforts. NAT may have been a cheap 
hack. Time will tell whether IPv6 is regarded as the right thing or an 
expensive hack. So I'll set a cask of beer aside and we'll revisit the 
subject again in 2012.



Patrick M. Hausen wrote:
> Hi!
>
> On Mon, Aug 27, 2007 at 01:24:54PM -0400, Dave Piscitello wrote:
>
> > > First you should not rely on NAT as a security measure, anyway,
> > > because it isn't.
> >  I advocate using every measure possible to provide security. IP masquerading 
> >  helps thwart information gathering. I would never suggest using NAT as the 
> >  only security measure. By IP masquerading, I avoid having a RIR identify the 
> >  address blocks I use internally, as they would if I were to use public 
> >  space. Explain why you feel this is wrong?
>
> I don't feel this is wrong, I think good security practice
> should be to make it unnecessary by design. The security
> of a cipher should not depend on the secrecy of the algorithm.
>
> The security of a network should not depend on the secrecy of
> the structure, because sooner or later secrets will be no longer.
>
> A bit of social engineering, a fired insider, ... holds for
> ciphers and for networks, IMHO. And I mean *should* as in
> RFC language, not as in common English ;-)
>
> > > Third, this is the _only_ way to get rid of the "net 10 considered
> > > harmful" nightmare 
> > It's only a nightmare for people who do not exercise discipline
> > in assigning addresses.
>
> OK, so please hand me a list of the RFC 1918 networks of all
> third parties that I will need to connect to in the next ten
> years. Your crystal ball seems to be working a lot better than
> mine ;-)) No insult intended, honestly, but I don't buy the
> "discipline" argument. Different enterprises need to connect
> as business dictates, possibly tomorrow. And double NATing
> and proxying makes things worse, not better.
>
> As I said, SAP is already using addresses from their RIPE assigned
> allocation for their strictly internal VPN connections to customers.
> That would be "Oracle" for you American guys ;-) Biggest German
> software company ...
>
> > I could just as easily err with public addresses and assign the 
> > same block of addresses to multiple sites.
>
> Yes you can. But then it's your fault. And if the successor of
> the successor for your former position gets it wrong, then either
> you or the first successor did not document properly.
>
> But the addresses of arbitraty peers are strictly outside of
> my control ...
>
> Uniqe addresses for every single device. You can still hide
> them behind a proxy if you feel like it. That's the additional
> benefit. You can decide which hosts to expose and which ones
> to hide. With at least a /48 assigned to every end user, there's
> plenty of maneuver room.
>
> Compare that to an IPv4 /29 for your uplink and all of a sudden a
> 7th department wants a server with port 80 exposed to the
> Internet.
>
> > > IMHO theses are the combined reasons to start over and
> > > kill NAT forever.
> >  Won't happen in my lifetime, nor my childrens' lifetime.
>
> Time will tell ;-) I won't bet more than, say, a cask of
> beer on my position, but I strongly feel like it was
> The Right Thing [tm] and NAT was a cheap hack that has
> been far too successful.
>
> Kind regards,
> Patrick M. Hausen
> Leiter Netzwerke und Sicherheit

Attachment: dave.vcf
Description:

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards