[ppml] Comments sent to open michrophone

Wed Apr 20 13:10:30 EDT 2005

Per request I'm reposting text of comment to the list.

------------------------------------

These are comments for open microphone session at ARIN members meeting
on Wednesday (which as has been mentioned can be continuation of open
microphone at public policy meeting on Tuesday).

During brief comments on Tuesday the issues raised were in regards to
problem with bogon filters by somebody from Shaw and separately regarding 
problems with blocklists and possible relation of that to bogons by person 
from SBC. I'd like to address some of the concerns raised and provide 
clarification of the problems, some of which are specific to the companies 
mentioned. Before I begin I would like to first apologize for the length 
of my text as there are number of separate issues here that have to be 
explained.

First of all regarding bogons it is certainly true, that those who get
allocations from new /8 blocks experience some problems with connectivity.
This is largely due static bogon filters that some ISPs use and it did not
help that cisco was for some time selling routers that came with security
auto-configuration feature with static filter of unassigned IANA /8 blocks
that were known at the time router was made. These routers do not have auto
update feature for this filter and unfortunately majority of them are used
at the isp-edge by smaller companies that do not have IT department
dedicated to internet engineering that could regularly update bogon 
filter. The situation is now better as IANA unallocated filter has been 
removed from default security configuration of the newly sold cisco 
routers and those that have old static filter as well as ISPs that 
similarly use static bogon filter are being identified by efforts such as 
the one ARIN is going to participate when testing connectivity of its new 
73/8 block. If other ISPs here would like to help, I would encourage to 
check with your T1 and similar customers and especially ask if they had 
either setup bogon filter on their own or used autosecure command on cisco 
router bought within last 18 months and if so help make sure that bogon 
filter is removed or kept updated.

Another bogon related issue for ISPs is making sure that the ip block being
announced in BGP correctly matches size of ip block allocation listed in
ARIN whois. If its not then those users on the part of ip block that has 
no whois allocation data may see themselves blocked by bogon filter. As an 
example currently Shaw Communications is announcing in BGP network 
70.64.0.0/13, where as corresponding ip block in in ARIN whois is 
70.64.0.0 to 70.71.111.255, which means almost 1/2 of the announced block 
is bogon. This also causes entire block announced in bgp to appear as 
active bogon in some monitoring systems such as ones run by 
completewhois.com or seen in weekly cidr-report. I'm sure in this case as 
in many others this was not intentional and simply an oversight or 
miscommunication to network engineering team as to the expect size of arin 
allocation and improved internal company communication and double-checking 
would help to avoid problems like this.

Moving on to the comments made by the gentlemen from SBC who noted that
individual ips are sometimes reported as being blocked by bogon filter.
It should certainly be noted that number of users who are doing bogon
filtering on individual computers or with specific service such as mail
has increased 100 times or more in the last 12 months (at least based on
logs at completewhois dns-based bogon service and that does not account
for all those who download entire bogon list on regular basis with ftp,
rsync or http), but all such bogon data is kept accurate and updated daily
and there were no serious errors with the data in at least a year, so except
for few cases such as one mentioned with Shaw, the users should not see
their individual ips blocked by bogon filter. Instead what is happening
is that many end-users who use bogon filtering may also be using number
of other blocklists, especially for mail filtering. Some users would then
get confused as to exactly which of the blocklists was responsible for
inability to communicate and may blame bogon filter when it is almost
certain is not the problem. This maybe result of either human error or
technical problem, for example openrbl.org which some use to determine
if ip is on any blocklist (and if so which one) has a problem with their
algorithm as they use string comparison instead of numerical and this
results in errors in about 5% of what they report as a match. For this
and similar reasons any reports of ip being on any blocklist should
always be double-checked by ISP staff by using dig or similar utility to
document and verify exactly which blocklist is a problem.

Further I remember that gentlemen from SBC mentioned that they ran into
problems with delisting of the ips from some blocklists and he complained
that somebody was asking them $2000 for it. I find this highly unlikely
and while I don't pretend have list of every blocklist every used or know
all their policies, all the major ones I'm aware of do not operate in this
way and are maintained based on donations or support of those who use
blocklist. None of those I know ever ask for money for delisting with
exception of SORBS (and I dont support their policy in this regard)
that does ask for $50 (but not $2000!) to be donated to a charity and
that is only to get the case expedited as otherwise listings there would
still be removed, it may just take longer. So the issue is not likely
to be money if ISP block or ip is listed, but time it may take for ISP
techs  to get in touch with blocklist operator and answer their questions
(usually to make certain the reported abuse has been dealt with).

Next it was also noted by gentelement representing SBC that while abuse
only came from one or two specific ips (often due to viruses or user
computer becoming a zombie controlled by spammer) larger ISP blocks are
ending up in blocklist. Again I don't pretend to know policy of every
blocklist, but I  do know that many if not majority do lookups in ARIN
whois to try to determine size of the block to be listed. And while
some blocklist would only limit to individual ips, its often enough that
abuse comes from several nearby ips and usually the problem are several
computers on the same LAN (easier for virus to spread and if more then
one computer is vulnerable its likely that same organization may have
security problem and other computers that are vulunerable too) and as such
preventative measure has been to expand listing to entire ip block as
listed in end-user assignment.

In case of SBC, this may have caused some additional problems. In particular
for last 12 months SBC has been listing in whois large blocks (such as
/22) as "Residential Customer / Private Address". While I originally
thought myself this assignment is to just one customer (as per my
reading of 2003-3 policy), after further research, I came to believe that
majority of such /22 are combined listing for many individual residential
dsl customers with actual user assignments varying from /32 to /26 and
that SBC is choosing to consolidate it all into one reassignment.
Blocklist operators may also be confused by this and believe that it
really is one reassignment and not multiple SBC customers.

As my interpretation of 2003-3 is different then the use by SBC described
above, I would like to see ARIN staff provide their position as to if
consolidation of multiple reassignment records into one very large one
and listing it all as "Private Customer" is in accordince with the policy.
In either case it does seem that this use is causing misunderstanding
as to the size of the exact block assigned by SBC to a customer and this
may well be part of the reason for larger SBC blocks getting listed.

I hope in above remarks I clarifed some of the issues in regards to bogons
and blocklisting. If you do have more comments on these subjects, please
raise them further on ppml or other appopriate mail list.

-- 
William Leibzon
Elan Networks
william at elan.net