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

Sure, ask the client

[wertarbyte]

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

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.

Re:Sure, ask the client

[Karzz1]

I think the idea here is to cut off net access for an unpatched machine so it doesn't get infected in the first place.

So, assuming you are not a huge corporate customer, how exactly *do* you get updates at this point?

Article summary

[ledow]

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

Promising...

[Mr_Icon]

But, alas, falls short of implementing the "Evil Bit."

Why build it into the stack?

[Kadin2048]

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?

Re:Why build it into the stack?

[twiddlingbits]

Thats exactly the point. It's a bastardization of the TCP/IP standard by M$. They want everything to operate to the M$ standard not the approved W3C/ISO standards. Which means that if someone implements an opensource version then M$ sues them. This should be a Security Service that runs in the background and annoys the user that they may be using an "insecure" connection.

The first time the CEO can't get his email because his laptop wasn't patched to the right level all hell will break loose and this will be turned off.

It's also insecure as hell, someone could write a virus that does nothing but shut off this checking and then erases itself. Then you got a lot of time spent by the Help Desk and/or Techs trying to figure out why no one can connect! And unless the techs are ultra sharp about how the "new" TCP/IP stack operates they are going to be really puzzled and frustrated.

Re:Why build it into the stack?

[TheRaven64]

There shouldn't be. The DHCP specification explicitly allows you to embed arbitrary information in the request, and a server can filter based on any of this information. The 'options' field of the DHCP request (known as 'vendor extensions' in BOOTP, on which DHCP is based) is provided for this exact purpose. There's also nothing stopping an open source DHCP client from populating these fields saying 'I am a fully patched Windows machine,' or, indeed stopping an unpatched Windows machine doing the same thing, making it somewhat useless.

What the load of misinformation

[zdzichu]

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.

Re:What the load of misinformation

[zdzichu]

1. Didn't even read the article

  I was commenting blurb, not article itself.

2. What does the design of the tcp/ip stack in any other OS have anything to do with this?

Compund TCP is not stack design. It's one of congestion algorithms for TCP.

It will have the ability to restrict your network

[mrjb]

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

Key phrase: "restrict your network access"

[BrakesForElves]

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

Trojan'd Box? What about hacked DHCP Server?

[Anonymous Coward]

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?

Re:It will have the ability to restrict your netwo

[Tim C]

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.

Asking the Google for more info...

[NullProg]

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.

White paper here: http://download.microsoft.com/download/d/0/8/d08df 717-d752-4fa2-a77a-ab29f0b29266/NAC-NAP_Whitepaper .pdf

Interesting chat transcript here: http://www.microsoft.com/technet/community/chats/t rans/network/06_0914_tn_network.mspx

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,