Subject: [I2nsf] WG: Can you comment on the Flow Security Policy objects that can be Exchanged between Overlay network and underlay network?

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 15 Jun 2016 16:07:48 +0000

FYI - Cheers, Walter

Von: Haeffner, Walter, Vodafone DE
Gesendet: Mittwoch, 15. Juni 2016 02:27
An: 'Linda Dunbar'
Cc: [email-masked]'
Betreff: AW: Can you comment on the Flow Security Policy objects that can be Exchanged between Overlay network and underlay network?

Hi Linda, hi LuYuan,

First of all, LuYuan's proposal looks very good. I like it. What we finally have to check is the willingness of network operators to share all the information you mentioned in the draft and in the list below. I will contact our corporate security folks the next days  to ask for their opinion.

When you talk about "Inter-Cloud DDoS Mitigation Abstract Layer"  what do you have in mind? Do you talk about an autonomous network or will the PE routers probably take over/include such functionality?  I think both possibilities are appropriate (if implemented).

Data exchange between operators should be done in a secured network (out-of-band, TLS, IPSec).

One should not only consider high volume (d)DoS attacks but also "blended attacks". These may have a small data volume but inject attacks into higher layers.  As you know these types of attacks may not be detected by the common statistical approaches.  Maybe in a next step you could consider to additionally  include related info in your data exchange model. On the other hand such threats may be beyond the scope of the I2NSF WG. But frankly spoken, I didn't check your charter.

Last not least I know by experience that e.g. wrong eBGP routes injected in a network may cause similar disasters. But this is another story.

W.r.t. the data model below:  Your data model is already very rich and on a first view it seems to be more than sufficient to describe traditional DoS attacks.

For completeness: We have an IDS just behind all Internet gateways. In case of an issue the flows will be redirected to a "washing machine" or dev0.

Best regards,
Walter

Von: Linda Dunbar [mailto:[email-masked]]
Gesendet: Dienstag, 24. Mai 2016 00:20
An: Haeffner, Walter, Vodafone DE
Betreff: Can you comment on the Flow Security Policy objects that can be Exchanged between Overlay network and underlay network?

Walter,

LuYuan's draft  (on behalf of Microsoft https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/) is more on the desired flow security policy between Cloud Network and Underlay network.

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 traffic rules to be enforced, I2NSF can be used by overlay networks to request certain flow based security rules to be enforced by its underlay networks. So that the unwanted attacks traffic, including the DDoS attacks, don't even appear on the physical links and ports to the overlay network nodes, to avoid the overlay nodes' CPU/Storage/Port utilization being weighted down by the various attacks.

I2NSF defines Flow Based Security Rules as: Event - Condition - Action.

It is desirable to specify the common data model for Events, Conditions, and Actions that one operator (e.g. overlay network) can retrieve from underlay network. Overlay network can also use those objects to formulate flow policy rules to be enforced by its underlay network.
The Security capability information exchanged between Overlay or underlay doesn't have to be 100% complete. Even a very high level capability information exchange is better than today's practice, where one domain does not know anything about the security capabilities that other domains can enforce/monitor/report.
Here are the security mitigation objects:

-   Event-Object

-   Based-on-starting-stopping-time

-   Based-ingress-port-threshold

-   None

-   Condition-object

-   Based-on-packet-header-fields

-   Based-on-peering-gateway-status

-   Action-object

-   Rate-limiting-sub-object

-   TCP-flood-rate-limiting

-   Based-on-number-of-concurrent-connections-per-interval

-   Based-on-number-of-new-connections-per-interval

-   Based-on-number-of-concurrent-connections-per-interval

-   Based-on-number-of-fragment-packets-per-interval

-   Based-on-number-of-packets-per-interval

-   TCP-flags-flood-protection

-          Based-on-SYN

-          Based-on-ACK

-          Based-on-RST

-          none

-   UDP-flood-rate-limiting

-   Honey-pot

-   Black-holing

-   BGP-flowspec

-   RFCxxx

-   IDMS

-   Yes

-   No

-   Solution-name /*string */

-   Forensic-object

-   Attack-report

-   Starting-time

-   Volume

-   Impacted-ports

-   Detailed-time-stamp

-   None

-   Black-list

-   White-list

Policy-object /* Domain A can request Domain B for each of the objects specified above and get the information on whether if any of the attributes can be Created/Read/Updated/Deleted (CRUD) that Domain B provides to Domain A */

Want to hear your feedback on this proposal.

Linda

From: Luyuan Fang [mailto:[email-masked]]
Sent: Sunday, May 15, 2016 10:20 PM
To: Linda Dunbar; John Strassner
Cc: Farrel Adrian
Subject: RE: Meeting note on the Information Model of Inter Domain Security Policy Exchange

Hi Linda,

Thank you for capturing our discussion, It is indeed a very productive session, thanks to both you and John.
I'm happy to see that I2NSF WG taking the operational requests seriously and you guys are making great effort to help us moving the info model along. We'd like to see things get to implementable level asap.

Will follow up with my items.

Thanks,
Luyuan

From: Linda Dunbar [mailto:[email-masked]]
Sent: Friday, May 13, 2016 3:59 PM
To: Luyuan Fang <[email-masked]<mailto:[email-masked]>>; John Strassner <[email-masked]<mailto:[email-masked]>>
Cc: Farrel Adrian <[email-masked]<mailto:[email-masked]>>
Subject: Meeting note on the Information Model of Inter Domain Security Policy Exchange

LuYuan and John,

Thank you very much for a very productive discussion yesterday.
Here is the note that I captured. I am very encouraged that those security objects desired by Microsoft are actually very concrete and can be useful for many network providers. The very important next step is

-        to get feedback from more network operators to see if it is feasible for them to provide the information on any of security objects to other operators and

-        to reach out to more vendors to see if it is feasible for them to support those objects.

LuYuan emphasized:
The Security capability information exchanged between carriers or domains doesn't have to be 100% complete. Even a very high level capability information exchange is better than today's practice, where one domain does not know anything about the security capabilities that other domains can enforce/monitor/report.
Many carriers/domains may not have all the capabilities listed here.
For the capability offered, one domain can request the other domain to apply the rules defined.

John suggested that all the capabilities are listed as objects. One domain can query the list of security objects (along with its associated sub-objects) that other domain supports.
Action Items to follow up:

-   Lu Yuan will approach Microsoft Cloud business partner (DT and China Telecom) to get their feedback on those objects defined and how feasible it is for them to respond when requested.

-   John will help to formulate the information model for the proposed security objects.

Here are the security mitigation objects:

-   Event-Object

-   Based-on-starting-stopping-time

-   Based-ingress-port-threshold

-   None

-   Condition-object

-   Based-on-packet-header-fields

-   Based-on-peering-gateway-status

-   Action-object

-   Rate-limiting-sub-object

-   TCP-flood-rate-limiting

-   Based-on-number-of-concurrent-connections-per-interval

-   Based-on-number-of-new-connections-per-interval

-   Based-on-number-of-concurrent-connections-per-interval

-   Based-on-number-of-fragment-packets-per-interval

-   Based-on-number-of-packets-per-interval

-   TCP-flags-flood-protection

1.      Based-on-SYN

2.      Based-on-ACK

3.      Based-on-RST

4.      none

-   UDP-flood-rate-limiting

-   Honey-pot

-   Black-holing

-   BGP-flowspec

-   RFCxxx

-   IDMS

-   Yes

-   No

-   Solution-name /*string */

-   Forensic-object

-   Attack-report

-   Starting-time

-   Volume

-   Impacted-ports

-   Detailed-time-stamp

-   None

-   Black-list

-   White-list

Policy-object /* Domain A can request Domain B for each of the objects specified above and get the information on whether if any of the attributes can be Created/Read/Updated/Deleted (CRUD) that Domain B provides to Domain A */

Thanks, Linda