On 1 Jul 2002, Eric Brandwine wrote:
> The doc currently states "This option MUST be available on a
> per-interface basis." Perhaps going one step further, and requiring
> per-interface application of ACLs that are checked against the
> purported source address would be useful.
We may just be debating words, but per-interface basis doesn't really
capture what I'm looking for. I really want to apply controls on a
per-application basis in the router. For example, apply controls on what
kind of packets reach the NTP or BGP application process additionally
identified by the interface. Packets just passing through an interface
may not be of interest. If someone sends an IP Source Routed NTP packet
to my router, I probablly want to drop it. If someone sends someone else
an IP source routed NTP packet through my router, I may forward it
without further throught. If I add another logical or physical interface
on a router, the application controls would still be applied even if
the change control process missed setting an ACL on the new interface.
I can understand the argument that applications all listen on ports
on interfaces. So by implementing the controls on a per-interface basis
you can achieve the same affect. A clever engineer can figure out
which packets are passing through an interface, and which packets are
destined for a port on an interface. If we're just trying to specify how
to make new routers behave like the ciscos we're all used to, I can
understand the limitations we're operating under.
In Cisco-speak it could be yet another extension of the extended ACL.
access-list 100 deny ip any any option lsrr
access-list 100 permit ip host 172.16.10.10 any
access-list 100 deny ip any any log
Then you could filter packets with unwanted options (lsrr, rr, etc) where
ever ACLs are used, including per-interface, per-protocol, per-vty, etc.
Otherwise, what I'm afraid will happen is the requirement to do this on
a per-interface basis will be interpreted by router vendors as
interface ethernet 0
no ip source-route