Thanks for all the tips and packets we have received so far regarding protocol 61 traffic. I would like to summarize some of the responses here.

We got two captures of the suspect traffic. The source IPs are identical (5.5.128.1 and 2.2.128.1). The last octet of the target IP address is always 1. In each target network, only 1 or 2 IPs are hit by the odd packets.

The captures exhibit different time to live values, which may indicate that the packets originated from the same source in either case, but the sample is clearly too small at this point to decide about spoofed or not spoofed. My "guess" is that the IP addresses are spoofed. Yes, they are assigned real networks according to whois, but the addresses themselves just loop suspicious. Two addresses with the same last two octets, but very different first two octets doesn't sound right.

One reader pointed to a recent talk at a security conference showing that some routers are susceptibe to a denial of service if hit by odd protocols. It is possible that this tool attempts to trigger this condition, but unlikely as this wouldn't require packets at a high rate.

Most of the packets are 40 bytes in length with 20 bytes of IP header and 20 bytes of payload. One possible explanation would be that the 20 bytes of payload are actually a TCP header, but the data doesn't quite line up for that. For example, if interpreted as TCP, the TCP header length doesn't come up as 20 Bytes, and the flags are "wrong".

There are a couple of larger packets (up to 1500 bytes), but the vast majority is 40 bytes.

One reader provided some insight that the packets may be caused by an unspecified configuration or hardware error:

I have exactly the same, now for the 3rd or 4th time. Pretty unclear what this should be my guess after discussion with our upstram ISP's NOC was that there is something broken. The packets seem not to be spoofed and typically it lasts a week or so.

Personally, my bet is that this will turn out to be a configuration error or a bug, not an attack. But keep the packets coming (if you have any). Thanks to everybody contributing to this.

Two Sample packets (anonymized. The target network was changed to 10.10)

IP 5.5.128.1 > 10.10.128.1:  ip-proto-61 20
0x0000:  4500 0028 0000 0000 2f3d 7c88 0505 8001  E..(..../=|.....
0x0010:  0a0a 8001 0060 0ff3 c69c 78e1 7b42 1a25  .....`....x.{B.%
0x0020:  1197 1c27 d964 0000 0000 0000 0000       ...'.d........

IP 2.2.128.1 > 10.10.128.1:  ip-proto-61 20
0x0000:  4500 0028 0000 0000 2f3d 7f8b 0202 8001  E..(..../=......
0x0010:  0a0a 8001 0060 0ff7 c69c 60e6 7b36 e948  .....`....`.{6.H
0x0020:  ecf5 3f78 3a8d 0000 0000 0000 0000       ..?x:.........

Marked up fields for first packet

IP 5.5.128.1 > 10.10.128.1:  ip-proto-61 20
0x0000:  4500 0028 0000 0000 2f3d 7c88 0505 8001  E..(..../=|.....
         VHTO LEN  IPID FLAG TTPR CHSU Source IP
0x0010:  0a0a 8001 0060 0ff3 c69c 78e1 7b42 1a25  .....`....x.{B.%
         Target IP <--- Payload 
0x0020:  1197 1c27 d964 0000 0000 0000 0000       ...'.d........
                   ---> (ethernet padding)

V = version, H=header length, LEN=datagram length, FLAG: Frag. flags and offsets
TT: TTL, PR: Protocol, CHSU: checksum

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter