[j-nsp] ARP resolution algorithm? Storage of MX transit packets?

[Clarke Morledge]

Thank you for the input thus far, folks.

Let me explain just a bit more about what I am dealing with. Because we 
get so much garbage scanning, if the scanner tries to hit an IP address, 
that does not have an ARP resolution, it really clutters up traffic 
unnecessarily. A simple case from my lab illustrates some of the 
difficulty.

Here I am sending a single transit packet, passing through my MX, destined 
to an IP that will not resolve. Since the MX has nowhere immediately to 
send the packet, the RE spits out a bunch of ARP requests:

17:30:35.095861 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, 
length 46
17:30:35.713821 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, 
length 46
17:30:36.613849 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, 
length 46
17:30:37.513831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, 
length 46
17:30:38.313831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, 
length 46

Correspondingly, rtsockmon -tn logs this:

[17:30:35:099.939] kernel     P    route      add     inet 192.168.10.21 
tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290 
rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0 
rt_mcast_nhiflist=-1610628420
[17:30:35:101.376] kernel     P    nexthop    add     inet  nh=hold 
flags=0x1 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0
[17:30:39:013.595] kernel     P    route      delete  inet 192.168.10.21 
tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290 
rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0 
rt_mcast_nhiflist=-1610628420
[17:30:39:013.710] kernel     P    nexthop    delete  inet  nh=hold 
flags=0x5 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0

In a real world case, we have generally observed a fairly even 
distribution of scanning attempts on non-resolving IPs, across an entire 
subnet, over time. So, let's say you have an unused class C, being scanned 
at the rate of 4 IPs per second, such that every address gets scanned once 
a minute.  Assuming that each incoming transit packet kicks off 5 ARP 
requests (1 initial, plus 4 retries), as I saw above, that would trigger 
somewhere over 1200 ARP requests a minute, or about 20 ARP packets a 
second.

That is a fairly moderate amplification type of attack.

In a DHCP-serviced subnet, like a /20 with some 4000 available host IPs, 
we might have only 3000 being used at any one time, but we want to give 
enough headroom to accommodate fluctuations in DHCP usage. But that leaves 
those 1000 remaining, unused IPs unintentionally triggering lots of 
unnecessary ARP traffic.

Specifically, what would be nice, is if there was a way to manipulate that 
ARP retry mechanism, from 4 retries, down to 2, to cut down on the noise. 
So far, I have not found a knob in Junos on the MX to do this.

Am I missing something?

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
200 Ukrop Way
Williamsburg VA 23187