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

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:

[Orange Crush]

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.

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. Obviously this is useless against a machine that has already been compromised.

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?

Re:

[COMON$]

Remember this only matters if you have a DHCP server and I imagine the MS one at that. So if you are running a SOHO network you wont notice it as it will be turned off. Otherwise it is just a matter of pointing the machine to Windows Update only. If you have read up on the similar cisco technology it does the same thing, you have to update before you can authenticate with the network, so you get pointed to the WSUS server and AV repository until you meet the specified requirements.

Re:

[LurkerXXX]

er, if you are not a corporate customer, you aren't likely to have a new Microsoft DHCP server giving you your IP address, and caring if you are patched or not.

So you download updates normally. Your ISP's DHCP server, or the one built into that $25 home router you bought, isn't going to care what your windows patch level is.

Re:

[foamrotreturns]

I was wondering the same thing. There are commercial products out there that limit network access to unpatched machines, but they allow quarantined machines to access certain sites like windowsupdate.com and the AV def servers. I wonder if there are any patents held by those companies with which they could deliver a smackdown to MS.

Or maybe

[Eric Damron]

Or to cut off net access for any non-windows PCs maybe?

Re:

[the_bard17]

Or to cut off net access for any Windows PCs?

Boy, wouldn't that be ironic... ;oD

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:

[Tim C]

Please see this post [slashdot.org] for refutations of your first few points (the rest I'll let stand as being pure speculation at this point).

Re:

[rbanffy]

Is there a way to forbid Microsoft from calling this TCP/IP?

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.

Re:

[Creepy Crawler]

Better yet, each registered MS Windows machine could have their own hidden, protected private key along with a public key.

To set up what seems to be called "CTCP", all you'd do are have appended DHCP flags already allowed by the standard, with one last extra flag as "SIGNATURE" flag, signed by the private key. All data would be in clear-text, and easily read AND changeable, BUT the signature guarantees unmodification. The MS DHCP server could verify the sig, and grant/refuse an IP address.

Of course, there'd

How 'bout...

[Mateo_LeFou]

Windows Genuine(TM) TCP/IP Experience(TM)?

Re:

[grcumb]

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.

Exactly. This strategy has been advocated in Microsoft internal documents dating from years back. Eric S. Raymond quotes a Microsoft confidential Linux strategy report [catb.org] as saying:

Linux can win as long as services / protocols are commodities.

I know I've been waiting since then for this particular shoe to drop. As for the rest of you, especiall

Re:

[r3m0t]

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!

Not if:
1) This code is in the kernel,
2) You are running a version of Vista which forbids patching of the kernel (i.e. modification of the kernel that is running) - that's any 64-bit installation

Also not if:
1) The setting requires a UAC prompt,
2) The company has gone to the bother

Re:

[twiddlingbits]

ROTFLMAO...I suspect Vista will be almost as full of security holes as XP. The M$ process, try as they may, is just not focused to build a secure OS. So kernel viruses will exist.

On your second point, kernels swap pages to disk all the time and load/unload services. All the virus has to do it mask itsef as Service X, and when the OS loads Service X and Service X has kernel level authority then the virus installs. You can prevent this by not allowing any services to run at the kernal level (which is how Linu

Re:

[earthbound kid]

TCIP is an IETF standard, not a W3C or ISO. In fact, W3C doesn't actually make publish "standards" at all -- only recommendations. ISO does publish standards, but it hasn't made many very important internet standards, unless you count string encodings, but those can be used offline as well.

This isn't to say MS isn't trying to destroy standards. Just know what you're talking about before you say something.

Re:

[twiddlingbits]

The whole network stack is called the Open Systems Interconnection Reference Model, the OSI Reference Model, or even just the OSI Model. It was published in 1984 by both the ISO, as standard ISO 7498, TCP/IP is an implementation of parts of this stack. The actual definition of TCP/IP is contained in and RFC 793 and many others are called out as extensions. Wow..split that hair, what W3C reccomends becomes know and referred to as the "Standard" even if it's not offically published and given a name or number

Re:

[earthbound kid]

Well, they just seem to make a big deal about it not being a "standard" in the ISO sense sometimes is all I'm saying.

Re:

[cp.tar]

Seems to me like a really nasty virus would turn it on.

And upgrade it with Clippy.

But really... I'm no programmer, but couldn't, say, a perfectly common TCP/IP stack from XP be inserted in the place of the new one?
There should be a way to do something like that... then you just make a cute screensaver, put this in the installer and off you go switching the damned thing off webwide. And see what happens, as Emperor Gregor would say.
Hell, scrap the screensaver... just proclaim it a nasty alert remover and

It's called embrace and extend

[Colin Smith]

By making these changes in the stack you can improve the windowswindows performance while reducing the windowsother performance. It creates an environment which in which it is strongly beneficial to have a windows only network.

Re:

[mpe]

By making these changes in the stack you can improve the windowswindows performance while reducing the windowsother performance.

Assuming no active device in the network takes exception to what Windows is doing. In which case performance with this MS/IP could drop through the floor compared with anything using standard IP.

Re:

[dave562]

From the article, my emphasis in bold

They also claim that CTCP has been designed for "TCP fairness" to allow CTCP and regular TCP traffic to play nicely when sharing the same link - Microsoft's data shows that CTCP doesn't induce enough loss to wreak havoc with regular TCP allowing then to both maximize their throughput.

Incase you missed Networking 101, it is beneficial from a networking point of view to have only one protocol running on a network. But hell, if you want to... you can run a bunch of pro

Re:

[hr raattgift]

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 da

Re:

[COMON$]

Here is what I think is funny. Everyone bitches about this feature when MS implements it. How it could be an app or service of some sort. But when Cisco does it with CSA http://www.cisco.com/en/US/products/sw/secursw/ps 5 057/index.html [cisco.com] It is the best idea ever.

If I can tell my routers and switches to ignore all traffic from a MAC until it certifies I call that a good thing. I imagine MS is trying to do the same thing with AD. Even in a DHCP network I can set up ethereal and grab an IP within the netwo

Re:

[jZnat]

That's because network admins are to Cisco as Mac fanboys are to Macs.

Re:

[dave562]

That's because network ENGINEERS are to Cisco as Mac fanboys are to Macs.

Corrected, and don't make that mistake again. You don't want a network admin going anywhere near IOS.

Re:

[jZnat]

Good catch. I'm neither a network admin nor a network engineer (more in to computer science and general "* Admin" stuff).

Because residential ISPs might implement it

[tepples]

Here is what I think is funny. Everyone bitches about this feature when MS implements it. How it could be an app or service of some sort. But when Cisco does it with CSA http://www.cisco.com/en/US/products/sw/secursw/ps5 057/index.html [cisco.com] It is the best idea ever.

There's a specific difference. Residential ISPs are more likely to require something that is available as part of the Windows base install than something that requires proprietary software from Cisco. In addition, something from Microsoft is more likely to be used to deny Linux users the ability to connect or to require them to move up to the next tier of service at twice the monthly rate.

Re:

[bill_mcgonigle]

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.

Setting your rootkits aside (valid argument), I assume the point here is to defend against network software that doesn't use WINS or AD, e.g. network-spreading viruses/worms. Without an IP most current malware won't spread.

Re:

[davidsyes]

Maybe to kill off or flag and issue red alerts on Linux boxes in corporate quarterly security audits/reports? If Linux keeps popping up, and if the bandwidth is screwed with by the server running undocumented code to hamper or impede services run on Linux boxes....

Well, I guess smart IT shops will just put such servers outside the CDHCP servers....

Nice try, mshaft. Take your bat and ball and go home. Try again another day...

Re:

[jdray]

Let's take preconceived notions about Microsoft out of the equation here for just a minute (hard to do, I know). If a system can't even get an IP address without proving that it's a good network citizen, then it can't do much of anything network related. In my experience, there's not typically a requirement to sign on to Active Directory or participate in WINS to get out on the Net; if you have an IP address and client software, you're surfing.

Sometimes you need an IP, Sometimes you don't.

[bill_mcgonigle]

What!?...I think you are missing the point. The guy was trying to say that unless YOU have an IP address (which the issue everyone has been discussing), you cannot do anything.

The AC has a point - the things he mentions are all possible without an IP. Spreading general mischief on a LAN requires no IP.

What the AC fails to acknowledge is that that the proposed technique would prevent some malware from spreading. This is a good thing.

What isn't addresses is how to then get updates - kind of hard without an

Re:

[dave562]

What isn't addresses is how to then get updates - kind of hard without an address.

The buzzword "quarantine network" has been tossed around for at least the last six months. The theory behind the technology is that a client that fails to meet the policy requirements will be directed to a completely seperate subnet (think DMZ) where it will have access to a server that will push down the necessary patches and AV upgrades to bring the client into compliance. In otherwords, if your network is on 10.1.1.x the

Re:

[ultranova]

It will definitely address the problem of Joe Blow bringing in his laptop from home full of virii.

No it won't. The viruses will simply take over the TCP/IP stack and say "Yep, we're fully patched and running AV, no viruses here, no sir!" to the DHCP server.

Re:

[dave562]

No it won't. The viruses will simply take over the TCP/IP stack and say "Yep, we're fully patched and running AV, no viruses here, no sir!" to the DHCP server.

Perhaps, but it adds another layer of complexity to the equation. The checksums and return values for "fully patched" will be constantly changing so the virii will need to constantly adapt.

Re:

[jZnat]

ISPs could always implement a blacklist instead that blocks old versions of Windows...

Re:

[myowntrueself]

ISPs could always implement a blacklist instead that blocks old versions of Windows...

s/old versions of //

client?

[Gr8Apes]

How are you going to ask the client, when said DHCP client is one of those nifty routers we all own?

I don't think anyone on /., or even most in the world, directly connect their machines to a network connection anymore. All the broadband connections all go through some sort of router these days, provided by the ISPs themselves.

Re:

[Lord Ender]

The point is so that you can find and patch machines that aren't patched before the hackers/worms find them. Security isn't a boolean value. There is real value to security measures which reduce, but don't eliminate risk.

Incidentally, this technology has been marketed as Network Access Control (NAC) for years by other vendors. It usually isn't DHCP based.

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

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:

[mpe]

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.

Whilst this might work for a simple network it coul

I heard...

[camperdave]

I heard that, buried deep in Vista's core, is a distributed computing program that emulates the mind of Bill Gates, and that he is able to jack into this virtual mind at his bunker on the Redmond Campus. Just like his corporation overwhelmed and undercut the competition, now his electronic minions are going to slowly and surely take over the internet, one LAN at a time. You see, VISTA will always work flawlessly, but will randomly inject false packets to non-Vista machines, briefly kicking them off the ne

Re:

[humphrm]

The only thing worse than FUD coming out of Redmond is FUD coming out of the OSC

Re:

[stubear]

By "technicl managerial" you mean "typical slashbot" right? This article was specifically written to be included on the front page of Slashdot to work up the unwashed (and I truly mean unwashed) masses of slashbots worldwide, facts and truth be damned.

Promising...

[Mr_Icon]

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

Re:

[$RANDOMLUSER]

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

Don't kid yourself, Vista is the evil nibble.

Promise Kept

[twitter]

falls short of implementing the "Evil Bit."

I'm sure there are plenty of evil bits in this new M$TCP/IP. Remember, folks, the 1998 Halloween document called for replacing all of the world's simple protocols. They have finally gotten around to DHCP and TCP. Hopefully vendors will have the good sense to ignore the whole scheme. A network that discriminates on OS brand rather than behavior is worse than one that does not discriminate at all.

Re:

[Reziac]

I don't know enough about networking protocols to comment intelligently on that part, but what did strike me, as I RTFA'd, was that this dovetails all too well with Treach^H^H^H^H Trusted Computing.

Anyone who hasn't reviewed Alsee's comments here on /. re TC, is strongly advised to do so.

10 LET M$ = "Microsoft"

[tepples]

AC: Which items of Paul Rogers' laundry list did twitter's comment violate? If the M$ one was the most significant, consider that M$ is a valid name for a string variable in (at least early dialects of) BASIC; a lot of people thus use M$ to imply that the world might have been a better place had Microsoft kept making languages and office software instead of branching off into operating systems.

the whole point...

[advocate_one]

apart from providing some "security" measures, is to lock Linux out of the corporate network. As soon as a Longhorn server goes into a network, then Linux boxes will have all sorts of problems. And there won't be any way to legally get around it as Microsoft will have all the required patents to wave in the faces of anyone who attempts to do so.

Re:

[piranha(jpl)]

That doesn't make a lick of sense. References please.

Re:

[grcumb]

Quoth parent:

That doesn't make a lick of sense. References please.

No problem. Here you go.

http://catb.org/~esr/halloween/halloween1.html [catb.org]:

"OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market."

That was too easy....

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:Bingo!

[mpapet]

The extra effort this entails for BIG deployments of windows will be a temporary headache for a small group of sysadmins until of course they upgrade to the Microsoft server designed to handle this....

The bigger picture is locking everything out.

1. Reaching into the networking peripherals market to extract a tax for the privilege of connecting to a Vista PC. Give Microsoft a few cents for every device sold and no consumer will care. Microsoft can then tighten the DRM noose and increase revenue simultaneou

Re:

[mpe]

apart from providing some "security" measures, is to lock Linux out of the corporate network. As soon as a Longhorn server goes into a network, then Linux boxes will have all sorts of problems.

There are all sorts of devices which have DHCP clients embedded in firmware. As well as every prior version of Windows.

Re:

[rbanffy]

Unless they push this "improvements" down the Windows Update pipe.

Re:

[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 O

Patent: not likely, but DMCA -- access control?

[lpq]

I can't imagine a patent covering this functionality.

While the idea might be patentable, it would be a patent of restricting access to the network based on what software the computer is running.

On a Linux box, to serve back a packet to allow the machine to obtain access would most certainly not use the same algorithm nor be an example of the same idea since the Linux box would be implementing a "work-around" -- simulating a "valid reply" -- not actually returning it's real "windows patch level".

OTOH -- Mayb

I love ...

[VincenzoRomano]

... complex things especially when they plan to be very cumbersome, slow, error prone and possibly non working.
Many thanks to the big brains in Redmond!

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:

[zdzichu]

Actually, after reading TFA, it look pretty good. Only submitter f**ked up blurb :/

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?

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.

Re:It will have the ability to restrict your netwo

[mollymoo]

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

Hopefully not whoever owns the network. I mean, what kind of a world would it be where sysadmins could control who connected to their networks! Allowing sysadmins to keep unpatched Windows boxes off their networks is obviously nothing but pure evil. It's Microsoft, so it must be evil, right?

Yes, M$ is evil and M$TCP is stupid.

[twitter]

Allowing sysadmins to keep unpatched Windows boxes off their networks is obviously nothing but pure evil. It's Microsoft, so it must be evil, right?

Keeping windows boxes off a network would be nice, but it would be better to simply cut off machines that misbehave. Every machine on the botnet is going to know exactly what to tell the silly C(luster fuck)DHCP server for maximum access. Brands of OS M$ does not like will not. DHCP is already slow, adding this overhead won't rid your network of infection

Re:It will have the ability to restrict your netwo

[zootm]

Probably the network administrator, but as the article admits, they've really no idea.

Re:It will have the ability to restrict your netwo

[MyHair]

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

If you have to ask, you don't get to decide and you definintely have a down-level machine. ;-)

My first thought on reading this article is that this could control some of the Windows network spamming I've seen too much of, but this really is the wrong way to go about fixing it.

Microsoft security man...

[Rosco P. Coltrane]

which is called Compound TCP/IP (CTCP). From the article: "...security policy will come from a centralized source.

Yeah, trust a blind man to invent a new pencil...

Stream of conciousness babblling?

[Ancient_Hacker]

Is it just me, or does this article sound like random babbling? Nowhere did I see any explanation of what CTCP is, what it does, how it does it, or why it's a good or bad thing. Instead there's lots of uninformed speculation. Apparently it has something to do with bigger TCP windows and/or better or throttled thruput. But we end up more mystified than when we came in.

Re:

[UnknowingFool]

Is it just me, or does this article sound like random babbling? Nowhere did I see any explanation of . . .

You must be new here. J/K. Yeah, the article was all about technical and short on explanation. From the tone, I gather that the Vista stack is doing things in the name of security that really isn't very secure. Also there are implications to other OSs that are running on the same network that use a more standard TCP/IP stack. That's what I could gather.

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

Re:

[swissmonkey]

If you weren't such a retard maybe you'd understand that the OS level required is specified by the admin depending on what he wants to allow on his network, not by MS.

But that would be too much to ask of you wouldn't it ?

Re:

[r3m0t]

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

WTF are you talking about? This allows network admins (the people who run your company's DHCP server to be precise) to collect (insecure and

Re:

[Alsee]

collect (insecure and not entirely trustable) information about your computer's setup when you plug it in and set it to use DHCP

Network Access Control (NAC) is all about Microsoft's plan to force Trusted Computing on everyone. As you and virtually everyone else has pointed out, simply sending an ordinary system configuration report is unreliable and worthless. If you want/expect this system to actually work, you *have to* tie it to a Trusted Computing enforced report on the system configuration.

If you do no

obligatory abbreviation joke

[Speare]

CTCP is also a portion of the core IRC protocol, which was a goofy way to extend command set.

/CTCP ACTION slaps Microsoft around with a large trout.

I can see a niche for a benign rootkit here...

[kahei]

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.

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?

Raises questions

[MECC]

"It will have the ability to restrict your network access if you have a down-level machine."

That raises some questions. Does this mean that the stack itself on the system in question will place some kind of access restriction? Are they trying to wedge this into layer 4? Have they devised some kind of MS client-server extension to DHCP that sends a data structure to a server which in turn pushes a policy out to the stack? Or is this intended to be part of an 802.1x based scheme?

Re:

[Todd Knarr]

It's just more vendor-specific fields in the DHCP request and response, plus some ioctl() hooks into the network stack. Basically a CTCP client brings up a normal unrestricted TCP stack and sends it's info in fields in the DHCP request. The DHCP server sees the fields, analyzes them and sends back configuration info in the DHCP response. The client then interprets the configuration info and uses the CTCP API to tell the network stack to impose the rules the server sent.

Of course, you can see several gaping

less than half the story

[redelm]

DHCP embrace-and-extend (MS patent) to OS/pl/sw reporting isn't entirely stupid, however, the smarts will have to be in gateway/proxy machines that will have to recognize the extended DHCP requests and reconfigure their routers appropriately.

One big problem is that few of these gateways are MS-Windows machines. Most are Criscos that get fried up by the heavy traffic :) I doubt an x86 box could service a full-speed OC-3 if the table look-ups get extensive.

Re:

[redelm]

Really? Since when? Last I heard they used MIPS64. Still, I suppose x86 might work inside a decidedly non-PC architecture with a serious Northbridge.

TCP/IP stack embrace and extend?

[Whammy666]

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.

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 [microsoft.com]

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

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,

Better Existing Alternatives

[Dark Coder]

CTCP is like that 'finger' protocol. Useless, alone. You eventually get poked from and into unexpected places.

To all home, business and corporate admins, you want control? Of which PC can connect to your LAN? Complete with OS versioning and all?
Best existing methods are in combo:

1. IEEE [wikipedia.org] 802.1X [ieee802.org] (wlan_supplicant) [linux.com]
2. VLAN [wikipedia.org] (IEEE 802.1Q)
3. IPSec (various IEEE RFCs [wikipedia.org])
4. THEN finger protocol

These options gives LAN administrator absolute power to allow which PC can join their own precious LAN or not.

Every prot

Not all patches are for security

[mattr]

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.

Easy fix

[octaene]

CTCP can be enabled/disabled from the command prompt

So then no worries, right? The first virus I get will surely disable CTCP for me, no sweat...

Re:

[AArmadillo]

Except you need an elevated command prompt, so there will be a warning dialog that pops up asking for elevated privledges. Granted, most users will see it and click OK anyway, but in theory the user would be able to prevent this from happening.

Why a special TCP?

[guruevi]

Why don't they just use TCP/IP fingerprinting as available in security packages like say NMap? It has been around for years (I've used it since NT 3) and works perfectly for what you want. So if the patch level changes the TCP/IP fingerprint or it embeds it in the DHCP request, we don't have to mess around with special software written to only run for Windows and screw the users/servers having Mac, Linux and other OS'es.

Really bad idea.

[earthbound kid]

A virus gets on to the network and thinks, "Hmm, who should I try to attack next." Suddenly, a broadcast, "Hey, everyone! I'm running Vista version XYZ. You know, the one that came out before that big vulnerability patch? Yeah, if someone were to try to infect me, no need to waste time with technique B since I still have security flaw A from before that patch came out." Virus says, "Thanks for the tip," infects the machine, tells it to shut up about needing patches. Administrator comes by and looks at the s

People might prefer that.

[Kadin2048]

Admittedly though, I think part of this is market-driven. Partially because people have just accepted that "Windows way" is just how computers in general are supposed to work, a lot of home users are frustrated with computers and would probably readily accept 'applianceized' computing.

A significant percentage of users only want a 'content delivery box' for their computer. That's what they use it for; that and as a game machine. Most people don't really use their computer for anything that wouldn't be provid

Re:

[Akaihiryuu]

Backward compatibility is not the correct term to use. Falling back to the standard when your bastardized version of it doesn't work isn't backward compatibility. Microsoft would probably like for it to be called backward compatibility though, it makes it sound like their nonstandard implementation is "more advanced". The correct term to use is broken.

New vector of attack

[Archangel Michael]

Assuming one can trust the DHCP server to not send bogus and forged request to the client OS, which would then shut the thing down.

Here's the scenario: Client OS = Vista, DHCP Server is Rooted or otherwise compromised box. The client requests DHCP using standard Vista protocols, and gets a response from the Hosed server, which then sees that it is a Vista box (because the vista box tells everything), and sends either a response designed to shut it off, or worse "infect" it with a known exploit based upon cu

Re:

[a.d.trick]

CTCP is not just a Microsoft thing. http://www.die.net/doc/linux/man/man7/ctcp.7.html [die.net]

(That's not to say that Microsoft's implementation isn't completely borked and incompatible with everyone else)

As for CTCP itself, I don't see much use for it, but I could be wrong.

Re:

[dave562]

Unless things drastically change, the ISPs aren't going to give two shits about what you do on their network. They give you a router and make sure that you get connectivity from the router to the CO. After that, their job is pretty much done. It would be great if ISPs started holding computer users accountable for not spreading malicious code or attaching infected machines to the network, but the fact of that matter is that day might very well never come. ISPs don't want to get into the business of play

Re:

[tepples]

Unless things drastically change, the ISPs aren't going to give two shits about what you do on their network.

Things are likely to drastically change [slashdot.org].

It would be great if ISPs started holding computer users accountable for not spreading malicious code or attaching infected machines to the network, but the fact of that matter is that day might very well never come.

Unless the only high-speed ISP in town is "with MSN Premium". Or unless ISP A makes ISP B's implementation of "trusted" TCP a condition of peering arrangements (otherwise prepare to pay extra for transit to ISP A's customers and/or have packets deprioritized) or e-mail delivery arrangements (otherwise prepare to have e-mail from ISP B routed to ISP A customers' junk mail folders).