Consultation on change to RIP interception definition ("unintentional interception")

[Ian Batten]

> 
> And (on a much longer timescale) I could imagine someone with a static IP address and an MX server disappearing (but their DNS entries remaining), and their IP address being reassigned to another subscriber, who might start receiving some "wrong" emails (mainly Spam, but I don't see an exemption for intercepting those) if he sets up an MX server.

Many years ago, I managed to accidentally pull off a much more spectacular variation of this, which presumably would see me in chokey for decades these days.

Some part of the US Government started it (honest, guv).  They presumably had an internal mail server which offered final delivery and an external-facing system which was somewhat hardened (this is the mid-90s, so something like Gauntlet might have been in use).    This was before split-horizon DNS servers were common, so they simply published:

whatever.gov. in mx 20 external.whatever.gov.
whatever.gov. in mx 10 internal.whatever.gov.
external.whatever.gov. in a 4.5.6.7   ;;; a globally routable IP number
internal.whatever.gov. in a 192.168.1.1   ;;; RFC1918 private IP number

This is neat, they must have thought.  Instead of having to configure that pesky external system, the MX records mean it all just works: senders try to contact the internal system, fail and fall back to the external system, but the external system looks for a lower MX preference, finds it and relays the mail.  Of course, if the sender happens to have a mail server on 192.168.1.1 it'll probably break, but what are the chances, right?   

So they've been pretty silly.   Next up steps Batten, who is asked to write a config file for a Cisco to advertise his employer's networks to his ISP, because (at the time) that was how they wanted it done.  But the rule to filter out our internal networks was wrong, so as well as advertising our CIDR blocks (17 Class C addresses: those were the days, eh?) we also advertised 10/8, 172.16/12 and 192.168/16.  And the final piece of silliness in this trifecta of cocking it up was someone at PSI who neglected to filter RFC1918 from advertisements and everyone else in the world ever who happily propagated it over BGP.

Over the following days, our firewall logs lit up with endless hammering at 192.168.1.1 port 25 (we had at least correctly written the firewall rules to block all incoming RFC1918 and 127/8).  In the end we got sufficiently fed up with the alerts to bring a machine up on that IP number in a new DMZ, to have a look at what the traffic looked like.   And there it was.  Once we looked at the MX records for the traffic we were seeing it all fell into place, and was easy to fix.  I trust ISPs don't propagate routes for RFC1918 any more...

ian