[97299] in North American Network Operators' Group
Re: Security gain from NAT: Top 5
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jun 7 00:45:26 2007
In-Reply-To: <20070606194041.F57414@eboyr.pbz>
Cc: North American Network Operators Group <nanog@merit.edu>
From: Owen DeLong <owen@delong.com>
Date: Wed, 6 Jun 2007 21:43:30 -0700
To: Roger Marquis <marquis@roble.com>
Errors-To: owner-nanog@merit.edu
--Apple-Mail-102-1020747823
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
> #1 NAT advantage: it protects consumers from vendor
> lock-in.
>
Speaking of FUD... NAT does nothing here that is not also accomplished
through the use of PI addressing.
>
> #2 NAT advantage: it protects consumers from add-on
> fees for addresses space.
>
More FUD. The correct solution to this problem is to make it possible
for end users to get reasonable addresses directly from RIRs for
reasonable fees.
>
> #3 NAT advantage: it prevents upstreams from limiting
> consumers' internal address space.
>
Regardless of the amount of growth, do you really see the likelihood
of any household _EVER_ needing more than 65,536 subnets?
I don't even know the exact result of multiplying out 16*1024^6, but,
I'm betting you can't fill 65,536 subnets that big ever no matter how
hard you try. So, again, I say FUD.
> #4 NAT advantage: it requires new protocols to adhere to
> the ISO seven layer model.
>
Quite the contrary... NAT has encouraged the development of hack upon
hack to accommodate these protocols. Please explain to me how you
would engineer a call setup-tear-down protocol for an independent
audio stream that didn't require you to embed addresses in the payload.
Until you can solve this problem, we will have to have protocols that
break this model. Other than from some sort of ISO purity model
(notice how popular OSI networking is today, compared to IP?), SIP
is actually a pretty clean solution to a surprisingly hard problem.
Unless you have a better alternative for the same capabilities, I'm
not buying it. We shouldn't have to give up useful features for
architectural purity. If the architecture can't accommodate real world
requirements, it is not the requirements that are broken.
That's sort of like saying that OSPF and BGP break the ISO layer model
because they talk about layer three addresses in layer 4-7 payload.
Heck, even ISIS is broken by that definition. Again, I cry FUD.
> #5 NAT advantage: it does not require replacement security
> measures to protect against netscans, portscans, broadcasts
> (particularly microsoft's netbios), and other malicious
> inbound traffic.
>
??? This is pure FUD and patently untrue. Example: About the cheapest
NAT capable firewall you can buy is a Linksys WRT-54G. If you put
real addresses on both sides of it and change a single checkbox in the
configuration GUI, you end up with a Stateful Inspection firewall that
gives you all the same security you had with the NAT, but, without the
penalties imposed by NAT.
Until you can show me a box that is more than USD 40 cheaper than
a WRT-54G that cannot have NAT turned off, again, I cry FUD.
Oh, btw, a WRT-54G sells for about USD 40 last time I bought one
brand new at Best Buy, so, that's a pretty hard metric to meet.
> These are just some of the reasons why NAT is, and will continue to
> be, an increasingly popular technology for much more than address
> conservation.
>
Since each and every one of them is FUD, that is certainly the pot
calling
the kettle black. Unfortunately, time and again, american politics has
proven that FUD is a successful marketing tactic, so, you are probably
right, there will probably be a sufficient critical mass of ignorant
consumers
and vendors that will buy into said FUD and avoid the real solution
in favor of continuing the abomination that is NAT and all the baggage
of STUN, difficult debugging, header mangling, address conflicts,
and the rest that tends to come with it.
Owen
--Apple-Mail-102-1020747823
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw
ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER
MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE
ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ
KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow
fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP
MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl
bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY
0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1
V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb
Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G
QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu
EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8
UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA
MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH
K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL
/euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX
zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT
CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl
cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ
ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA2MDcwNDQzMzFaMCMGCSqGSIb3DQEJBDEWBBSnzaXFHiwr
ahJPJKDi4F50kOwdpTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG
A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv
bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU
MA0GCSqGSIb3DQEBAQUABIIBAKaUy/db6SwY1SkBToYW3S2C/BHp9QPnVhaPLFCuXhx/rElDLUXe
MBfeIcEh4oJ9Fa1PsnUzCwddoTbndzT+polbwbBuKYYZA2QZiu/2F23Gppyid+ToejzDCRrHzPWx
6CAxefVzMGUigkgXp9GK6CkpeSvj7Sguk8CAjofF4/vKPyGc1X7bKPQLyKjiYfdIHobI4bX3YgV6
iV8a+Y3iw1AqLD6cS8/dhMT2xnF4iIt+s13SCskAQAGX7z5ULmLDUqGwsae2Q4Ch0vljuYaQ4U+s
iaycQWKUaoNqkYRDqZsdOLx+LGc2yYNhUfQ0OXyXWLpCxQN2M3RbztOg/41sH1AAAAAAAAA=
--Apple-Mail-102-1020747823--
