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