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..."

Comments

Re:Article summary

[complete loony]

I read some interesting stuff that came out of Microsoft research a while ago. They worked out an algorithm for scanning the structure of an ethernet network. Every Vista box on the network will participate in scanning the ethernet topology periodically, using spoofed MAC addresses. This process can determine the logical structure of the hubs, switches and wireless networks that are between machines. Using methods like this it will be perfectly reasonable for each machine on the network to know the total bandwidth that is available. Some further reading on the new QOS features in Vista also suggests this information can be fed back into applications to allow them to change codecs or otherwise notify the user of networking issues that may be degrading application performance.

Altogether these are some very interesting concepts, and I hope that they pan out in practice. (I too haven't tested any of this myself).

Re:the whole point...could happen

[redelm]

... until the Linux `dhcpcd` starts faking answers. Which will be Zero-day. A bigger problem will be when the servers does encoded challenge/response ala "Trecherous Computing". As an adjudged monopolist, MS will have be be enjoined from invoking the DMCA.

Re:the whole point...

[mandelbr0t]

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