Subject: [Int-area] Tracking RFC1812 compliance for ICMP replies

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 30 Jul 2013 22:29:40 +0200

Hello,

The original ICMP specification recommended that every ICMP error 
message included the Internet header and at least the first 8 data bytes 
of the datagram that triggered the error. RFC1812 changed this 
recommendation to the following

 >4.3.2.3 Original Message Header
 >
 >   Historically, every ICMP error message has included the Internet
 >   header and at least the first 8 data bytes of the datagram that
 >   triggered the error.  This is no longer adequate, due to the use of
 >   IP-in-IP tunneling and other technologies.  Therefore, the ICMP
 >   datagram SHOULD contain as much of the original datagram as possible
 >   without the length of the ICMP datagram exceeding 576 bytes.  The
 >   returned IP header (and user data) MUST be identical to that which
 >   was received, except that the router is not required to undo any
 >   modifications to the IP header that are normally performed in
 >   forwarding that were performed before the error was detected (e.g.,
 >   decrementing the TTL, or updating options).

Over the years, several routers have implemented this section of 
4.3.2.3. Since the publication of RFC1812, middleboxes have been 
deployed in various parts of IP networks. Sometimes, these middleboxes 
create problems that are hard to debug. RFC1812 compliant routers would 
ease such debugging by returning large parts of transmitted packets.

We have anecdotal evidence that the following OSes support this part of 
RFC1812 :

  Cisco IOX, Linux, Alcatel, Palto Alto firewalls

while Cisco IOS and Juniper routers do not support this RFC.

We would be interested in getting more information about the state of 
support of this section of RFC1812 on routers. If you are responsible 
for a router OS, we would appreciate if you could let us know since 
which version you send a large ICMP message back if you support it ?

The motivation for this request is that Gregory Detal recently wrote the 
tracebox tool that exploits RFC1812 compliant routers to detect 
middleboxes. It works like traceroute but sends TCP segments that 
contain various types of options and compares the transmitted segment 
with the information found in the returned ICMP messages. If the ICMP 
message is returned by an RFC1812 compliant router, tracebox is able to 
detect any modification performed by intermediate middleboxes.

 From the IETF network (a network which is much cleaner than typical 
enterprise networks from a middlebox viewpoint) we can observe the 
following with tracebox :

sudo tracebox -p 'ip{}/tcp{dst=80}/MPCAPABLE/mss(9000)' bahn.de

tracebox to 81.200.198.6 (bahn.de): 64 hops max
1: rtra.meeting.ietf.org (130.129.8.2) IP::CheckSum
2: 193.159.164.161 (193.159.164.161) IP::TTL IP::CheckSum
3: f-ed5-i.f.de.net.dtag.de (217.5.95.58) IP::TTL IP::CheckSum
4: 80.150.168.30 (80.150.168.30) IP::TTL IP::CheckSum
5: 92.79.213.121 (92.79.213.121) IP::TTL IP::CheckSum
6: 92.79.214.2 (92.79.214.2) IP::TTL IP::CheckSum
7: 92.79.201.226 (92.79.201.226) IP::TTL IP::CheckSum
8: bln-145-254-5-158.arcor-ip.net (145.254.5.158) IP::TTL IP::CheckSum
9: 88.79.13.62 (88.79.13.62) IP::TTL IP::CheckSum
10: 81.200.194.234 (81.200.194.234) IP::TTL IP::CheckSum
11: 81.200.197.9 (81.200.197.9) IP::TTL IP::CheckSum
TCPOptionPad was added
TCPOptionMPTCPCapable was suppressed
12: 81.200.198.6 (81.200.198.6) TCP::CheckSum IP::TTL IP::CheckSum 
TCPOptionMaxSegSize::MaxSegSize

In this example, we sent a huge MSS and add the MPCAPABLE option which 
is used by Multipath TCP in the SYN. tracebox shows that at hop 11 there 
is a middlebox that removes the MPCAPABLE option and later on the MSS 
option is changed. tracebox will be presented at IMC'14 in October and 
the tool will be available in open-source from http://www.tracebox.org

Best regards,

Olivier Bonaventure

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be