Re: Rate of growth on IPv6 not fast enough?
William Herrin wrote:
Not to take issue with either statement in particular, but I think there needs to be some consideration of what "fail" means.
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed.
In addition to fail-closed NAT also means: * search engines and and connectivity providers cannot (easily) differentiate and/or monitor your internal hosts, and * multiple routes do not have to be announced or otherwise accommodated by internal re-addressing. Roger Marquis
On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote:
William Herrin wrote:
Not to take issue with either statement in particular, but I think there needs to be some consideration of what "fail" means.
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed.
In addition to fail-closed NAT also means:
* search engines and and connectivity providers cannot (easily) differentiate and/or monitor your internal hosts, and
Right, because nobody has figured out Javascript and Cookies.
* multiple routes do not have to be announced or otherwise accommodated by internal re-addressing.
I fail to see how NAT even affects this in a properly structured network. Owen
The whole thread made me thought about this: http://www.ipinc.net/IPv4.GIF The energy that people are willing to spend to fix it (NAT, LSN), rather than bite the bullet is amazing.
I am looking for a technical contact inside the IANA regarding their internal network if anyone knows one. Todd Glassey
On Thu, 22 Apr 2010 18:10:10 +1200 (MAGST) Franck Martin <franck@genius.com> wrote:
The whole thread made me thought about this:
The energy that people are willing to spend to fix it (NAT, LSN), rather than bite the bullet is amazing.
Probably and sadly, they don't remember the Internet before NAT. I think Brantley Colie has somewhat redeemed himself by inventing ATA over Ethernet. http://www.coraid.com/COMPANY/Management Also, sadly, even though I'm an strong IPv6 advocate, I think a period of LSN/GCN is inevitable. There's now not enough time to properly convert from IPv4 to IPv6, and, also sadly, Jon Postel isn't around anymore to make subtle and veiled threats of loss of connectivity .. (http://www.rfc-editor.org/in-notes/museum/tcp-ip-digest/tcp-ip-digest.v1n6.1) ------------------------------ From: POSTEL at USC-ISIF Subject: Disabling NCPs There has been some talk of "forcing" the move to TCP by various administrative and policy measures. There was also a claim that there was no technical way to force the abandonment of NCP. It should be pointed out that a quite simple modification to the IMP program would enable the IMPs to filter out and discard all NCP traffic. As far as i know, there has been no decision to do this, but you should be aware that it is technical feasible. --jon. ------------------------------
On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong <owen@delong.com> wrote:
On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote:
William Herrin wrote:
Not to take issue with either statement in particular, but I think there needs to be some consideration of what "fail" means.
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed.
In addition to fail-closed NAT also means:
* search engines and and connectivity providers cannot (easily) differentiate and/or monitor your internal hosts, and
Right, because nobody has figured out Javascript and Cookies.
Having worked for comScore, I can tell you that having a fixed address in the lower 64 bits would make their jobs oh so much easier. Cookies and javascript are of very limited utility. On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6.
* multiple routes do not have to be announced or otherwise accommodated by internal re-addressing.
I fail to see how NAT even affects this in a properly structured network.
That's your failure, not Roger's. As delivered, IPv6 is capable of dynamically assigning addresses from multiple subnets to a PC, but that's where the support for multiple-PA multihoming stops. PCs don't do so well at using more than one of those addresses at a time for outbound connections. As a number of vendors have done with IPv4, an IPv6 NAT box at the network border can spread outbound connections between multiply addressed upstream links. On Thu, Apr 22, 2010 at 2:10 AM, Franck Martin <franck@genius.com> wrote:
http://www.ipinc.net/IPv4.GIF The energy that people are willing to spend to fix it (NAT, LSN), rather than bite the bullet is amazing.
A friend of mine drives a 1976 Cadillac El Dorado. I asked him why once. He explained that even at 8 miles to the gallon and even after having to find 1970's parts for it, he can't get anything close to as luxurious a car from the more modern offerings at anything close to the comparatively small amount of money he spends. The thing has plush leather seats that feel like sinking in to a comfy couch and an engine with more horsepower than my mustang gt. It isn't hard to see his point. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6.
the idea is covered by one or more patents held by cisco. --bill
Regards, Bill Herrin
On Thu, Apr 22, 2010 at 7:30 AM, <bmanning@vacation.karoshi.com> wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6.
the idea is covered by one or more patents held by cisco.
Won't stop the worms from using it to hide which PC they're living on. -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Apr 22, 2010 at 07:46:50AM -0400, William Herrin wrote:
On Thu, Apr 22, 2010 at 7:30 AM, <bmanning@vacation.karoshi.com> wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6.
the idea is covered by one or more patents held by cisco.
Won't stop the worms from using it to hide which PC they're living on.
no... but then you just block the /32 and your fine... :) kind of like how people now block /8s for ranges that are "messy" --bill
On Apr 22, 2010, at 4:30 AM, bmanning@vacation.karoshi.com wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6.
the idea is covered by one or more patents held by cisco.
--bill
Regards, Bill Herrin
It's default behavior in Windows 7 and is specified in an RFC. Look for IPv6 Privacy Addressing. Owen
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/2010 05:34, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
Simon I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently.
Of course, for browsers, as someone else mentioned, it's somewhat moot because of cookies. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvQR1IACgkQ2fXFxl4S7sT0agCglqjxX9d2kYuadrreIqPo5+rN FMAAniW1GodHwArieT/Czd96aMGQTgEF =xYjP -----END PGP SIGNATURE-----
On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/22/2010 05:34, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
Simon I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently.
4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address. Owen
Owen DeLong wrote:
On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/22/2010 05:34, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
Simon
I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently.
4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address.
Owen
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from. Matthew Kaufman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/2010 22:18, Matthew Kaufman wrote:
Owen DeLong wrote:
On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/22/2010 05:34, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
Simon
I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently.
4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address.
Owen
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Matthew Kaufman Yeh that information leak is one reason I can think of for supporting NAT for IPv6. One of the inherent security issues with unique addresses I suppose. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvRMCsACgkQ2fXFxl4S7sShwACgpZEd1rQD+/+dxonkOVpwPaUj oBIAoOJ78A5Yvftfz+JPjGWWQoVhb6F8 =oQHv -----END PGP SIGNATURE-----
Matthew Kaufman wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. Jack
On Apr 23, 2010, at 6:17 AM, Jack Bates wrote:
Matthew Kaufman wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks.
Jack
That is sad news, indeed. Hopefully it won't lead to NAT-T becoming a common part of software as the ISVs catch on to IPv6. Owen
Matthew Kaufman wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And
Jack Bates wrote: preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information) Matthew Kaufman
Matthew Kaufman wrote:
Jack Bates wrote:
Matthew Kaufman wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information)
And to further clarify, I don't think "hide internal topology" is actually something that needs to happen (and can show several ways in which it can be completely violated, including using the browser and/or browser plugins to extract the internal addresses and send them to a server somewhere which can map it all out). But it *is* present as a mandatory checklist item on at least one HIPPA and two SOX audit checklists I've seen,.. and IT departments in major corporations care much more these days about getting a clean SOX audit than they do about providing connectivity... and given how each affects the stock price, that's not surprising. Matthew Kaufman
On Apr 23, 2010, at 10:34 AM, Matthew Kaufman wrote:
Matthew Kaufman wrote:
Jack Bates wrote:
Matthew Kaufman wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information)
And to further clarify, I don't think "hide internal topology" is actually something that needs to happen (and can show several ways in which it can be completely violated, including using the browser and/or browser plugins to extract the internal addresses and send them to a server somewhere which can map it all out). But it *is* present as a mandatory checklist item on at least one HIPPA and two SOX audit checklists I've seen,.. and IT departments in major corporations care much more these days about getting a clean SOX audit than they do about providing connectivity... and given how each affects the stock price, that's not surprising.
Matthew Kaufman
Yes, much education is required to the audit community. Owen
On Apr 23, 2010, at 10:16 AM, Matthew Kaufman wrote:
Jack Bates wrote:
Matthew Kaufman wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks. Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information)
So can TCP fingerprinting and several other techniques. Finally, the belief that hiding the number of subnets or which hosts share subnets is a meaningful enhancement to security is dubious at best. Owen
Owen DeLong wrote:
On Apr 23, 2010, at 10:16 AM, Matthew Kaufman wrote:
Jack Bates wrote:
Matthew Kaufman wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Which is why some firewalls already support NAT for IPv6 in some form or fashion. These same firewalls will also usually have layer 7 proxy/filtering support as well. The concerns and breakage of a corporate network are extreme compared to non-corporate networks.
Agreed on the last point. And I'm following up mostly because I've received quite a few private messages that resulted from folks interpreting "hide internal topology" as "block access to internal topology" (which can be done with filters). What I mean when I say "hide internal topology" is that a passive observer on the outside, looking at something like web server access logs, cannot tell how many subnets are inside the corporation or which accesses come from which subnets. (And preferably, cannot tell whether or not two different accesses came from the same host or different hosts simply by examining the IP addresses... but yes, application-level cooperation -- in the form of a browser which keeps cookies, as an example -- can again expose that type of information)
So can TCP fingerprinting and several other techniques.
Finally, the belief that hiding the number of subnets or which hosts share subnets is a meaningful enhancement to security is dubious at best.
Agreed, but see my own followup to myself. Entirely dubious, and yet entirely required by audit checklists which feed up into SEC reporting which affects stock prices. Matthew Kaufman
On 04/22/2010 10:18 PM, Matthew Kaufman wrote:
Owen DeLong wrote:
On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/22/2010 05:34, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
Simon
I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently.
4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address.
Owen
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Does your nat box reset or non-determisitically rewrite the ttl on the outgoing packet? ALGs are dramatically better topology hiding devices...
Matthew Kaufman
On Thu, 22 Apr 2010 22:18:56 -0700 Matthew Kaufman <matthew@matthew.at> wrote:
Owen DeLong wrote:
On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/22/2010 05:34, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
Simon
I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently.
4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address.
Owen
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Are you saying that hiding network topology is going to be your only security measure to protect these systems? Yikes! How about (a) having them authenticate people who try to use them (b) have those people use two factor authentication (c) not co-locating them on the same subnet (with a /48 you could give many of your vital hosts their own individaul subnet) i.e. fundamentally, don't use subnets as a security domain boundary (d) not setting reverse DNS names that give away what the hosts are for (e) not providing them with globally routable addresses in the first place Obscurity is a cheap and easy first level defence in depth measure. However it'll only fool the stupid and mostly uninterested attacker. Any attacker who's determined will easily bypass this obscurity, via malware, key sniffers, guessable passwords, black bag jobs, theats of violence and bribery. If obscurity is such an effective measure why are zebras also able to run fast and kick hard?
Am 25.04.2010 um 03:29 schrieb Mark Smith:
If obscurity is such an effective measure why are zebras also able to run fast and kick hard?
Because the stripes hide them from the flies, not the lions. http://en.wikipedia.org/wiki/Zebra#cite_note-5 -- Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
On Apr 24, 2010, at 6:29 PM, Mark Smith wrote:
On Thu, 22 Apr 2010 22:18:56 -0700 Matthew Kaufman <matthew@matthew.at> wrote:
Owen DeLong wrote:
On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/22/2010 05:34, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
Simon
I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently.
4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address.
Owen
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Are you saying that hiding network topology is going to be your only security measure to protect these systems? Yikes!
I doubt that's what he is saying, but, I do think he over-emphasizes the value of obscurity...
How about
(a) having them authenticate people who try to use them (b) have those people use two factor authentication (c) not co-locating them on the same subnet (with a /48 you could give many of your vital hosts their own individaul subnet) i.e. fundamentally, don't use subnets as a security domain boundary (d) not setting reverse DNS names that give away what the hosts are for (e) not providing them with globally routable addresses in the first place
None of these are mutually exclusive with obscurity.
Obscurity is a cheap and easy first level defence in depth measure. However it'll only fool the stupid and mostly uninterested attacker. Any attacker who's determined will easily bypass this obscurity, via malware, key sniffers, guessable passwords, black bag jobs, theats of violence and bribery.
And, to follow that up, any attacker who would be somehow blocked or even impeded by this obscurity today would be just as effectively blocked by the other measures above (if not more so) without such obscurity. Obscurity is of very limited value to security. If there is a significant cost to it (and there is a significant cost to NAT), then, the value proposition is easily lost. Owen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/2010 22:00, Owen DeLong wrote:
On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/22/2010 05:34, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
Simon I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently.
4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address.
Owen
K. Can't say I've read the RFC all the way through (skimmed it). Current implementations do the time thing. XP, Vista, and 7 seem to have it turned on by default. *nix has support via the "net.ipv6.conf.all.use_tempaddr=2" variable, typically not on by default. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRLkUACgkQ2fXFxl4S7sQ2YgCg3uSkp1GNxcgjCDVc1jxnDv7s DtoAniXH8nND7+r6xEFJXGHrRJ77CBkZ =eSHI -----END PGP SIGNATURE-----
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Matthew Kaufman
Yeh that information leak is one reason I can think of for supporting NAT for IPv6. One of the inherent security issues with unique addresses I suppose. <flame-suit-on>
What makes you think that not using NAT exposes internal topology?? I have many cases where either filtering at layer-2 or NAT'ing a /48 for itself (or proxy-arp for those that do not have kits that can NAT IP blocks as itself) does NOT expose internal topology. Get your filtering correctly setup, and there is no use for NAT/PAT in v6. NAT was designed with one puropose in mind ..... extending the life of v4... period! The so called security that most think NAT gives them is a side effect. NAT/PAT also breaks several protocols (PASV FTP, H.323, etc) and I for one will be happy to see it go. I think it's a mistake to include NAT in v6 because there are other methodologies of accomplishing all of the side effects that everyone is use to seeing NAT provide without having to actually translate IP's or ports. I for one (as well as alot of other folks I know) am not/will not be using any kind of NAT moving forward. </flame-suit-on>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/23/2010 06:17, Clue Store wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Matthew Kaufman
Yeh that information leak is one reason I can think of for supporting NAT for IPv6. One of the inherent security issues with unique addresses I suppose.
<flame-suit-on>
What makes you think that not using NAT exposes internal topology?? I have many cases where either filtering at layer-2 or NAT'ing a /48 for itself (or proxy-arp for those that do not have kits that can NAT IP blocks as itself) does NOT expose internal topology. Get your filtering correctly setup, and there is no use for NAT/PAT in v6.
NAT was designed with one puropose in mind ..... extending the life of v4... period! The so called security that most think NAT gives them is a side effect. NAT/PAT also breaks several protocols (PASV FTP, H.323, etc) and I for one will be happy to see it go. I think it's a mistake to include NAT in v6 because there are other methodologies of accomplishing all of the side effects that everyone is use to seeing NAT provide without having to actually translate IP's or ports.
I for one (as well as alot of other folks I know) am not/will not be using any kind of NAT moving forward.
</flame-suit-on>
I'm not really advocating NAT for v6. I'm just saying it's one valid security issue with using any sort of globally unique IP address (v4 or v6), in that analyzing a bunch of traffic from a particular netblock would allow one to build a topology map. It's easier with IPv6 since you can presume most if not all addresses are on /64s out of a /48 (so look to the fourth quad for the "subnet ID"). Obviously if someone is super concerned with revealing this sort of info there are other things besides NAT they can do, such as using a proxy server(s) for various internet applications, transparent proxies, etc. But it is a valid security concern for some. Also, is that your real name? ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRozwACgkQ2fXFxl4S7sSACQCfeRfk5VmKjkW2SYkn/gZl53Ng Q0cAoKsQTGdTTBaEg1paE44yTNVy2OSQ =WAPA -----END PGP SIGNATURE-----
I'm just saying it's one valid security issue with using any sort of globally unique IP address (v4 or v6), in that analyzing a bunch of traffic from a particular netblock would allow one to build a topology map. It's easier with IPv6 since you can presume most if not all addresses are on /64s out of a /48 (so look to the fourth quad for the "subnet ID").
I understand and totally agree.
Obviously if someone is super concerned with revealing this sort of info there are other things besides NAT they can do, such as using a proxy server(s) for various internet applications, transparent proxies, etc. But it is a valid security concern for some.
Could not agree more which is why I stated that there are other ways of accomplishing the "hiding internal topology" using other methodoligies. NAT/PAT has caused me many headaches which is why I am so opposed to using it.
Also, is that your real name? ;-)
No, but this list is great for buying and selling clue. In today's market, clue is equivalent to gold. :)
On Apr 23, 2010, at 9:17 AM, Clue Store wrote:
But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from.
Matthew Kaufman
Yeh that information leak is one reason I can think of for supporting NAT for IPv6. One of the inherent security issues with unique addresses I suppose. <flame-suit-on>
What makes you think that not using NAT exposes internal topology??
Or that internal topology cannot leak out through NAT's ? I have seen NATed enterprises become massively compromised. Regards Marshall
I have many cases where either filtering at layer-2 or NAT'ing a /48 for itself (or proxy-arp for those that do not have kits that can NAT IP blocks as itself) does NOT expose internal topology. Get your filtering correctly setup, and there is no use for NAT/PAT in v6.
NAT was designed with one puropose in mind ..... extending the life of v4... period! The so called security that most think NAT gives them is a side effect. NAT/PAT also breaks several protocols (PASV FTP, H.323, etc) and I for one will be happy to see it go. I think it's a mistake to include NAT in v6 because there are other methodologies of accomplishing all of the side effects that everyone is use to seeing NAT provide without having to actually translate IP's or ports.
I for one (as well as alot of other folks I know) am not/will not be using any kind of NAT moving forward.
</flame-suit-on>
What makes you think that not using NAT exposes internal topology??
Or that internal topology cannot leak out through NAT's ? I have seen NATed enterprises become massively compromised.
NAT allows people to become far too lazy. Your typical NAT allows connections outbound, typically configured without any audit trail, etc., so once a bad guy is inside the "secure NAT firewall," they're free to connect out to the 'net. In comparison, an actual real firewall can prohibit {most, all} outbound access and force the use of proxies. Proxies can provide logging, content scanning, etc., services. Many times, those who argue in favor of NAT as a "firewall" are the same ones who seem to actually be relying on the NAT as inbound protection, but who aren't really doing anything to control their outbound traffic, or IDS, etc. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection. --bill
That's Hedley. -----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Thursday, April 22, 2010 10:34 AM To: Simon Perreault Cc: nanog@nanog.org Subject: Re: Rate of growth on IPv6 not fast enough? On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection. --bill
Actually, no. Not from the Mel Brooks movie. Hedy Lamarr http://en.wikipedia.org/wiki/Hedy_Lamarr Hedy Lamarr (November 9, 1914 - January 19, 2000) was an Austrian-born American actress and engineer. Though known primarily for her film career as a major contract star of MGM's "Golden Age", she also co-invented an early form of spread spectrum communications technology, a key to modern wireless communication.[1] ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139
-----Original Message----- From: John Lightfoot [mailto:jlightfoot@gmail.com] Sent: Thursday, April 22, 2010 11:05 AM To: bmanning@vacation.karoshi.com; 'Simon Perreault' Cc: nanog@nanog.org Subject: RE: Rate of growth on IPv6 not fast enough?
That's Hedley.
-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Thursday, April 22, 2010 10:34 AM To: Simon Perreault Cc: nanog@nanog.org Subject: Re: Rate of growth on IPv6 not fast enough?
On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection.
--bill
I think he was actually quoting the movie. They always called Harvey Korman's character "Hedy" and he'd always correct them with "That's Hedley" in a most disapproving tone. You had to have watched that movie way too many times (much to my wife's chagrin) to catch the subtle joke. On Thu, Apr 22, 2010 at 11:10 AM, Matthew Huff <mhuff@ox.com> wrote:
Actually, no.
Not from the Mel Brooks movie.
Hedy Lamarr
http://en.wikipedia.org/wiki/Hedy_Lamarr
Hedy Lamarr (November 9, 1914 - January 19, 2000) was an Austrian-born American actress and engineer. Though known primarily for her film career as a major contract star of MGM's "Golden Age", she also co-invented an early form of spread spectrum communications technology, a key to modern wireless communication.[1]
---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139
-----Original Message----- From: John Lightfoot [mailto:jlightfoot@gmail.com] Sent: Thursday, April 22, 2010 11:05 AM To: bmanning@vacation.karoshi.com; 'Simon Perreault' Cc: nanog@nanog.org Subject: RE: Rate of growth on IPv6 not fast enough?
That's Hedley.
-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Thursday, April 22, 2010 10:34 AM To: Simon Perreault Cc: nanog@nanog.org Subject: Re: Rate of growth on IPv6 not fast enough?
On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection.
--bill
On 4/22/2010 10:17, Charles Mills wrote:
I think he was actually quoting the movie. They always called Harvey Korman's character "Hedy" and he'd always correct them with "That's Hedley" in a most disapproving tone.
Oh. The only thing I watch less-of than TV is movies. Say....did they ever make a sequel to "Crocodile Dundee"? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Thu, 22 Apr 2010 10:25:43 -0500 Larry Sheldon <LarrySheldon@cox.net> wrote:
On 4/22/2010 10:17, Charles Mills wrote:
I think he was actually quoting the movie. They always called Harvey Korman's character "Hedy" and he'd always correct them with "That's Hedley" in a most disapproving tone.
Oh.
The only thing I watch less-of than TV is movies.
Say....did they ever make a sequel to "Crocodile Dundee"? --
Yep. Every Australian has probably seen that too. http://www.imdb.com/title/tt0092493/ (you have no idea how big our butter knives are these days, all because of that movie)
Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner.
Freedom under a constitutional republic is a well armed lamb contesting the vote.
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On 4/22/2010 10:04, John Lightfoot wrote:
That's Hedley.
-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Thursday, April 22, 2010 10:34 AM To: Simon Perreault Cc: nanog@nanog.org Subject: Re: Rate of growth on IPv6 not fast enough?
On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection.
Hedwig Eva Maria Kiesler aka Hedy Lamarr -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Apr 22, 2010, at 11:04 AM, John Lightfoot wrote:
That's Hedley.
I believe that he is talking about Hedy Lamarr, the co-inventor of frequency hopping spread spectrum. Regards Marshall
-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com ] Sent: Thursday, April 22, 2010 10:34 AM To: Simon Perreault Cc: nanog@nanog.org Subject: Re: Rate of growth on IPv6 not fast enough?
On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection.
--bill
On 04/22/2010 08:25 AM, Marshall Eubanks wrote:
On Apr 22, 2010, at 11:04 AM, John Lightfoot wrote:
That's Hedley.
I believe that he is talking about Hedy Lamarr, the co-inventor of frequency hopping spread spectrum.
The patent which bears her and George Antheil's name is by no means (and about 30 years) the earliest example of this technology.
Regards Marshall
-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Thursday, April 22, 2010 10:34 AM To: Simon Perreault Cc: nanog@nanog.org Subject: Re: Rate of growth on IPv6 not fast enough?
On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes.
That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of.
not RFC4941... think abt applying Heddy Lamars patents on spread-spectrum to source address selection.
--bill
On 4/24/2010 14:07, Joel Jaeggli wrote:
The patent which bears her and George Antheil's name is by no means (and about 30 years) the earliest example of this technology.
Few patents are. I can't think of a one, but I suppose there must be one containing no prior art at all. Does a movie star of the startlingly attractive persuasion being an accomplished engineer bother you? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Thu, 22 Apr 2010, William Herrin wrote:
On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong <owen@delong.com> wrote:
On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote:
William Herrin wrote:
Not to take issue with either statement in particular, but I think there needs to be some consideration of what "fail" means.
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed.
In addition to fail-closed NAT also means:
* search engines and and connectivity providers cannot (easily) differentiate and/or monitor your internal hosts, and
Right, because nobody has figured out Javascript and Cookies.
Having worked for comScore, I can tell you that having a fixed address in the lower 64 bits would make their jobs oh so much easier. Cookies and javascript are of very limited utility.
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6.
See RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Regards, Janos Mohacsi
On Thu, 22 Apr 2010 07:18:18 -0400 William Herrin <bill@herrin.us> wrote:
On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong <owen@delong.com> wrote:
On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote:
William Herrin wrote:
Not to take issue with either statement in particular, but I think there needs to be some consideration of what "fail" means.
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed.
In addition to fail-closed NAT also means:
* search engines and and connectivity providers cannot (easily) differentiate and/or monitor your internal hosts, and
Right, because nobody has figured out Javascript and Cookies.
Having worked for comScore, I can tell you that having a fixed address in the lower 64 bits would make their jobs oh so much easier. Cookies and javascript are of very limited utility.
On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6.
Might be this - "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host." by Peter M. Gleitz and Steven M. Bellovin (i.e. the Steven Bellovin who shows up on this list quite often) http://www.cs.columbia.edu/~smb/papers/tarp.pdf
* multiple routes do not have to be announced or otherwise accommodated by internal re-addressing.
I fail to see how NAT even affects this in a properly structured network.
That's your failure, not Roger's. As delivered, IPv6 is capable of dynamically assigning addresses from multiple subnets to a PC, but that's where the support for multiple-PA multihoming stops. PCs don't do so well at using more than one of those addresses at a time for outbound connections. As a number of vendors have done with IPv4, an IPv6 NAT box at the network border can spread outbound connections between multiply addressed upstream links.
On Thu, Apr 22, 2010 at 2:10 AM, Franck Martin <franck@genius.com> wrote:
http://www.ipinc.net/IPv4.GIF The energy that people are willing to spend to fix it (NAT, LSN), rather than bite the bullet is amazing.
A friend of mine drives a 1976 Cadillac El Dorado. I asked him why once. He explained that even at 8 miles to the gallon and even after having to find 1970's parts for it, he can't get anything close to as luxurious a car from the more modern offerings at anything close to the comparatively small amount of money he spends.
The thing has plush leather seats that feel like sinking in to a comfy couch and an engine with more horsepower than my mustang gt. It isn't hard to see his point.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (21)
-
bmanning＠vacation.karoshi.com -
Charles Mills -
Clue Store -
Franck Martin -
Jack Bates -
Jim Burwell -
Joe Greco -
Joel Jaeggli -
John Lightfoot -
Larry Sheldon -
Mark Smith -
Marshall Eubanks -
Matthew Huff -
Matthew Kaufman -
Mohacsi Janos -
Owen DeLong -
Roger Marquis -
Simon Perreault -
Stefan Bethke -
todd glassey -
William Herrin