I. Hint to enable the PMTU-function for Windows 2000 Sever (Win2000) - For all Windows Operating Systems without Windows 2000 the PMTU function is enabled by default. (Maybe sometimes other default values in some cases) - For Operating System Windows 2000 the PMTU function has to be enabled by adding the two following keys HKEY-LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Parameter Type Value ------------------------------------------------------------------------------------ EnablePMTUBHDetect DWORT-Wert 1 EnablePMTUDiscovery DWORT-Wert 1 Date of state: 10.4.2003 ######################################################################################## Additional Information to the statement: > For all Windows Operating Systems without Windows 2000 the PMTU function is enabled by default. > (Maybe sometimes other default values in some cases) Excerpt from MS-knowledge-base articles: 1. TCP/IP and NBT Configuration Parameters for Windows -------------------------------------------------------------------------------------------- The information in this article applies to: Microsoft Windows 2000 Professional Microsoft Windows 2000 Server Microsoft Windows 2000 Advanced Server Microsoft Windows 2000 Datacenter Server Microsoft Windows NT Workstation versions 3.5 , 3.51 , 4.0 Microsoft Windows NT Server versions 3.5 , 3.51 , 4.0 ... EnablePMTUDiscovery ------------------------------------- Key: Tcpip\Parameters Value Type: REG_DWORD - Boolean Valid Range: 0,1 (False, True) Default: 1 (True) Description: Setting this parameter to 1 (True) causes TCP to attempt to discover the Maximum Transmission Unit (MTU or largest packet size) over the path to a remote host. By discovering the Path MTU and limiting TCP segments to this size, TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs. Fragmentation adversely affects TCP throughput and network congestion. Setting this parameter to 0 causes an MTU of 576 bytes to be used for all connections that are not to machines on the local subnet. 2. TCP/IP and NBT Configuration Parameters for Windows --------------------------------------------------------------------------------------------- The information in this article applies to: Microsoft Windows 95 Microsoft Windows 98 Microsoft Windows 98 Second Edition Microsoft Windows Millennium Edition ... PMTUDiscovery = 0 oder 1 ------------------------------------------- Datentyp: DWORD Für Windows 98 ist der Datentyp eine Zeichenfolge. Legt fest, ob Microsoft TCP/IP die MTU-Discovery gemäß RFC 1191 ausführt. Der Standardwert ist 1. II. Important hints for using PMTU Discovery in connection with IPSec and SIF PMTU discovery has the aim to prevent/prohibit fragmentation over any LAN / WAN or Tunnel interface. It does not matter wether the IP-packets are transmitted over leased lines, dialup-lines, IPSec tunnels or wether the internet is used or not. The realization is rather simple: - Every TCP/IP hosts system has the possibility to activate PMTU discovery - When PMTU discovery is activated, this hosts sends every IP packet with the 'Dont fragment'-Flag set - A router which has to route such a packet is not allowed to split this packet into fragments. He must inform the sender of the packet, that it could not deliver the packet. - This information is given to the sender of the packet via a ICMP packet (Type 3, Code 4), also called "destination unreachable, fragmentation needed" (see RFC 792) - Within this ICMP packet the MTU which can be used is also delivered, so that the sender can lower the used MTU accordingly Using a BinTec as IPSec Gateway makes this implementation a little bit more complex. - if a host within the LAN sends a packet with e.g. size 1500 the BinTec would notice this at once and will inform him about the lower MTU (because of the IPSec overhead) via a ICMP. - if the BinTec itself sends a packet via Internet and any router which has to route this IPSec packet (ESP packet) would have to fragment it, this router will send a ICMP packet back to the BinTec - Because the ESP packet contains encrypted data the BinTec will only know which tunnel the original packet had belonged to, but in this moment he does not know what the original sender was. So the BinTec remembers the max. MTU for this tunnel. - If another host within LAN wants to send a packet over this tunnel, he can inform this host at once. IMPORTANT: For ensuring PMTU discovery to work, one has to assure, that these ICMP packets are not filtered/blocked 1.) between the BinTec IPSec Gateway and the Internet (e.g. if the BinTec is located within a DMZ behind a firewall) 2.) between the BinTec IPSec Gateway and the hosts within the LAN. 3.) BinTec itself must not block the ICMP packets when arriving from Internet Point 1.) ======= must be configured on the firewall if any exists. Point 2.) ======= To ensure that the BinTec can transmit ICMP packets to hosts in the LAN, one has to configure the IPSec traffic list accordingly. This means, ICMPs send from the router must be allowed to be transmitted unencrypted. If the PostIPSec-Defaultrule is set to "pass" -> it should function anyway If the PostIPSec-Defaultrule is set to "drop it" -> there must be configured Pre-IPSec-Rules, which define that the router can route ICMP packets unencrypted. There also must be a Pre-IPSec-Rule (which passes your local net unencrypted) if you have defined a traffic list with Remote Address "0.0.0.0". The SIF (Stateful Inspection Firewall) _never_ blocks ICMP packets originating from the router itself, because all locally initiated sessions are allowed by SIF anyway. Point 3.) ======= For this point the implementation was adapted in the past. This means, a.) there is no NAT entry necessary to allow ICMP packets (type 3 code 4) arriving from the internet b.) there is no special entry necessary for IPSec -> the inbound IPSec filter catches this ICMP packet and computes the resulting MTU for this tunnel c.) there is no SIF entry necessary because this ICMP packet never reaches the SIF subsystem 21.05.2003 III. Hints to the implementation of MSS-Clamping on BinTec-Routers Basic informations to the topic MSS: ------------------------------------------------------- MSS is an abbreviation for "Maximum Segment Size" and is used in the TCP-Protocol. The MSS-value determines the maximum size of data-payload which can be received from a data terminal endpoint (e.g. host) within tcp-frame. The MSS-value is advertised from each data terminal endpoint during the initiation of the TCP-session. For the initiation of the TCP-session between two data terminal endpoints three IP data-packets are transmitted. The advertising of the MSS-values happens in data-packet one and two within the TCP initiation phase. The MSS-value is contained in the option field of the TCP-Header. Data-format of the TCP-option field: 1.Octet 2.Octet n octets ------------------------------------------------------- | Type | Length in octets | Value | ------------------------------------------------------- The Option MSS-value is defined with: Type : 0x02 Length: 0x04 Value : e.g. 0x05b4 The MSS-value is computed as follows: MSS = MTU - (20 octets IP-Header) - (20 octets TCP-Header) The following trace shows an ethernet-frame during an initiation of TCP-session. The TCP option-field is underlined by >>[....]<<. Step 1 - Initiator of the TCP-session sends an IP data-packet with SYNC-Flag=1 and ACK-Flag=0 and a MSS-value of 0x05b4 (1460 decimal) 000004.515625 R DATA[0062] 0000: 00 a0 f9 02 4a ee 00 00 b4 55 40 ff 08 00 45 00 ....J....U@...E. 0010: 00 30 10 24 40 00 80 06 d7 47 c0 a8 0a 01 c2 19 .0.$@....G...... 0020: 86 99 04 b6 00 50 f5 73 db 16 00 00 00 00 70 02 .....P.s......p. 0030: 40 00 5a 32 00 00 >>[02 04 05 b4]<< 01 01 04 02 @.Z2.......... DST=00:a0:f9:02:4a:ee SRC=00:00:b4:55:40:ff protocol 0x0800 IP-Packet from 192.168.10.1 to 194.25.134.153 protocol 0x6 TCP-Message, sourceport 1206 destinationport 80 sequence number 4118010646 acknowledgement number 0 offset 7 flags SYN window 16384 checksum 0x5a32 urgent 0 Step 2 - Responder of the TCP-session sends an IP data-packet with SYNC-Flag=1 and ACK-Flag=1 and a MSS-value of 0x05b4 (1460 decimal) 000005.445313 X DATA[0062] 0000: 00 00 b4 55 40 ff 00 a0 f9 02 4a ee 08 00 45 00 ...U@.....J...E. 0010: 00 30 da 47 40 00 35 06 58 24 c2 19 86 99 c0 a8 .0.G@.5.X$...... 0020: 0a 01 00 50 04 b6 7d ae 66 a6 f5 73 db 17 70 12 ...P..}.f..s..p. 0030: fa f0 ba db 00 00 01 01 04 02 >>[02 04 05 b4]<< .............. DST=00:00:b4:55:40:ff SRC=00:a0:f9:02:4a:ee protocol 0x0800 IP-Packet from 194.25.134.153 to 192.168.10.1 protocol 0x6 TCP-Message, sourceport 80 destinationport 1206 sequence number 2108581542 acknowledgement number 4118010647 offset 7 flags ACK SYN window 64240 checksum 0xbadb urgent 0 Step 3 - Initiator of the TCP-session sends an IP data-packet with SYNC-Flag=0 and ACK-Flag=1 -> TCP-Session is established 000005.500000 R DATA[0060] 0000: 00 a0 f9 02 4a ee 00 00 b4 55 40 ff 08 00 45 00 ....J....U@...E. 0010: 00 28 10 27 40 00 7f 06 d7 4c c0 a8 0a 01 c2 19 .(.'@....L...... 0020: 86 99 04 b6 00 50 f5 73 db 17 7d ae 66 a7 50 10 .....P.s..}.f.P. 0030: 44 70 9e 20 00 00 20 20 20 20 20 20 Dp. .. DST=00:a0:f9:02:4a:ee SRC=00:00:b4:55:40:ff protocol 0x0800 IP-Packet from 192.168.10.1 to 194.25.134.153 protocol 0x6 TCP-Message, sourceport 1206 destinationport 80 sequence number 4118010647 acknowledgement number 2108581543 offset 5 flags ACK window 17520 checksum 0x9e20 urgent 0 TCP-Clamping - What is the idea of this feature? -------------------------------------------------------------------------- TCP-clamping is a mechanism of our router to the manipulation of the MSS-value during the establishing of the TCP-session between two data terminal endpoints. This is sometimes useful in order to prevent fragmentation of the ip-packets in connection with firewalls or other routers. Hints to the implementation of MSS-Clamping on BinTec-Routers ----------------------------------------------------------------------------------------------------- The BinTec-router clamps the MSS-value to a certain value. In the normal case the MSS-value is computed automatically from the router as described. MSS = MTU - (20 octets IP-Header) - (20 octets TCP-Header) The normal value of MSS for data terminal endpoints with an ethernet interface is 1460 octets (0x05b4). In connection with PPP-connections the MSS-value depends from the MRU-value which is advertised during the PPP-establishing phase. Important hints: - MSS-clamping is always activated on PPP-interfaces with activated NAT - MSS-clamping is normally deactivated on ethernet-interfaces - The BinTec-Router clamps the MSS-value only for outgoing data-packets that is, for data-packets which are transmitted from the router to the data-endpoint. This has consequences when the MSS-clamping works during the TCP-establishment phase. Two cases are to be differentiated here in principle. Please see the following scenario: Scenario: MSS-clamping on | V external host <---> X1200 <---> internal host Case a) TCP-sessions is initiated from internal host: In this case, MSS-Clamping works in step 1 during the establishing of the TCP-session. That is, during the TCP-SYNC IP-Packet transmitted from initiator of the connection. external host <-----TCP-SYNC (MSS-Clamping)----- internal host external host ---TCP-ACK (none MSS-Clamping)---> internal host Case b) TCP-sessions is initiated from external host: In this case, MSS-Clamping works in step 2 during the establishing of the TCP-session. That means, during the TCP-ACK IP-Packet transmitted from responder of the connection. external host ---TCP-SYNC (none MSS-Clamping)---> internal host external host <------TCP-ACK (MSS-Clamping)------ internal host The MSS-value is also configurable statically on BinTec-routers. That is, that the value is not computed automatically from the router. The MSS-value can be configured on two ways. 1. For PPP-Interfaces: By changing of the parameter "Mtu" in the "pppExtIfTable". 2. PPP-Interfaces and all other interfaces: By changing of the parameter "TcpMssClamping" in the "ipExtIfTable". The MIB-refence description for the parameter "TcpMssClamping": "This object specifies whether TCP MSS clamping is enabled on the interface. -1 disables clamping, 0 clamps the MSS depending on the interface MTU. A value > 0 will be used as clamping size." 26.05.2003