NetworkDeelACLs

From PDP/Grid Wiki
Jump to navigationJump to search

Setting and applying ACLs on the deel and nikopn BigIron RX series

The ACLs on deel and nikopn can only be inbound, and should eb applied to all physical and virtual interfaces in a consistent way in order to be effective. Since deel contains many different kinds of networks, it is logically easier to think of the protected to be applied to the outbound direction, i.e. what kind of traffic you allow to flow towards a particular subnet, instead of thinkging aboutn the traffic allowed inbound. However, the outbound ACLs you would need to implement the logical idea are not supported on the BigIron-RX series hardware. Similarly, access-policy-groups cannot be used.

To offset this limitation, a translation utility (tr-acl) has been built to convert logical access control rules in a set of inbound-only ACLs to be used on the foundry. It converts a high-level description of all connected subnets and the list of access controls to be applied in a set of inbound ALCs, one for each subnet. Onle ACEs relevant to the connected subnet are actually put in the ACL, to limit it's total length. For this reason, the list of connected networks in the ruleset is critical!

To work in this way, you:

  1. write or update the high-level description. The one used for deel and nikopn is in the private SVN "ndpf" repository (ndpf/nl.nikhef.ndpf.config/router/ruleset.in or ruleset-nikopn.in). Make sure to commit and log changes
  2. run the tr-acl command: tr-acl ruleset.in > /tftpboot/deel-acl
  3. load the new ACLs in the router: cop tftp run 192.168.254.4 deel-acl
  4. apply them to the interfaces: conf t and ip rebind-acl all
  5. check to make sure that the CAM has not been exhausted and all ACLs actually have been applied. There should be no errors if you give the command: sho log

Example ruleset

The ruleset language looks an awful lot like the foundry syntax, but defines a couple of new constructs like subnetwork definitions, fixed pre- and post-fixes, and simple (non-recursive!) macros. For example

! ruleset for new deel router
!
interface interconnect
 connects 192.16.186.164/30
 connects 0.0.0.0/0
 excludes 192.16.186.192/26
 excludes 192.16.186.128/30
 excludes 194.171.96.0/21
 excludes 145.100.9.44/30
 excludes 172.16.0.0/12
 excludes 239.0.0.0/8
 excludes 0.0.0.0/32
 ! ban forged source IPs from entering
 ! do this once we configure IPs on our own VLANs
 prepend deny ip 194.171.96.0/21 any
 prepend deny ip 192.16.186.192/26 any
 end
! macro definitions
stanza permit-webserver
 permit tcp $src $dest eq http
 permit tcp $src $dest eq ssl
 end
!
! actual rules start here
ruleset
 !
 ! always allow established connections but filter localdomain
 permit tcp any any established
 deny ip 127.0.0.0/8 any
 deny ip any 127.0.0.0/8
 !
 ! HTTP and SSL servers on gridsrv are accessible from anywhere
 $permit-webserver(src=any,dest=194.171.96.64/28)
 !
 ! and deny all other traffic
 deny ip any any
!
end

CAM and ACLs

The SVN subdirectory also contains a simple script to inspect CAM usage on the line cards. The CAM is used for storing the ACLs and is very, very limited on the BigIron RX series. In particular:

  • each 10G port on a 4-port line card has 1024 words of CAM
  • each set of 12 1G ports on a line card (fibre, copper or telco) has 1024 words on CAM
  • each ACL takes between 2 and 8 words of CAM!

IPv6 ACLs

The foundry-tracl utility also has translators for IPv6 (when IPv6 access-lists are applied on inbound interfaces, which is needed even for the MLX-series routers since you cannot have inbound v4 and v6 ACLs on the same PPRC at the same time. Grrrr.

The 'tr6-acl' utility is pure-perl, but due to the length of the v6 prefixes and the matching algo it is a very slow tool. The 'ftr6-acl' tool uses a C-library for address matching, and relies on NetAddr::IP for that. NetAddr::IP is avaialbel from CPAN and common EL repos. Syntax is the same as for tr-acl (apart from the obvious use of v6 addresses).