Subject: [I2nsf] "draft-dunbar-i2nsf-problem-statement-02.txt" - few comments.

From: Alexey Gorbunov <[email-masked]>
Date: Tue, 17 Mar 2015 20:20:26 -0500

Hi Folks

Just read "draft-dunbar-i2nsf-problem-statement-02.txt" and would like to
share my thoughts and concerns. From my point of view it’s better to not
focus on the specific names but on the functionality of network security
function itself.  Most probably the main use case for NSF is virtual
firewall with IPS/IDS and VPN capabilities. Openstack is the ideal
candidate for NSF.

We have already virtual firewall and it's good to look at it's features and
functionality. I summarized most of the firewall features below:

*-Access-list*.  Defines which traffic are allowed to enter and pass
firewall.

It's covered in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-02

*- Policy.*  Defines which traffic are allowed to pass firewall and in
which direction.

*- Dos protection:*  multicast, broadcast rate limiting. DHCP, ARP
protection and rate-limiting. Limitation of mac-address numbers.

*-“Screens”*  – Juniper calls it screens, cisco doesn’t have name for it.
Basically it’s protection against well-know network attacks.

*- “Intrusion prevention” *– Signatures of any malicious activity.

*- VPN PKI*- configuration of IPSEC with PKI.

*- Control-plane protection of firewall itself.*

*- L7 filtering and proxy.*

- *Application detection.*  Some applications uses tcp port 80 and most of
the firewall can detect it.

 - *Monitoring and reporting traffic.* Something similar to Openflow, Jflow
and etc.

What exactly is going to be covered by i2nsf? Is i2nsf going to meet in the
Dallas at IETF 92?

Thanks everybody for attention to this email.

Alexey Gorbunov

Telco Cloud and Security Architect at Nokia

CCIE R&S 41088

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 18 Mar 2015 11:13:56 +0000

Alexey,

Thank you very much for the comments and suggestions. Yes, we have agreed to focus on functionality instead of device name. I2NSF will start with Flow Based Security Functions.

https://tools.ietf.org/html/draft-ietf-netmod-acl-model-02  is a good start, but not comprehensive enough.
For example, for the Policy (that defines which traffic are allowed to pass firewall and in which direction), it is necessary for NSF to register which field the NSF can enforce the traffic (SA? DA? VLAN? TCP/UDP ports? TCP flag? Direction? HTTP header? Size? Etc).  such as:
           Ingress Port & match
                            |
                            |
       +-------+---------+--+----+--------+-------+---------+-------+
       |       |         |       |        |       |         |       |
       |       |         |       |        |       |         |       |
      L3Header L2header  L4    VLAN      VN ID    size    event .. HTTP

The actions can be more, some NSF only allows “Pass/Drop”, other NSFs can support more sophisticated actions (e.g. steering to different functions, ..
Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Alexey Gorbunov
Sent: Tuesday, March 17, 2015 8:20 PM
To: [email-masked]
Subject: [I2nsf] "draft-dunbar-i2nsf-problem-statement-02.txt" - few comments.

Hi Folks

Just read "draft-dunbar-i2nsf-problem-statement-02.txt" and would like to share my thoughts and concerns. From my point of view it’s better to not focus on the specific names but on the functionality of network security function itself.  Most probably the main use case for NSF is virtual firewall with IPS/IDS and VPN capabilities. Openstack is the ideal candidate for NSF.

We have already virtual firewall and it's good to look at it's features and functionality. I summarized most of the firewall features below:

-Access-list.  Defines which traffic are allowed to enter and pass firewall.
It's covered in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-02
- Policy.  Defines which traffic are allowed to pass firewall and in which direction.
- Dos protection:  multicast, broadcast rate limiting. DHCP, ARP protection and rate-limiting. Limitation of mac-address numbers.
-“Screens”  – Juniper calls it screens, cisco doesn’t have name for it. Basically it’s protection against well-know network attacks.
- “Intrusion prevention” – Signatures of any malicious activity.
- VPN PKI- configuration of IPSEC with PKI.
- Control-plane protection of firewall itself.
- L7 filtering and proxy.
- Application detection.  Some applications uses tcp port 80 and most of the firewall can detect it.
 - Monitoring and reporting traffic. Something similar to Openflow, Jflow and etc.

What exactly is going to be covered by i2nsf? Is i2nsf going to meet in the Dallas at IETF 92?

Alexey Gorbunov

---

From: Alexey Gorbunov <[email-masked]>
Date: Wed, 18 Mar 2015 19:24:27 -0500

Hi Linda

Thanks for your reply and clarification of my questions. I agree that
mentioned rfc draft isn't comprehensive enough. Have you already started "Flow
Based Security Functions"? Do you have link to this draft?

Linda, is I2NSF participants are going to meet in Dallas at IETF 92? I
think it would be quite efficient to discuss ideas during IETF.

“Screens” - are basic attack and settings. Like allowing or denying ip
fragments. Regarding your question "Is there any run time policy (based on
some events) that can be sent to the “Screen” feature?". These settings
aren't changed frequently based on some events. They are discussed,
defined, configured and just stay in the running configuration. I just
mention that it should be possible somehow to specify these settings.
Probably with the same approach like ALC with Netconf. Anyway, that should
be different topic.

Br, Alexey Gorbunov

Br, Alexey Gorbunov

2015-03-18 6:13 GMT-05:00 Linda Dunbar <[email-masked]>:

>  Alexey,
>
>
>
> Thank you very much for the comments and suggestions. Yes, we have agreed
> to focus on functionality instead of device name. I2NSF will start with
> Flow Based Security Functions.
>
>
>
> For example, for the Policy (that defines which traffic are allowed to
> pass firewall and in which direction), it is necessary for NSF to register
> which field the NSF can enforce the traffic (SA? DA? VLAN? TCP/UDP ports?
> TCP flag? Direction? HTTP header? Size? Etc).  such as:
>
>            Ingress Port & match
>
>                             |
>
>                             |
>
> The actions can be more, some NSF only allows “Pass/Drop”, other NSFs can
> support more sophisticated actions (e.g. steering to different functions, ..
>
> Linda
>
>
>
>
>
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *Alexey
> Gorbunov
> *Sent:* Tuesday, March 17, 2015 8:20 PM
> *To:* [email-masked]
> *Subject:* [I2nsf] "draft-dunbar-i2nsf-problem-statement-02.txt" - few
> comments.
>
>
>
> Hi Folks
>
>
>
> We have already virtual firewall and it's good to look at it's features
> and functionality. I summarized most of the firewall features below:
>
>
>
> - *Application detection.*  Some applications uses tcp port 80 and most
> of the firewall can detect it.
>
>  -* Monitoring and reporting traffic.* Something similar to Openflow,
> Jflow and etc.
>