Cisco IOS: Uniform Fragmentation bei IPSec

Im Cisco Security-Kurs DVS (Designing VPN Security) wird als ein Thema “look-ahead fragmentation” (in der Doku “IPSec pre-fragmentation” genannt) angesprochen. Bei diesem Verfahren wird ein IP-Paket, das nach der Verschlüsselung größer als die Link-MTU wäre, schon vor der Verschlüsselung fragmentiert. Dieses wird gemacht, damit der IPSec-Peer nicht zwei IPSec-Fragmente im Process-Switching zusammenbauen muß, um diese dann entschlüsseln zu können.
In dem Kursbeispiel wird ein IP-Paket von 1500 Byte bei einem angenommenen ESP-Overhead von 46 Bytes in zwei IP-Fragmente von 1454 und 66 Bytes fragmentiert. Das widerspricht natürlich komplett der Dokumentation, die von einer “Uniform Fragmentation” spricht, in der die IP-Pakete in gleich große Fragmente zerteilt werden, um die Wahrscheinlichkeit weiterer Fragmentierung auf dem Weg zu verringern.

Was der Router bei der “look-ahead fragmentation” wirklich macht, ist leicht mit einem Sniffer (das Beispiel unten wurde mit Wireshark aufgenommen) herauszubekommen. Dabei habe ich ein ICMP-Paket von 1500 Byte (ping mit einer Payload von 1472 Byte) durch einen IPSec-Tunnel gesendet und auf dem Empfangs-PC mitgesniffert.

Dabei kamen auf dem Ziel-PC nachfolgende Fragmente an:

Ethernet II, Src: 00:04:dd:0f:e4:59, Dst: 00:12:3f:e8:42:9a
Internet Protocol, Src: 10.255.254.152, Dst: 192.168.255.2
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 764
    Identification: 0x8f31 (36657)
    Flags: 0x02 (More Fragments)
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..1. = More fragments: Set
    Fragment offset: 0
    Time to live: 127
    Protocol: ICMP (0x01)
    Header checksum: 0xc08c [correct]
    Source: 10.255.254.152
    Destination: 192.168.255.2
    Reassembled IP in frame: 36
Data (744 bytes)

Ethernet II, Src: 00:04:dd:0f:e4:59, Dst: 00:12:3f:e8:42:9a
Internet Protocol, Src: 10.255.254.152, Dst: 192.168.255.2
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 756
    Identification: 0x8f31 (36657)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 744
    Time to live: 127
    Protocol: ICMP (0x01)
    Header checksum: 0xe037 [correct]
    Source: 10.255.254.152
    Destination: 192.168.255.2
    [IP Fragments (1480 bytes): #35(744), #36(736)]
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x2948 [correct]
    Identifier: 0x0300
    Sequence number: 0x1400
    Data (1472 bytes)

Auf dem Ziel-PC wurden also zwei Fragmente empfangen, die eine IP-Länge von 764 und 756 Bytes hatten. Zu diesem Thema hatte die Cisco-Doku recht und es ist einfach nur einer von vielen Fehlern in den Cisco-Schulungsunterlagen.