Flooding an edge router with purposefully crafted packets it can be possible to DoS the control plane.
Possible solution:
- controller replication
- proactive rules
A fault in the implementation of the network forwarding element software can lead to losing control of it to the attacker
Possible solution:
- software updates
- self-healing mechanisms
- diversity
Insecure communication can lead to evesdropping control layer messages, or worst their modification and subsequent loss of control over the network
Possible solution:
- encrypted comms
- mutual authentication
The headers of a packet can be specially crafted to attack the control layer that receives the headers from a network FE that does not know what to do with the packet. Loss of controller means loss of network.
Possible solution:
- software updates
- strict header formats
An implementation fault in one of the applications that create the rules can result in loss of control over that application, worst it can be used to generate rules in favor of the attacker.
Possible solution:
- rule conflict analysis
- network policies
If the applications are not certified and authenticated, it could be possible to inject a malicious application that should not be there.
Possible solution:
- app-controller mutual authentication
- encrypted comms
- authorisation roles
All routers and switches contain some kind of match-action based logic for packet forwarding. OpenFlow generalises the table and rules into the 'flow table'.
- Security enforcement kernel (SEK)
- Authorisation roles
- Security policies
- Application authentication
- Rule Conflict Analysis
Problems:
- Single point of failure (DoS)
- Delays (Information disclosure)
- Security application development framework
- SEK (FortNOX)
- Modular applications
- Application authentication
- Authorisation roles
- Security policies
- RCA
Comprehensive set of tools
Problems:
- Single point of failure (DoS)