OSPF bypasses Control Plane Host Subinterface

I wanted to implement a mechanism that would automatically (using EEM) block unstable OSPF neighbors. Once you identify the neighbors to block (this should be the hard part), blocking them is easy if you're running point-to-point interfaces (you just make the interface passive), but blocking a single neighbor on a multi-access interface is a royal pain. I didn't want to use the access lists, as it would be very hard to integrate OSPF-specific filters with existing incoming access-lists configured on the interfaces. Control Plane Protection looked like the ideal tool to use; if I could drop certain inbound IP packets (OSPF hello packets) based on their source IP address (= unstable neighbor) and IP protocol (= OSPF), they would never get to the OSPF process and the adjacency would not form, resulting in a more stable network.

Update: After the comment from William Chu, I've tested 12.4 mainstream release. OSPF is blocked as configured. Next I've re-read the documentation … and found that one of the documented restrictions is that the host subinterface only filters UDP and TCP traffic. Configuring the service policy on the aggregate path (the control-plane keyword with no options) worked.

Before trying to figure out the integration between the SYSLOG messages and router configuration changes, I performed an easy test: I tried blocking all OSPF traffic in the host control-plane (the one controlling packets received by the IOS processes) with the following configuration:

class-map match-all BlockOSPF
 match access-group name BlockOSPF
!
!
policy-map ControlPlane
 class BlockOSPF
   drop
!
ip access-list extended BlockOSPF
 permit ospf any any
!
control-plane host
 service-policy input ControlPlane
However, according to the show commands, the service policy did not identify any packets as belonging to the BlockOSPF class and the OSPF adjacencies were not affected:
C1#show policy-map control-plane host
 Control Plane Host

  Service-policy input: ControlPlane

    Class-map: BlockOSPF (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name BlockOSPF
      drop

    Class-map: class-default (match-any)
      5 packets, 400 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
C1#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
10.0.0.12 1 FULL/DR 00:00:30 10.0.1.2 FastEthernet0/0
10.0.0.2 0 FULL/ - 00:00:33 10.0.0.2 Serial1/0.101
10.0.2.2 0 FULL/ - 00:00:33 10.0.0.1 Serial1/0.100
After a few more tests, I had to conclude that the Control Plane Protection using host subinterface does not work on OSPF packets (and it might does not work on other non-TCP/UDP traffic either). Consequently you cannot protect your router from a DoS attack coming through an interface on which you have to run OSPFTo filter non-TCP/UDP traffic, use the aggregate path control plane protection.

16 comments:

  1. Can you check the same thing with EIGRP?
    Maybe some other protocols (not necessary routing) are also exempted? I bet on IPSsec, GRE and IPinIP.
    May you test this issue with SCTP(IP/132, RFC4960) ?

    ReplyDelete
  2. May be control plane protection work only with unicast traffic, not with multicast ?

    ReplyDelete
  3. I would need to check when I am in work but I think on many cisco platforms match-all is not supported in COPP.

    Colin

    ReplyDelete
  4. @Colin: the 'match-all' is the default produced by the router. I did not enter it manually (you have to enter 'match-any' manually, if I remember correctly).

    @Visir: I thought about that as well, but then the DBD packets are not sent as multicast on multi-access networks (or at least that was my understanding, but I might be wrong) and without the DBD packets the OSPF adjacency would not be established.

    @Anonymous: it looks like CoPP works only for TCP and UDP, but I would have to do more tests.

    ReplyDelete
  5. looks like CSCso12838 but you forgot to specify the IOS you're using. try using the "police" keyword with the "drop" option for both "conform"-ing and "exceed"-ing traffic instead of the "drop" action.

    ReplyDelete
  6. @ivan: are you sure you can't protect router from icmp flooding with CoPP ?

    ReplyDelete
  7. Ivan:

    What IOS were you using?

    I tested on my router using IOS 12.4(18) mainline and it worked.

    C3640#sh ip ospf n

    C3640#sh policy-map control-plane
    Control Plane

    Service-policy input: OSPF

    Class-map: BlockOSPF (match-all)
    4 packets, 376 bytes
    5 minute offered rate 0 bps, drop rate 0 bps
    Match: access-group name B-OSPF
    drop

    Class-map: class-default (match-any)
    138 packets, 9042 bytes
    5 minute offered rate 1000 bps, drop rate 0 bps
    Match: any
    C3640#

    My config is below:

    class-map match-all BlockOSPF
    match access-group name B-OSPF
    !
    policy-map OSPF
    class BlockOSPF
    drop
    !
    ip access-list extended B-OSPF
    permit ospf host 199.11.18.171 any
    !
    control-plane
    service-policy input OSPF
    !

    ReplyDelete
  8. @William: You're right, it works in 12.4, but there you don't have the three different control policies. Looks like 12.4T-specific bug.

    @Xavier: thanks for the hint, will test.

    ReplyDelete
  9. Ivan:

    I just tested again on a router that was running IOS 12.4(15)T5 and here are my results:

    1. Drop didn't work if I attached the service policy under the control-plane host sub-interface (like what you did)

    2. Drop worked if I attached the service policy under the control-plane main interface (without the host keyword), which was similar to what I did in IOS 12.4 mainline.

    So in other words, below works in IOS 12.4(15)T5 if I don't put the policy under control-plane host.

    class-map match-all BlockOSPF
    match access-group name B-OSPF
    !
    policy-map OSPF
    class BlockOSPF
    drop
    !
    ip access-list extended B-OSPF
    permit ospf host 199.11.18.171 any
    !
    control-plane
    service-policy input OSPF
    !

    From the Cisco doc it said that the use of the host subinterface for control-plane is optional, so I guess we can use it as a workaround for now and open a case with Cisco for the host subinterface issue.

    Thoughts?

    William Chu

    ReplyDelete
  10. @William: We obviously work in parallel :) I did the same tests, came to the same conclusions and fixed the post :))

    ReplyDelete
  11. Yeah, the Cisco doc was confusing because in one area it said the host subinterface would be used to handle traffic destined to the router itself (including OSPF, EIGRP, etc). So now the aggregate conrol plane interface is like a "catch-all" interface for anything else :-)

    ReplyDelete
  12. Guys, my understanding of this issue is that multicast traffic is handled by 'control-plane transit' policy. It works well for OSPF and LDP, where only the unicast packets for both protocols are being taken care of by 'control-plane host'.

    ReplyDelete
  13. Correction/update to the previous statement...

    OSPF unicast - TRANSIT (!!!)
    OSPF multicast - TRANSIT
    LDP unicast - HOST
    LDP multicast - TRANSIT
    iBGP - HOST
    eBGP - TRANSIT (???)
    ARP - CEF-EXCEPTION

    ReplyDelete
    Replies
    1. U can check in http://www.cisco.com/web/about/security/intelligence/understanding-cppr.html

      Delete
  14. Can't PBR (driving incoming ospf to null0) under the interface do the job?

    ReplyDelete
  15. @Tassos: That's an interesting thought ... but then PBR would have to be deployed on every (affected) interface (similar to inbound access-lists). I was looking for a more centralized solution.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.