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

Matthew Moyle-Croft mmc at internode.com.au
Fri Aug 1 12:00:55 EST 2008


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

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

My point (again) is that both are bits of software that are going to  
be equally poorly implemented - so we're actually no better off.

Esp where a protocol has no formal definition or is very loose in  
definition.

MMC

>
>
>
> 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
> 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
> 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
> 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
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/ba361ba2/attachment.html>


More information about the AusNOG mailing list