Informationen zur Implementierung von Microsoft Windows 2000 tcp/IP

Das Flussdiagramm in Abb. 2 zeigt, wie eine Anwendung QoS RSVP verwendet, um einen Datenfluss an einen Client oder an Clients zu liefern. Die Anwendung ist ein Audioserver und benötigt eine zuverlässige Bandbreite von 1 Megabit pro Sekunde, um dem Client einen akzeptable Audioqualität bereitzustellen. RSVP unterstützt sowohl Unicast- als auch Multicastdatenflüsse. In diesem Beispiel wird ein Unicastdatenfluss an einen einzelnen Client verwendet.

Die Anwendung initialisiert und vervollständigt eine Struktur, die an GQoS bereitzustellen ist. Diese Struktur enthält eine Spezifikation für das Senden und Empfangen des Datenflusses. Datenflussspezifikationen enthalten Parameter, wie Spitzenbandbreite, Latenzzeit, Verzögerungsabweichungen, Diensttyp usw. Beispiele für Diensttypen sind Höchstleistung und Garantierter Dienst.

Die Anwendung ruft dann WSAConnect auf, um eine Verbindung zum Client herzustellen. Ein Aufruf dieser Funktion löst eine Reihe von Ereignissen aus. RSVP wird aufgerufen, um dem Netzwerk durch das Senden spezieller Pfadmeldungen Signale zu senden. Eine Pfadmeldung wird an dieselbe Ziel-IP-Adresse geschickt, an die der Datenfluss geht, sie soll jedoch die Router in dem Datenfluss einrichten und den Datenfluss identifizieren. Ein Router, der eine Pfadmeldung erhält, fügt seine eigene IP-Adresse in den letzten Abschnitt der Pfadmeldung ein und leitet die Meldung an den nächsten Router in dem Pfad weiter, bis diese den Client erreicht. Dadurch kennt der Client den Pfad zwischen dem Sender und sich selbst und reserviert auf diesem Pfad Bandbreite für die Anwendung. Der Client gibt eine Reservierungsanforderung auf demselben Pfad zurück (in der erneut der gewünschte Datenfluss beschrieben wird). Die Router entlang des Pfades sind zuständig für das Prüfen der ihnen zur Verfügung stehenden Ressourcen und entscheiden, ob sie die Reservierung akzeptieren können. Wenn alle Router entlang des Pfades der Reservierung zustimmen, kann die Anwendung sich darauf verlassen, dass die gewünschte Netzwerkbandbreite und andere Charakteristika verfügbar sind.

Da Netzwerke dynamisch sind und Server oder Client ihre Ressourcen irrtümlich aufgeben können, ohne das Netzwerk zu informieren, müssen sowohl Pfadmeldungen als auch Reservierungsanforderungen häufig aktualisiert werden. Wenn sich in dem Netzwerk nichts geändert hat, aktualisieren weitere Pfadmeldungen und Reservierungen nur den bestehenden Pfad. Wenn jedoch eine neue Route erscheint, kann sich der Pfad, der von dem Datenfluss genommen wird, "on the fly" ändern, sobald das Netzwerk die Anpassungen vornimmt.

Wenn eine Serveranwendung für das Multicasting an viele Clients verwendet wird, ergibt sich eine ähnliche Abfolge von Ereignissen. Ein interessanter Unterschied besteht darin, dass Router, wenn sie Reservierungsanforderungen von verschiedenen Clients enthalten, die auf denselben Datenfluss verweisen, die Reservierungsanforderungen zusammenfassen können, anstatt einzelne Reservierungen für denselben Informationsfluss vorzunehmen.

Weitere ausführliche Informationen zu diesen Themen finden Sie in der Winsock2-Spezifikation und RFC 2205.

IP-Sicherheit (IPSec)

IPSec (IP-Sicherheit) ist eine weitere neue Funktion von Windows 2000. Die Merkmale und Einzelheiten zur Implementierung von IPSec sind sehr komplex und sind ausführlich in einer Reihe von RFCs und IETF-Entwürfen sowie in anderen Microsoft-Whitepaper beschrieben. IPSec verwendet Sicherheit durch Verschlüsselung, um Zugriffskontrolle, verbindungslose Integrität, Datenursprungsauthentifizierung, Wiedergabeschutz, Vertraulichkeit und begrenzte Vertraulichkeit des Datenflusses bereitzustellen. Da IPSec auf der IP-Ebene bereitgestellt wird, stehen seine Dienste den Protokollen der obereren Schicht in dem Stapel und transparent den bestehenden Anwendungen zur Verfügung.

IPSec ermöglicht einem System die Auswahl von Sicherheitsprotokollen, die Entscheidung, welche(r) Algorithmus (Algorithmen) für den (die) Dienst(e) verwendet werden soll(en) und die Einrichtung und Verwaltung von kryptographischen Schlüsseln für jede Sicherheitsbeziehung. IPSec kann Pfade zwischen Hosts, zwischen Sicherheitsgateways oder zwischen Hosts und Sicherheitsgateways schützen. Die für den Datenverkehr verfügbaren und erforderlichen Dienste werden anhand der IPSec-Richtlinie konfiguriert. Die IPSec-Richtlinie kann lokal auf einem Computer konfiguriert werden oder kann durch Mechanismen der Windows 2000-Gruppenrichtlinien mithilfe der Active Directory™-Dienste zugewiesen werden. Wenn Active Directory verwendet wird, erkennen Hosts die Richtlinienzuordnung beim Starten, rufen die Richtlinie ab und suchen in regelmäßigen Abständen nach Aktualisierungen der Richtlinie. Die IPSec-Richtlinie gibt an, wie sich Computer gegenseitig vertrauen. IPSec kann entweder Zertifikate oder Kerberos als eine Methode zur Echtheitsbestätigung verwenden. Das am einfachsten zu verwendende Vertrauen ist das auf Kerberos basierende domänenübergreifende Vertrauen unter Windows 2000. Vordefinierte IPSec-Richtlinien sind so konfiguriert, dass sie Computern in derselben oder in anderen vertrauten Windows 2000-Domänen vertrauen.

Jedes IP-Datagramm, das in der IP-Schicht verarbeitet wird, wird mit einer Reihe von Filtern verglichen, die von der Sicherheitsrichtlinie bereitgestellt werden, welche von einem zu einer Domäne gehörenden Administrator für einen Computer verwaltet wird. IP kann eine der drei folgenden Aktionen mit einem Datagramm durchführen:

• 
  IPSec-Dienste bereitstellen.
  
• 
  Es unmodifiziert passieren lassen.
  
• 
  Es verwerfen.
  

• 
  Einrichten eines Filters, der den gesamten Verkehr zwischen den beiden Hosts spezifiziert
  
• 
  Auswählen einer Authentifizierungsmethode
  
• 
  Auswählen einer Verhandlungsrichtlinie (sicherer Server in diesem Fall, gibt an, dass der gesamte Datenverkehr, der dem (den) Filter(n) entspricht, IPSec verwenden muss)
  
• 
  Auswählen einer Verbindungsart (LAN, DFÜ oder alle)
  

Source IP Dest IP Prot Description

Das Öffnen einer der IP-Datagramme, die nach dem Einrichten des SA gesendet werden, lässt nur sehr wenig von dem erkennen, was sich tatsächlich in dem Datagramm befindet (eine TCP SYN- oder eine Verbindungsanforderung). Die einzigen unverschlüsselten Teile des Pakets sind die Ethernet- und IP-Header. Selbst der TCP-Header ist verschlüsselt und kann nicht von Netmon analysiert werden, wenn ESP verwendet wird.

Src IP Dest IP Protoc Description
===================================================
davemac-ipsec calvin-ipsec IP ID = 0xC906; Proto = 0x32; Len: 96
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0xC906; Proto = 0x32; Len: 96
IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Precedence = Routine
IP: Type of Service = Normal Service
IP: Total Length = 96 (0x60)
IP: Identification = 51462 (0xC906)
+ IP: Flags Summary = 2 (0x2)
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = 0x32
IP: Checksum = 0xD55A
IP: Source Address = 172.30.250.139
IP: Destination Address = 157.59.24.37
IP: Data: Number of data bytes remaining = 76 (0x004C)
00000: 52 A4 68 7B 94 80 00 00 90 1D 84 80 08 00 45 00 R.h{..........E.
00010: 00 60 C9 06 40 00 80 32 D5 5A AC 1E FA 8B 9D 3B .`..@..2.Z.....;
00020: 18 25 18 D9 03 E8 00 00 00 01 F6 EF D0 23 1C 59 .%...........#.Y
00030: BD 01 78 BE 69 24 D6 EB AE 4F 08 DA 0F D4 6C 04 ..x.i$...O....l.
00040: 5F BC A6 E0 8D BE 5C 89 2D 56 60 80 FA 8B CC 5E _.....\.-V`....^
00050: 4E 61 3D 46 75 B9 D1 5B 52 45 79 7D 1E 36 1F 01 Na=Fu..[REy}.6..
00060: FF 25 E5 BA 48 AF D7 7A D5 9A 34 3E 5D 7D .%..H..z..4>]}

Die Verwendung einer sicheren Serverrichtlinie verhindert auch, dass alle anderen Arten von Datenverkehr, die IPSec nicht verstehen oder nicht Teil derselben vertrauenswürdigen Gruppe sind, ihr jeweiliges Ziel erreichen Die Sicherer Initiator-Richtlinie stellt Einstellungen bereit, die am besten zu Servern passen. Die Datenverkehrsicherheit wird versucht, aber wenn der Client IPSec nicht versteht, wird in den Verhandlungen wieder zum Senden von Klartextpaketen übergegangen.

Wenn IPSec zum Verschlüsseln von Daten verwendet wird, geht die Netzwerkleistung in der Regel aufgrund der allgemeinen Belastung durch die Verschlüsselung zurück. Eine mögliche Methode zum Verringern dieser allgemeinen Belastung ist das Abladen der Verarbeitung auf ein Hardwaregerät. Da NDIS 5.0 das Abladen von Tasks unterstützt, ist es auch möglich, Verschlüsselungshardware in NICs aufzunehmen. NICs, die das Abladen von IPSec auf Hardware unterstützen, sind bei verschiedenen Anbietern erhältlich.

IPSec wird sich voraussichtlich zu einem beliebten Standard für den Schutz des Datenaufkommens in öffentlichen Netzwerken und für das interne vertrauliche Datenaufkommen in Firmen-/Behördennetzwerken entwickeln. Eine standardmäßige Implementierung kann darin bestehen, dass die IPSec-Richtlinie für Sicherer Server nur auf spezielle Server angewendet wird, die zum Speichern und/oder Bereithalten von vertraulichen Informationen verwendet werden.

Windows 2000 stellt Unterstützung der Stufe 2 (volle Unterstützung) für IP-Multicasting (IGMP, Version 2) bereit, wie in RFC 1112 und RFC 2236 beschrieben. Die Einleitung zu RFC 1112 enthält eine gute Zusammenfassung des IP-Multicasting. In dem Text heißt es:

"IP multicasting is the transmission of an IP datagram to a host group—a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same 'best-effort' reliability as regular unicast IP datagrams; that is, the datagram is not guaranteed to arrive intact to all members of the destination group or in the same order relative to other datagrams."

"The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it."

"A host group may be permanent or transient. A permanent group has a well-known, administratively assigned IP address. It is the address—not the membership of the group—that is permanent; at any time a permanent group may have any number of members, even zero. Those IP multicast addresses that are not reserved for permanent groups are available for dynamic assignment to transient groups that exist only as long as they have members."

"Internetwork forwarding of IP multicast datagrams is handled by multicast routers that may be co-resident with, or separate from, Internet gateways. A host transmits an IP multicast datagram as a local network multicast that reaches all immediately-neighboring members of the destination host group. If the datagram has an IP time-to-live greater than 1, the multicast router(s) attached to the local network take responsibility for forwarding it towards all other networks that have members of the destination group. On those other member networks that are reachable within the IP time-to-live, an attached multicast router completes delivery by transmitting the datagram as a local multicast."

Zur Unterstützung des IP-Multicasting wird eine zusätzliche Route auf dem Host definiert. Die Route (standardmäßig hinzugefügt) gibt an, dass ein Datagramm, das an eine Multicasthostgruppe gesendet wird, durch die lokale Schnittstellenkarte an die IP-Addresse der Hostgruppe und nicht an das Standardgateway weitergeleitet werden sollte. Die folgende Route (die Sie mit dem Befehl route print anzeigen können) veranschaulicht dies:

Netzwerkadresse Netzwerkmaske Gateway Schnittstelle Anzahl
224.0.0.0 224.0.0.0 10.99.99.1 10.99.99.1 1

Hostgruppenadressen sind leicht zu erkennen, da sie im Bereich der Klasse D, nämlich 224.0.0.0 bis 239.255.255.255, liegen. Diese IP-Adressen haben alle 1110 als ihre oberen Bits.

Um ein Paket an eine Hostgruppe mit der lokalen Schnittstelle zu senden, muss die IP-Adresse als eine MAC-Adresse (Media Access Control) aufgelöst werden. Gemäß den RFCs gilt:

"An IP host group address is mapped to an Ethernet multicast address by placing the low-order 23 bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). Because there are 28 significant bits in an IP host group address, more than one host group address may map to the same Ethernet multicast address."

Beispielsweise würde ein Datagramm, das an die Multicastadresse 225.0.0.5 gerichtet ist, an die (Ethernet) MAC-Adresse 01-00-5E-00-00-05 gesendet. Die MAC-Adresse wird gebildet durch die Zusammensetzung von 01-00-5E und den 23 unteren Bits von 225.0.0.5 (00-00-05).

Da mehr als eine Hostgruppenadresse der gleichen Ethernet-Multicastadresse zugeordnet sein kann, kann die Schnittstelle Hand-Up-Multicasts für eine Hostgruppe anzeigen, an denen keine lokalen Anwendungen ein registriertes Interesse haben. Diese überflüssigen Multicasts werden von TCP/IP gelöscht.

Das IP-Multicasting wird gegenwärtig nur auf AF_INET-Sockets vom Typ SOCK_DGRAM und SOCK_RAW unterstützt. Standardmäßig werden IP-Multicastdatagramme mit einer Gültigkeitsdauer (Time to Live, TTL) von 1 versendet. Anwendungen können mit der Funktion setsockopt eine TTL angeben. Per Konvention verwenden die Multicastrouter die TLL-Schwellen, um zu bestimmen, wie weit Datagramme weitergeleitet werden. Diese TLL-Schwellenwerte sind wie folgt definiert:

• 
  Multicastdatagramme mit einer anfänglichen TTL 0 sind auf denselben Host beschränkt.
  
• 
  Multicastdatagramme mit einer anfänglichen TTL 1 sind auf dasselbe Subnetz beschränkt.
  
• 
  Multicastdatagramme mit einer anfänglichen TTL 32 sind auf denselben Standort beschränkt.
  
• 
  Multicastdatagramme mit einer anfänglichen TTL 64 sind auf dieselbe Region beschränkt.
  
• 
  Multicastdatagramme mit einer anfänglichen TTL 128 sind auf denselben Kontinent beschränkt.
  
• 
  Multicastdatagramme mit einer anfänglichen TTL 255 sind in ihrer Reichweite nicht eingeschränkt.
  

Einige Komponenten von Windows NT und Windows 2000 arbeiten mit ICMP. Beispielsweise werden für die Routersuche standardmäßig Multicasts verwendet. WINS-Server verwenden Multicasting, wenn sie versuchen, einen Replikationspartner zu finden.

TCP stellt einen verbindungsbasierten Dienst für Anwendungen mit zuverlässigem Bytedatenstrom bereit. Das Microsoft-Networking stützt sich auf den TCP-Transport für die Anmeldung, die Datei- und Druckerfreigabe, Replikation von Informationen zwischen Domänencontrollern, Transfer von Suchlisten und andere gemeinsame Funktionen. Es kann nur für die 1:1-Kommunikation verwendet werden.

TCP verwendet eine Prüfsumme sowohl in den Headern als auch in der Nutzlast von jedem Segment, um die Wahrscheinlichkeit zu verringern, dass eine Netzwerkstörung unentdeckt bleibt. NDIS 5.0 stellt Unterstützung für das Abladen von Tasks bereit, und Windows 2000 TCP nutzt dieses, indem es der NIC gestattet, die TCP-Prüfsummenberechnungen durchzuführen, sofern der NIC-Treiber diese Funktion unterstützt. Das Abladen der Prüfsummenberechnungen an die Hardware kann in Umgebungen mit hohem Durchsatz zu Verbesserungen der Leistung führen. Windows 2000 TCP wurde auch gegen eine Vielzahl von Angriffen gewappnet, die in den letzten Jahren veröffentlicht wurden, und wurde einer internen Sicherheitsüberprüfung unterzogen, die die Anfälligkeit für zukünftige Angriffe weiter mindern sollte. Beispielsweise wurde der anfängliche Sequenznummernalgorithmus so geändert, dass ISNs in zufälligen Inkrementen zunehmen. Dafür wird ein RC4-basierter Zufallsnummerngenerator verwendet, der beim Systemstart mit einem 2048-Bit-Zufallsschlüssel initialisiert wird.

Größenberechnung des TCP-Empfangsfensters und Fensterskalierung (RFC 1323)

Die Größe des TCP-Empfangsfenster ist die Menge der Empfangsdaten (in Bytes), die auf einmal in einer Verbindung gepuffert werden kann. Der sendende Host kann nur diese Datenmenge senden, bevor er auf eine Bestätigung und eine Fensteraktualisierung von dem empfangenden Host wartet. Der Windows 2000 TCP/IP-Stapel wurde so konzipiert, dass er sich an die meisten Umgebungen anpasst und größere Standardfenstergrößen verwendet als Vorgängerversionen. Anstatt einen festen Standardwert für die Fenstergröße zu verwenden, passt TCP sich an gerade Inkremente der maximalen Segmentgröße (maximum segment size, MSS) an, die während des Verbindungsaufbaus ausgehandelt wurde. Die Abstimmung des Empfangsfensters auf gerade Inkremente der MSS erhöht den Prozentsatz der TCP-Segmente mit voller Größe, die während der Übertragung von Massendaten verwendet werden.

Das Empfangsfenster hat standardmäßig eine Größe, die sich folgendermaßen errechnet:

1. 
   Die erste an einen Remotehost geschickte Verbindungsanforderung gibt eine Empfangsfenstergröße von 16 KB (16.384 Bytes) an.
   
2. 
   Nach Herstellen der Verbindung wird die Größe des Empfangsfensters auf ein Inkrement mit der maximalen TCP-Segmentgröße (maximum segment size, MSS) aufgerundet, die beim Verbindungsaufbau ausgehandelt wurde.
   
3. 
   Wenn dies nicht mindestens das Vierfache der MSS ist, wird diese auf 4 * MSS angepasst, mit einer maximalen Größe von 64 KB, sofern nicht eine Fensterskalierungsoption (RFC 1323) wirksam ist.
   

• 
  Der Registrierungsparameter TcpWindowSize (siehe Anhang A)
  
• 
  Die Windows Sockets-Funktion setsockopt (pro Socket)
  

"The three-byte Window Scale option may be sent in a SYN segment by a TCP. It has two purposes: 1. indicate that the TCP is prepared to do both send and receive window scaling, and 2. communicate a scale factor to be applied to its receive window Thus, a TCP that is prepared to scale windows should send the option, even if its own scale factor is 1. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations.

TCP Window Scale Option (WSopt):
Kind: 3 Length: 3 bytes
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+

"This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by 'shift.cnt' bits for transmission in SEG.WND. The value shift.cnt may be zero (offering to scale, while applying a scale factor of 1 to the receive window).

"This option may be sent in an initial segment (in other words, a segment with the SYN bit on and the ACK bit off). It may also be sent in a segment, but only if a Window Scale option was received in the initial segment. A Window Scale option in a segment without a SYN bit should be ignored.

"The Window field in a SYN (in other words, a or ) segment itself is never scaled."

Wenn Sie Netzwerk-Ablaufverfolgungen einer Verbindung lesen, die von zwei Computern aufgebaut wurde, die skalierbare Fenster unterstützen, beachten Sie, dass die in der Ablaufverfolgung angegebenen Fenstergrößen um den ausgehandelten Skalierfaktor skaliert werden müssen. Der Skalierfaktor kann in den Paketen zum Verbindungsaufbau (Drei-Wege-Handshake) beobachtet werden, wie im folgenden Mitschnitt von Netzwerkmonitor dargestellt:

*************************************************************************

Der Computer, der das Paket oben sendet, bietet die Fensterskalieroption mit einem Skalierfaktor von 5 an. Wenn der Zielcomputer antwortet und die Fensterskalieroption im SYN-ACK akzeptiert, gilt als vereinbart, dass jedes TCP-Fenster, das von diesem Computer bekanntgegeben wird, von diesem Punkt an um 5 Bits nach links verschoben werden muss (das SYN selbst wird nicht skaliert). Wenn der Computer beispielsweise ein 32 KB-Fenster bei seinem ersten Datenversand bekanntgegeben hat, müsste dieser Wert, wie nachfolgend dargestellt, um 5 Bits nach links verschoben (und mit Nullen aufgefüllt) werden:

32Kbytes = 0x7fff = 111 1111 1111 1111
Left-shift 5 bits = 1111 1111 1111 1110 0000 = 0xffffe (1,048,544
bytes)
Zur Kontrolle: wenn eine Zahl um 5 Bits nach links verschoben wird, entspricht dies
einer Multiplikation mit 2^5 oder 32. 32767 * 32 = 1,048,544

Der Skalierfaktor ist nicht notwendig symmetrisch, so dass er für jede Richtung des Datenstroms unterschiedlich sein kann.

Windows 2000 verwendet die Fensterskalierung automatisch, wenn TcpWindowSize auf einen Wert gesetzt wird, der größer als 64 KB ist und der Registrierungsparameter Tcp1323Opts entsprechend festgelegt wird. Weitere Einzelheiten zum Festlegen dieses Parameters finden Sie in Anhang A.

Verzögerte Bestätigungen

Wie in RFC 1122 spezifiziert, verwendet TCP verzögerte Bestätigungen (acknowledgments, ACKs), um die Anzahl der Pakete zu reduzieren, die über die Medien versendet werden. Der Microsoft TCP/IP-Stapel wählt einen bekannten Ansatz für die Implementierung von verzögerten ACKs. Wenn Daten von TCP über eine Verbindung empfangen werden, sendet es nur dann eine Bestätigung zurück, wenn eine der folgenden Bedingungen erfüllt ist:

• 
  Es wurde keine ACK für das zuvor erhaltene Segment versendet.
  
• 
  Es wird ein Segment empfangen, es geht aber innerhalb von 200 Millisekunden kein weiteres Segment für diese Verbindung ein.