<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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.</div><div><br></div><div>Remind me then how the protocol tweaking will decline? </div><div><br></div><div>MMC</div><div><br></div><div><br><div><div>On 01/08/2008, at 10:08 AM, Chris Chaundy wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>A further comment on this topic - I agree entire on the comments<br>regarding accessibility versus addressability. One of the problems with<br>NAT is all the tweaking needed for some protocols that 'break the rules'<br>as far as layering of protocols go by embedding information about lower<br>layers in higher layers which leads to complexity which inevitably leads<br>to bugs.<br><br>While IPv6 is may problematic for some of these protocols, it is a<br>problem that will have to be solved, and once solved, NAT (and the<br>tweaking) will no longer be necessary when we have sufficient address<br>space (well in the perfect world anyway :-). Long live the KISS<br>principle...<br><br>-----Original Message-----<br>From: <a href="mailto:ausnog-bounces@ausnog.net">ausnog-bounces@ausnog.net</a> [<a href="mailto:ausnog-bounces@ausnog.net">mailto:ausnog-bounces@ausnog.net</a>] On<br>Behalf Of Mark Newton<br>Sent: Friday, 1 August 2008 8:51 AM<br>To: Robert Brockway<br>Cc: <a href="mailto:ausnog@ausnog.net">ausnog@ausnog.net</a><br>Subject: Re: [AusNOG] IPv4 Exhaustion, APNIC EC, and James is a nice<br>bloke ;-)<br><br><br>On 01/08/2008, at 1:11 AM, Robert Brockway wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">Please excuse me if I'm wrong but it seems like you are equating<br></blockquote><blockquote type="cite">'publically accessible' to 'publically addressable'. They need not <br></blockquote><blockquote type="cite">be the<br></blockquote><blockquote type="cite">same thing as per earlier parts of the thread.<br></blockquote><br>There's a certain amount of cross-purposes discussion going on here.<br><br>I don't think anyone is equating the two issues in the way you've<br>described. It might be useful for you to assume that those in this<br>thread who have taken a contrary view have a full and complete<br>understanding of the problem and simply disagree with you.<br><br>Let me expand on it just slightly, by way of illustration.<br><br>Lets say you have some firewall code in your CPE. That's something<br>that controls "accessibility."<br><br>And lets also say you have some NAT code in your CPE. That's something<br>that controls "addressability."<br><br>Flows passing through the CPE are NAT'ed (re-addressed), and also<br>passed through the firewall. That seems to be the typical way that<br>most CPE works; Whether you're talking about a Cisco or a Billion,<br>the stateful inspection configuration stanzas and internal code paths<br>are different beasts.<br><br>Now -- Lets assume you're using cheap and nasty CPE that has<br>firmware that's of, shall we say, variable quality.<br><br>If the firewall is buggy, it'll incorrectly block some traffic and<br>incorrectly pass other traffic. The one Bevan is worried about is<br>incorrectly passing traffic to his fridge -- i.e., making an<br>incorrect decision about whether his fridge should be accessible.<br><br>Separately:<br><br>If the NAT code is buggy, it'll incorrectly translate inside<br>addresses to outside addresses. The degenerate, almost inevitable<br>case is that devices on the "inside" won't have an network access<br>due to NAT bugs.<br><br>Now consider each facility being present or not present individually,<br>and consider the failure modes.<br><br>In the presence of bugs on a device that has NAT and no firewall,<br>devices inside your network won't have network access.<br><br>In the presence of bugs on a device that has a firewall and no<br>NAT, incorrect decisions regarding accessibility will be made and<br>Bevan's fridge will conceivably be reachable from the outside.<br><br>In the presence of bugs on a device that has a firewall and NAT,<br>incorrect decisions regarding accessibility won't matter very<br>much because nothing on the inside is addressable, or, consequently,<br>reachable; and NAT failures will -still- cause devices inside<br>your network to not have network access.<br><br>So -- although NAT != security, what NAT *does* do is make your<br>firewall fail-safe. The preference in the event of a bug when<br>NAT is present is to deny access. The preference in the event of<br>a bug without NAT is to either incorrectly permit or incorrectly<br>deny, depending on the bug. NAT is, therefore, a net gain, and<br>a marginal improvement on the quality of the security provided<br>by the solution.<br><br>Now, I'm not emotionally attached to NAT, and I don't think its<br>inevitable culling in an IPv6 world represents a huge problem. But<br>I think you're making a mistake by suggesting that taking away<br>NAT makes no difference because protecting the network is the firewall's<br>job. We don't live in an ideal world, and some CPE firmware is so<br>badly tested that it won't even boot, so I don't think you can trust<br>the firewall. So what does that leave you with?<br><br><blockquote type="cite"> I would not allow my<br></blockquote><blockquote type="cite">appliances to be publically accessible but I'm fine with them being<br></blockquote><blockquote type="cite">publically addressable.<br></blockquote><br>What about when your firewall is buggy? Is it ok then?<br><br><br> - mark<br><br>--<br>Mark Newton Email:<br><a href="mailto:newton@internode.com.au">newton@internode.com.au</a> <br> (W)<br>Network Engineer Email: <br><a href="mailto:newton@atdot.dotat.org">newton@atdot.dotat.org</a> (H)<br>Internode Systems Pty Ltd Desk: +61-8-82282999<br>"Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223<br><br><br><br><br><br>_______________________________________________<br>AusNOG mailing list<br><a href="mailto:AusNOG@ausnog.net">AusNOG@ausnog.net</a><br><a href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>_______________________________________________<br>AusNOG mailing list<br>AusNOG@ausnog.net<br>http://lists.ausnog.net/mailman/listinfo/ausnog<br></div></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>-- <br>Matthew Moyle-Croft Internode/Agile Peering and Core Networks<br>Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia<br>Email: <a href="mailto:mmc@internode.com.au">mmc@internode.com.au</a> Web: <a href="http://www.on.net/">http://www.on.net</a><br>Direct: +61-8-8228-2909<span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span> Mobile: +61-419-900-366<br>Reception: +61-8-8228-2999 Fax: +61-8-8235-6909<br></div></div></span> </div><br></div></body></html>