In today’s world, where everything is connected, preventing unwanted traffic has become a key challenge. More and more networks, including various types of Internet of Things (IoT) networks, information-centric networks (ICN), content delivery networks (CDN), and cloud networks, are in some form of overlay network with their paths (or links) among nodes that are provided by other networks (aka, underlay networks). These paths are considered a single hop by the virtual networks. The approach of overlay networks having their own security solutions cannot prevent various attacks from saturating the access links to the overlay network nodes, which may cause overlay nodes’ CPU/links to become too over utilized to handle their own legitimate traffic.
Very much like traditional networks placing a firewall or an intrusion prevention system (IPS) on the wire to enforce traffic rules, Interface to Network Security Functions (I2NSF) can be used by overlay networks to request that certain flow-based security rules are enforced by underlay networks. By this mechanism, unwanted traffic, including DDoS attacks, doesn’t appear on the physical links and ports to the overlay network nodes, thereby avoiding excessive or problematic overlay node CPU/storage/port utilization.
I2NSF has two types of interfaces: a service layer and a capability layer. The service layer specifies how a client’s security policies may be expressed to a security controller. The capability layer specifies how to control and monitor flow-based security functions (NSFs) at a functional implementation level.
The policies over the Service Layer Interface don’t care which NSFs are used to enforce the policies. There could be multiple NSFs to enforce one Service Layer policy. The policies over the Capability Layer Interface are to specific NSFs.
The I2NSF Working Group (WG) was charted in October 2015. From IETF 94 to IETF 95, I2NSF WG has adopted four Internet-Drafts: draft-ietf-i2nsf-problem-and-use-cases-00, draft-ietf-i2nsf-framework-00, draft-ietf-i2nsf-gap-analysis-01, and draft-ietf-i2nsf-terminology-00. The WG has agreed to use the Event-Condition-Action paradigm for the Flow Based Security Rules polices over both the Service Layer Interface and the Capability Layer Interface.
