[171084] in North American Network Operators' Group
Re: Requirements for IPv6 Firewalls
daemon@ATHENA.MIT.EDU (Matthew Kaufman)
Thu Apr 17 20:51:33 2014
In-Reply-To: <alpine.OSX.2.02.1404171914320.648@brugal.local>
From: Matthew Kaufman <matthew@matthew.at>
Date: Thu, 17 Apr 2014 17:51:03 -0700
To: Brandon Ross <bross@pobox.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
While you're at it, the document can explain to admins who have been burned,=
often more than once, by the pain of re-numbering internal services at stat=
ic addresses how IPv6 without NAT will magically solve this problem.
Matthew Kaufman
(Sent from my iPhone)
> On Apr 17, 2014, at 4:20 PM, Brandon Ross <bross@pobox.com> wrote:
>=20
> On Thu, 17 Apr 2014, Sander Steffann wrote:
>=20
>>> Also, I note your draft is entitled "Requirements for IPv6 Enterprise
>>> Firewalls." Frankly, no "enterprise" firewall will be taken seriously
>>> without address-overloaded NAT. I realize that's a controversial
>>> statement in the IPv6 world but until you get past it you're basically
>>> wasting your time on a document which won't be useful to industry.
>>=20
>> I disagree. While there certainly will be organisations that want such a '=
feature' it is certainly not a requirement for every (I hope most, but I mig=
ht be optimistic) enterprises.
>=20
> And I not only agree with Sander, but would also argue for a definitive st=
atement in a document like this SPECIFICALLY to help educate the enterprise n=
etworking community on how to implement a secure border for IPv6 without the=
need for NAT. Having a document to point at that has been blessed by the I=
ETF/community is key to helping recover the end-to-end principle. Such a do=
cument may or may not be totally in scope for a "firewall" document, but sho=
uld talk about concepts like default-deny inbound traffic, stateful inspecti=
on and the use of address space that is not announced to the Internet and/or=
is completely blocked at borders for all traffic.
>=20
> Heck, we could even make it less specific to IPv6 and create a document th=
at describes these concepts and show how NAT is not necessary nor wise for I=
Pv4, either. (Yes, yes, other than address conservation.)
>=20
> --=20
> Brandon Ross Yahoo & AIM: BrandonNRo=
ss
> +1-404-635-6667 ICQ: 22694=
42
> Skype: brandonros=
s
> Schedule a meeting: http://www.doodle.com/bross
>=20
