Re: Security gain from NAT: Top 5

[Jo Rhett]

On Jun 26, 2007, at 7:44 PM, Jeff Woolsey wrote:
Things sure are different now, aren't they?   I remember having a  
whole

class C from you guys for my half-dozen machines at home... That was a
while ago...


Not from me/us, and not since ARIN existed or cared about usage ;-)

Meer.net before it started operating a colocation company was a just- 
for-friends ISP business and they were given tons of IP space from  
their providers back in the mid-1990s and shared it around.  What you  
have is Verio-assigned space.


The colocation division came into being after ARIN existed and has  
always used strict allocation guidelines.


--
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550

Re: Security gain from NAT: Top 5

[Jo Rhett]

On Jun 6, 2007, at 9:43 PM, Owen DeLong wrote:

  #1 NAT advantage: it protects consumers from vendor
  lock-in.

Speaking of FUD...  NAT does nothing here that is not also  
accomplished

through the use of PI addressing


If you completely ignore the cost of routing table growth to give  
every company their own PI, sure.



  #2  NAT advantage: it protects consumers from add-on
  fees for addresses space.


More FUD.  The correct solution to this problem is to make it possible
for end users to get reasonable addresses directly from RIRs for
reasonable fees.


Reasonable is a hard word.  We've had to turn away customers who  
wanted to assign a /27 to each and every machine, without actual  
justification for more than 3 IPs per machine.  Sometimes people want  
to do insane things that aren't technically reasonable, but it's what  
they want to do.  NAT gives them that option.


--
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550

Re: Security gain from NAT: Top 5

[Joe Abley]

On 7-Jun-2007, at 02:48, Brandon Butterworth wrote:




  #1 NAT advantage: it protects consumers from vendor
  lock-in.

Speaking of FUD...  NAT does nothing here that is not also  
accomplished

through the use of PI addressing.


True, diy PI (mmm, PI) is a major reason people use it for v4 and why
they'll want something similar for v6. No internal renumbering,
ever. I can see why they choose it, even with the disadvantages

PI for everyone?


LISP! :-)

Re: Security gain from NAT: Top 5

[Brandon Butterworth]

> >   #1 NAT advantage: it protects consumers from vendor
> >   lock-in.
> >
> Speaking of FUD...  NAT does nothing here that is not also accomplished
> through the use of PI addressing.

True, diy PI (mmm, PI) is a major reason people use it for v4 and why
they'll want something similar for v6. No internal renumbering,
ever. I can see why they choose it, even with the disadvantages

PI for everyone?

brandon

Re: Security gain from NAT: Top 5

[Owen DeLong]

  #1 NAT advantage: it protects consumers from vendor
  lock-in.


Speaking of FUD...  NAT does nothing here that is not also accomplished
through the use of PI addressing.


  #2  NAT advantage: it protects consumers from add-on
  fees for addresses space.


More FUD.  The correct solution to this problem is to make it possible
for end users to get reasonable addresses directly from RIRs for
reasonable fees.


  #3  NAT advantage: it prevents upstreams from limiting
  consumers' internal address space.


Regardless of the amount of growth, do you really see the likelihood
of any household _EVER_ needing more than 65,536 subnets?
I don't even know the exact result of multiplying out 16*1024^6, but,
I'm betting you can't fill 65,536 subnets that big ever no matter how
hard you try.  So, again, I say FUD.


  #4  NAT advantage: it requires new protocols to adhere to
  the ISO seven layer model.


Quite the contrary... NAT has encouraged the development of hack upon
hack to accommodate these protocols.  Please explain to me how you
would engineer a call setup-tear-down protocol for an independent
audio stream that didn't require you to embed addresses in the payload.
Until you can solve this problem, we will have to have protocols that
break this model.  Other than from some sort of ISO purity model
(notice how popular OSI networking is today, compared to IP?), SIP
is actually a pretty clean solution to a surprisingly hard problem.
Unless you have a better alternative for the same capabilities, I'm
not buying it.  We shouldn't have to give up useful features for
architectural purity.  If the architecture can't accommodate real world
requirements, it is not the requirements that are broken.

That's sort of like saying that OSPF and BGP break the ISO layer model
because they talk about layer three addresses in layer 4-7 payload.
Heck, even ISIS is broken by that definition.  Again, I cry FUD.


  #5  NAT advantage: it does not require replacement security
  measures to protect against netscans, portscans, broadcasts
  (particularly microsoft's netbios), and other malicious
  inbound traffic.


??? This is pure FUD and patently untrue.  Example:  About the cheapest
NAT capable firewall you can buy is a Linksys WRT-54G.  If you put
real addresses on both sides of it and change a single checkbox in the
configuration GUI, you end up with a Stateful Inspection firewall that
gives you all the same security you had with the NAT, but, without the
penalties imposed by NAT.

Until you can show me a box that is more than USD 40 cheaper than
a WRT-54G that cannot have NAT turned off, again, I cry FUD.
Oh, btw, a WRT-54G sells for about USD 40 last time I bought one
brand new at Best Buy, so, that's a pretty hard metric to meet.


These are just some of the reasons why NAT is, and will continue to
be, an increasingly popular technology for much more than address
conservation.

Since each and every one of them is FUD, that is certainly the pot  
calling

the kettle black.  Unfortunately, time and again, american politics has
proven that FUD is a successful marketing tactic, so, you are probably
right, there will probably be a sufficient critical mass of ignorant  
consumers

and vendors that will buy into said FUD and avoid the real solution
in favor of continuing the abomination that is NAT and all the baggage
of STUN, difficult debugging, header mangling, address conflicts,
and the rest that tends to come with it.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: Security gain from NAT: Top 5

[Matthew Palmer]

On Wed, Jun 06, 2007 at 08:49:21PM -0700, Roger Marquis wrote:
> Problem is that NAT will not go away or even become less common in
> IPv6 networks for a number of reasons.
> 
>   #1 NAT advantage: it protects consumers from vendor
>   lock-in.
> 
> Consider the advantage of globally unique public addressing to ISPs
> and telcos.  Without NAT they have a very effective vendor lock-in.
> Want to change ISPs?  It's only as easy as reconfiguring every device
> and/or DHCP server on your internal network.  With NAT you only need
> to reconfigure a single device, sometimes not even that.

Isn't this the problem that router advertisements are meant to solve?  Do
you have operational experience which suggests that they aren't a sufficient
solution?

>   #2  NAT advantage: it protects consumers from add-on
>   fees for addresses space.
> 
> Given the 100 to 10,000% mark-ups many telcos and ISPs already charge
> for more than a /29 it should come as no surprise they would be
> opposed to NAT.

I was under the impression that each end-user of an IPv6 ISP got a /64
assigned to them when they connected.

>   #3  NAT advantage: it prevents upstreams from limiting
>   consumers' internal address space.
> 
> Even after full implementation of IPv6 the trend of technology will
> continue to require more address space.  Businesses will continue to
> grow and households will continue to acquire new IP-enabled devices.
> Without NAT consumers will be forced to request new netblocks from
> their upstream, often resulting in non-contiguous networks. Not
> surprisingly, often incurring additional fees as well.

By my calculations, the /64 of address space given to each connection will
provide about 18446744073709551616 addresses.  Is that an insufficient
quantity for the average user of an ISP?

>   #4  NAT advantage: it requires new protocols to adhere to
>   the ISO seven layer model.
> 
> H.323, SIP and other badly designed protocols imbed the local address
> in the data portion of IP packets.  This trend is somewhat discouraged
> by the layer-isolation requirements of NAT.

NAT doesn't seem to have stopped the designers of these protocols from
actually deploying their designs, though.

>   #5  NAT advantage: it does not require replacement security
>   measures to protect against netscans, portscans, broadcasts
>   (particularly microsoft's netbios), and other malicious
>   inbound traffic.
> 
> The vendors of non-NAT devices would love to have you believe that
> their stateful inspection and filtering is a good substitute for the
> inspection and filtering required by NAT devices. Problem is the
> non-NAT devices all cost more, many are less secure in their default
> configurations, and the larger rulesets they are almost always
> configured with are less security than the equivalent NAT device.

Haven't we already had this thread killed by the mailing list team today?

- Matt

-- 
If only more employers realized that people join companies, but leave
bosses. A boss should be an insulator, not a conductor or an amplifier.
-- Geoff Kinnel, in the Monastery

Re: Security gain from NAT: Top 5

[Roger Marquis]

Mark Smith wrote:

For all those people who think IPv4 NAT is quite fine, I
challenge them to submit RFCs to the IETF that resolve, without
creating worse or more even more complicated problems, the list
of problems here. All the IPv6 RFCs do ...



These RFCs clearly have an agenda: selling IPv6.  It is unfortunate
they don't feel it necessary to make a balanced presentation of the
pros and cons but instead appear to believe that spreading FUD about
NAT is an effective method of promoting IPv6.

Problem is that NAT will not go away or even become less common in
IPv6 networks for a number of reasons.

  #1 NAT advantage: it protects consumers from vendor
  lock-in.

Consider the advantage of globally unique public addressing to ISPs
and telcos.  Without NAT they have a very effective vendor lock-in.
Want to change ISPs?  It's only as easy as reconfiguring every device
and/or DHCP server on your internal network.  With NAT you only need
to reconfigure a single device, sometimes not even that.

  #2  NAT advantage: it protects consumers from add-on
  fees for addresses space.

Given the 100 to 10,000% mark-ups many telcos and ISPs already charge
for more than a /29 it should come as no surprise they would be
opposed to NAT.

  #3  NAT advantage: it prevents upstreams from limiting
  consumers' internal address space.

Even after full implementation of IPv6 the trend of technology will
continue to require more address space.  Businesses will continue to
grow and households will continue to acquire new IP-enabled devices.
Without NAT consumers will be forced to request new netblocks from
their upstream, often resulting in non-contiguous networks. Not
surprisingly, often incurring additional fees as well.

Follow the money and you'll end up with these three reasons why the
technical arguments being made against NAT in opinion pieces like
Keith Moore's (URL above) are so one sided and overtly biased.  But
there are still more reasons NAT will continue to increase in
popularity regardless of IPv6.

  #4  NAT advantage: it requires new protocols to adhere to
  the ISO seven layer model.

H.323, SIP and other badly designed protocols imbed the local address
in the data portion of IP packets.  This trend is somewhat discouraged
by the layer-isolation requirements of NAT.

  #5  NAT advantage: it does not require replacement security
  measures to protect against netscans, portscans, broadcasts
  (particularly microsoft's netbios), and other malicious
  inbound traffic.

The vendors of non-NAT devices would love to have you believe that
their stateful inspection and filtering is a good substitute for the
inspection and filtering required by NAT devices. Problem is the
non-NAT devices all cost more, many are less secure in their default
configurations, and the larger rulesets they are almost always
configured with are less security than the equivalent NAT device.

These are just some of the reasons why NAT is, and will continue to
be, an increasingly popular technology for much more than address
conservation.

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/

Dead Thread (Re: Security gain from NAT)

[alex]

I think at this point, everything that could possibly be said about NAT
and security has been said.

Unless you have something profound to add which hasn't been mentioned in
this thread before, please refrain from adding to this thread.

-Alex (for the mailing list team)

Re: Security gain from NAT

[Mark Smith]

On Wed, 6 Jun 2007 09:45:01 -0700
David Conrad <[EMAIL PROTECTED]> wrote:

> 
> On Jun 6, 2007, at 8:59 AM, Stephen Sprunk wrote:
> > The thing is, with IPv6 there's no need to do NAT.
> 
> Changing providers without renumbering your entire infrastructure.
> 
> Multi-homing without having to know or participate in BGP games.
> 
> (yes, the current PI-for-everybody allocation mindset would address  
> the first, however I have to admit I find the idea of every small  
> enterprise on the planet playing BGP games a bit ... disconcerting)
> 
> > However, NAT in v6 is not necessary, and it's still evil.
> 
> Even ignoring the two above, NAT will be a fact of life as long as  
> people who are only able to obtain IPv6 addresses and need/want to  
> communicate with the (overwhelmingly IPv4 for the foreseeable future)  
> Internet.  Might as well get used to it.  I for one welcome our new  
> NAT overlords...
>

For all those people who think IPv4 NAT is quite fine, I challenge them
to submit RFCs to the IETF that resolve, without creating worse
or more even more complicated problems, the list of problems here. All
the IPv6 RFCs do ... :

http://www.cs.utk.edu/~moore/what-nats-break.html

I've spent a number of years wondering why people seem to like NAT
(don't bother trying to convince me, my burnt stubs of fingers have
convinced me it's evil), and the only feasible conclusion I can come to
is that it is a chance to live out the "invisible man" fantasy they had
in their childhood. We've all had that fantasy I think, and we'd all
like to live it out ...

In IPv6, if you want to have a globally reachable service, you bind it
to a global address, and you protect the rest of the services/layer 4
protocol endpoints on that host that use global addresses via an SI
firewall, preferably on the host itself.

If you don't want to have a service globally reachable, then you don't
bind it to a global address - bind the service only to the to the ULA
addresses on the host. Then it'll be globally unreachable regardless of
whether there is a SI firewall active or not (although if people start
convincing upstreams and peers to accept their ULA routes external to
their own private network ... well, they made that choice, they'll have
to live with the security consequences)



-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: Security gain from NAT

[David Conrad]

On Jun 6, 2007, at 8:59 AM, Stephen Sprunk wrote:

The thing is, with IPv6 there's no need to do NAT.


Changing providers without renumbering your entire infrastructure.

Multi-homing without having to know or participate in BGP games.

(yes, the current PI-for-everybody allocation mindset would address  
the first, however I have to admit I find the idea of every small  
enterprise on the planet playing BGP games a bit ... disconcerting)



However, NAT in v6 is not necessary, and it's still evil.


Even ignoring the two above, NAT will be a fact of life as long as  
people who are only able to obtain IPv6 addresses and need/want to  
communicate with the (overwhelmingly IPv4 for the foreseeable future)  
Internet.  Might as well get used to it.  I for one welcome our new  
NAT overlords...


Rgds,
-drc
 

Re: Security gain from NAT

[Stephen Sprunk]

Thus spake "Roger Marquis" <[EMAIL PROTECTED]>

I, for one, give up. No matter what you say I will never
implement NAT, and you may or may not implement it if people
make boxes that support it.


Most of the rest of us will continue to listen to both sides and
continue to prefer NAT, in no small part because of the absurd
examples and inconsistent terminology NATophobes seem to feel is
necessary to make their case.


The thing is, with IPv6 there's no need to do NAT.  What vendors have (so 
far) failed to deliver is a consumer-grade firewall that does SI with the 
same rules on by default that v4 NAT devices have.  Throw in DHCP PD and 
addressing (and renumbering) are automatic.  This is simpler than NAT 
because no "fixup" is required; a v6 firewall with SI and public addresses 
on both sides just needs to inspect packets, not modify them.


The same device will probably be a v4 NAT device; nobody is trying to take 
that away because it's a necessary evil.  However, NAT in v6 is not 
necessary, and it's still evil.


S

Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Re: Security gain from NAT

[Nathan Ward]

On 6/06/2007, at 2:53 PM, Roger Marquis wrote:




So now the cruft extends and embraces, and you have to play DNS
view games based on whether it's on company A's legacy net,
company B's legacy net, or the DMZ in between them, and start
poking around in the middle of DNS packets to tweak the replies
(which sort of guarantees you can't deploy DNSSEC).





You clearly missed the start of this conversation, and my summaries  
in the last couple of days, about which I am not surprised.


We were discussing IPv6, the lack of NAT was brought up as being  
viewed as a blocker for security reasons, and solutions were  
presented so that it no longer is, assuming adequate education is  
provided.


--
Nathan Ward

Re: Security gain from NAT

[Bill Stewart]

On 6/5/07, Roger Marquis <[EMAIL PROTECTED]> wrote:

Are you proposing that every company use publicly routable address
space?  How about the ones that don't qualify for a /19 and so are
dependent on addresses owned by their upstream?


This discussion evolved from an IPv6 discussion, so there's plenty of
address space for everybody in the assumptions, and you can have a /48
even if a /64 is overkill.


To change ISPs for example, would it be simpler to change the IP
address of every node in the company or to run NAT on the gateways?


Unlike the security discussions, that's one area where NAT really does
make life easier for medium-large companies (either 1-1 NAT or PNAT
will do.)  It lets you number your internal space as 10/8, regardless
of what ISP or ISPs you're using externally, so if you have to change
one of your ISPs, you don't have to renumber anything except possibly
a couple of externally-visible servers and gateways.
Of course, that only remains true until some merger or acquisition
mashes your 10/8 address space into another company's 10/8 address
space , at which point you've still got work to do unless you were
both careful about taking random subnets of 10/8, e.g. 10.x/16 for
randomly selected x>10.


Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.

Re: Security gain from NAT

[Roger Marquis]

So now the cruft extends and embraces, and you have to play DNS
view games based on whether it's on company A's legacy net,
company B's legacy net, or the DMZ in between them, and start
poking around in the middle of DNS packets to tweak the replies
(which sort of guarantees you can't deploy DNSSEC).


Are you proposing that every company use publicly routable address
space?  How about the ones that don't qualify for a /19 and so are
dependent on addresses owned by their upstream?

To change ISPs for example, would it be simpler to change the IP
address of every node in the company or to run NAT on the gateways?

How about multi-homing?  Can you even do it without NAT on a network
too small assign an AS?

In the mid-90s I was CSO at a company whose internal networks were
publicly routable thanks to a /16 they owned (though they really only
needed a few /24s).  In my experience, for every example of how
complex NAT is there are at least 10 counter-examples of how an
equivalent non-NATed network is more complex, less flexible, less
reliable, and less secure.

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/

Re: Security gain from NAT

[Valdis . Kletnieks]

On Tue, 05 Jun 2007 17:44:40 PDT, Roger Marquis said:
> 
> >> Sure, very easily, by using NAT between the subnets.
> >
> > Have at it. Nothing like trying to reach 10.10.10.10 nad having
> > to put in a dns entry pointing to 172.29.10.10
> 
> End-users prefer hostnames to IPs.  DNS hostnames are valid on both
> sides due to either local zone files or a DNS protocol-NAT.  It's a
> no-brainer to implement and a lot easier than using public address
> space given the relatively complex firewalling and filtering that
> requires.

So now the cruft extends and embraces, and you have to play DNS view games
based on whether it's on company A's legacy net, company B's legacy net,
or the DMZ in between them, and start poking around in the middle of DNS
packets to tweak the replies (which sort of guarantees you can't deploy DNSSEC).

And if the company aquires *another* one with rfc1918 on their legacy net,
then you get to play "as seen from A, B, or C, or this DMZ, or that DMZ"..

I think somebody on this list mentioned that due to corporate acquisitions,
there were legitimate paths between machines that traversed 5 or 6 NATs.

But yeah, "Sure, very easily".  Whatever you say...


pgpdCBdLMSh2q.pgp
Description: PGP signature

Re: Security gain from NAT

[Roger Marquis]

Sure, very easily, by using NAT between the subnets.


Have at it. Nothing like trying to reach 10.10.10.10 nad having
to put in a dns entry pointing to 172.29.10.10


End-users prefer hostnames to IPs.  DNS hostnames are valid on both
sides due to either local zone files or a DNS protocol-NAT.  It's a
no-brainer to implement and a lot easier than using public address
space given the relatively complex firewalling and filtering that
requires.


NAT'ing the address on your side to their side and from their
side back to your side, and adding the rules. That's definitely
simpler than allow a -> b for service c.


Not simpler than running something like "fixup protocol dns" on a
VPN termination.


I, for one, give up. No matter what you say I will never
implement NAT, and you may or may not implement it if people
make boxes that support it.


Most of the rest of us will continue to listen to both sides and
continue to prefer NAT, in no small part because of the absurd
examples and inconsistent terminology NATophobes seem to feel is
necessary to make their case.

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/

Re: Security gain from NAT

[Donald Stahl]

I, for one, give up. No matter what you say I will never implement NAT, and 
you may or may not implement it if people make boxes that support it. Clearly 

...

This was supposed to be a private reply and was not meant to go to the 
list. My apologies.


I will also refrain from further responses- something I definitely should 
have done 20 messages ago... -Don

Re: Security gain from NAT

[Donald Stahl]

Sure, very easily, by using NAT between the subnets.
Have at it. Nothing like trying to reach 10.10.10.10 nad having to put in 
a dns entry pointing to 172.29.10.10, NAT'ing the address on your side to 
their side and from their side back to your side, and adding the rules. 
That's definitely simpler than allow a -> b for service c.



Can you clarify this claim?  What about managing NAT is allegedly
difficult.  Are you unable to easily map public addresses with private
addresses on your own networks?
Easily map them? Sure- I can do my external tcpdump, see some funny 
traffic, then match that up with the dynamic nat's. That's a lot easier 
than just going "oh, hey, it's this user" without any further steps.


I, for one, give up. No matter what you say I will never implement NAT, 
and you may or may not implement it if people make boxes that support it. 
Clearly neither of us will change our minds so why bother. I'm sure we've 
both gotten supportive emails in private and both know we are "right." In 
the end it isn't going to change a thing.


-Don

Re: Security gain from NAT

[Roger Marquis]

Donald Stahl wrote:

Ever try to set up a VPN between two offices using the same
address space?


Sure, very easily, by using NAT between the subnets.


NAT is still evil though, the problems it causes operationally
are just plain not worth it.


Can you clarify this claim?  What about managing NAT is allegedly
difficult.  Are you unable to easily map public addresses with private
addresses on your own networks?


Stateful inspection provides security benefits.


Neither SI nor NAT provides any security.  It is the rules commonly
implemented on top of them that can provide security.  Please be
consistent in the use of these terms to avoid confusing the issue.

Jeff McAdams wrote:

But it is correct. Just mangling the addresses in the headers
doesn't actually stop anything from getting through, it just
means it gets through mangled. The security comes from SI and
dropping packets that don't have an active session established
from inside, or related.


Crux of the thread for sure.  In an academic context NAT only swaps
header addresses, however, in the world of network operators and
end-users all NAT devices do SI and filtering.  It is the filtering,
blocking connections initiated from public addresses, that provides
"NAT security".  That is still "NAT security" if only because it is
characteristic of virtually all NAT devices, and not the default or
even a common configuration of non-NAT network devices and
applications.

Perhaps it is difficult to understand this vernacular "NAT" after
studying Comer, Stevens et al, but when you've run the equivalent of
'sh conn' regularly for several years the narrow, some would say ivory
tower, definition of NAT tends to morph into one based on actual
implementations.

Since this mailing list is by and for network operators as opposed to
academics perhaps we could ask the later (NANAGs?) to use footnotes(1)
to clarify their meaning?

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/

Re: Security gain from NAT

[Steven M. Bellovin]

On Mon, 04 Jun 2007 22:06:25 -0400
Daniel Senie <[EMAIL PROTECTED]> wrote:

> 
> At 09:07 PM 6/4/2007, Jason Lewis wrote:
> 
> 
> >I figured SMB would chime in...but his research says it's not so
> >anonymous.
> >
> >http://illuminati.coralcdn.org/docs/bellovin.fnat.pdf

The traffic load on this list is rather high; I've had to flush most
of this and other threads 
> 
> Give or take NAT boxes / firewalls that specifically have features to
> mess with the IP ID. The SonicWALL products have, for example, a
> checkbox that says: "Randomize IP ID".

That's relatively new, and possibly in response to my paper; as of when
I wrote it, I couldn't find any vendors that DTRT.
> 
> Some vendors apparently have taken measures to ensure methods such as
> monitoring IP ID are less effective. The paper notes this, and the
> issues with doing this.
> 
> So the "not so anonymous" statement above is really "not so
> anonymous, give or take the implementation of the firewall/NAT".
> 
I suspect there are other information leaks, such as the RFC 1323
timestamps, TCP sequence numbers (for some platforms), port number
allocation, etc.  Many of these are (or can be) randomized on some
platforms, but I don't know of any systematic analysis.  I also wonder
if some popular web sites' cookies embed the IP address -- possibly
encrypted to them, so they can track where you are.  I'm 100% that some
sites do that for authenticated connections.

(On the larger issue, I feel that typical NATs provide no security
benefit over typical stateful packet filters.  Given other issues --
traceability of attacks, impediments to end-to-end secure connections,
the need for special-purpose things like STUN servers, etc. -- I could
make a good case that they're a net disadvantage.  But I'm on the verge
of flushing this thread, so I may not see the responses)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

RE: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[David Schwartz]

> Again, whether the lock/deadbolt come as a package deal with the screen
> door or not, it is the lock/deadbolt that provide the security, not
> the screen
> door.

Wow, I don't know what to say. I've never heard of a screen door that came
with, and could not work without, a lock and deadbolt. It's totally obvious
that you had no intention of implying that typical NAT implementations
didn't provide any security.

And, by the way, in all of my real examples, it was the actual NAT that
provided the security. The Windows machines are behind a device that has but
one rule configured in it, and it's a NAT rule. The NAT rule is the only
thing that causes the machine to do any stateful inspection at all. That is,
one single element provides the NAT and the SI, SI is the means by which the
NAT is implemented, and SI is the only way to provide NAT.

The device is *NOT* configured to reject inbound by default. Other machines
on other parts of my private network *can* reach it through its NAT on its
private addresses. Our wireless network, for example, has its own NAT to
reach the Internet and its own block of private addresses, but can reach the
wired Windows boxes on their private addresses.

Yet you *STILL* can't log into my Linux box even with the root password. You
still can't access my Windows network shares even with the administrator
password. If it was on a public IP address, all other things being the same,
it would take you ten seconds to get into it.

These machines have never been compromised. All other things being precisely
the same, without the private addresses, they would never have lasted.

It is simply a fact that private addresses and NAT itself do provide some
security. You can get this same security without the private addresses and
without the NAT, but that changes nothing.

This is the claim you are defending: "There's no security gain from not
having real IPs on machines. Any belief that there is results from a lack of
understanding." So why can't you break into these machines when the only
thing stopping you is that they don't have real IPs. There is no other
security of any kind in place. There is no "reject inbound by default", no
firewall rules (except NAT itself). The only stateful inspection is used to
make NAT work and is the *implementation* of NAT itself.

All I have is the very thing you claim provides "no security gain". And it's
what's stopping you.

DS

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Perry Lorier]

The only ways into these machines would be if the NAT/PAT device were
misconfigured, another machine on the secure network were compromised, or
another gateway into the secure network was set up. Guess what? All of these
things would defeat a stateful inspection firewall as well.
  
I disagree.  (All of the below is hypothetical, I haven't tested it, but 
I believe it to be true.)


Premise 1: The machines behind the firewall are actually on and 
functioning, and presumably may be even being used.


Premise 2: The OS's on the machines will periodically do *some* kind of 
traffic.  Some common examples might be ntp syncronisation, or DNS 
resolving of an update service for antivirus, OS patches, whatever.  The 
traffic may be provided by the user actually using the machine for 
whatever real users actually do.


Premise 3: Many NAPT's are of the "Cone" type.  This is desirable for 
end users as it allows their applications/devices to use their NAPT 
busting technologys (STUN, Teredo etc) without having to configure 
static port forwards.


Premise 4: The external port chosen for an outgoing protocol is easily 
guessed.  Many NAPT boxes will prefer to use the same port as the 
original host, or will assign port mappings sequentially a bit of 
research here would go a long way, presumably entire networks are likely 
to be using the same NAPT's in an ISP's provided CPE.


Thus, for example if you are running a single host behind a NAPT box 
that is doing regular NTP queries and I can guess the external port on 
the NAPT box which with a bit of research I suspect is trivial, I can 
send that port on your external IP a packet and it will be forwarded 
back to your machine.  This could easily lead to a compromise via a 
buffer overflow or other exploit.


This would primarily work for UDP based services that by design tend to 
be used over the Internet itself such as DNS, NTP, SIP etc.  It seems 
unlikely that this would work against TCP based services.  Exploits in 
ICMP could also be "tunneled" back through a NAPT box in a similar 
manner.  GRE/IPIP/IPv6/ESP/AH can probably use similar techniques to 
infect machines behind a NAPT box (Disclaimer I don't know those 
protocols very well, but on the flipside, I suspect that NAPT boxes 
don't know them very well either and do dumb things with them like 
forward all GRE packets to the one host inside your network that has 
ever spoken GRE).


Just because you've never seen someone exploit through a NAPT box 
doesn't mean it won't happen. 

Re: Security gain from NAT

[James R. Cutler]

Maybe one should consider the customer viewpoint and not just 
semantic twiddle. When I install one of those little and inexpensive 
boxes it is for several reasons, not just security. However, the "I 
hear you knocking, but you can't come in." is invaluable to keep out 
probes of popular Microsoft points (ports) of vulnerability. In a 
very practical sense this is added security for the end system.  Yes, 
it is from the Stateful Inspection and not, per se, from address or 
port translation.  That really does not matter because it comes as a 
package in those cute little boxes.


Regarding efficacy of NAT: Have you considered what the typical ISP 
policy on address assignment and routing will be? Will Comcast 
announce routes to all my end system addresses to the world? Will 
Comcast even allow for more than one address per connection? 
Substitute your vendor of choice here.  Be it BT or whatever, until 
you assure me that my ISP will not interfere with my local SOHO or 
home network or increase my rate per system added, I will encourage 
multiplexing of addresses, regardless of IPv4, IPv6, landline 
telephone number, PO Box, or whatever.


Listen to Ahnberg and Dillon. What they say makes much sense and 
avoids the semantic quibbling that has consumed too much of NANOG 
mailing list bandwidth.  We already know that "All dragons are 
scotsmen, but not all scotsmen are dragons."


-
James R. Cutler
[EMAIL PROTECTED]

Re: Security gain from NAT

[Adrian Chadd]

On Tue, Jun 05, 2007, Mattias Ahnberg wrote:
> 
> Donald Stahl wrote:
> > Keep it simple. NAT is a terrible terrible hack- and it's sad that it's
> > become so accepted in the maintsream.
> 
> Probably mostly because it WORKS for people, it doesn't require you
> to be a network specialist.

You know, I can't help but see parallels between this and the IP versus other
protocols (esp OSI) from what I read during my stint as an undergraduate
EE. (No, I'm not an EE now.) I'm sure there's plenty of grumpy telco
people out there who think IP is just a hack and OSI/ATM/ISDN were the
technologies that were thought out 'right' and should've caught on, damnit!




Adrian
(won't post again on this thread, sorry!)

Re: Security gain from NAT

[Mattias Ahnberg]

Donald Stahl wrote:
> Keep it simple. NAT is a terrible terrible hack- and it's sad that it's
> become so accepted in the maintsream.

Probably mostly because it WORKS for people, it doesn't require you
to be a network specialist. Someone just purchases a NAT gateway to
connect to their ADSL/cable connection where they have one dynamic
IP allocated by their ISP.

They get automatic DHCP by the internal ports on the router and all
is set, they can connect many computers to the network. They don't
have to understand PAT, NAT or policies.

This is certainly part of the problem too, that users don't know a
lot about their underlying connectivity and why things work the way
it does; but that is another discussion.

To get rid of NAT and the advantages it has someone would've needed
to design stuff differently to begin with. Allocate larger blocks
of IPs to customers with more than one computer at home, or default
allocate more. Imagine the bureaucracy around that?
-- 
/ahnberg.

RE: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[michael.dillon]

> I posit that a screen door does not provide any security.

"Any" is too strong a word. For people living in an area with
malaria-carrying mosquitoes, that screen door may be more important for
security than a solid steel door with a deadbolt. It all depends on what
the risks are, what you are protecting, and where your priorities are.

It is rather odd to see this discussion just a few weeks after the IETF
issued RFC 4864 to address just this misconception of NAT. How many of
the participants have read the RFC? Assuming vendors of cheap consumer
IPv6 gateway boxes implement all the LNP (Local Network Protection)
features of RFC 4864, is there any reason for these boxes to also
support NAT?

As far as I can see the only good reason to put NAT in an IPv6 gateway
is because uneducated consumers demand it as a checklist feature. In
that case, let's hope that it is off by default and that disabling the
NAT does not disrupt any of the other LNP features. That way, when the
customer calls the support desk to complain that they are not getting
SIP calls from Mom, you can tell them to turn off the NAT and try again.

--Michael Dillon

Re: Security gain from NAT

[brett watson]

On Jun 4, 2007, at 9:51 PM, Donald Stahl wrote:

A SI firewall ruleset equivalent to PAT is a single rule on a  
CheckPoint firewall (as an example):


Src: Internal - Dst: Any - Action: Allow

Done.


Done indeed! Botnet operators *love* this policy. This type of policy  
is probably worse than any issue discussed in this thread so far.


-b

Re: Security gain from NAT

[Donald Stahl]

A core but often neglected factor in IT security is KIS.  NAT,
particularly in the form of PAT, is an order of magnitude simpler to
administer than a stateful firewall with one-to-one address mappings.
Why would a stateful firewall have one-to-one address mappings? I'm not 
even sure what you mean by this. Are you referring to static NAT with SI? 
Are you suggesting that someone would enter a rule for every individual 
host on the network rather than simply have one rule that says the entire 
subnet can get out but nothing can come in?


PAT is not simple- it's the antithesis of KIS. It means added code in your 
apps and firewall. It means it takes longer to troubleshoot problems. It 
means thinking about firewall rules AND the NAT that accompanies them.


A SI firewall ruleset equivalent to PAT is a single rule on a CheckPoint 
firewall (as an example):


Src: Internal - Dst: Any - Action: Allow

Done.


Given the degree to which complexity negatively correlates with
security,

This is exactly why NAT is bad, not why it's good.


Any security auditor will tell you that, in the real world, stateful
one-to-one firewalls are rarely as secure as NAT gateways for the
simple reason that the non-NAT firewalls have more rules.

As a former security auditor I will tell you that you are wrong.

I've done security audits for years, been certified by the NSA to perform 
IAM audits, worked extensively with a variety of firewalls and intrusion 
detections systems, and I co-moderate a firewall mailing list. I think I 
can safely state that NAT adds complexity to a firewall rule set, it does 
not remove it.


A CheckPoint without NAT has N rules. A CheckPoint with NAT has N rules + 
M NAT rules where M is the number of NAT'd hosts. If you are doing port 
address translation rather than simpler static NAT then M is the number of 
NAT'd services as opposed to the number of NAT'd hosts. Either way it is 
definitely more complex. This is true of CheckPoint, ipfw and a myriad of 
other firewalls. (Sorry for all the CheckPoint examples- I just happened 
to have a client's CheckPoint ruleset open while responding).



This debate mirrors one that took place in a large university where I
worked several years ago.  The network admins made passionate
arguments against NAT but did little to firewall vulnerable
departments.
So because these network engineers were exceedingly lazy and or sloppy 
then NAT is somehow better?


Even supposing you could always enter PAT rules as simple firewall rules- 
how are 20 PAT statements smaller and or simpler than 20 SI statements?



The risk was obvious but so was the underlying
motivation.  They were simply protecting their turf.  In this case
multiple class-B allocations, awarded decades ago, before NAT and PAT
became affordable technologies.
How was this "protecting" their class-B? More than likely it was awarded 
before ARIN and there is no RSA agreement that would allow anyone to 
reclaim the addresses.



I don't know
all of the reasons but, having managed thousands of clients behind NAT
and unNATted gateways I'll take NAT any day.

Ever try to set up a VPN between two offices using the same address space?
I'll stick with no NAT any day.

-Don

Re: Security gain from NAT

[Roger Marquis]

Matthew Palmer wrote:

While "protection from mistakes" is a valid reason, it's a pretty
weak one.


It is indeed a weak reason but, evidently, much stronger as a straw
man argument.  NAT is A security tool, not THE security tool.


I would say that those who rely on NAT for security are the ones
with the narrow world-view.


Depends wholly on the security requirements of the client.  Then
again, I can't say I've ever seen a site that relies on NAT
exclusively.  This is another straw man argument.

A core but often neglected factor in IT security is KIS.  NAT,
particularly in the form of PAT, is an order of magnitude simpler to
administer than a stateful firewall with one-to-one address mappings.
Given the degree to which complexity negatively correlates with
security, for non-server addresses at least, NAT has far and away the
better ROI.

Any security auditor will tell you that, in the real world, stateful
one-to-one firewalls are rarely as secure as NAT gateways for the
simple reason that the non-NAT firewalls have more rules.

This debate mirrors one that took place in a large university where I
worked several years ago.  The network admins made passionate
arguments against NAT but did little to firewall vulnerable
departments.  The risk was obvious but so was the underlying
motivation.  They were simply protecting their turf.  In this case
multiple class-B allocations, awarded decades ago, before NAT and PAT
became affordable technologies.  Perhaps they also did a lot of
peer-to-peer filesharing behind those non-NATed subnets.  I don't know
all of the reasons but, having managed thousands of clients behind NAT
and unNATted gateways I'll take NAT any day.

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/

Re: Security gain from NAT

[Sam Stickland]

Matthew Palmer wrote:

I can think of one counter-example to this argument, and that's
SSL-protected services, where having a proxy, transparent or otherwise, in
your data stream just isn't going to work.  

Not so. Look at: http://muffin.doit.org/docs/rfc/tunneling_ssl.html

S

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Owen DeLong]

On Jun 4, 2007, at 1:41 PM, David Schwartz wrote:




On Jun 4, 2007, at 11:32 AM, Jim Shankland wrote:



Owen DeLong <[EMAIL PROTECTED]> writes:

There's no security gain from not having real IPs on machines.
Any belief that there is results from a lack of understanding.



This is one of those assertions that gets repeated so often people
are liable to start believing it's true :-).



Maybe because it _IS_ true.


*No* security gain?  No protection against port scans from  
Bucharest?

No protection for a machine that is used in practice only on the
local, office LAN?  Or to access a single, corporate Web site?


Correct.  There's nothing you get from NAT in that respect that  
you do

not get from good stateful inspection firewalls.  NONE whatsoever.


Sorry, Owen, but your argument is ridiculous. The original  
statement was

"[t]here's no security gain from not having real IPs on machines". If
someone said, "there's no security gain from locking your doors",  
would you
refute it by arguing that there's no security gain from locking  
your doors

that you don't get from posting armed guards round the clock?


Except that's not the argument.  The argument would map better to:

There's no security gain from having a screen door in front of your
door with a lock and dead-bolt on it that you don't get from a door
with a lock and dead-bolt on it.

I posit that a screen door does not provide any security. A lock and
deadbolt provide some security.  NAT/PAT is a screen door.
Not having public addresses is a screen door.  A stateful inspection
firewall is a lock and deadbolt.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: Security gain from NAT

[Edward B. DREGER]

DI> Date: Mon, 04 Jun 2007 15:22:11 -0400
DI> From: Dave Israel

DI> So you make end devices unaddressable by normal means, and while it
DI> shouldn't give them more security, it turns out it does.  No matter
DI> how much it shouldn't, and how much we wish it didn't, it does.

"Hey, this so-called 'DMZ' feature looks handy.  Now I can run a server
process... and I'm protected because I'm using a private address!"

The security comes from state, full stop.


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita

DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Edward B. DREGER]

JS> Date: Mon, 04 Jun 2007 12:20:38 -0700
JS> From: Jim Shankland

JS> If what you meant to say is that NAT provides no security benefits
JS> that can't also be provided by other means, then I completely

What Owen said is that "[t]here's no security gain from not having real
IPs on machines".  That is a true statement.

Moreover...

Provider: "We're seeing WormOfTheDay.W32 from 90.80.70.60."

Downstream: "That's our firewall."

Provider: "Chances are you have one or more compromised hosts behind
your firewall."

Downstream: "But we have 150 workstations.  How do we find which 
one(s)?"

Bonus points for finding downstreams who understand "NIDS", "monitor 
port", "state mapping tables", et cetera. :-)

In the big picture, I submit that NAT *worsens* the security situation.  
Of course, the cost falls to "other people" -- a topic that inevitably 
launches a protracted thread.


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita

Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Jim Shankland]

[EMAIL PROTECTED] writes:
> Let's not forget all the NAT boxes out there that are *perfectly*
> willing to let a system make an *outbound* connection.  So the user
> makes a first outbound connection to visit a web page, gets exploited,
> and the exploit then phones home to download more malware.
> 
> Yeah, that NAT *should* be providing security, but as you point out,
> there's that big gap between should and is... :)

I will happily (well ...) further concede that NAT does not provide
*absolute* security.  Let me be the first to mention that NAT provides
precisely zero protection against:  "Hey, kids, just download and
run this .EXE to see a cute cartoon of Santa dancing with a polar
bear" :-).

Jim

RE: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[David Schwartz]

> On Jun 4, 2007, at 11:32 AM, Jim Shankland wrote:

> > Owen DeLong <[EMAIL PROTECTED]> writes:
> >> There's no security gain from not having real IPs on machines.
> >> Any belief that there is results from a lack of understanding.

> > This is one of those assertions that gets repeated so often people
> > are liable to start believing it's true :-).

> Maybe because it _IS_ true.

> > *No* security gain?  No protection against port scans from Bucharest?
> > No protection for a machine that is used in practice only on the
> > local, office LAN?  Or to access a single, corporate Web site?

> Correct.  There's nothing you get from NAT in that respect that you do
> not get from good stateful inspection firewalls.  NONE whatsoever.

Sorry, Owen, but your argument is ridiculous. The original statement was
"[t]here's no security gain from not having real IPs on machines". If
someone said, "there's no security gain from locking your doors", would you
refute it by arguing that there's no security gain from locking your doors
that you don't get from posting armed guards round the clock?

DS

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Larry Smith]

On Monday 04 June 2007 13:54, [EMAIL PROTECTED] wrote:
> On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
> > *No* security gain?  No protection against port scans from Bucharest?
> > No protection for a machine that is used in practice only on the
> > local, office LAN?  Or to access a single, corporate Web site?
>
> Nope. Zip. Zero. Ziltch.  Nothing over and above what a good properly
> configured stateful *non*-NAT firewall should be doing for you already.

Cool, then I need four of these firewalls, and two Class-C (512) worth of IP 
space that works behind my current ISP at no more than $39.95 each (my basic 
price for a Dlink, Netgear, etc cable/dsl router with NAT) with no additional 
cost to my monthly internet - and I will start switching over networks...

Yes, I am joking, but the point being that _currently_ NAT serves a purpose; 
is supported by lots and lots of little "boxes" that customers can plugin, 
configure, and be on the "net" quickly and easily without having to know 
about all the "firewall" related stuff; and _does_ do all those neat stateful 
things for people that have absolutely no interest in knowing about much less 
learning how to make work.

While I agree with the principle being discussed, would that many, many, many 
more cable in particular and dsl customers of  had 
such NAT boxes installed and maybe the rest of us would not be getting quite 
so much spam from hacked cable/dsl/whatever machines...

-- 
Larry Smith
SysAd ECSIS.NET
[EMAIL PROTECTED]

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Valdis . Kletnieks]

On Mon, 04 Jun 2007 12:20:38 PDT, Jim Shankland said:

> I can't pass over Valdis's statement that a "good properly configured
> stateful firewall should be doing [this] already" without noting
> that on today's Internet, the gap between "should" and "is" is
> often large.

Let's not forget all the NAT boxes out there that are *perfectly* willing
to let a system make an *outbound* connection.  So the user makes a first
outbound connection to visit a web page, gets exploited, and the exploit
then phones home to download more malware.

Yeah, that NAT *should* be providing security, but as you point out, there's
that big gap between should and is... :)


pgpOXUqCTf010.pgp
Description: PGP signature

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Colm MacCarthaigh]

On Mon, Jun 04, 2007 at 11:47:15AM -0700, Owen DeLong wrote:
> >*No* security gain?  No protection against port scans from Bucharest?
> >No protection for a machine that is used in practice only on the
> >local, office LAN?  Or to access a single, corporate Web site?
> >
> Correct.  There's nothing you get from NAT in that respect that you do
> not get from good stateful inspection firewalls.  NONE whatsoever.

Argueably the instant hit of IP source anononymity you get with NAT is a
security benefit (from the point of view of the user). Of course these
days there all sorts of fragment and timing analyses that will allow you
to determine origin commonality behind NAT, but it's nowhere near as
convenient as a public IP address.

A non-NAT stateful firewall can't simulate that, you need high-rotation
dhcp or similar to get close. Although IPv6 privacy addresses rock :-)

The argument can go either way, you can spin it as a benefit for the
network operator ("wow, user activity and problems are now more readily
identifiable and trackable") or you can see it as an organisational
privacy issue ("crap, now macrumors can tell that the CEO follows them
obsessively"). 

NAT is still evil though, the problems it causes operationally are
just plain not worth it.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]

Re: Security gain from NAT

[Dave Israel]

[EMAIL PROTECTED] wrote:

On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:

*No* security gain?  No protection against port scans from Bucharest?
No protection for a machine that is used in practice only on the
local, office LAN?  Or to access a single, corporate Web site?


Nope. Zip. Zero. Ziltch.  Nothing over and above what a good properly
configured stateful *non*-NAT firewall should be doing for you already.



What the firewall *should* be doing?  The end devices *should* not need 
protection in the first place, because they *should* be secure as 
individual devices.  But they are not.  So you put a firewall in front 
of them, and that device *should* give them all the protection they 
need.  But sometimes, it doesn't.  So you make end devices unaddressable 
by normal means, and while it shouldn't give them more security, it 
turns out it does.  No matter how much it shouldn't, and how much we 
wish it didn't, it does.


The difference between theory and practice is that in theory, there is 
no difference, but in practice, there is.

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Robert Bonomi]

> From [EMAIL PROTECTED]  Mon Jun  4 13:54:55 2007
> Subject: Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)
> Date: Mon, 4 Jun 2007 14:47:06 -0400
>
> On 4-Jun-2007, at 14:32, Jim Shankland wrote:
>
> > Shall I do the experiment again where I set up a Linux box
> > at an RFC1918 address, behind a NAT device, publish the root
> > password of the Linux box and its RFC1918 address, and invite
> > all comers to prove me wrong by showing evidence that they've
> > successfully logged into the Linux box?
>
> Perhaps you should run a corresponding experiment whereby you set up  
> a linux box with a globally-unique address, put it behind a firewall  
> which blocks all incoming traffic to that box, and issue a similar  
> invitation.
>
> Do you think the results will be different?

Consider the possible *FAILURE* modes.
  e.g. (1) where somebody brings up _another_ path between the LAN that that 
   box is onn, and the public internet, with no translations or other
   protections whatsoever.   
   (2) where the 'protection box' "fails open" -- e.g. passes all traffic
   without modification.


NAT/PAT is 'belt and suspenders', but it *does* provide an additional layer of
protection, _if_the_primary_protection_fails_.

That 'additional protection' may or may not be 'significant', depending on
one's viewpoint.