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

Fri Aug 1 11:07:02 EST 2008

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

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