You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Like #434, this is an old research paper translated from Chinese to English. It is also similar to #434 in its subject matter, namely null routing. It has not been available in English before.
This paper describes a way of blocking IP addresses using blackhole routing, or null routing. It is very similar to "A route propagation–based access control method for large-scale networks" from 2003. To block access to an external IP address, install a static route on all egress routers that sends traffic for that IP address to an internal blackhole server. The authors show how such routes may be automatically propagated to egress routers from a configuration host, using dynamic routing protocols. A self-diagnostic program based on Telnet remote login checks that routes are properly installed. At the blackhole server, there exists the possibility capturing packets to collect statistics on access attempts. The system described has seen "several months of practical operation".
Figure 1: Schematic diagram of IP blocking system connection using dynamic routing learning method
One could implement blackhole routing by manually logging into the control port of every egress router to edit their configurations, but this is cumbersome and wears out NVRAM. Instead, this paper uses dynamic routing protocols (RIP and OSPF) and IP tunneling (virtual links between routers) to automatically propagate the routes to egress routers from a central configuration host. Attach a "configuration router" (R0) to the network, connected to a "configuration host" (H0). Establish an IP tunnel from the configuration router to each of the network's egress—as if they were directly connected by a one hop. To block an IP address, simply configure the IP address on the configuration host's network interface. (Literally just an ifconfig(8) command: ifconfig fxp0 204.177.92.196 netmask 255.255.255.255 if you want to block the IP address 204.177.92.196.) The configuration host advertises its ownership of the IP address to the configuration router over RIP. From there, the static route is further propagated to the egress routers over OSPF.
Now, when a packet addressed to a blocked IP address hits an egress router, the egress router routes it to the configuration router (over the IP tunnel), then to the configuration host. The configuration host may simply drop the packets that are directed to it, or capture them for analysis. This is illustrated by a traceroute example that follows the path R1→R0→H0. In effect, RIP and OSPF become a convenient management interface for distributing IP address blocking rules. The only action required to block an IP address is to configure the address on the configuration host's network interface; the route propagation follows automatically after that.
It is all basically analogous to the setup of #434. The "configuration router" R0 corresponds to #434's "sample router" sr. The "configuration host" H0 serves as both the "sample server" ss and the "blackhole server" fs. Here, there are no "propagation routers" kr; the IP tunnels between routers are like the "virtual links" of #434 Section 2.1. This paper has no specialized command interface by which the configuration host instructs the configuration router to create a static route; that happens automatically when the configuration host claims an IP address.
This is a practice-oriented paper. To detect link failures and router configuration errors, there is a self-diagnostic system based on remote access over Telnet. The goal seems to be to log into the egress routers and run a command to dump the route table. The paper devotes an inordinate amount of space to the self-diagnostic system, going so far as to show the state transition diagram of a finite automaton that filters out Telnet control commands and ANSI escape sequences from the byte stream. The scan of Figure 2, the state transition diagram, is not fully legible, but you can, for example, see that reading a Telnet IAC byte takes us from STATE-TELNET-DATA to STATE-TELNET-CMD; or that reading an ASCII ESC byte takes us from STATE-TELNET-DATA to STATE-TELNET-ANSI to start processing an ANSI escape sequence. (The state machine is incorrect, by the way: Telnet and ANSI should be separate layers, with the Telnet on the outside. It would incorrectly handle a Telnet command that appears in the middle of an ANSI escape sequence, for example.)
Besides the primary effect of blocking access to IP addresses, there is a secondary advantage to this routing-based system. You can capture packets at the blackhole configuration host in order to collect statistics about which source addresses are trying to access which blocked destinations. They log the source and destination IP addresses of "all TCP packets where the destination IP address is a harmful address and the SYN flag is set in the TCP header". (It is reminiscent of "I'll shake your hand", where the censor went even further, sending a forged SYN+ACK from the blackhole server.) The surveillance system must be somewhat developed, as they have a query module to generate statistics from the logs.
The system is claimed to have been operation for several months, which would likely put the beginning of deployment in the year 2000. See #434 (comment) for evidence of such systems being deployed in practice in China in 2002.
通过几个月的实际运行,证明采用 IP 访问控制技术能够高效、安全、方便地进行对有害网站的访问控制和审计,实际效果恨好。
After several months of practical operation, it has been demonstrated that the use of IP access control technology can efficiently, safely, and conveniently implement access control and auditing of harmful websites, delivering good practical results.
The IP address 204.177.92.196 used in an example belongs to AS701, UUNET, US.
The text was updated successfully, but these errors were encountered:
As I said before, it is "misused". Under normal circumstances, a static route is a route given by the administrator based on the network topology or for other purposes. This route should at least be correct, and it can guide the router to forward the message to the correct destination. The static route used in GFW's route propagation technique is actually a wrong route, and it is intentionally misconfigured. Its purpose is to direct all messages destined for a certain IP address to a "blackhole server" instead of forwarding them to the correct destination. Nothing can be done on the blackhole server so that messages are dropped silently. More often, the messages can be analyzed and counted on the server to get more information, or even to make a false response.
乔佩利 (Qiao Peili) (b. 1951) is a professor at the Harbin University of Science and Technology. As of 2018 he was the Dean of the School of the Computer Science and Technology, according to his IEEE profile.
Like #434, this is an old research paper translated from Chinese to English. It is also similar to #434 in its subject matter, namely null routing. It has not been available in English before.
Implementation of an IP access control technology
李蕾 (Li Lei), 乔佩利 (Qiao Peili), 陈训逊 (Chen Xunxun)
Journal homepage
Original Chinese PDF
Online English HTML
English PDF
This paper describes a way of blocking IP addresses using blackhole routing, or null routing. It is very similar to "A route propagation–based access control method for large-scale networks" from 2003. To block access to an external IP address, install a static route on all egress routers that sends traffic for that IP address to an internal blackhole server. The authors show how such routes may be automatically propagated to egress routers from a configuration host, using dynamic routing protocols. A self-diagnostic program based on Telnet remote login checks that routes are properly installed. At the blackhole server, there exists the possibility capturing packets to collect statistics on access attempts. The system described has seen "several months of practical operation".
Figure 1: Schematic diagram of IP blocking system connection using dynamic routing learning method
One could implement blackhole routing by manually logging into the control port of every egress router to edit their configurations, but this is cumbersome and wears out NVRAM. Instead, this paper uses dynamic routing protocols (RIP and OSPF) and IP tunneling (virtual links between routers) to automatically propagate the routes to egress routers from a central configuration host. Attach a "configuration router" (R0) to the network, connected to a "configuration host" (H0). Establish an IP tunnel from the configuration router to each of the network's egress—as if they were directly connected by a one hop. To block an IP address, simply configure the IP address on the configuration host's network interface. (Literally just an ifconfig(8) command:
ifconfig fxp0 204.177.92.196 netmask 255.255.255.255
if you want to block the IP address 204.177.92.196.) The configuration host advertises its ownership of the IP address to the configuration router over RIP. From there, the static route is further propagated to the egress routers over OSPF.Now, when a packet addressed to a blocked IP address hits an egress router, the egress router routes it to the configuration router (over the IP tunnel), then to the configuration host. The configuration host may simply drop the packets that are directed to it, or capture them for analysis. This is illustrated by a traceroute example that follows the path R1→R0→H0. In effect, RIP and OSPF become a convenient management interface for distributing IP address blocking rules. The only action required to block an IP address is to configure the address on the configuration host's network interface; the route propagation follows automatically after that.
It is all basically analogous to the setup of #434. The "configuration router" R0 corresponds to #434's "sample router" sr. The "configuration host" H0 serves as both the "sample server" ss and the "blackhole server" fs. Here, there are no "propagation routers" kr; the IP tunnels between routers are like the "virtual links" of #434 Section 2.1. This paper has no specialized command interface by which the configuration host instructs the configuration router to create a static route; that happens automatically when the configuration host claims an IP address.
This is a practice-oriented paper. To detect link failures and router configuration errors, there is a self-diagnostic system based on remote access over Telnet. The goal seems to be to log into the egress routers and run a command to dump the route table. The paper devotes an inordinate amount of space to the self-diagnostic system, going so far as to show the state transition diagram of a finite automaton that filters out Telnet control commands and ANSI escape sequences from the byte stream. The scan of Figure 2, the state transition diagram, is not fully legible, but you can, for example, see that reading a Telnet IAC byte takes us from STATE-TELNET-DATA to STATE-TELNET-CMD; or that reading an ASCII ESC byte takes us from STATE-TELNET-DATA to STATE-TELNET-ANSI to start processing an ANSI escape sequence. (The state machine is incorrect, by the way: Telnet and ANSI should be separate layers, with the Telnet on the outside. It would incorrectly handle a Telnet command that appears in the middle of an ANSI escape sequence, for example.)
Besides the primary effect of blocking access to IP addresses, there is a secondary advantage to this routing-based system. You can capture packets at the blackhole configuration host in order to collect statistics about which source addresses are trying to access which blocked destinations. They log the source and destination IP addresses of "all TCP packets where the destination IP address is a harmful address and the SYN flag is set in the TCP header". (It is reminiscent of "I'll shake your hand", where the censor went even further, sending a forged SYN+ACK from the blackhole server.) The surveillance system must be somewhat developed, as they have a query module to generate statistics from the logs.
The system is claimed to have been operation for several months, which would likely put the beginning of deployment in the year 2000. See #434 (comment) for evidence of such systems being deployed in practice in China in 2002.
The IP address 204.177.92.196 used in an example belongs to AS701, UUNET, US.
The text was updated successfully, but these errors were encountered: