Extending IPv4 with source translation/source privacy.

There's your mistake. You cannot talk about "the" path from source to destination because in general there are multiple paths and different packets in the same TCP flow might travel by different routes.

NAT, which you mention in a later post, only works because everyone in the private address space is behind a single router. (One could presumably implement some sort of co-operative NAT if you had multiple boundary routers, but this certainly isn't how it works in the average home or small office.) That single router is, of course, also a single point of failure, so your proposal actually depends on something that some people would reckon was a problem.

The gateway protocols 4to6 and 6to4 perform such translations in a low-state fashion, and have provisions for permanent translations.

We are burying the world in NAT, and yet more NAT. It is time to set the net free, and get bigger addresses.

The error that people do when they try this is to do ipv6 over ipv4. You have to convert, and run ipv4 on ipv6. The entire address room of ipv4 fits in a little corner of ipv6, so you can do this. Linux and FreeBSD do this almost automatically if there is 6to4 support somwhere in the network.

You can then run privacy schemes in the ipv6 backbone. You just make an extension header to a private protocol. Or you could run ipsec.

-- mrr

In comp.dcom.lans.ethernet Morten Reistad wrote in part:

Perhaps. But why go from 32-bits all the way to 128? It goes against the grain to agree with Skybuck Flying, but aside from the additional overhead, there are serious privacy concerns -- some of these bits will get used for persistant identifiers (MAC) and some governments may mandate some for social numbers.

The nice thing about IPv4 is it _has_ all this DHCP and NAT. It is difficult to identify any particular user, and impossible once logs expire (1wk-2yr). With IPv6, it would be possible for anyone to do so, and long after the fact.

-- Robert

I voted for Tuba (64 bits) in the Big Vote. We lost. So

128 bits it is, and all options moved to extension headers. Apart from that, and some dns etc support to handle it there is not a big change.

It is easier to translate ipv4 "half-nat" nat64 into ipv4 than it is to do ipv4 NAT, expecially when the two are stacked. One big difference is that ipv6 has addresses to burn so you can map stuff to addresses instead of to internal tables.

This is purely "anonymity by obscurity". If we really want an anonymous service we have to use tor-like techniques; and then we need more adresses for it to resist attacks.

"security by obscurity" does not work, nor does it provide anonymity.

There are bit scramblers for the ipv6 visible mac address. These are trivial to deploy in the router OS'es I use, and they can be configured not to have persistent state (surviving a reboot) easily.

rtadvd does not assign an ip address, it just tells you what the network is, where the routers and core servers are. You then assign yourself your own IP address based on some transformation of your IP address. This transformation can be a one-way trap door function; there are enough bits available for that. Supported in windows since xp sp2, openbsd since 3.6, freebsd since 5.something, linux since some early 2.4 kame.

So, it you want to deploy an IPv6 network where no server carries state from the endpoints it is possible to do so. Just as it was on the IPv4 network up until 1992 or so.

Whenever there is persistant server state, there will be logs. DHCP to mac assignments that must be somewhat persistent, NAT tables; and these usually follow some quite predictable patterns.

I am more than willing to allow for twice as big a header for that. Actually, about 2/3rds the traffic out of my home office is ipv6 now. It was a liberation to be able to squander addresses again.

And, remarkably, the ipv6 implementatons are generally better. They handle ip fragmentation a lot better, and source quenches etc are respected. Even if the ipv6 network is tunnelled on top of ipv4 access lines, it is noticably faster.

-- mrr

Hello,

Robert Redelmeier a écrit :

What's so nice about NAT and DHCP ? IPv6 has its own version of DHCP too, DHCPv6.

Maybe you haven't heard about IPv6 privacy extensions and temporary addresses.

I disagree with this meme. There is no absolute security or anonymity by _any_ means. All can be penetrated by sufficiently advanced countermeasures. Security is a continuum, not discrete. The point is to elevate the cost of the attack such that it is not in widespread use, especially long after the fact.

I have no particular problem with law enforcement violating security or anonymity, preferably with probable cause under the supervision of some court. But if not, simply making it difficult will achieve much the same ends. If it is difficult, even the most nefarious police will have trouble doing much.

In this sense the horrible mixup that is DHCP and NAT are useful obscurants. Furthermore, they are pretty much obligatory under IPv4. Under IPv6, an interventionist government (who else controls the police?) could easily ban all the privacy extentions and refuse to pass/flag packets with scrambled MACs.

Sorry about Tuba, but I don't think IPv6 is inevitable. Newer-better does not always win. Blu-ray isn't so healthy.

-- Robert

With "security by obscurity" you make a dent in the continuum. It may work for a while, until someone finds out what you are doing, and then the "security" implodes. Much like a virus attack.

So, tell me, how are they to avoid this; considering that this is a default behaviour in the latest windows versions?

And, if you use something like openbsd, there are no bits saying "this is a scrambled mac address". You cannot filter what isn't tagged in the first place.

For obscuring an address, a 4to6, a tranmission section to a different jurisdiction, and then a 6to4 are way better.

No, ipv6 will live in the fringes, just like ipv4 did from

1986 to 1995. Meanwhile ipv4 will decay to become a nightmare for anyone doing stuff that is only slightly beyond mainstream.

Already you can expect your external IP to flap wildly on some carrier implementations.

-- mrr

"Obscurity" is not a single thing -- even crypto keys may be said to be only obscure and not secure. Obscurity may be very obscure when humans have to get involved to retrieve logs. Not at all like an automated attack.

I would be _very_ surprised if MAC scrambling were part of MS-Windows in any default config. A number of [cable] ISPs still use MAC for authentication, as do a number of corporate router security schemes. MS may be many things, but they usually default in favor of their direct customers (PC mfrs) interests -- reducing support calls.

Sure you can -- whitelist rather than blacklist on border routers. No good MAC -- bitbucket or worse.

And only when IPv4 becomes totally unworkable for a critical mass of users (~30%?) will the switch happen.

"wildly" is a vague adjective -- how fast? I've seen some DHCPs last _years_ although most last only days/week. For current services, I see little problem and in fact _benefits_ for the ISP

-- they charge more for static IPs, and relatively few users need external accessiblity. For those few, DDNS and proprietary DNS (Pogoplug/Cloud) work OK. Most other users would rather _not_ have external access if they ever thought about it. Perhaps some compeling service will come along, but I don't see it.

-- Robert

The point about this saying is that you should be able to publish your methods; software etc and rely on easily changable keys for your security and privacy.

RFC3041. Generating random identifiers for use outside the current subnet. Enabled by default in windows server >= 2003, and in xp at some service pack level (ISTR sp1). So, you _cannot_ use the EUI-64 as a path to the mac address.

The local administrator can do so. But outside the local LAN such schemes will not work with rfc3041. This is on purpose.

We are already in the morass of decay. Corporate users should think hard about a switch already. Simple deployment and some router intelligence using already 5 year old standards will solve a lot of problems, keeping the ipv4 stack on local machines if they need it.

I have seen flapping on the several tens of minute level.

ISPs are in the squeeze too. The timers are made tighter and tigher.

ssh sessions through wireless broadband is pretty useless without a tunnel of some sort.

Yes, you can pile up the cludges. You can make ipv4 work, sort of, with a clueful administrator. The trouble is, 90% of administrators are totally clueless. The technical head of a _large_ isp I have the pleasure of communicating with us unable to make the connection between a prefix (i.e. 1.2.3.192/28) and the addresses this prefix represents. When such people gets to administer stuff that needs thinking you can smell disaster.

At a recent project of deploying a stock SIP platform about 38% of the work was directly related to solving NAT and private address space issues. 38%. Going up. How much more such pain before we do the relatively minor upgrade to v6?

-- mrr

In comp.dcom.lans.ethernet Morten Reistad wrote in part:

... and those keys remaining private. Well, DHCP logs are private in much the same way as keys. I do not know of any ISP that puts them on-line for all to see. Most will not even give them to the public even on specific request. Some will even insist the police have court authorization. A nefarious government might force an ISP to provide their police with continuous access, but they will still have to search them.

No, but you can use the first 64 bits, especially if they don't change much. RFC3041 is not without controversy:

the more anonymity, the more you are vulnerable to DDoS. Put another way, if RFC3041 goes general, it is like having Tuba with the extra overhead. The EUI-64 will be ignored or used for other things (msg signing?)

So control-minded govts/corps will either ban RFC3041 (force users to turn it off), it is not compulsory or required. Or use the first 64bits.

Sorry, I don't see it. You may well be on the bleeding edge. My sympathies.

Which timers? An ISP that is short on addresses will have problems, sure. But there is a solution -- NAT the customers! Give them a private address, not public. There are still lots of ports available, and browsers will work fine.

Of course this will break some applications, but this is by no means undesireable. You can make people pay more for better service, including an external addr. "Browser/email only" service for e20/mo, vs full "gaming" serive for e50/mo! Whether you like it or not, market segmentation is a route to profits.

I suppose that depends on the ISPs involved. I've had no trouble, and I've used lots of direct ssh over wireless. At least halft the time, the connection stays up overnight. But addr changes several times per hour might get annoying.

From where do you get that statistic? I expect most netadmins to be fully clued in to problem areas they currently face, and probably ignorant of any problem they have not faced or any new service. Most netadmins are not charged or paid as architects and are kept extremely busy just keeping existing networks and services running.

"Technical Head" is a contradiction in terms. "Technical" implies a knowledge of technology. "Head" implies a manager. These are totally different skill sets. Some people like knowing about things and manipulating them. Other people like knowing about people and motivating/manipulating them. People are not things, we do not react according to physical laws.

The American [Harvard MBA] theory that management is fungible (ie. manager can manage anything) has some serious flaws, but separation of specialities is not one of them. The [frequently] European practice of promoting excellent technologists into managment has even more basic flaws (lack of people skills, micromanagement).

I am shocked it was only 38% . Why do you expect RFC3261 to be painless? You are inflicting pain upon long-distance voice revenues of telcos and governments. Nevermind that they are being stupid and greedy, they also usually control datalines. I expect most of your problems were with the mess of different router workings. WHen/if this gets solved, you may expect more active VoIP countermeasures. UAE & India vs RIM is just a start.

-- Robert

They are still on some disk and in some logs where a court backed cop can get to them.

Generally, the more anonymity, the more you are vulnerable

I would think getting promoted to default behaviour in windows would qualify as "going general" ? You have to give an ifconfig-command in a console window to turn it off.

Yes, there was a reason I campaigned and voted for tuba. (that would have been version 5, btw)

The first 64 bits tell you the LAN. OK, home users can get on the hook, but not completely. For Wifi, corporate users etc this is far from a complete identification.

NAT, NAT and more NAT. Lots of code to compensate.

Yep, NATint customers is old hat. Now the external NAT addresses are scarce, so they tighten timers for how long a session lasts.

If they had a clue. Most of these schemes are deployed by people without an incling of a clue. Hint: The lead technician in a large corporation was unable to make a route/netmask out of 15 single IP addresses for a filter.

This means that garbage configs for cheap home deployment makes it onto large, corporate installations.

VPN, or 6to4. Problem solved. My ip use went to 65% almost overnight. All repos, microsoft included, are ipv6 enabled. So are the gateway sites I use. It just makes the world so much barable. No more hanging sessions. And it is noticably faster, too.

The huge problem is with the ISPs of large telcos. They just deploy vendor services without a clue.

This was where the case got escalated. The endpoint of escalation. Customer was large corporate entity with 24x7 contract and several gigabit connections.

This was just CPE and router workarounds. This was for a large integrator, working closely with an incumbent telco, so counter- measures was not in the equation. The 38% was just the work getting everything to work with several layers of flapping nat devices.

-- mrr

In comp.dcom.lans.ethernet Morten Reistad wrote in part:

Sure. Nothing obscure about it. Just not easy for everyone to do. I did not claim this was undesireable.

Or as part of ubiquitous startup scripts.

Again, you expect too much of people. Sure, it would be good if they knew. But they don't have to, so they don't. They've lasted this long without, and may have achieved considerable success reinforcing their ignorance. It would be nice if people who maintained machines & systems also knew enough to build them, but they don't. They know different things, often things the builders do not know.

If it can be made to work for now, that is often good enough. Cost pressures prohibit investing for the future. Of course corners are cut. It looks stupid in hindsight, but might not be in foresight--alot of futureproofing is thrown away when _that_ future doesn't show up an a different one does instead.

But I do not have these problems! I see no advantage with VPN, and only use it when port fwding config require it. I am a bit surprised at your speedup. Could it be going through better router [software]? IPv4 is somewhat the victim of its' own success -- droped/mangled packets cause fairly silent retransmits. So you get alot of them at a cost in speed.

One thing I do to help IPv4 is work on MTU to minimize fragmentation downstream. My current favorite is 1454 octets.

-- Robert

Yep. You have to enable it on Linux, but it is a single command. Some Linux distros may have it on by default. Apple are making privacy noises, so they may turn it on by default, too.

Sure, they make networks that work, sort of. But combined with address squeeze, lots of NAT, a steady stream of new services it does not fly.

The consequence is that incumbent ip offerings raise an increasing level of problems. That may be a market opportunity for small operations to deliver it done right; on top of the incumbent's (regulated) infrastrucure.

I have analysed the speedup. It is noticable, and measurable.

Reason #1 is that MTUs are negotiated properly. No network- generated fragmentation. MTU discovery is mandatory. Around

40% of packets on my ipv4 links arrive fragmented by the network.

Reason #2 is that there is no NAT, and routers just switch packets and do filter lists. Otherwise we are deploying NAT devices with lame cpus and memory interfaces on pretty high packet rates. Not rewriting packets mean a great deal. The latency differences are easily measurable.

Reason #3 is that I am pretty much alone on the ipv6 network, so I get the route caches all for my packets, and the few others using the network.

46 octets? Two tunnels and a pptp?

I have tested this on large numbers of networks, and it seems 1440 is safe everywhere. But the difference to

1454 is negligable. I see bigger effects from 1460 up.

-- mrr