Tài liệu Windows Internals covering windows server 2008 and windows vista- P20 pdf

To support legacy protocols such as NetBIOS, which make use of the deprecated TDI interface, the network stack also includes a component called TDX, which creates device objects that rep

■ Authority For secure clients (which have their name records signed by a certifying authority), the authority is identified by an SHA-1 hash of an associated public key, while for unsecured clients, it is zero If a client is secure, PNRP validates the name record before publishing it

■ Classifier The classifier uses a simple string to identify a service provided by a peer, which allows multiple services to be provided by the same device

To create a PNRP ID, PNRP hashes the P2P ID and combines it with a unique 128-bit ID called the service location, as shown in Figure 12-21 The service location identifies different instances of the same P2P ID in the same cloud (PNRP uses two clouds: a global cloud, which corresponds to all IPv6 addresses on the Internet, and the link-local cloud, which corresponds to IPv6 addresses within a single subnet.)

PNRP Resolution and Publication

PNRP name resolution occurs in two phases:

■ Endpoint determination In this phase, the requesting peer determines the IPv6 address associated with the peer responsible for publishing the PNRP ID of the desired service

■ PNRP ID resolution In this phase, once the requesting peer has located and confirmed the availability of the peer associated with the IPv6 address, it sends a PNRP request message for the PNRP ID of the service being requested The peer providing the service replies to confirm the PNRP ID and can supply a comment and up to 4 KB of additional data, such as context information related to the service

During the first phase, PNRP iterates over nodes while locating the publishing node, such that the node performing name resolution will be responsible for contacting nodes that are successively closer to the desired PNRP ID Each iteration works as follows: Once a peer receives

a request message, it performs a lookup in its cache for the requested PNRP ID If a match is found, the request message is sent directly; otherwise, it is sent to the next closest PNRP ID (by seeing how much of the ID matches)

When a node receives a request message for which it cannot find a PNRP ID, it checks the distance of any other IDs in the cache to the target ID If it finds a node that is closer, the requested node sends a reply to the requesting node, where the reply contains the IPv6 address of the peer that most closely matches the target PNRP ID The requesting node can then use the IPv6 address to send another query to that address’s node If no node is closer, the requesting node is

notified, and that node sends the request to the next closest node Assuming PNRP IDs of 200, 350,

450, 500, and 800, Figure 12-22 depicts a possible endpoint determination phase for an example in which peer A is trying to find the endpoint for PNRP 800 (peer E)

To publish its PNRP ID(s), a peer first sends PNRP publication messages to its closest neighbors (entries in its cache that have IDs that are in the lowest levels) to seed their caches It then randomly chooses nodes in the cloud that are not neighbors and sends them PNRP name resolution requests for its own PNRP ID Through the mechanism described earlier, the endpoint determination phase will result in the seeding of the PNRP ID across the caches of the random nodes that were chosen in the cloud

12.5 Location and Topology

Today’s networked computers often move between networks that require different configuration settings, for example, a corporate LAN and a home-based wireless network Additionally, today’s networks are complex, often spanning multiple devices across different topologies Windows includes the Network Location Awareness (NLA) service to enable the dynamic configuration of network applications and settings based on location, and Link-Layer Topology Discovery (LLTD) to enable the intelligent discovery and mapping of networked devices

Network Location Awareness (NLA)

The NLA service provider is implemented as a Winsock Namespace Provider (NSP) and provides the necessary framework for allowing computers and devices that move across different networks to select the most appropriate configuration settings For example, an application taking

advantage of NLA can detect when the user moves from a high-speed LAN to a high-latency wireless network and fine-tune its bandwidth use appropriately NLA can also detect when a home computer on a LAN may also have a secondary VPN connection to the office and select the proper configuration options

Instead of having developers rely on manual network interface information to figure out the type of network, and the IP addresses or DNS names associated with them, NLA provides a standardized query API for enumerating all the local network attachment information and correlating it with network interface information The NLA API also includes notifications that enable applications to respond to changes when they occur NLA provides applications two pieces

of location information:

■ Logical network identity This identity is based on the logical network’s DNS domain name

If one does not exist, NLA uses custom static information stored in the registry together with the network’s subnet address as the identity

■ Logical network interfaces For each network that a device is attached to, NLA creates an adapter name that identifies interfaces such as NICs or RAS connections in a unique fashion Applications use adapter names with the IP Helper API (%SystemRoot%\System32\Iphlpapi.dll)

to query interface information and characteristics

Each logical network is implemented as a service class with an associated GUID and properties NLA creates instances of that service class when it returns information about a logical network Service classes are schemas that describe a namespace; they define the name, identifier, and namespace-specific information that is common to all instances These classes are then used

in combination with the WSALookupService* API when performing name resolution

Link-Layer Topology Discovery (LLTD)

The LLTD protocol operates over both wired and wireless networks and enables applications

to discover the topology of a network For example, the Network Map functionality in Windows uses LLTD to draw the local network topology for the connected devices that support the LLTD protocol Additionally, LLTD supports Quality of Service (QoS) extensions, which allow applications to diagnose network problems such as low signal strength on a wireless network and bandwidth constraints on home networks Because it operates on the OSI Data-link layer (2), LLTD works only on a single subnet, and therefore can’t cross routers, but its capabilities make it suitable for most home and small-office networks

The LLTD Mapper I/O and the LLTD Responder components implement LLTD The former

is responsible for the discovery process and for generating network maps Because it uses a protocol different from IP, the LLTD Mapper uses NDIS APIs to directly send commands to the network via the network adapter The LLTD Responder listens for and responds to discovery commands with information about the computer As mentioned earlier, only devices that have a responder are shown in the network map

12.6 Protocol Drivers

Networking API drivers must take API requests and translate them into low-level network protocol requests for transmission across the network The API drivers rely on transport protocol drivers in kernel mode to do the actual translation Separating APIs from underlying protocols gives the networking architecture the flexibility of letting each API use a number of different protocols The Internet’s explosive growth and reliance on the TCP/IP protocol has made TCP/IP the preeminent protocol in Windows The Defense Advanced Research Projects Agency (DARPA) developed TCP/IP in 1969 specifically as the foundation for the Internet; therefore, TCP/IP has WAN-friendly characteristics such as routability and good WAN performance TCP/IP is the preferred Windows protocol and is installed by default, although it can be removed

However, the 4-byte network addresses used by the IPv4 protocol on the legacy TCP/IP stack limits the number of public IP addresses to roughly 4 billion, which is a limit that will be pressed

as more and more devices, such as cell phones and PDAs, acquire an Internet presence For that reason, the IPv6 protocol, which has 16-byte addresses, is gaining adoption Windows includes a combined TCP/IP stack, called the Next Generation TCP/IP Stack, which supports both IP and IPv6 When operating on IPv6 networks, the stack also supports coexistence with IPv4 networks through the use of tunneling The Next Generation TCP/IP Stack offers several advanced features

to improve network performance, some of which are outlined in the following list:

■ Receive Window Auto Tuning The TCP protocol defines a receive window size, which determines how much data a receiver can accept before the server requests an acknowledgment A higher size favors low-latency networks with high throughput, while lower values work better on networks such as Wi-Fi The Windows TCP/IP stack is capable of analyzing the conditions of a network and choosing the optimal receive window size, adjusting it as needed if the network conditions change

■ Compound TCP (CTCP) While automatically changing the receive window size allows more data to be received, CTCP aggressively increases the amount of data that can be sent by a machine, while monitoring bandwidth, latency, and packet loss Using CTCP on a high-bandwidth, low-latency network can significantly improve transfer speeds CTCP is disabled by default

■ Explicit Congestion Notification (ECN) Whenever a TCP packet is lost, the TCP protocol assumes that the data was dropped because of router congestion and enforces congestion control, dramatically lowering the sender’s transmission rate ECN allows routers to explicitly mark packets as being forwarded during congestion, which is read by the Windows TCP/IP stack as a sign that transmission rates should be lowered Lowering rates in this manner results in better performance than relying on congestion control ECN is disabled by default

■ High-loss throughput improvements, including the NewReno Fast Recovery Algorithm, Enhanced Selective Acknowledgment (SACK), Forward RTO-Recovery (F-RTO), and Limited Transit These algorithms reduce the overall retransmission of acknowledgments or TCP segments during high-loss scenarios while still maintaining the integrity of the TCP stream This allows for greater bandwidth in these environments and preserves TCP’s reliable transport semantics

The Next Generation TCP/IP Stack (\%SystemRoot%\Drivers\Tcpip.sys), shown in Figure 12-23, implements TCP, UDP, IP, ARP, ICMP, and IGMP To support legacy protocols such as NetBIOS, which make use of the deprecated TDI interface, the network stack also includes a component called TDX, which creates device objects that represent particular protocols so that clients can obtain a file object representing a protocol and issue network I/O to the protocol using TDI IRPs The TDX component creates several device objects that represent various TDI client–accessible protocols: \Device\Tcp6, \Device\Tcp, \Device\Udp6, \Device\Udp,

\Device\Rawip, and \Device\Tdx

eXPeriMeNT: Looking at TCP/iP’s Device Objects

Using the kernel debugger to look at a live system, you can examine TCP/IP’s device objects After performing the !drvobj command to see the addresses of each of the driver’s device objects, execute !devobj to view the name and other details about the device object

1 kd> !drvobj tdx

2 Driver object (861d9478) is for:

3 \Driver\tdx

4 Driver Extension List: (id , addr)

5 Device Object list:

11 Current Irp 00000000 RefCount 7 Type 00000012 Flags 00000050

12 Dacl 8b1bc54c DevExt 861cd4f8 DevObjExt 861cd500

13 ExtensionFlags (0x00000800)

14 Unknown flags 0x00000800

15 Device queue is not busy

16 lkd> !devobj 861db440

17 Device object (861db440) is for:

18 RawIp \Driver\tdx DriverObject 861d9478

19 Current Irp 00000000 RefCount 0 Type 00000012 Flags 00000050

20 Dacl 8b1bc54c DevExt 861db4f8 DevObjExt 861db500

21 ExtensionFlags (0x00000800)

22 Unknown flags 0x00000800

23 Device queue is not busy

24 lkd> !devobj 861d8440

25 Device object (861d8440) is for:

26 Udp6 \Driver\tdx DriverObject 861d9478

27 Current Irp 00000000 RefCount 0 Type 00000012 Flags 00000050

28 Dacl 8b1bc54c DevExt 861d84f8 DevObjExt 861d8500

29 ExtensionFlags (0x00000800)

30 Unknown flags 0x00000800

31 Device queue is not busy

32 lkd> !devobj 861d03e8

33 Device object (861d03e8) is for:

34 Udp \Driver\tdx DriverObject 861d9478

35 Current Irp 00000000 RefCount 6 Type 00000012 Flags 00000050

36 Dacl 8b1bc54c DevExt 861d04a0 DevObjExt 861d04a8

43 Current Irp 00000000 RefCount 7 Type 00000012 Flags 00000050

44 Dacl 8b1bc54c DevExt 861cd4f8 DevObjExt 861cd500

51 Current Irp 00000000 RefCount 167 Type 00000012 Flags 00000050

52 Dacl 8b1bc54c DevExt 861d23d0 DevObjExt 861d23d8

59 Current Irp 00000000 RefCount 0 Type 00000021 Flags 00000050

60 Dacl 8b0649a8 DevExt 00000000 DevObjExt 861d9408

61 ExtensionFlags (0x00000800)

62 Unknown flags 0x00000800

63 Device queue is not busy

Windows Filtering Platform (WFP)

Windows includes a rich and extensible platform for monitoring, intercepting, and processing network traffic at all levels in the network stack Other Windows networking services extend basic networking features of the TCP/IP protocol driver by relying on the WFP These include network address translation (NAT), IP filtering, IP inspection, and Internet Protocol Security (IPSec) Figure 12-24 shows how the different components of the WFP are integrated with the TCP/IP stack These include:

■ Filter engine The filter engine is implemented in both user mode and kernel mode and performs all the filtering operations on the network Each filter engine component consists of filtering layers, one for each component of the network stack The user-mode engine, responsible for RPC and IPSec keying policy, among other things, contains approximately 10 filters, while the kernel-mode engine, which performs the network and transport layer filtering of the TCP/IP stack, contains around 50

■ Shims Shims are the kernel-mode components that reside between the network stack and the filter engine They are responsible for making the decision to allow or block network traffic based on their filtering behavior, which is defined by the filter engine A shim operates in three steps: it parses the incoming data to match incoming values with entries in the filter engine, calls the filter engine to return an action based on the incoming values, and then interprets the action (drop the packet, for example)

■ Base filtering engine (BFE) The BFE is a user-mode service (%SystemRoot%\System32

\Bfe.dll) that manages all WFP operations It is responsible for adding and removing filters from the WFP stack, managing the filter configuration, and enforcing security on the filter database

■ Callout drivers Callout drivers are kernel-mode components that add custom filtering functionality outside the basic support provided by the WFP Callout drivers associate callout functions with one or more kernel-mode filtering layers, and the WFP enables callout functions to perform deep packet inspection and modification Network address translation (described next) and IPSec, are implemented as callout drivers, for example

Network Address Translation

Network address translation (NAT) is a routing service that allows multiple private IP addresses to map to a single public IP address Without NAT, each computer of a LAN must be assigned a public IP address to communicate across the Internet NAT allows one computer of the LAN to be assigned an IP address and the other computers to use private IP addresses and be connected to the Internet through that computer NAT translates between private IP addresses and the public IP address as necessary, routing packets between LAN computers and the Internet NAT components on Windows consist of a NAT device driver, \%SystemRoot%\System32

\Drivers\Ipnat.sys, that interfaces with the WFP stack as a callout driver, as well as editors that can perform additional packet processing beyond address and port translation NAT can be installed as

a routing protocol component with the Routing And Remote Access MMC snapin or by configuring Internet Connection Sharing (ICS), although NAT is much more configurable when installed using the Routing And Remote Access MMC snap-in

IP Filtering

Windows includes a very basic IP filtering capability with which a user can choose to allow only certain ports or IP protocols into or out of the network While this capability can serve to protect a computer from unauthorized network accesses, its drawback is that it is static and does not automatically create new filters for traffic initiated by applications running on the computer Windows also includes host firewall capability, called Windows Firewall, that goes beyond the basic filtering just described Windows Firewall uses WFP to provide a stateful firewall, which

is one that keeps track of traffic flow so that it distinguishes between TCP/IP traffic that originates

on the local LAN and unsolicited traffic that originates on the Internet When Windows Firewall is enabled on an interface, one of three profiles can be applied—public, private, and domain By default, when the public profile is chosen (or until a profile is selected), all unsolicited incoming and outgoing traffic received and sent by the computer is discarded, other than traffic from network services and other system applications A user or application can define exceptions so that services running on the computer, such as file and printer sharing or a Web site, can be accessed from other computers

The Windows Firewall service, which executes in a Svchost process, uses the BFE to pass exception rules defined in the configuration user interface to the IPNat driver The WFP filter engine executes the callback functions of each registered callout driver as it processes both inbound and outbound IP packets A callback function can provide NAT functionality by modifying source and destination addresses in a packet, or as a firewall by returning a status code

to TCP/IP that requests that TCP/IP drop the packet and cease processing for it In kernel mode, Windows Firewall uses a driver (%SystemRoot%\System32\Drivers\Mpsdrv.sys) that provides support for PPTP and FTP filtering, since those protocols provide their own

Network Address Translation

Network address translation (NAT) is a routing service that allows multiple private IP addresses to map to a single public IP address Without NAT, each computer of a LAN must be assigned a public IP address to communicate across the Internet NAT allows one computer of the LAN to be assigned an IP address and the other computers to use private IP addresses and be connected to the Internet through that computer NAT translates between private IP addresses and the public IP address as necessary, routing packets between LAN computers and the Internet NAT components on Windows consist of a NAT device driver, \%SystemRoot%\System32

\Drivers\Ipnat.sys, that interfaces with the WFP stack as a callout driver, as well as editors that can perform additional packet processing beyond address and port translation NAT can be installed as

a routing protocol component with the Routing And Remote Access MMC snapin or by configuring Internet Connection Sharing (ICS), although NAT is much more configurable when installed using the Routing And Remote Access MMC snap-in

IP Filtering

Windows includes a very basic IP filtering capability with which a user can choose to allow only certain ports or IP protocols into or out of the network While this capability can serve to protect a computer from unauthorized network accesses, its drawback is that it is static and does not automatically create new filters for traffic initiated by applications running on the computer

Windows also includes host firewall capability, called Windows Firewall, that goes beyond the basic filtering just described Windows Firewall uses WFP to provide a stateful firewall, which

is one that keeps track of traffic flow so that it distinguishes between TCP/IP traffic that originates

on the local LAN and unsolicited traffic that originates on the Internet When Windows Firewall is enabled on an interface, one of three profiles can be applied—public, private, and domain By default, when the public profile is chosen (or until a profile is selected), all unsolicited incoming and outgoing traffic received and sent by the computer is discarded, other than traffic from network services and other system applications A user or application can define exceptions so that services running on the computer, such as file and printer sharing or a Web site, can be accessed from other computers

The Windows Firewall service, which executes in a Svchost process, uses the BFE to pass exception rules defined in the configuration user interface to the IPNat driver The WFP filter engine executes the callback functions of each registered callout driver as it processes both inbound and outbound IP packets A callback function can provide NAT functionality by modifying source and destination addresses in a packet, or as a firewall by returning a status code

to TCP/IP that requests that TCP/IP drop the packet and cease processing for it In kernel mode, Windows Firewall uses a driver (%SystemRoot%\System32\Drivers\Mpsdrv.sys) that provides support for PPTP and FTP filtering, since those protocols provide their own

Internet Protocol Security

Internet Protocol Security (IPSec), which is integrated with the Windows TCP/IP stack, helps protect unicast (IPSec itself supports multicast, but the Windows implementation does not) IP data against attacks such as eavesdropping, sniffer attacks, data modification, IP address spoofing, and man-in-the-middle attacks (as long as the identity of the remote machine can be verified, such as a VPN) You can use IPSec to provide defense-in-depth against network-based attacks from untrusted computers; certain attacks that can result in the denial-of- service of applications, services, or the network; data corruption, data theft, and user-credential theft; and the administrative control over servers, other computers, and the network IPSec helps defend against network-based attacks through cryptography-based security services, security protocols, and dynamic key management

IPSec provides the following properties for unicast IP packets sent between trusted hosts:

■ Data origin authentication, which verifies the origin of an IP packet and ensures that unauthenticated parties cannot access data

■ Data integrity, which protects an IP packet from being modified in transit without being detected

■ Data confidentiality, which encrypts the payload of IP packets before transmission Data confidentiality ensures that only the IPSec peer with which a computer is communicating can read and interpret the contents of the packets This property is optional

■ Anti-replay (or replay protection), which ensures that each IP packet is unique and can’t be reused This property prevents an attacker from intercepting IP packets and inserting modified packets into a data stream between a source computer and a destination computer When

anti-replay is used, attackers cannot reply to captured messages to establish a session or gain unauthorized access to data

You can use IPSec to help defend against network-based attacks by configuring host-based IPSec packet filtering and enforcing trusted communications When you use IPSec for hostbased IPSec packet filtering, IPSec can permit or block specific types of unicast IP traffic based on source and destination address combinations and specific protocols and specific ports

In an Active Directory environment, Group Policy can be used to configure domains, sites, and organizational units (OUs), and IPSec policies (called connection security rules) can then be assigned as required to Group Policy objects (GPOs) through Windows Firewall with Advanced Security configuration settings Alternatively, you can configure and assign local IPSec policies Active Directory–based connection security rules are stored in Active Directory, and a copy of the current policy is maintained in a cache in the local registry Local connection security rules are stored in the local system registry

To establish trusted communications, IPSec uses mutual authentication, and it supports the following authentication methods through AuthIP, Microsoft’s extension to Internet Key Exchange (IKE):

■ Interactive user Kerberos 5 credentials or interactive user NTLMv2 credentials

■ User x.509 certificates

■ Computer SSL certificates

■ NAP health certificates

■ Anonymous authentication (optional authentication)

■ Preshared key

If AuthIP is not available, plain IKE is also supported by IPSec The Windows implementation of IPSec is based on IPSec Requests for Comments (RFCs) The Windows IPSec architecture includes Windows Firewall with Advanced Security, the legacy IPSec Policy Agent, the IKE and Authenticated Internet Protocol (AuthIP) protocols, and an IPSec WFP callout driver

■ Windows Firewall with Advanced Security In addition to the filtering functionality described earlier, the Windows Firewall service is also responsible for providing the security and policy configuration settings for IPSec, which can be configured through Group Policy either locally or on an Active Directory domain

■ Legacy IPSec Policy Agent The legacy IPSec Policy Agent runs as a service In the Services snap-in in the Microsoft Management Console (MMC), the IPSec Policy Agent appears

in the list of computer services under the name IPSEC Policy Agent The IPSec Policy Agent obtains legacy IPSec policy from an Active Directory domain or the local registry and then passes

IP address filters to the IPSec driver and authentication and security settings to IKE These policies are honored for compatibility with older versions of Windows, which implement IPSec management through Active Directory

■ IKE and AuthIP IKE is a protocol that supports the authentication and key negotiation services required by IPSec For outgoing traffic, IKE waits for requests to negotiate security associations (SAs) from the IPSec driver, negotiates the SAs, and then sends the SA settings back

to the IPSec driver For incoming traffic, IKE receives a negotiation request directly from the remote peer, and all other traffic from the peer is dropped until the SAs have been successfully negotiated SAs are a combination of mutually agreeable IPSec policy settings and keys that defines the security services, mechanisms, and keys that are used to help secure communications between IPSec peers Each SA is a one-way or simplex connection that secures the traffic it carries IKE negotiates main mode SAs and quick mode SAs when requested by the IPSec driver The IKE main mode (or ISAKMP) SA protects the IKE negotiation The quick mode (or IPSec) SAs protect application traffic AuthIP is an extension to IKE supported by Windows Vista and later versions It adds a secondary authentication mechanism to increase security and simplify maintenance and configuration of IPSec

■ IPSec WFP callout driver The IPSec WFP callout driver is a device driver (\%SystemRoot%\System32\Drivers\Ipsec.sys) that is bound to the WFP and that processes packets that pass through the TCP/IP driver The IPSec driver monitors and secures outbound unicast IP traffic, and it monitors, decrypts, and validates inbound unicast IP packets The WFP receives filters from the IPSec Policy Agent and invokes the callout, which then permits, blocks,

or secures packets as required To secure traffic, the IPSec driver uses active SA settings, or it requests that new SAs be created

You can use the Windows Firewall with Advanced Security (Wf.msc) snap-in that is available in MMC to create and manage connection security rules by using the New Connection Security Rule Wizard, shown in Figure 12-25 This snap-in can be used to create, modify, and store local connection security rules or Active Directory–based connection security rules, and to modify connection security rules on remote computers Alternatively, you can use the Netsh utility with the netsh advfirewall consec command to manage connection security rules After IPSec-secured communication is established, you can monitor IPSec information for local computers and for remote computers by using the Windows Firewall with Advanced Security snap-in or the Netsh utility with the netsh advfirewall monitor command

12.7 NDiS Drivers

When a protocol driver wants to read or write messages formatted in its protocol’s format from or to the network, the driver must do so using a network adapter Because expecting protocol drivers to understand the nuances of every network adapter on the market (proprietary network adapters number in the thousands) isn’t feasible, network adapter vendors provide device drivers that can take network messages and transmit them via the vendors’ proprietary hardware In 1989, Microsoft and 3Com jointly developed the Network Driver Interface Specification (NDIS), which lets protocol drivers communicate with network adapter drivers in a device-independent manner Network adapter drivers that conform to NDIS are called NDIS drivers or NDIS miniport drivers The version of NDIS that ships with Windows Vista SP1 and Windows Server 2008 is NDIS 6.1 The NDIS library (\%SystemRoot%\System32\Drivers\Ndis.sys) implements the NDIS boundary that exists between network transports, such as the TCP/IP driver, and NDIS drivers The NDIS library is a helper library that NDIS driver clients use to format commands they send to NDIS drivers NDIS drivers interface with the library to receive requests and send back responses Figure 12-26 shows the relationship between various NDIS-related components

Instead of merely providing the NDIS boundary helper routines, the NDIS library provides NDIS drivers with an entire execution environment NDIS drivers aren’t genuine Windows drivers because they can’t function without the encapsulation the NDIS library gives them This insulation layer wraps NDIS drivers so thoroughly that NDIS drivers don’t accept and process IRPs Rather, protocol drivers such as TCP/IP call a function in the NDIS library, NdisAllocateNetBuffer, and pass the packets to an NDIS miniport by calling an NDIS library function (NdisSendNetBufferLists, for example) Additionally, to make development simpler, all components of the Windows Next Generation TCP/IP Stack make use of net buffers, including TCP/IP and WSK, which streamlines communications with NDIS

NDIS includes the following features:

■ NDIS drivers can report whether or not their network medium is active, which allows Windows to display a network connected/disconnected icon on the taskbar This feature also allows protocols and other applications to be aware of this state and react accordingly The TCP/IP transport, for example, will use this information to determine when it should reevaluate addressing information it receives from DHCP

■ NDIS drivers can be paused and resumed, which enables run-time reconfiguration, such as during a response to a Plug and Play event This allows dynamic operations such as binding and unbinding a protocol driver without requiring a reboot

■ TCP/IP offloading, including task and chimney offloading Task offloading allows a miniport to use advanced features of a network adapter to perform operations such as packet checksums and IPSec NDIS includes support for IPSec Task Offload Version 2, which includes support for additional cryptography suites used in IPSec, such as AES, as well as IPv6 support Chimney offloading provides a direct connection (the so-called chimney) between network applications and the network card hardware, enabling greater offloading and connection state management to be implemented by the network card These offloading operations can improve system performance by relieving the CPU from the tasks

■ Receive scaling enables multiple processors to perform packet receive operations and appropriate scaling to be selected based on the most efficient use of available target processors NDIS supports the receive-side scaling (RSS) interface at the hardware level and queues DPCs to the appropriate processors

■ Wake-on-LAN allows a wake-on-LAN-capable network adapter to bring Windows out of a suspend power state Events that can trigger the network adapter to signal the system include media connections (such as plugging a network cable into the adapter), the receipt of protocol-specific patterns registered by a protocol (the TCP/IP transport asks to be woken for Address Resolution Protocol [ARP] requests), and, for Ethernet adapters, the receipt of a magic packet (a network packet that contains 16 contiguous copies of the adapter’s Ethernet address)

■ Header-data split allows compatible network cards to improve network performance by splitting the data and header part of an Ethernet frame into different buffers and subsequently combining the buffers into smaller regions of memory than if the buffers were combined This allows more efficient memory usage as well as better caching because multiple headers can fit in a single page

■ Connection-oriented NDIS (CoNDIS) allows NDIS drivers to manage connectionoriented media such as PPP devices (CoNDIS is described in more detail shortly.)

The interfaces that the NDIS library provides for NDIS drivers to interface with network adapter hardware are available via functions that translate directly to corresponding functions in the HAL

eXPeriMeNT: Listing the Loaded NDiS Miniports

The Ndiskd kernel debugger extension library includes the !miniports and !miniport commands, which let you list the loaded miniports using a kernel debugger and, given the address

of a miniport block (a data structure Windows uses to track miniports), see detailed information

about the miniport driver The following example shows the !miniports and !miniport commands being used to list all the miniports and then specifics about the miniport responsible for interfacing the system to a PCI Ethernet adapter (Note that WAN miniport drivers work with dial-up connections.)

1 lkd> load ndiskd

2 Loaded ndiskd extension DLL

3 lkd> !miniports

4 NDIS Driver verifier level: 0

5 NDIS Failed allocations : 0

6 Miniport Driver Block: 86880d78, Version 0.0

7 Miniport: 868cf0e8, NetLuidIndex: 1, IfIndex: 9, RAS Async Adapter

8 Miniport Driver Block: 84c3be60, Version 4.0

9 Miniport: 84c3c0e8, NetLuidIndex: 3, IfIndex: 15, VMware Virtual Ethernet Adapter

10 Miniport Driver Block: 84c29240, Version 0.0

11 Miniport: 84c2b438, NetLuidIndex: 0, IfIndex: 2, WAN Miniport (SSTP)

17 BUS_MASTER, 64BIT_DMA, IGNORE_TOKEN_RING_ERRORS

18 DESERIALIZED, RESOURCES_AVAILABLE, SUPPORTS_MEDIA_SENSE

58 Translated Allocated Resources:

59 Memory: ecef0000, Length: 10000

60 Interrupt Level: 9, Vector: a8

68 Miniport Filter List:

69 Miniport Open Block Queue:

70 8669bad0: Protocol 86699530 = NDISUIO, ProtocolBindingContext 8669be88, v6.0

71 86690008: Protocol 86691008 = VMNETBRIDGE, ProtocolBindingContext 866919b8, v5.0

72 84f81c50: Protocol 849fb918 = TCPIP6, ProtocolBindingContext 84f7b930, v6.1

73 84f7b230: Protocol 849f43c8 = TCPIP, ProtocolBindingContext 84f7b5e8, v6.1 The Flags field for the miniport that was examined indicates that the miniport supports 64-bit direct memory access operation (64BIT_DMA), that the media is currently not active (NOT_MEDIA_CONNECTED), and that it can dynamically detect whether the media is connected or disconnected (SUPPORTS_MEDIA_SENSE) Also listed are the adapter’s system-to-device power-state mappings and the bus resources that the Plug and Play manager assigned to the adapter (See the section “The Power Manager” in Chapter 7 for more information

on power-state mappings.)

12.7.1 Variations on the NDIS Miniport

The NDIS model also supports hybrid network transport NDIS drivers, called NDIS intermediate drivers These drivers lie between transport drivers and NDIS drivers To an NDIS driver, an NDIS intermediate driver looks like a transport driver; to a transport driver, an NDIS intermediate driver looks like an NDIS driver NDIS intermediate drivers can see all network traffic taking place on a system because the drivers lie between protocol drivers and network drivers Software that provides fault tolerant and load balancing options for network adapters, such as Microsoft’s Network Load Balancing Provider, are based on NDIS intermediate drivers Finally, the NDIS model also implements lightweight filter drivers (LWDs), which are similar to intermediate drivers but specifically designed for filtering network traffic LWDs support dynamic insertion and removal while the protocol stack is running Filter drivers have the ability to filter almost all communications to and from the underlying miniport adapter because they’re not associated with a particular protocol driver They also have the ability to select only certain services for filtering and to be bypassed for those that they are not interested in Just like insertion and removal, these service bindings are also dynamic and can change at run time

12.7.2 Connection-Oriented NDIS

Support for connection-oriented network hardware (for example, PPP) is native in Windows, which makes connection management and establishment standard in the Windows network architecture Connection-oriented NDIS drivers use many of the same APIs that standard NDIS drivers use; however, connection-oriented NDIS drivers send packets through established network connections rather than place them on the network medium

In addition to miniport support for connection-oriented media, NDIS includes definitions for drivers that work to support a connection-oriented miniport driver:

■ Call managers are NDIS drivers that provide call setup and teardown services for connection-oriented clients (described shortly) A call manager uses a connectionoriented miniport

to exchange signaling messages with other network entities such as network switches or other call managers A call manager supports one or more signaling protocols

■ An integrated miniport call manager (MCM) is a connection-oriented miniport driver that also provides call manager services to connection-oriented clients An MCM is essentially an NDIS miniport driver with a built-in call manager

■ A connection-oriented client uses the call setup and teardown services of a call manager or MCM and the send and receive services of a connection-oriented NDIS miniport driver A connection-oriented client can provide its own protocol services to higher levels in the network stack, or it can implement an emulation layer that interfaces connectionless legacy protocols and connection-oriented media An example of an emulation layer fulfilled by a connection-oriented client is a LAN emulation (LANE), which hides the connected-oriented characteristics of ATM and presents a connectionless media (such as Ethernet) to protocols above it

Figure 12-27 shows the relationships between these components

eXPeriMeNT: using Network Monitor to Capture Network Packets

Microsoft provides a tool named Network Monitor that lets you capture packets that flow through one or more NDIS miniport drivers on your system by installing an NDIS lightweight filter driver (Netmon) You can obtain the latest version of Network Monitor by going to the Microsoft Support Knowledge Base Article http://support.microsoft.com/kb/955998 When you first start Network Monitor, you’ll see a window similar to the one shown here:

In the Select Networks pane, Network Monitor lets you select which network connection you want to monitor After selecting one or more, start the capture environment by clicking the New Capture button on the toolbar You can now initiate monitoring by clicking the Start button on the toolbar Perform operations that generate network activity on the connection you’re monitoring (such as browsing to a Web site), and after you see that Network Monitor has captured packets, stop monitoring by clicking the Stop button In the Frame Summary pane, you will see all the raw network traffic during the capture period The Network Conversations pane will display network traffic isolated by process, whenever possible By clicking on the Iexplore.exe process in this example, Network Monitor shows only the relevant frames in the Frame Summary view, as shown next

The window shows the HTTP packets that Network Monitor captured as the Microsoft Web site was accessed through Internet Explorer If you click on a frame, Network Monitor displays a view of the packet that breaks it apart to show various layered application and protocol headers in the Frame Details pane, as shown in the previous screen shot

Network Monitor also includes a number of other features, such as capture triggers and filters, that make it a powerful tool for troubleshooting network problems You can also add parsers for other protocols, as well as view and modify their source code Network Monitor parsers are hosted

on CodePlex, the Microsoft open source project site

12.7.3 Remote NDIS

Prior to the development of Remote NDIS, a vendor that developed a USB network device, for example, had to provide a driver that interfaced with NDIS as a miniport driver as well as interfacing with a USB WDM bus driver, as shown in Figure 12-28 If the vendor’s hardware supported other buses, such as IEEE 1394, the vendor was required to implement drivers that interfaced with each specific bus type

Remote NDIS is a specification for network devices on dynamic Plug and Play I/O buses such as USB, IEEE 1394, Bluetooth, and Infiniband The specification eliminates the need for a hardware vendor to write an NDIS miniport driver at all by defining bus-independent messages

and the mechanism by which the messages are transmitted over various buses Remote NDIS messages mirror the NDIS interface and include messages for initializing and resetting a device, transmitting and receiving packets, setting and querying device parameters, and indicating media link status

The Remote NDIS architecture, in Figure 12-29, relies on a Microsoft-supplied NDIS miniport driver, \%SystemRoot%\System32\Drivers\Rndismp.sys, that translates NDIS commands and forwards them to a bus transport driver for the bus on which a device is located The architecture allows for a single NDIS miniport driver to be used for all Remote NDIS drivers and

a single bus transport driver for each supported bus

Currently, Remote NDIS for USB devices is included on Windows While Remote NDIS on IEEE 1394 is fully specified, Windows does not yet support it, nor does it support it over Infiniband

12.7.4 QoS

If no special measures are taken, IP traffic is delivered over a network on a first-come, firstserve basis Applications have no control over the priority of their messages, and they can experience bursty network behavior, where they occasionally obtain high throughput and low latencies, but otherwise receive poor network performance While this level of service is acceptable in most situations, an increasing number of network applications demand more consistent service levels, or quality of service (QoS) guarantees Video conferencing, media streaming, and enterprise resource planning (ERP) are examples of applications that require good network performance QoS allows an application to specify minimum bandwidth and maximum latencies, which can be satisfied only if every networking software and hardware component between a sender and a receiver supports QoS standards such as IEEE 802.1P, an industry standard that specifies the format of QoS packets and how OSI layer 2 devices (switches and network adapters) respond to them

Windows supports QoS through a policy-based QoS implementation that takes full advantage

of the Next Generation TCP/IP network stack, the WFP, and NDIS lightweight filter drivers The implementation allows for managing or prioritizing bandwidth use based on different conditions, such as the application, the source or destination IP address, the protocol being used, and the

source or destination ports Network administrators typically apply QoS settings to a logon session

or a computer with Active Directory–based Group Policy, but they can be applied locally as well Policy-based QoS provides two methods through which bandwidth can be managed The first uses a special field in the IP header called the Differentiated Services Code Point (DSCP) Routers that support DSCP read the value and separate packets into specific queues The QoS architecture

in Windows can mark outgoing packets with the appropriate DSCP field so that network devices can provide differentiated levels of service The other bandwidth management method is the ability to simply throttle outgoing traffic based on the conditions outlined earlier, where the QoS components limit bandwidth to a specified rate

The Windows QoS implementation consists of several components, as shown in Figure 12-30 First, the QoS Client Side Extension (%SystemRoot%\System32\Gptext.dll) notifies the Group Policy client and the QoS Inspection Module that QoS settings have changed Next, the QoS Inspection Module (eQoS), which is a WFP packet-inspection component implemented in the TCP/IP driver that reacts to policy changes, retrieves the updated policy and works with the transport layer and QoS Packet Scheduler to mark traffic that matches the policy Finally, the QoS Packet Scheduler, or Pacer (%SystemRoot%\System32\Drivers\Pacer.sys), provides the NDIS lightweight filter functionality, such as throttling and setting the DSCP value, to control packet scheduling based on the QoS policies Pacer also provides the GQoS (Generic QoS) and TC (Traffic Control) API support for legacy Windows applications that used these mechanisms

In addition to the systemwide, policy-based QoS support provided by the QoS architecture, Windows enables specific classes of socket-based applications to have individual and specific control of QoS behavior through an API called the Quality Windows Audio/Video Experience, or qWAVE Network-based multimedia applications, like Voice over IP (VoIP), can use the qWAVE API to query information on real-time network bandwidth and adapt to changing network conditions, as well as to prioritize packets to efficiently use the available bandwidth qWAVE also takes advantage of the topology protocols described earlier to dynamically determine if the current network devices will support the required bandwidth for a video stream, for example It can notify applications of diminishing bandwidth, at which point the multimedia application is expected to reduce the stream quality, for example

qWAVE is implemented in the QoS2 (%SystemRoot%\System32\Qwave.dll) API library and provides four main components:

■ Admission control, which determines, when a new network multimedia stream is started, if the current network can support the sustained bandwidth requested Windows Internals, Fifth Edition

■ Caching, which allows the detailed admission control checks to be bypassed if similar usage patterns occurred in the past and the calculation result was already cached

■ Monitoring and probing, which keep track of available bandwidth and notify applications during low-bandwidth or high-latency situations

■ Traffic tagging and shaping, which uses the 802.11p and DSCP technologies mentioned earlier to tag packets with the appropriate priority to ensure timely delivery

Figure 12-31 shows the general overview of the qWAVE architecture:

12.8 Binding

The final piece in the Windows networking architecture puzzle is the way in which the components at the various layers—networking API layer, transport driver layer, NDIS driver layer—locate one another The name of the process that connects the layers is binding You’ve witnessed binding taking place if you’ve changed your network configuration by adding or removing a component using the Network Connections folder

When you install a networking component, you must supply an INF file for the component (INF files are described in Chapter 7.) This file includes directions that setup API routines must follow to install and configure the component, including binding dependencies or binding relationships A developer can specify binding dependencies for a proprietary component so that the Service Control Manager (the Service Control Manager is described in Chapter 4) will not only load the component in the correct order but will load the component only if other components the proprietary component depends on are present on the system Binding relationships, which the bind engine determines with the aid of additional information in a component’s INF file, establish

connections between components at the various layers The connections specify which components a network component on one layer can use on the layer beneath it

For example, the Workstation service (redirector) will automatically bind to the TCP/IP protocol The order of the binding, which you can examine on the Adapters And Bindings tab in the Advanced Settings dialog box, shown in Figure 12-32, determines the priority of the binding (See the section “Multiple Redirector Support” earlier in this chapter for instructions on how to launch the Advanced Settings dialog box.) When the redirector receives a request to access a remote file, it submits the request to both protocol drivers simultaneously When the response comes, the redirector waits until it has also received responses from any higherpriority protocol drivers Only then will the redirector return the result to the caller Thus, it can be advantageous to reorder bindings so that bindings of high priority are also the most performance efficient or applicable to most of the computers in your network You can also manually remove bindings with the Advanced Settings dialog box

The Bind value, in the Linkage subkey of a network component’s registry configuration key, stores binding information for that component For example, if you examine HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage\Bind, you’ll see the binding information for the Workstation service

12.9 Layered Network Services

Windows includes network services that build on the APIs and components we’ve presented

in this chapter Describing the capabilities and detailed internal implementation of these services is outside the scope of this book, but this section provides a brief overview of remote access, Active Directory, Network Load Balancing, and Distributed File System (DFS), including DFS Replication (DFSR)

Remote Access

Remote access, which is available with Windows Server with the Routing and Remote Access service, allows remote access clients to connect to remote access servers and access

network resources such as files, printers, and network services as if the client were physically connected to the remote access server’s network Windows provides two types of remote access:

■ Dial-up remote access is used by clients that connect to a remote access server via a telephone or other telecommunications infrastructure The telecommunications medium is used to create a temporary physical or virtual connection between the client and the server

■ Virtual private network (VPN) remote access lets a VPN client establish a virtual pointto-point connection to the server over an IP network such as the Internet Windows also supports the Secure Socket Transmission Protocol (SSTP), which is a newer tunneling protocol for VPN connections that has the ability to pass through most firewalls and routers that block PPTP or L2TP/IPSec traffic It does so by packaging PPP data over the SSL channel of the HTTPS protocol Because the latter operates on port 443 and is usually part of typical Web browsing behavior, it is much more likely to be available than traditional VPN tunneling protocols

Remote access differs from remote control solutions because remote access acts as a proxy connection to a Windows network, whereas remote control software executes applications on a server, presenting a user interface to the client

Active Directory

Active Directory is the Windows implementation of Lightweight Directory Access Protocol (LDAP) directory services Active Directory is based on a database that stores objects representing resources defined by applications in a Windows network For example, the structure and membership of a Windows domain, including the user account and password information, are stored in Active Directory Object classes and the attributes that define properties of objects are specified by a schema The objects in the Active Directory are hierarchically arranged, much like the registry’s logical organization, where container objects can store other objects, including other container objects (See Chapter 6 for more information on container objects.)

Active Directory supports a number of APIs that clients can use to access objects within an Active Directory database:

■ The LDAP C API is a C language API that uses the LDAP networking protocol Applications written in C or C++ can use this API directly, and applications written in other languages can access the APIs through translation layers

■ Active Directory Service Interfaces (ADSI) is a COM interface to Active Directory implemented on top of LDAP that abstracts the details of LDAP programming ADSI supports multiple languages, including Microsoft Visual Basic, C, and Microsoft Visual C++ ADSI can also be used by Microsoft Windows Script Host (WSH) applications

■ Messaging API (MAPI) is supported for compatibility with Microsoft Exchange client and Outlook Address Book client applications

■ Security Account Manager (SAM) APIs are built on top of Active Directory to provide an interface to logon authentication packages such as MSV1_0 (\%SystemRoot%\System32

\Msv1_0.dll, which is used for legacy NT LAN Manager authentication) and Kerberos (\%SystemRoot%\System32\Kdcsvc.dll)

■ Windows NT 4 networking APIs (Net APIs) are used by Windows NT 4 clients to gain access to Active Directory through SAM

■ NTDS API is used to look up SIDs and GUIDs in an Active Directory implementation (via DsCrackNames mostly) as well as for its main purposes, Active Directory management and replication Several third parties have written applications that monitor Active Directory from these APIs

Active Directory is implemented as a database file that by default is named

\%SystemRoot%\Ntds\Ntds.dit, and that is replicated across the domain controllers in a domain The Active Directory directory service, which is a Windows service that executes in the Local Security Authority Subsystem (Lsass) process, manages the database, using DLLs that implement the on-disk structure of the database as well as provide transaction-based updates to protect the integrity of the database The Active Directory database store is based on a version of the Extensible Storage Engine (ESE), also known as JET Blue, database used by Microsoft Exchange Server 2007, Desktop Search, and Windows Mail The ESE library (%SystemRoot%\System32

\Esent.dll) provides routines for accessing the database, which are open for other applications to use as well Figure 12-33 shows the Active Directory architecture

Network Load Balancing

As we stated earlier in the chapter, Network Load Balancing, which is included with Windows Server 2008, is based on NDIS lightweight filter technology Network Load Balancing allows for the creation of a cluster containing up to 32 computers, which are called cluster hosts in Network Load Balancing The cluster can maintain multiple dedicated IP addresses and a single virtual IP address that is published for access by clients Client requests go to all the computers in the cluster, but only one cluster host responds to the request The Network Load Balancing NDIS drivers effectively partition the client space among available cluster hosts in a distributed manner