revised ACL 112 ?

Hi nanogers,

Recently (today :slight_smile: I've been playing with configuring Sean
ACL 112 on our transit BGP router.
I'm surprised by the number of routes which have been dropped,
especialy in the 206.0.0.0/7 range.

The exact access list is the one Sean described on this
list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112

Here are the result:

Before:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
144.85.0.5 4 6893 42 30 687201 0 0 00:22:52 13
194.38.74.206 4 6776 28 37 687201 0 0 00:24:54 21
194.38.74.214 4 65501 26 27 687202 0 0 00:22:15 2
194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin)
194.148.254.253 4 3334 28 30 687162 0 0 00:23:04 2
195.89.0.85 4 5378 22567 26 687202 0 0 00:20:38 59045
195.141.225.1 4 6730 22398 15 687202 0 0 00:09:00 62345
195.202.192.33 4 8493 1040 1042 687202 0 0 17:17:48 0
195.202.192.41 4 8493 1040 1042 687202 0 0 17:17:53 0
195.202.192.77 4 8493 1040 1042 687202 0 0 17:17:48 0
195.202.192.117 4 8493 89 91 687202 0 0 01:26:17 0

Right after (clear ip bgp (5378|6730) soft in):
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
144.85.0.5 4 6893 45 33 749634 0 0 00:25:43 13
194.38.74.206 4 6776 31 40 749634 0 0 00:27:45 21
194.38.74.214 4 65501 28 30 749634 1 0 00:25:06 2
194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin)
194.148.254.253 4 3334 30 32 687372 0 0 00:25:56 2
195.89.0.85 4 5378 22669 29 687372 1 0 00:23:30 41236
195.141.225.1 4 6730 22452 17 687372 14 0 00:11:52 42188
195.202.192.33 4 8493 1043 1045 749634 0 0 17:20:40 0
195.202.192.41 4 8493 1043 1045 749634 0 0 17:20:44 0
195.202.192.77 4 8493 1043 1045 749634 0 0 17:20:40 0
195.202.192.117 4 8493 92 94 749634 0 0 01:29:09 0

lsne-br1#sh access-lists 199
Extended IP access list 199
    permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 (35236 matches)
    permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 (20987 matches)
    permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 (15285 matches)
    permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 (894 matches)
    permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 (611 matches)
    permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0
    permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 (10520 matches)
    permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 (20 matches)
    permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 (6 matches)
    permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 (10 matches)
    permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 (2 matches)
    permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 (2 matches)
    permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 (2 matches)
    permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0
    permit ip 9.2.0.0 0.0.255.255 host 255.255.0.0 (2 matches)
    permit ip 9.20.0.0 0.0.255.255 host 255.255.192.0
    permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0
    deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 (1458 matches)
    deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255
    deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255
    deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255
    deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255
    deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255
    deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255
    deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255
    deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0
    deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 (4635 matches)
    deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255
    deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255
    deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255
    deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255
    deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255
    deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255
    deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255
    deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 (12062 matches)
    deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255
    deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255
    deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255
    deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255
    deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255
    deny ip 224.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255
    deny ip 224.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255
    deny ip 224.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255
    deny ip 224.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255
    deny ip 224.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255
    deny ip 224.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255
    deny ip any host 255.255.255.0 (9567 matches)
    deny ip any 0.0.0.128 255.255.255.127 (335 matches)
    deny ip any 0.0.0.64 255.255.255.191
    deny ip any 0.0.0.32 255.255.255.223
    deny ip any 0.0.0.16 255.255.255.239
    deny ip any 0.0.0.8 255.255.255.247
    deny ip any 0.0.0.4 255.255.255.251
    deny ip any 0.0.0.2 255.255.255.253
    deny ip any 0.0.0.1 255.255.255.252
    deny ip 240.0.0.0 15.255.255.255 any
    deny ip 0.0.0.0 0.255.255.255 any

After reverting order of specific bit masking:
Right after (clear ip bgp (5378|6730) soft in)..
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
144.85.0.5 4 6893 378 366 808741 0 0 05:56:23 88
194.38.74.206 4 6776 364 383 808741 0 0 05:58:25 21
194.38.74.214 4 65501 359 360 808741 0 0 05:55:46 2
194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin)
194.148.254.253 4 3334 361 377 808741 0 0 05:56:36 2
195.89.0.85 4 5378 81719 362 808741 0 0 05:54:09 40707
195.141.225.1 4 6730 31911 350 808741 0 0 05:42:32 42273
195.202.192.33 4 8493 1374 1376 809317 0 0 22:51:19 0
195.202.192.41 4 8493 1374 1376 809317 0 0 22:51:24 0
195.202.192.77 4 8493 1374 1376 809317 0 0 22:51:19 0
195.202.192.117 4 8493 422 424 809317 0 0 06:59:48 0

lsne-br1#sh access-lists 199
Extended IP access list 199
    permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 (35360 matches)
    permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 (23838 matches)
    permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 (15257 matches)
    permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 (894 matches)
    permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 (612 matches)
    permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0
    permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 (10540 matches)
    permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 (20 matches)
    permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 (6 matches)
    permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 (10 matches)
    permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 (2 matches)
    permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 (2 matches)
    permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 (2 matches)
    permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0
    permit ip 9.2.0.0 0.0.255.255 host 255.255.0.0 (2 matches)
    permit ip 9.20.0.0 0.0.255.255 host 255.255.192.0
    permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0
    deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 (1434 matches)

means that ~700 networks in the old A class are announced /15

    deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 (12 matches)
    deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 (6 matches)
    deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 (6 matches)
    deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255
    deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255
    deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255
    deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 (4 matches)
    deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0
    deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 (2946 matches)

~1500 networks in the old B class are announced /23

    deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 (656 matches)
    deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 (281 matches)
    deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 (156 matches)
    deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 (170 matches)
    deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 (205 matches)
    deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 (123 matches)
    deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 (147 matches)
    deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 (7752 matches)

~3800 nets announced /23 in the supposedely /18 allocated old C space

    deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 (1379 matches)
    deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 (1047 matches)
    deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 (770 matches)
    deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 (676 matches)
    deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 (422 matches)
    deny ip 224.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255
    deny ip 224.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255
    deny ip 224.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255
    deny ip 224.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255
    deny ip 224.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255
    deny ip 224.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255
    deny ip any host 255.255.255.0 (9611 matches)
    deny ip any 0.0.0.1 255.255.255.252
    deny ip any 0.0.0.2 255.255.255.253 (18 matches)
    deny ip any 0.0.0.4 255.255.255.251 (28 matches)
    deny ip any 0.0.0.8 255.255.255.247 (22 matches)
    deny ip any 0.0.0.16 255.255.255.239 (53 matches)
    deny ip any 0.0.0.32 255.255.255.223 (102 matches)
    deny ip any 0.0.0.64 255.255.255.191 (92 matches)
    deny ip any 0.0.0.128 255.255.255.127 (45 matches)
    deny ip 240.0.0.0 15.255.255.255 any
    deny ip 0.0.0.0 0.255.255.255 any

I know that some old unused A classe were being reallocated
CIDR. Don't know much about anything else.
Also, old 1995 ACL112 doesn't consider europeean allocation
policy (194/8 at /24, 195/8 at /20 for example), while
today sprint filtering policy take this into consideration.

Anyone clueful on this topic? Is old 1995 ACL112 way to
restrictive? or ISP behavior really really bad (RAM is cheap
nowadays.. except cisco RAM :slight_smile:

TIA, cheers.

Who is announcing these crap routes?

Would be interesting to add 'top 10 bogus route announcements' to the
weekly CIDR list.

-Dan

Since you are using my copy of Sean's filters, I'll comment.

I put that up as reference material, not as a recommendation. My
"official" recommendation for filtering is:

http://www.merit.edu/ipma/docs/help.html

And it might interest you to know that, to the best of my knowledge,
neither EBONE (Sean's current employer) or Sprint (Sean's former employer)
use that type of filter any longer. The only thing I can see from any big
providers is filtering on /24s. (If someone knows differently, please
correct me. I'm just commenting on what I see - I have no first hand
knowledge of the filters in anyone else's routers.)

But feel free to use whatever you like on your network. I just don't want
you to think that *I* use those.

TTFN,
patrick

In February we received a new /20 CIDR from ARIN. I felt that we might be
caught by the filters at ISPs like Sprint (http://www.sprint.net/filter.htm).
I contacted Sprint twice and spoke to two different engineers, both told
me that they were not filtering as their page described, and they would
allow advertisements for /20 in 206/8 - 233/8. Since that time I have
spoken to several people who purchase transit from Sprint, and they do
indeed see my advertisements. Looking at NetFlow stats I can't find any
major provider that we have not had traffic flow between. I assume they
had to have accepted my advertisements, nobody runs BGP and default routes
:).

BTW: I also contacted, and received a similar response from ANS.

The exact access list is the one Sean described on this
list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112

Something I had forgotten was pointed out to me by a friend. THAT LIST
CONTAINS ERRORS - YOU ARE DENYING VALID ROUTES. And I do not mean just
those with masks longer than 19 bits.

Specifically, from
http://www.cctec.com/maillists/nanog/historical/9509/msg00107.html, we see:

! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *)
! (allow mask bits in first 18 bits)
! 1100111x == {206,207}
! 1110xxxx == {208-239}
!
access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0
access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0

Which *should* be:

! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *)
! (allow mask bits in first 18 bits)
! 1100111x == {206,207}
! 1101xxxx == {208,224}
! 1110xxxx == {224-239}
!
access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0
access-list 112 permit ip 208.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0
access-list 112 permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0

(Ignoring the fact that /19s were just allowed in 206/8 in the line before. :slight_smile:

This was a very early rev of 112, posted by Sean here on NANOG. (The
earliest I could find, in fact.) First of all, you are blocking even /19s
in all but 206/8, allowing /18s. But you are *completely* blocking
208-224, as there is no permit statement for them.

I am sorry, I never intended that page to be USED by anyone, it was
strictly there for historical/reference purposes.

Philippe, if you are going to use something like a modern ACL112, please
check out Sean's later posts in the NANOG archive.

I shall update the page soon with a correct version of 112, and a
corrected/updated version of my filter from the merit page. Sorry if
anyone else has used this filter.

Philippe Strauss, ingenieur reseau/systemes, Urbanet SA

TTFN,
patrick

P.S. I am no way implying this is Sean's fault. The web page is an early,
untested version and I really never meant for anyone to actually USE it.
In fact, there is no link to the list anywhere on any of my other pages or
anything like that. Philippe must have attended one of my classes or
something, where I specifically stated it was an early, broken version.

>The exact access list is the one Sean described on this
>list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112

Something I had forgotten was pointed out to me by a friend. THAT LIST
CONTAINS ERRORS - YOU ARE DENYING VALID ROUTES. And I do not mean just
those with masks longer than 19 bits.

Specifically, from
http://www.cctec.com/maillists/nanog/historical/9509/msg00107.html, we see:

! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *)
! (allow mask bits in first 18 bits)
! 1100111x == {206,207}
! 1110xxxx == {208-239}
!
access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0
access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0

Which *should* be:

! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *)
! (allow mask bits in first 18 bits)
! 1100111x == {206,207}
! 1101xxxx == {208,224}
! 1110xxxx == {224-239}
!
access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0
access-list 112 permit ip 208.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0
access-list 112 permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0

Oh ok, quiet a nice chunk of adresse space left on the floor there :slight_smile:

(Ignoring the fact that /19s were just allowed in 206/8 in the line before. :slight_smile:

This was a very early rev of 112, posted by Sean here on NANOG. (The
earliest I could find, in fact.) First of all, you are blocking even /19s
in all but 206/8, allowing /18s. But you are *completely* blocking
208-224, as there is no permit statement for them.

I am sorry, I never intended that page to be USED by anyone, it was
strictly there for historical/reference purposes.

Yes, I've used it because it was the only version of Sean's ACL112 I've found.
My goal was just to experiment about how isp's desaggregate ip space
relative to how assigning authorities distribute it.

I've deployed this ACL on a stub AS, with a default route pointing to
one of my transit provider.

Philippe, if you are going to use something like a modern ACL112, please
check out Sean's later posts in the NANOG archive.

OK, thanks for the advice.
Will look the archive.
But for production, I stick to your ACL190.
Anyone having references about how assigning authorities claim
to aggregate address space? (I know that RIPE never allocater longer than /20
in 195.0.0.0/8)
ACL112 take various assumption, were are the reference information about
that?

I shall update the page soon with a correct version of 112, and a
corrected/updated version of my filter from the merit page. Sorry if
anyone else has used this filter.

>Philippe Strauss, ingenieur reseau/systemes, Urbanet SA

TTFN,
patrick

P.S. I am no way implying this is Sean's fault. The web page is an early,
untested version and I really never meant for anyone to actually USE it.
In fact, there is no link to the list anywhere on any of my other pages or
anything like that. Philippe must have attended one of my classes or
something, where I specifically stated it was an early, broken version.

Altavista found it for me :slight_smile:
Try ACL112 and look the result. Time to write a robot.txt :-))

Thanks for you time.

I am sorry, I never intended that page to be USED by anyone, it was
strictly there for historical/reference purposes.

Yes, I've used it because it was the only version of Sean's ACL112 I've found.
My goal was just to experiment about how isp's desaggregate ip space
relative to how assigning authorities distribute it.

Funny, I wonder why you didn't get the original NANOG post - the URL to
which I copied in my last post.

Philippe, if you are going to use something like a modern ACL112, please
check out Sean's later posts in the NANOG archive.

OK, thanks for the advice.
Will look the archive.

Actually, I did a brief perusal of the archives on www.nanog.org and didn't
find the final version. Does anyone have a copy I can post on the web site?

But for production, I stick to your ACL190.

Thanx, but there is a minor error in that one too. :slight_smile: Don't use the
192.0.0.0/8 line. (Not that it should hurt anything, but don't use it
anyway.) I'll be putting up a better one in a little while.

Anyone having references about how assigning authorities claim
to aggregate address space? (I know that RIPE never allocater longer than /20
in 195.0.0.0/8)
ACL112 take various assumption, were are the reference information about
that?

If you go to the URL I copied in my last post and look at the threads
surrounding it, Sean's logic is partially exposed in posts to this very
list - as well as other peoples' reactions to his logic. (Please note that
I am in no way claiming to know why Sean did something, just pointing out
that he posted some reasons to NANOG that might clarify his reasoning.)

Altavista found it for me :slight_smile:
Try ACL112 and look the result. Time to write a robot.txt :-))

Heh. Those damned robots. :slight_smile:

Philippe Strauss, ingenieur reseau/systemes, Urbanet SA

TTFN,
patrick