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

Fri Aug 1 11:48:08 EST 2008

The problem that Chris (Hi!) is talking about is where a higher layer
protocol starts to embed IP addresses
or port numbers.

The traditional one is FTP.  The firewall protected FTP client opens the
control channel and passes the data channel
port number that it is listening on to the server.  The server is then
meant to open a TCP connection
to that port.  This commonly causes a firewall to rewrite the port
number inside the FTP message to one
that is free on the public side.

The main one people have to deal with today is SIP.  It passes the IP
address over for the RTP over UDP
session.  This is commonly not the same as the SIP client. (e.g. media
gateways.)

Imagine that you are using a PBX and dial out to somebody.  When they
ask you for your phone number,
you are pretty stuffed.  NAT is the same problem.

Scott

________________________________

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

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.

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

-----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

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

_____________________________________________________________________ 
This e-mail has been scanned for viruses by MCI's Internet Managed 
Scanning Services - powered by MessageLabs. For further information 
visit http://www.mci.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20080801/b6f502c0/attachment.html>