RE: ICMP unreachable question

["Ofir Arkin" <ofir () sys-security com>]

Steve,

If I understood you correctly you are referring to the ICMP Error
Message "Destination Unreachable - Fragmentation needed but the DF Bit
Was Set". This is Type 3 Code 4 ICMP Message.

> From "ICMP Usage in Scanning" (http://www.sys-security.com) Page 19-20:
"The (ICMP) Unused field with this datagram will be 16 bits in length,
instead of 32 bits, with this type of message. The rest of the 16 bits
will be used to carry the MTU (Maximum Transfer Unit) used for the link
that could not deliver the datagram to the next hop (or destination)
because the size of the datagram was too big to carry. Since this
datagram could not be fragmented (the DF Bit was set) an error message
has been sent to the sender indicating that a lower MTU should be used,
hinting the size of the next hops links".

This mean, that by setting this value with the ICMP error message, the
targeted host for the error message will use it to determine the MTU of
the slower link, and should use it as the maximum packet size when
initiating a communication to its target.

You can lower this value up to 68bytes (this is the lowest value the RFC
specifies). Sure it will cause the connection between two end points to
be slow, very slow.

But, RFC 1191 describes a process called "The Path MTU Discovery
Process". It defines the means to determine the path maximum transfer
unit between two communicating end points. One of the definitions, or
suggestions, is to have, periodically, tests to determine if the MTU can
be set to a lower or a higher value.

This is implementation dependent. This means that if an OS followed the
RFC closely, you can potentially lower/cripple the link between two
communicating hosts, using IP spoofing of course, but the dynamic nature
of the PMTU discovery process will set the PMTU value to his exact value
after a while.

If you know the exact interval between one dynamic PMTU discovery
process to another (determined by an algorithm), potentially you can use
it as a denial of service attack.

Hope this helps.


Ofir Arkin [ofir () sys-security com]
Founder
The Sys-Security Group
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA



-----Original Message-----
From: Steve Culligan [mailto:stephen_culligan () hotmail com] 
Sent: ו 26 אוקטובר 2001 12:05
To: pen-test () securityfocus com
Subject: ICMP unreachable question

I'm interested in a particular ICMP packet which seems to change the
client 
/ servers MTU size.
The scenario is like this
client----------->Router-vpn-vpn-vpn-vpn-vpn-Router
--------------->Firewall 
------------->Server
- Client initiates a connection with the server and starts to transmit
data.
- Router places its ESP header on the packets coming from the server
which 
brings the MTU over the maximum size
- Router sends the following packet back to the server
        icmp: 172.*.*.*  unreachable - need to frag (mtu 1454)
- ICMP packet from the router gets blocked by the firewall and the 
connection is eventually lost as the router cannot handle this MTU size.

but

If the Firewall permits the ICMP packet from the router through to the 
server, the server will lower its MTU and continue the connection.

So my question is , Can this be used as a denial of service attack to 
continually send these ICMP packets to a server to confuse it or bring
it 
down.
Anybody had any experience with this or know any tools which can
generate 
these ICMP reachable packets ?

Regards,

Steve Culligan

_________________________________________________________________
Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp


------------------------------------------------------------------------
----
This list is provided by the SecurityFocus Security Intelligence Alert
(SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please
see:
https://alerts.securityfocus.com/


----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/