[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