[nsp] Favorite access lists

dre andre@operations.net
Thu, 26 Sep 2002 16:52:36 -0700


On Thu, Sep 26, 2002 at 01:48:59PM -0700, Chris Whyte wrote:
> I think you make an excellent point. I'm not completely aware to the
> extent that ACL, prefix-list and filter-list (named and numbered)
> conventions exist today within the ISP community. However, making sure
> they do exist and are published appropriately would add tremendous value
> to simplifying the operations of our collective infrastructures, imho. 
> 
> Sounds like a good (informational) RFC to me...

Also for as-path access-lists, e.g.:

ip as-path access-list 1 permit .* (Permit all)
ip as-path access-list 2 deny .*   (Deny all)
ip as-path access-list 3 permit ^$ (Permit only our routes)

and configuring route-maps so there is a final, explicit
permit statement that allows or denies appropriately.

Note these were taken from Avi Freedman's "Intro to BGP Tutorial".

I would personally like to hear accounts of ACL change procedures
at both the orgnaizational level as well as the technical details.

Example:
Business rules require two levels of authorization, one from a
2nd-level manager or supervisor (much like the 4 installer skill
levels from Telcordia) and another from the change/problem
management group that represents the network operations group.

Technical process includes loading the ACL (whether by tftp, ftp,
scp, etc or by pasting in the new configuration via telnet, ssh),
which also requires removing not the previous ACL (preventing
failback), but the second most recent ACL loaded.  The process
is then official by listing all appropriate external interface
sources (determined with e.g. "sh ip bgp s" and "sh ip int br"
and/or "sh run | i interface | access-g") and preparing two
templates - one with the new ACL name/number, the other with
the current ACL name/number - then loaded/pasted config-wise
to apply the new ACL to the appropriate interfaces.  Obviously,
you will also want to do a "show access-l <name/number>" and
note that the ACL is counting properly and again, check that
the ACL was applied to the correct interfaces.  You also
might want to test the functionality externally with tools
like nmap/hping/fragrouter/etc.

All said, ACL work can be extremely complex (firewalls are
just as bad, but I don't even want to go there) and there
should be industry standards on how they are done.

Cisco policy language can also be much different than other
compteting vendors, so standardizing is even more difficult.

What *we* operators need is a language like RPSL to describe
other types of policy ... ACL's, firewall filtering, MPLS,
things your would find in Cisco's MQoS, etc.

I had a similar idea like this after reading RFC 3346 where
the authors note "What this means is that much more is required
in the form of various types of tools to simplify and automate
the MPLS TE function".  An OO language like RPSL extensions
for MPLS could really help in building the tools.

The RPS-WG is probably not the place for this, maybe we need
a "Network Policy System" working group in the IETF.

I would appreciate any feedback (you can send mail to me
personally) on any of the above ideas.

-dre