Subject: [I2nsf] FW: Any feedback on the Protocol Independent Flow Security Policies exchanged over I2NSF service layer interface?

From: Linda Dunbar <[email-masked]>
Date: Wed, 15 Jun 2016 12:54:43 +0000

Oops, I copied to the wrong WG list.  any comments from I2NSF participants?

Linda

From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 13, 2016 4:25 PM
To: [email-masked]; BOUCADAIR Mohamed IMT/OLN
Cc: [email-masked]
Subject: Re: [i2rs] Any feedback on the Protocol Independent Flow Security Policies exchanged over I2NSF service layer interface?

Christian,

Thank you very much for the feedback.

Agree 100% of what you said:
Using BGP FS to exchange flow-based security policy information between domains is probably one of the most attractive approaches, but I assume this information will have to comply with BGP FS encoding schemes, whether the corresponding policy is described in a NETCONF/YANG data model or not. So, I think it's fair to state that, whatever the semantics of the (flow-based) security policy data model, corresponding information may be exchanged between domains and formatted according to the protocol used to carry such information between domains. It seems to me that both considerations are orthogonal.

The reason that BGP FlowSpec is mentioned here is:

-        To emphasize the different aspects that I2NSF is to tackle:  the comprehensive Flow Security Policies data model (that are not constrained to the BGP encoding scheme). For example, if used between "domains", one domain inquiry of "flow security policies" capability of other domain is a very important part. The actual flow polices from one domain to another is only part of the game.

It is really good that you brought this up: "inter-domain QoS policy enforcement remains very hard to achieve"

The Inter-Domain Flow Security Policy are different in the following aspects:

-         the I2NSF Flow Security Policy, (i.e. over the I2NSF Service Layer Interface), are inquired and set by each domain's management system (or domain's controllers). There have be authentication, authorization and billing process involved for one domain management system to grant the requests from other domain's management systems.

-        Whereas the QoS mechanism (as being carried by encoding in data packets), It is difficult for forwarding devices from one domain to take actions (that requires its own $$$ resources) based on bits set by other domains.

Thanks,

Linda
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, June 13, 2016 11:23 AM
To: Linda Dunbar; BOUCADAIR Mohamed IMT/OLN
Subject: RE: Any feedback on the Protocol Independent Flow Security Policies exchanged over I2NSF service layer interface?

Hello Linda,

A few preliminary comments from my side, based upon the enclosed text below (I didn't read the draft yet).

[snip]

As BGP Flow Specification [exchanged among BGP peers] can been deployed to achieve DDoS mitigation, the Flow Security Policy setting from one domain to another domain is protocol independent.
[CJ] I don't understand the above causality effect, since BGP FS is explicitly mentioned. As a matter of fact, I think policies (whatever their nature) are protocol-independent by nature, as implicitly indicated in the definition reminded in the supa WG charter<https://datatracker.ietf.org/wg/supa/charter/>, for example.
 I2NSF focuses on the information/data models, allowing domains using NETCONF or RESTCONF to exchange capability and set up the flow security policies.
[CJ] Right, but again, information and data models can rely upon various semantics - YANG, but also SMI, SPPI, etc. Using BGP FS to exchange flow-based security policy information between domains is probably one of the most attractive approaches, but I assume this information will have to comply with BGP FS encoding schemes, whether the corresponding policy is described in a NETCONF/YANG data model or not. So, I think it's fair to state that, whatever the semantics of the (flow-based) security policy data model, corresponding information may be exchanged between domains and formatted according to the protocol used to carry such information between domains. It seems to me that both considerations are orthogonal.

"Protocol Independent Flow Security Policies" is for one domain (A) to request another domain (B) to enforce the desired policies for flows destined towards the Domain A. This can be an effective way for Domain A to prevent the unwanted attacks (e.g. DDoS)  from even occupying its links/ports connected to the Domain B.

BGP flow specification is configured in the BGP peers, whereas the I2NSF Protocol Independent Flow Security Policies"  are exchanged between domains,
[CJ] Why not simply state "flow-based security policy information"? Besides, the above wording suggests the whole security policy information is supposed to be exchanged between domains, which I think is debatable. Also, exchanging policy information between domains raises consistency and security issues: this is why inter-domain QoS policy enforcement remains very hard to achieve for example.
which can be
Enterprise domain <-> Provider domain, Overlay <-> Underlay, Cloud provider <-> Underlay.

Enterprise can have its own DDoS mitigation tools, but those internal DDoS mitigation tools can't effectively prevent the DoS attacks that saturate the access ports and links between Enterprise and the providers.
[CJ] Right, but one would argue this is the responsibility of the service provider to prevent any attack that may saturate access resources that connect the enterprise customer to the network operated by the service provider. That is, why would internal mitigation tools be considered anyway?

Same goes for Overlay networks.

Very often, the paths (or links) among nodes of a overlay network are provided by other network operators (a.k.a. "underlay network").  Very much like traditional networks placing FW (Firewall) or IPS (Intrusion Prevention System) on the wire to enforce the flow security rules, I2NSF Protocol Independent Flow Security Policies can be used by overlay networks to request certain flow based security rules to be enforced by its underlay networks, to prevent the unwanted attacks traffic from occupying the physical links and ports to the overlay network nodes, and to avoid the overlay nodes' CPU/Storage/Port utilization being consumed down by the various attacks.  Here is one example of "Overlay Video Communication network" exchange Flow Policies to the Underlay network.

[CJ] The above example clearly shows the necessary interaction between the two PDPs/controllers, to make sure that decisions made by the network controller accommodate the needs of the video customer as possibly expressed towards the video controller: for example, customer demands that the confidentiality of the videoconference needs to be preserved, thereby suggesting the use of the IPsec protocol suite. The video controller may enforce an IPsec design based upon the transport mode, whereas the network controller is solicited to allocate IPsec resources (read for example no AH, ESP in NULL mode) accordingly. This may possibly raise conflicting configuration tasks (the video controller uses AH, the network controller doesn't), thereby leading to inconsistency that may jeopardize the service. Whether BGP FS is used to carry security policy information between the two controllers is hardly the point, imho: what matters is the consistency of the (flow-based security policies enforced by both parties, and which should be derived from the customer's requirements (if any).
The goal of I2NSF is to specify the common information model and data model for the  Protocol Independent Flow Security Policies which can be queried and set between domains.
[CJ] OK.

https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ is just the starting point. (needs more work to improve the clarity). We are asking if people to express their opinion on this work to the [email-masked]<mailto:[email-masked]> list.
[CJ] I need to read this draft and will get back to you accordingly, but this may take a couple of weeks as I'm pretty busy for the time being.

I'll let Med further comment as appropriate.

Cheers,

Christian.

Thanks, Linda

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 25 Jun 2016 13:19:15 -0400

Linda and Christian: 

On Filters + BGP: 

In the draft-ietf-i2rs-fb-data-model, I and the other co-authors propose
common yang encoding for storing flow filters in Filter-based RIBS which
are:

a)      configured as static filters, 

b)      configured I2RS ephemeral filters, and

c)      received filters stored in kernel after being received by a BGP.   

These filters are stored in a common format, but format is only indirectly
related to the BGP update encoding.   The format for these filters is
provided in this yang draft and the draft-ietf-i2rs-pkt-eca-data-model that
this draft refers to.  As you have mentioned, the BGP encoding on the wire
is an orthogonal format.  Prior to originating the BGP-FS filter rules, the
BGP peers store the originated BGP filters rules.  These originated filters
may also benefit by having the same format as the Filter-Based RIBs.  There
is a proposal for the yang extension to the BGP model to configure BGP Flow
Specification policy in the BGP.   I have suggested harmonization to these
authors. 

What I2NSF can do: 

I 100% it is very important that I2NSF tackle the comprehensive Flow
Security Policies data.  BGP-FlowSpec only focuses on the following 3
applications that need inter-AS work: (1) prevention of DoS, 2) BGP/MPLS VPN
traffic filtering, and 3) SDN/NFV centralized control that operates within
an AS or an AS confederation.   There a great deal of work beyond these Flow
Specifications need for security inter-domain and within a single domain.
100% agree it is difficult to do inter-domain flow-based security. 

I2NSF must look at the AAA, active prevention of DoS via filters + other
means, enabling white-list or black-list filtering of URLs/mail, and more.
In short, the capabilities for DoS prevention need to be consider.   And, I
am sure there is much more.  I hope those with strong security background
will consider both the I2NSF controller/manager to device, and the
application to I2NSF controller/manager in working on this work. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, June 15, 2016 8:55 AM
To: [email-masked]
Subject: [I2nsf] FW: Any feedback on the Protocol Independent Flow Security
Policies exchanged over I2NSF service layer interface?

Linda

From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 13, 2016 4:25 PM
To: [email-masked]; BOUCADAIR Mohamed IMT/OLN
Cc: [email-masked]
Subject: Re: [i2rs] Any feedback on the Protocol Independent Flow Security
Policies exchanged over I2NSF service layer interface?

Christian, 

Using BGP FS to exchange flow-based security policy information between
domains is probably one of the most attractive approaches, but I assume this
information will have to comply with BGP FS encoding schemes, whether the
corresponding policy is described in a NETCONF/YANG data model or not. So, I
think it's fair to state that, whatever the semantics of the (flow-based)
security policy data model, corresponding information may be exchanged
between domains and formatted according to the protocol used to carry such
information between domains. It seems to me that both considerations are
orthogonal.

-        To emphasize the different aspects that I2NSF is to tackle:  the
comprehensive Flow Security Policies data model (that are not constrained to
the BGP encoding scheme). For example, if used between "domains", one domain
inquiry of "flow security policies" capability of other domain is a very
important part. The actual flow polices from one domain to another is only
part of the game. 

It is really good that you brought this up: "inter-domain QoS policy
enforcement remains very hard to achieve"

The Inter-Domain Flow Security Policy are different in the following
aspects:

-         the I2NSF Flow Security Policy, (i.e. over the I2NSF Service Layer
Interface), are inquired and set by each domain's management system (or
domain's controllers). There have be authentication, authorization and
billing process involved for one domain management system to grant the
requests from other domain's management systems. 

-        Whereas the QoS mechanism (as being carried by encoding in data
packets), It is difficult for forwarding devices from one domain to take
actions (that requires its own $$$ resources) based on bits set by other
domains.  

Thanks, 

Linda  

From: [email-masked] [mailto:[email-masked]]

Sent: Monday, June 13, 2016 11:23 AM
To: Linda Dunbar; BOUCADAIR Mohamed IMT/OLN
Subject: RE: Any feedback on the Protocol Independent Flow Security Policies
exchanged over I2NSF service layer interface?

Hello Linda,

A few preliminary comments from my side, based upon the enclosed text below
(I didn't read the draft yet).

[snip]

As BGP Flow Specification [exchanged among BGP peers] can been deployed to
achieve DDoS mitigation, the Flow Security Policy setting from one domain to
another domain is protocol independent.

[CJ] I don't understand the above causality effect, since BGP FS is
explicitly mentioned. As a matter of fact, I think policies (whatever their
nature) are protocol-independent by nature, as implicitly indicated in the
definition reminded in the supa WG charter
<https://datatracker.ietf.org/wg/supa/charter/> , for example. 

 I2NSF focuses on the information/data models, allowing domains using
NETCONF or RESTCONF to exchange capability and set up the flow security
policies. 

[CJ] Right, but again, information and data models can rely upon various
semantics - YANG, but also SMI, SPPI, etc. Using BGP FS to exchange
flow-based security policy information between domains is probably one of
the most attractive approaches, but I assume this information will have to
comply with BGP FS encoding schemes, whether the corresponding policy is
described in a NETCONF/YANG data model or not. So, I think it's fair to
state that, whatever the semantics of the (flow-based) security policy data
model, corresponding information may be exchanged between domains and
formatted according to the protocol used to carry such information between
domains. It seems to me that both considerations are orthogonal.

"Protocol Independent Flow Security Policies" is for one domain (A) to
request another domain (B) to enforce the desired policies for flows
destined towards the Domain A. This can be an effective way for Domain A to
prevent the unwanted attacks (e.g. DDoS)  from even occupying its
links/ports connected to the Domain B. 

BGP flow specification is configured in the BGP peers, whereas the I2NSF
Protocol Independent Flow Security Policies"  are exchanged between domains,

[CJ] Why not simply state "flow-based security policy information"? Besides,
the above wording suggests the whole security policy information is supposed
to be exchanged between domains, which I think is debatable. Also,
exchanging policy information between domains raises consistency and
security issues: this is why inter-domain QoS policy enforcement remains
very hard to achieve for example.

which can be

Enterprise domain <-> Provider domain, Overlay <-> Underlay, Cloud provider
<-> Underlay. 

Enterprise can have its own DDoS mitigation tools, but those internal DDoS
mitigation tools can't effectively prevent the DoS attacks that saturate the
access ports and links between Enterprise and the providers. 

[CJ] Right, but one would argue this is the responsibility of the service
provider to prevent any attack that may saturate access resources that
connect the enterprise customer to the network operated by the service
provider. That is, why would internal mitigation tools be considered anyway?

Very often, the paths (or links) among nodes of a overlay network are
provided by other network operators (a.k.a. "underlay network").  Very much
like traditional networks placing FW (Firewall) or IPS (Intrusion Prevention
System) on the wire to enforce the flow security rules, I2NSF Protocol
Independent Flow Security Policies can be used by overlay networks to
request certain flow based security rules to be enforced by its underlay
networks, to prevent the unwanted attacks traffic from occupying the
physical links and ports to the overlay network nodes, and to avoid the
overlay nodes' CPU/Storage/Port utilization being consumed down by the
various attacks.  Here is one example of "Overlay Video Communication
network" exchange Flow Policies to the Underlay network. 

 

[CJ] The above example clearly shows the necessary interaction between the
two PDPs/controllers, to make sure that decisions made by the network
controller accommodate the needs of the video customer as possibly expressed
towards the video controller: for example, customer demands that the
confidentiality of the videoconference needs to be preserved, thereby
suggesting the use of the IPsec protocol suite. The video controller may
enforce an IPsec design based upon the transport mode, whereas the network
controller is solicited to allocate IPsec resources (read for example no AH,
ESP in NULL mode) accordingly. This may possibly raise conflicting
configuration tasks (the video controller uses AH, the network controller
doesn't), thereby leading to inconsistency that may jeopardize the service.
Whether BGP FS is used to carry security policy information between the two
controllers is hardly the point, imho: what matters is the consistency of
the (flow-based security policies enforced by both parties, and which should
be derived from the customer's requirements (if any).

The goal of I2NSF is to specify the common information model and data model
for the  Protocol Independent Flow Security Policies which can be queried
and set between domains. 

[CJ] OK.

<https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigati
on-api/>
https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigatio
n-api/ is just the starting point. (needs more work to improve the clarity).
We are asking if people to express their opinion on this work to the
<mailto:[email-masked]> [email-masked] list. 

[CJ] I need to read this draft and will get back to you accordingly, but
this may take a couple of weeks as I'm pretty busy for the time being.

Cheers,

Christian.

Thanks, Linda 

____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.