[AusNOG] IPv4 Exhaustion, APNIC EC, and James is a nice bloke ; -)

McDonald Richards macca at vocus.com.au
Fri Aug 1 11:50:55 EST 2008


Because by participating in the protocol you are indicating adherence to the
specification where as NAT is just a giant hack.



 

From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] 
Sent: Friday, 1 August 2008 11:47 AM
To: McDonald Richards
Cc: 'Chris Chaundy'; ausnog at ausnog.net
Subject: Re: [AusNOG] IPv4 Exhaustion, APNIC EC, and James is a nice bloke ;
-)

 

For Application level proxying see my comments below about poor software and
protocol implementations.   Why would it be ANY better when you're just
going to see broken proxy implementations vs broken NAT vs broken stateful
firewalls.

 

MMC

 

On 01/08/2008, at 11:13 AM, McDonald Richards wrote:





> So application level proxying is okay but NAT isn't?    (*MMC looks around
to check it's a joke he's not in on*)

 

Normally when proxying you adhere more closely to the protocol
specifications you're supporting rather than having to rely on port
forwarding to "fix" issues introduced by NAT. Since a proxy actually
participates in signalling, it's less likely to cause the problems NAT does
(unreachable addresses contained inside signalling messages etc).

 

There is no reason that equipment cannot be given a global address if
required, this just allows the extra layer of security that having a
non-routable address gives us.

 

 

 

From: ausnog-bounces at ausnog.net [mailto:ausnog-bounces at ausnog.net] On Behalf
Of Matthew Moyle-Croft
Sent: Friday, 1 August 2008 11:35 AM
To: Chris Chaundy
Cc: ausnog at ausnog.net
Subject: Re: [AusNOG] IPv4 Exhaustion, APNIC EC, and James is a nice bloke ;
-)

 

 

On 01/08/2008, at 10:59 AM, Chris Chaundy wrote:






It's a while since I've had to deal with this, but as I understand it, there
are protocols that embed addressing and port information in payloads which
need to be fiddled if there is/are NAT(s) in the path.  If the extended
address space offered by IPv6 allows us to escape from the NAT
'functionality' (and we just have firewall security), then there is no need
for any fiddling.

 

But stateful firewalls still need to understand the protocol.   Not
understanding it properly still leads to a lack of connectivity (or too
much) will still means it doesn't work and leads to problems and
frustrations by the customers.

 

I'm just pointing out here that NAT isn't the problem.  It's badly written
software and poorly defined/implemented protocols no matter what
shape/flavour they are.    Getting rid of NAT and using stateful firewalls
just paints the fence a different colour.

 

 

Of course, as Macca pointed out, proxying will probably be the way things
will go for most applications in the future anyway.

 

So application level proxying is okay but NAT isn't?    (*MMC looks around
to check it's a joke he's not in on*)

 

MMC

 

 

-----Original Message-----
From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] 
Sent: Friday, 1 August 2008 11:07 AM
To: Chris Chaundy
Cc: ausnog at ausnog.net
Subject: Re: [AusNOG] IPv4 Exhaustion, APNIC EC, and James is a nice bloke ;
-)

 

Stateful firewalls (the solution touted as required for CPE) still appear to
require an understanding of the protocols going through them - to understand
the "state" of a protocol and what connections can/should be opened up.

 

Remind me then how the protocol tweaking will decline?   

 

MMC

 

 

On 01/08/2008, at 10:08 AM, Chris Chaundy wrote:

 

A further comment on this topic - I agree entire on the comments
regarding accessibility versus addressability.  One of the problems with
NAT is all the tweaking needed for some protocols that 'break the rules'
as far as layering of protocols go by embedding information about lower
layers in higher layers which leads to complexity which inevitably leads
to bugs.

While IPv6 is may problematic for some of these protocols, it is a
problem that will have to be solved, and once solved, NAT (and the
tweaking) will no longer be necessary when we have sufficient address
space (well in the perfect world anyway :-).  Long live the KISS
principle...

-----Original Message-----
From: ausnog-bounces at ausnog.net [mailto:ausnog-bounces at ausnog.net] On
Behalf Of Mark Newton
Sent: Friday, 1 August 2008 8:51 AM
To: Robert Brockway
Cc: ausnog at ausnog.net
Subject: Re: [AusNOG] IPv4 Exhaustion, APNIC EC, and James is a nice
bloke ;-)


On 01/08/2008, at 1:11 AM, Robert Brockway wrote:

 

Please excuse me if I'm wrong but it seems like you are equating

'publically accessible' to 'publically addressable'.  They need not  

be the

same thing as per earlier parts of the thread.


There's a certain amount of cross-purposes discussion going on here.

I don't think anyone is equating the two issues in the way you've
described.  It might be useful for you to assume that those in this
thread who have taken a contrary view have a full and complete
understanding of the problem and simply disagree with you.

Let me expand on it just slightly, by way of illustration.

Lets say you have some firewall code in your CPE.  That's something
that controls "accessibility."

And lets also say you have some NAT code in your CPE.  That's something
that controls "addressability."

Flows passing through the CPE are NAT'ed (re-addressed), and also
passed through the firewall.  That seems to be the typical way that
most CPE works;  Whether you're talking about a Cisco or a Billion,
the stateful inspection configuration stanzas and internal code paths
are different beasts.

Now -- Lets assume you're using cheap and nasty CPE that has
firmware that's of, shall we say, variable quality.

If the firewall is buggy, it'll incorrectly block some traffic and
incorrectly pass other traffic.  The one Bevan is worried about is
incorrectly passing traffic to his fridge -- i.e., making an
incorrect decision about whether his fridge should be accessible.

Separately:

If the NAT code is buggy, it'll incorrectly translate inside
addresses to outside addresses.  The degenerate, almost inevitable
case is that devices on the "inside" won't have an network access
due to NAT bugs.

Now consider each facility being present or not present individually,
and consider the failure modes.

In the presence of bugs on a device that has NAT and no firewall,
devices inside your network won't have network access.

In the presence of bugs on a device that has a firewall and no
NAT, incorrect decisions regarding accessibility will be made and
Bevan's fridge will conceivably be reachable from the outside.

In the presence of bugs on a device that has a firewall and NAT,
incorrect decisions regarding accessibility won't matter very
much because nothing on the inside is addressable, or, consequently,
reachable;  and NAT failures will -still- cause devices inside
your network to not have network access.

So -- although NAT != security, what NAT *does* do is make your
firewall fail-safe.  The preference in the event of a bug when
NAT is present is to deny access.  The preference in the event of
a bug without NAT is to either incorrectly permit or incorrectly
deny, depending on the bug.  NAT is, therefore, a net gain, and
a marginal improvement on the quality of the security provided
by the solution.

Now, I'm not emotionally attached to NAT, and I don't think its
inevitable culling in an IPv6 world represents a huge problem.  But
I think you're making a mistake by suggesting that taking away
NAT makes no difference because protecting the network is the firewall's
job.  We don't live in an ideal world, and some CPE firmware is so
badly tested that it won't even boot, so I don't think you can trust
the firewall.  So what does that leave you with?




I would not allow my

appliances to be publically accessible but I'm fine with them being

publically addressable.


What about when your firewall is buggy?  Is it ok then?


  - mark

--
Mark Newton                               Email:
newton at internode.com.au 
 (W)
Network Engineer                          Email:   
newton at atdot.dotat.org  (H)
Internode Systems Pty Ltd                 Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223





_______________________________________________
AusNOG mailing list
AusNOG at ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog
_______________________________________________
AusNOG mailing list
AusNOG at ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

 

-- 
Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc at internode.com.au    Web: http://www.on.net <http://www.on.net/> 
Direct: +61-8-8228-2909                                        Mobile:
+61-419-900-366
Reception: +61-8-8228-2999        Fax: +61-8-8235-6909

 

 

-- 
Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc at internode.com.au    Web: http://www.on.net <http://www.on.net/> 
Direct: +61-8-8228-2909                        Mobile: +61-419-900-366
Reception: +61-8-8228-2999        Fax: +61-8-8235-6909

 

 

-- 
Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc at internode.com.au    Web: http://www.on.net <http://www.on.net/> 
Direct: +61-8-8228-2909                        Mobile: +61-419-900-366
Reception: +61-8-8228-2999        Fax: +61-8-8235-6909

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20080801/4c84fe60/attachment.html>


More information about the AusNOG mailing list