<html>

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Helvetica;
        panose-1:2 11 5 4 2 2 2 2 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue style='word-wrap: break-word;-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space'>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Of course, as Macca pointed out, proxying
will probably be the way things will go for most applications in the future
anyway.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Matthew Moyle-Croft
[mailto:mmc@internode.com.au] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, 1 August 2008 11:07
AM<br>
<b><span style='font-weight:bold'>To:</span></b> Chris Chaundy<br>
<b><span style='font-weight:bold'>Cc:</span></b> ausnog@ausnog.net<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [AusNOG] IPv4
Exhaustion, APNIC EC, and James is a nice bloke ; -)</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>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.</span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Remind me then how the protocol tweaking will decline?
  </span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>MMC</span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>On 01/08/2008, at 10:08 AM, Chris Chaundy wrote:</span></font></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'><br>
<br>
</span></font></p>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>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>
<br>
</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Please excuse me if I'm wrong but it seems like you
are equating</span></font></p>

</blockquote>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>'publically accessible' to 'publically addressable'.
 They need not  </span></font></p>

</blockquote>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>be the</span></font></p>

</blockquote>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>same thing as per earlier parts of the thread.</span></font></p>

</blockquote>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'><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>
<br>
</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>I would not allow my</span></font></p>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>appliances to be publically accessible but I'm fine
with them being</span></font></p>

</blockquote>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>publically addressable.</span></font></p>

</blockquote>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'><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</span></font></p>

</div>

</div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>

<span style='orphans: 2;text-align:auto;widows: 2;-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;word-spacing:0px'>

<div apple-content-edited=true>

<div style='word-wrap: break-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=1 color=black
face=Helvetica><span style='font-size:7.0pt;font-family:Helvetica;color:black'>-- <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>                                   </span>   
 Mobile: +61-419-900-366<br>
Reception: +61-8-8228-2999        Fax: +61-8-8235-6909</span></font></p>

</div>

</div>

</div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'></span> </span></font></p>

</div>

</div>

</body>

</html>