Slashdot Mirror
Vista's TCP/IP Promises and Perils
boyko.at.netqos tips us to a new writeup on Vista's TCP/IP stack, which is called Compound TCP/IP (CTCP). From the article: "...security policy will come from a centralized source. When you get your DHCP lease, your computer will report to the stack what OS you're using, what version level, what patches, what anti-virus software that's active — all that kind of stuff. It will have the ability to restrict your network access if you have a down-level machine... We could see a lot of our customers with much higher WAN network utilization because of this new TCP/IP stack... CTCP can be enabled/disabled from the command prompt but there has been no mention of tuning parameters which leads us to ask the question: How are you supposed to configure this setting in Vista?... What worries us... is that Microsoft is basing this on packet round trip time. The round-trip time from the client-side will have the server processing time in it; but the clients aren't likely going to be the running the CTCP at first. If you have a server-to-server backup running, for example, CTCP may think its part of the round-trip time and it'll throw the delay window through the roof..."
So my trojan will be reporting values honored by the DHCP servers. This system is still relying on the information sent by the (possibly infected) machine, so it is not secure in any way.
Life is just nature's way of keeping meat fresh.
Article summary:
We haven't used Vista.
We haven't tested the features we're talking about.
We think they're actually probably very good.
We don't know (and nor does anyone) because we haven't tested them.
They could be bad.
They could do nasty stuff to your networks.
But we don't know because we haven't tested anything.
Sounds good in theory though.
And all the MS guys that have ever wrote about it say it works.
We don't think it'll work perfectly first time.
But we don't know because we haven't tested anything at all in any way.
We advise others to test before they make any decision.
Good article. (That was sarcasm. At least I think it was but I haven't tested it myself yet).
But, alas, falls short of implementing the "Evil Bit."
If you open yourself to the foo, You and foo become one.
I don't get it. If you're just going to be querying the OS for information about its configuration (antivirus, patch state, version level, etc.) why don't you just implement it at a higher level? I don't see any reason to bury this sort of stuff down in the network stack. It could just as easily run as an application-level service rather than being built in down on the transport level. (And in fact I know of systems which do this sort of thing running as userspace tools.)
The goal here seems to just be a way to allow corporate networks like WANs to restrict access based on the version of Windows that's running and the security software being implemented on the client. Setting aside how a rootkit would just fake the responses (and I don't believe for a second that there won't be rootkits for Vista once it gets mainstream), why does this have to be in the network stack? It could be easily implemented as part of the higher-level networking services like WINS or Active Directory, as a requirement before the user is allowed access to particular network resources.
This whole concept seems rather flawed, unless there's some large part of it that I'm missing, and it just seems like it's going to require other OSes to rewrite their perfectly good TCP/IP stacks in order to inter-operate with Windows networks. Maybe that's the whole point?
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I haven't read TFA, but based on blurb it will be horrible.
Compound TCP is not a TCP/IP stack! It's congestion avoidance/recovery algorithm for TCP streams. It's one of many (Vega, Reno, BIC, CUBIC etc. etc.). It's also available for Linux (but was removed from standard kernel some time ago).
Other things mentioned are parts of Network Access Control, which is already deployed in many companies. There are many software and hardware solutions available, Vista isn't special. It becoming must-have in corporate environment, praising Vista for having it is like claiming that DHCP client in OS is innovation.
:wq
"It will have the ability to restrict your network access if you have a down-level machine."
Ehm... and who decides what is a down-level machine?
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
"It will have the ability to restrict your network access if you have a down-level machine..."
Translation: "You WILL upgrade all of your machines to Vista, or Microsoft will artificially degrade their performance." It's called "market development."
Those M$ asshats are actually going to try to sell this as a NAC feature, when it's nothing but another license fee grab. Piss on them: I'm still running several totally stable, bullet-proof web servers on NT4 with 128Mb (albeit behind a good firewall), and I have neither the need nor the intention to "upgrade" them anytime soon (or ever, for that matter).
About the word "if": If bullfrogs had wings, they wouldn't bounce around on their little green butts.
Specifically, something to tell the CTCP stack that you're running the very latest version of everything, so that you don't get penalized by other nodes.
Of course, that would be bad news for everyone else on the network, if in fact your old, unpatched OS (which you are reporting as new and patched to avoid having to upgrade to Vista 2.5.9.396) _is_ infected. But then, that's part of the problem with including features that work AGAINST the person buying/using them.
To sum up: malicious/hijacked computers will report that everything's OK. Computers controlled by savvy users who don't want hassle will report that everything's OK. Computers that really have nothing interesting about them will report that everything's OK. There'll be a thin band of computers that really do have old OS versions but that nobody cares about enough to doctor -- these will report that everything's not OK, until they become an issue and are considered a painful extra cost of MS-based networks. The remaining 90% of all computers will have this feature disabled, thus saving all the bother at a very very low cost in security.
It's not that this feature is evil, it just comes from the wrong mindset. I think MS's misconception that it's good to start from the question 'how can we restrict or coerce customers', rather than 'how can we empower and help customers', is likely to prove permanent.
Whence? Hence. Whither? Thither.
People keep saying that your trojan'd box could report false information, but what about a rooted DHCP server (like in a coffee shop, or any area with free WIFI)? You computer would be telling an unknown system its exact patch level. Screw brute force attacks, it would know exactly where you're vulnerable. didn't microsoft learn anything about offering too much information?
Microsoft is famous for its "Embrace and Extend" philosophy of locking people into their products by corrupting open standards. This looks to be the same thing once again.
I have to admit, it's been a while since I've read the TCP/IP protocol specs, but I don't remember there being any provisions for communicating things like OS type, version, or patch lists over the TCP/IP headers.
This brings up a major compatibility question as to how this is going to work with routers, linux servers, printers, and other devices on a network who either don't know about CTCP or don't give a shit about CTCP. This scheme also seems to be extremely vunerable to spoofing.
If M$ would spend half as much effort in securing their OS as they do coming up with these hare-brained schemes, then we wouldn't need such contrived solutions to security.
When all else fails, run.
The network admins. Won't apply patches? You don't get network access. Won't run AV software? You don't get network access. Infected with known malware? You lose network access until it's cleaned up.
Or you could go with the paranoid conspiracy theory and assume that MS will shoot themselves in the foot by trying to close out competing OSes at the network level; that would be the slashdot way, after all.
It's official. Most of you are morons.
I discover NAC/NAP. Network Admission Control and Network Access Protection. While the idea is noble, its going to be costly (for customers) to implement in mixed networks. They also don't discuss non PC network clients (Printers, Scanners, hand held etc). Even worse (see below), your going to have to pay for a 3rd party network stack for Windows 2000.
f 717-d752-4fa2-a77a-ab29f0b29266/NAC-NAP_Whitepaper .pdf
t rans/network/06_0914_tn_network.mspx
White paper here: http://download.microsoft.com/download/d/0/8/d08d
Interesting chat transcript here: http://www.microsoft.com/technet/community/chats/
From the transcript:
Q: NAP seems to fulfill the pre-admission health/integrity check very well. Can customers use the same NAP infrastructure to support post-admission NAC? e.g. with NAP today I can check a desktop PC is healthy when it joins, but what about 24 hours later?
A: Post-admission enforcement depends on the enforcement mechanism you're using. For instance, health will be re-evaluated when a client attempts to renew their IP address when using DHCP as the enforcement mechanism. For IPSec, it will happen when health certs expire. For 802.1x, it will happen when re-authentication occurs. For VPN, it will happen when clients reconnect. Any health change on the client will trigger re-evaluation of the health state, too.
Q: What is the likelihood of a NAP agent for Windows 2000 clients in the network?
A: We are not planning to implement a Windows 2000 NAP client. However, we are licensing our protocols to 3rd party companies so that they can offer NAP clients on Windows 2000 (and other OS's like Mac, Linux, etc.)
Enjoy,
It's just the normal noises in here.
Some MS patches are made to add hard DRM (WMP10) or police liscenses (GenuineAdvantage) and maybe there are some other tinfoil-needy reasons.
MS and the next-gen DVD consortium for that matter treat the customer as a potential criminal and require the ability to disable functionality in whole or in part. In other words, "security" to these people, including Microsoft, means keeping things secured against the user.
As a real security scheme it looks quite weak and vulnerable. But engineering a way to get user's machines to spy on them and report not only compliance with security policies but also use of arbitrary applications seems quite useful both for pushing OS upgrades and conversions to Windows down people's throats and for providing ammo to content liscensing organizations. Vista will be able to tell centralized servers who you are, whether you comply with some policy, and whether you can withstand an arbitrary network attack. Doesn't sound too secure to me. Wonder how SuSE will "interoperate" with this.
Unix people will note that it has been possible to set up network rules based on OS fingerprint for some time now. PF (used by OpenBSD) has a feature which identifies what OS it is communicating with and allows you to set rules accordingly. The "Building Firewalls with PF and OpenBSD" (2nd. ed.) contains an example showing how to restrict the bandwidth available to machines running Windows operating systems. If Vista brings about a whole bunch of networks that refuse to talk to Linux machines, a concerted OpenBSD action (which they've been known to do in the past) could bring about a whole bunch of networks that refuse to talk to Windows machines. Of course, you'll be able to get around it by installing a patch for your Windows machine that fakes its TCP packets to look like a Linux machine ;)
mandelbr0t
"Please describe the scientific nature of the 'whammy'" - Agent Scully
So then no worries, right? The first virus I get will surely disable CTCP for me, no sweat...
I seem to have missed your Networking 101. Maybe that's good, because it seems your Networking 101 has garbled your understanding of layers and abstraction within a protocol stack.
As CTCP is a protocol carried in IP, there should be no impact within the network, as practically nothing does deep introspection of packets other than firewalls (for policy) and end systems (for multiplexing and demultiplexing). Intermediate systems (i.e., IP routers) simply won't care or necessarily even notice that the IP datagrams they're forwarding have something other than TCP or UDP or GRE or UTI or, well, there are a hundred other "layer 4" (transport layer) possibilities counting only those with assigned numbers from IANA. Internet routers examine and forward "layer 3" (network layer) packets.
Your ethernet switches and other varieties of LAN equipment will see frames carrying only one network layer protocol for any of these: IP. These switches examine and forward "layer 2" packets.
AppleTalk, IPX, XNS and so forth are separate network layer protocols ("layer 3") from IP, and it is extremely unlikely that CTCP ("layer 4") will be defined for any of these other than IPv6, and it's unlikely that any of them (possibly including IPv6) will be carried natively (i.e., not tunnelled) across more than the tiniest fraction of wide area networking infrastructure.
Using a single network layer ("layer 3") protocol is operationally easier than using multiple network layer protocols, and operator skill has not scaled nearly as well as either bandwidth or forwarding performance since multiprotocol WANs were common (late 1980s, early 1990s). This is especially true for very large scale networks, like international backbones and national network operators, and even larger regional and metro operators.
The trade-off favouring reduced operator knowledge ("we just move IP very very quickly") at the expense of encapsulation overhead (computation in the end systems, bandwidth everywhere else) has been an economic one, not a technical one. Indeed, many technical people, particularly IPv6 and MPLS proponents, really like the idea of a multiprotocol big-I Internet in order to experiment with possible future network-based services like finer-grained addressability or explicit routing. I am not one of these people, but my objections are almost entirely economic (well, I do think both MPLS and IPv6 are weak and overly conservative hacks at operational problems which unsurprisingly have evolved faster and further than these two protocol suites can reasonably be expected to cope with).
RFC 2001 describes the congestion-avoiding system at the heart of TCP, which is the Internet's dominant bulk transfer protocol. Any other bulk transfer protocol with a similar system to RFC 2001's slow start and congestion avoidance could reasonably say that it is designed for "TCP fairness" in that -- on average -- the occupancy of a pure tail-drop FIFO queue in front of a chronic bottleneck will be inversely proportional to the number of congestion-avoiding flows traversing that bottleneck at the same time.
This sort of fairness is easy to demonstrate both in simulation and live across a WAN or the Internet, and is done regularly, since improving TCP specifically or bulk transfer performance in general is an active area of networking research.
With respect to intermediate systems, their operators generally won't care about well-behaved (in the fairness sense) flows, since they should be nondisruptive and should not require special handling of the IP packets they're carried in.
Badly behaved flows are generally counterproductive. Most "greedy" and "impatient" bulk transfer protocols do not perform well in comparison with TCP, and usually end up generating more traffic and take more time to do the same work. Unfortunately, such flows can also slow down TCP bulk transfers by causing and increasing actual network congestion.
Queueing discip