[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

On Mar 24, 2010, at 2:49 PM, William Herrin wrote:

> On Wed, Mar 24, 2010 at 4:25 PM, Owen DeLong <owen at delong.com> wrote:
>> On Mar 24, 2010, at 1:03 PM, William Herrin wrote:
>>> A NAT firewall is a door with a pneumatic closer, a prox card reader
>>> and a pin code. This latter is less vulnerable to attack: stealing or
>>> duplicating the prox card is as hard or harder than picking a lock and
>>> even once you have the card, you still need the matching pin code for
>>> entry.
>> 
>> No.  A NAT firewall is a door with a lock and a deadbolt at best unless
>> rules must be expressed in terms of entry/exit zone in addition to
>> source/destination address.
> 
> Owen,
> 
> Believe it or not, I picked the door analogies deliberately.
> 
> Adding a door with a key is like adding a firewall. You can no walk
> packets freely in and out of the network.
> 
> The addition of a "pneumatic closer" is consistent with any stateful
> firewall. Unlike a basic packet filter, the stateful firewall pulls
> the door closed behind the permitted transport sessions, denying other
> packets.
> 
OK, I'll give you stateful = pneumatic.

> Adding a pin pad is consistent with adding any form of NAT. A mistake
> which causes bare routing or any subset of it has to somehow also use
> the right translation code.
> 
Not really, or, at least not any more so that requiring rulesets to be expressed
in forms which include source and destination security zones as well as IP
addresses.

> Switching from a key to a prox card is consistent with
> address-overloaded NAT specifically. Just as the prox card facilitates
> maintaining physical security a little better than keeping track of
> metal keys, address overloading saves you from a few more oopses that
> would cause mere nat to accept and translate connections where the
> single-to-many nature of address overloading can at worst expose a
> single host on a given port.
> 
Nope.  I still don't buy this argument. The prox card allows you to know
who opened the door. It doesn't tell you anything more about who went
through the door.  NAT does nothing of the sort.  It doesn't tell you any
more about who opened the door.  It doesn't tell you anything more about
who went through the door. In fact, it arguably tells you less, or, at least
it tells anyone that one of your internal hosts attacks less.  It requires the
(accidental or deliberate) opening of one more lock, just like a deadbolt.


> 
>>> And I will suggest that for any given firewall configuration, the
>>> otherwise-identical configuration that also does NAT has implemented
>>> stronger security.
>> 
>> Nope... I provided an example earlier where NAT actually reduced security.
> 
> No, you provided an example where you boldly but mistakenly claimed
> that NAT reduced security.
> 
My example was unrefuted. My above example shows that while NAT may
offer an additional deadbolt for the site deploying NAT, it certainly can reduce
security for sites which are attacked by the hosts you are protecting. Perhaps
that is not your concern, since you are still choosing to remain in support
of this toxic-polluter model of networking, but, some of us have to look at
the whole picture, not just the benefits of individual sites.

> 
> On Wed, Mar 24, 2010 at 4:47 PM, Michael K. Smith - Adhost
> <mksmith at adhost.com> wrote:
>> The point is that proving NAT is valuable based solely
>> upon its perceived benefits for inbound traffic doesn't address
>> the issue with all its complexities.
> 
> Hi Mike,
> 
> No argument.
> 
> 
>> Actually, RFC 1631 says that NAT is for addressing
>> address conservation specifically.
> 
> RFC 1631 spoke to the then mostly theoretical concept of NAT as
> discussed inside the IETF circa 1993-4. The basic idea was a
> one-to-one mapping of internal to external addresses. Only those very
> few internal hosts who needed to talk to the Internet would claim an
> external address and the external address space was flat, requiring no
> per-lan reserve slack and no subnet-oriented reserved IPs.
> 
Ummm... FAIL.  If RFC 1631 had not contemplated 1:many NAT, then,
there would have been no address conservation aspect to it, as 1:1
NAT does not conserve addresses, it is, at best, a no-op in the number
of public addresses consumed, and, could actually double the number
of public addresses consumed if the numbers on both sides of the NAT
are public addresses.

> In other words, it was almost exactly nothing like modern
> address-overloaded NAT as found in any commodity "DSL router."
> 
Actually, it was almost EXACTLY what is currently deployed in almost
any commodity DSL router.

> As modern NAT evolved out of transparent TCP proxies (which had
> evolved from the bastion host proxy firewalls), there were a number of
> folks who complained it should be called PAT (port address
> translation) because it wasn't really NAT. In a sense, they're
> right... the NAT name was hijacked by the new, vastly more popular
> process even though it bore only a passing resemblance to the old.
> 
While you continue to cling to this revisionist history of NAT/PAT, it
continues to remain false.  I remember talking extensively on the subject
with John Mayes back when he was starting Translation.com (also
known as Network Address Translation, Inc.) which was later purchased
by Cisco and rebranded into a little known product called a "PIX"
Firewall.

NAT/PAT grew out of NAT as an extension to Stateful Inspection Firewalls
which were then being touted as a superior solution to the TCP proxies
which often failed to be sufficiently transparent.

> My point is: RFC 1631 describes an obsolete process that has limited
> bearing here.
> 
I think someone should re-read RFC-1631. It's not as far out of date as
you appear to think.

Owen