Configuration of
Advanced Security Functions with I2NSF Security ControllerHuaweiwilliam.panwei@huawei.comHuaweifrank.xialiang@huawei.comThis draft defines a network security function (NSF-) facing
interface of the security controller for the purpose of configuring some
advanced security functions. These advanced security functions include
antivirus, anti-ddos, and intrusion prevention system (IPS). The
interface is presented in a YANG data model fashion and can be used to
deploy a large amount of NSF blocks that all support above mentioned
functions in the software defined network (SDN) based paradigm.I2NSF provides a technology and vendor independent way for a
centralized security controller in a SDN environment to manage and
configure the distributed NSFs [RFC8329]. The NSFs are automatically
customized in a programmable manner via a standard interface. In the
draft [I-D.ietf-i2nsf-nsf-facing-interface-dm], it proposed a generic
NSF-facing interface to manage which action should be applied on which
traffic. In addition, there is another draft that defined the NSF-facing
interface for management, including configuration and monitoring, of
IPsec SAs [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. In this document,
we defined another NSF-facing interface for security controller to
configure some advanced security functions including the antivirus,
anti-ddos, and IPS profiles. With the variety and complexity of the
advanced security functions, it is hardly to define all the interfaces
to configure each advanced security function. The antivirus, anti-ddos
and IPS profiles, these three functions are the most common and
well-developed advanced security functions and have been widely used.
Standardizing the interface of these three functions can minimize the
cost of management and configuration of the security controller with a
vendor independent way.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].This document uses the terms defined in
[I-D.ietf-i2nsf-terminology].A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:Brackets "[" and "]" enclose list keys.Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only).Symbols after data node names: "?" means an optional node and "*"
denotes a "list" and "leaf-list".Parentheses enclose choice and case nodes, and case nodes are
also marked with a colon (":").Ellipsis ("...") stands for contents of subtrees that are not
shown.The following tree diagram shows the interface for configuring
antivirus detections on incoming and outgoing files. The file transfer
protocol type, direction of file transfer, and the action applied on
the detected virus are able to be configured. In addition, this
interface also supports to configure the application and signature
exception features to apply specific actions on certain applications
and detected virus respectively. The anti-virus also supports to
configure a whitelist for trusted files.The following tree diagram shows the configuration parameters of
DDoS detection and prevention functions of different types of DDoS
attacks.* SYN flood: The total number of packets that have the same
destination address are counted in a period of time. If the counted
packets number exceeds a pre-defined threshold, the prevention
function is triggered. The anti-ddos system will alert the
user/administrator, and start up source address inspection or TCP
proxy function as configured.* UPD flood: The UDP flood packets normally have the same payload
or the payload changes regularly. The anti-ddos system is able to
automatically learn this payload characteristics, which is so called
fingerprint of the UDP flood attack packets. And then if a packet
matches the learned fingerprint, it will be discarded. For some UDP
flood attack that does not has a fingerprint, a threshold bandwidth
will be configured to limit the UDP traffic. If the UDP packet is
associated with some TCP packets, the anti-ddos system can trigger the
TCP protection measures and use the generated white list to determine
whether to discard the UDP packets.* HTTP and HTTPS flood: The detection mechanisms for these two
attacks are similar to SYN flood detection. The total number of
packets that have the same destination address are counted in a period
of time. A threshold is set for the purpose of alerting.* DNS request flood: The anti-ddos system counts the number of DNS
request packets that have the same destination address in a period of
time. Once this number exceeds a configured threshold, the prevention
function is triggered. The anti-ddos system sends a response to the
client to ask for another request with a TCP connection, and then
verify the source address.* DNS reply flood: The anti-ddos system counts the number of DNS
reply packets that have the same destination address in a period of
time. Once this number exceeds a configured threshold, the source
address inspection is triggered. The anti-ddos ask the sender to send
the reply message again with a new query ID and port number. If the
second reply message is received and the query ID and port number
match with the asked one. This source address will be added into the
white list.* ICMP flood: A threshold is configured to limit the rate of ICMP
traffic.* SIP flood: The anti-ddos system counts the number of SIP request
packets that have the same destination address in a period of time. If
the counted packets number exceeds a pre-defined threshold, the source
authentication is triggered. The anti-ddos system sends an OPTIONS
request packet with a specific branch value to verify whether the
source address exists. If the reply message is in response to the
OPTIONS packet, this source address will be added into the white
list.The following tree diagram shows the interface for configuring the
IPS. This interface supports to configure a set of IPS signature-based
filters to detect known type of attacks and to respond with user
defined actions such as sending an alert or block the matched
packets.This document makes no request of IANA.Note to RFC Editor: this section may be removed on publication as an
RFC.TBD.TBD