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

[Dave Piscitello <dave () corecom com>]

I'm sorry, but you are not using the term end-to-end in the correct context.

End-to-end has less do with addressing and more to do with where you put 
functionality. Read Saltzer, Reed and Clark's article on End to end 
principles in system design (ACM) or some classic articles by David 
Cheriton, et. al.

End-to-end was directed at the notion of "smart connection endpoints, 
dumb network", as opposed to a telephony model of "smart network, dumb 
endpoints (phones)".

Today, very few end user applications and connections are end-to-end 
addressed. Look at SSL VPNs. Look at many web or other application data 
centers.

We have far more "box in the middle" configurations than end-to-end 
addressable connections today, and as my respected colleague, Craig 
Melson has already stated so elegantly

"One of the great things about the perceived scarcity of IPv4
space on the Internet is that it finally forced most of the
institutions that were still using public addresses for everything
with an Ethernet port in it to implement NAT."

Almost any firewalled configuration uses IP masquerading and that's 
hugely important. Do you really think it's better to assign public 
address space behind firewalls? Do you really want everyone to know 
every IP address block your organization uses internally by querying an 
RIR?

These combined are reasons to implement IPv4 forever:-)

Having said this, I agree with much of what you say about writing an 
IPv6 firewall. Aside from writing secure code for the IPv6 kernel, a big 
chunk of the work is deciding what of the IPv6 datagram header pose 
security threats and how you intend to use or dispose of them. Vendors 
who wrote ALGs/proxies may in fact have some advantage over "intensely, 
pervasively and ecumenically stateful inspection" (aye, Cap'n).

It's not that it is hard Patrick, it's that we have hundreds of 
security vendors competing for a tiny fraction of IT budgets, so margins 
count. Few product development teams will place IPv6 implementation at 
the top of the feature list until the market matures. Currently, I would 
hesitate to even call the IPv6 market nascent (in terms of promise of 
revenue).

So we are stuck between the rock and the hard place.

Patrick M. Hausen wrote:
> Hi, wizards,
>
> On Thu, Aug 23, 2007 at 02:42:03PM -0400, Dave Piscitello wrote:
> >  Marcus, a proposal nearly identical to what you suggest was one of the first 
> >  presented at the IETF in the mid-1990s. At the time, the intelligentiaTF 
> >  poo-pooed it as not being sufficiently forward-looking and innovative. It 
> >  didn't consider 64-bit alignment. It didn't *fix* options. It didn't *fix* 
> >  QOS. It didn't accommodate IP security in a "native" manner.
> >
> >  Happily, time wounds all heels. Over a decade later, and we've bent, 
> >  twisted, tunneled, re-mapped, stretched, and NAT'd IPv4 until it does 
> >  everything IPv6 promised - and now, all IPv6 brings to the table is a bigger 
> >  field for addresses and an ungainly, unwanted and arguably unwarrantable 
> >  transition scenario.
>
> IPv6 brings back the end-to-end principle and NAT its well-deserved
> death. This alone should be enough reason to go for it.
>
> And I don't see what should be paticularly more difficult to
> implement in an IPv6 based application level gateway than in
> an IPv4 based one. Terminate both connections in a proxy process
> instead of messing with headers. Simple and effective.
>
> OK, honestly, I cannot write an "IPv6" firewall on a jug of beer
> and I don't claim I could. But some vendors got it mostly right
> for IPv4 simply by using transparent proxy processes instead
> of "deep adaptive whatever inspection".
>
> And a TCP connection carrying HTTP is a TCP connection carrying
> HTTP regardless of the layer 3 protocol. I expect the few remaining
> ALG vendors to be the first to have proper IPv6 capable solutions
> for this simple architectural reason.
>
> 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