Subject: [I2nsf] Questions to the draft-zhang-gap-analysis-03 - security

From: Linda Dunbar <[email-masked]>
Date: Wed, 1 Jul 2015 22:58:21 +0000

Sue, Robert, DaCheng and  Hosnieh,

Thank you very much for adding  a lot of good content to the draft-zhang-gap-analysis-03. It is really good that you introduced the concepts of I2NSF Client, I2NSF Agent, etc.

A few questions on the terminologies:
What does I2NSF SPDP represent?

How about I2NSF SEP?

One minor comment:

Since I2NSF latest charter has been reduced to Flow-Based NSF (with definition defined in I2NSF Problem Statement), Introduction Section should remove examples of "Remote Identity Management" and "Secure Key Management".

Thanks,

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, June 10, 2015 1:52 PM
To: [email-masked]
Cc: 'Kathleen Moriarty'
Subject: [I2nsf] draft-zhang-gap-analysis - security

Hi all
The gap  analysis took time to really look at how the security work in the IETF work fits together.   I published this draft, and I've received no input on the security area gap analysis.   I'd really like feedback.

Sue

=========

   On early focus on ACL policy enforcement on traffic entering a

   network is the 1990s COPS design (PEP and PDP) as shown in figure 1.

   The Policy decision point kept network-wide policy (E.g. ACLs) and

   sent it to Policy enforcements who then would control what data flows

   between the two These decision points controlled flow from PEP to

   PEP.

                 PDP

      +-----+    /  \    +-----+

      |PEP1 |--/     \---|PEP2 |

      |     | ACL/policy |     |

      |     |                |     |

    --| ----|------------|-----|-----

      +-----+  data flow +-----+

              Figure 1

   Today's security devices in 2015 replicate the same concept.The I2NSF

   Security provisioning policy/filter decision point (SPDP) and the

   I2NSF Agent Security Enforcement point (SEP) still look to control

   this flow through secure devices (see figure 2.).

                +---------+

                | I2NSF   |

                | SPDP    |

                |         |

                +---------+

      +-----+    /  \    +-----+

      | SEP |--/     \---| SEP |

      |     |            |     |

    --| ----|------------|-----|-----

      +-----+  data flow +-----+

        Figure 2

   The other security protocols work to interact to create the

   additional pieces of security the flows for users as follows (see

   figure 3):

   o SACM - examines if policy and reality match.It asks the questions

   "Have proper policies been pushed to the proper place", and "Has any

   policy been compromised?"

   o MILE - looks at events that go Bump in night in the Security 2015.

   MILE examines when events need to be reported or correlated.A MILE

   configuration is a policy pushed out by the SPDP

   o DOTS - picks up security the flow for when things go really wrong

   during security attacks.In this case, an SEP needs to be able to

   SCREAM for help, to get other SEP to ease its pain.DOTS policy is

   pushed out via SPDP.

   o I2NSF may connect to all of these devices to gather information

   about the security policy that is pushes down to I2NSF agent. I2NSF

   provides a common interface between an I2NSF client as a SPDP and the

   NSF security boxes with SEP agents (which may also DOTS agent or Mile

   agent).

                +---------+     +------+

      +------+  | I2NSF   |=====| DOTS |

      |SCAM  |  | SPDP    |     |client|----

      |client|==|         |     +------+   |

      +------+  |         |     +------+   |

                |         |     |MILES |   |

    +------+    |         |     |client|   |

    |SCAM  |    +---------+     +----:-+   |

    |Agent |       / \               :     |

    +------+      /   \              :     |

      +-----+    /     \    +-----+  :     |

      | SEP |--/        \---| SEP |  :     |

      |     |               |     |  :     |

      |     |               |MILES|..:     |

      |     |               |Agent|        |

      |     |               |DOTS |        |

      |     |               |Agent|---------

    --| ----|---------------|-----|-----

      +-----+  data flow    +-----+

        Figure 3

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 1 Jul 2015 20:39:36 -0400

Linda and all I2NSF folk: 

Could you send me any information you have the following related to I2NSf:

.         ETSI NFV ISG,  OpenStack Firewall / SaaS, CSA SaaS. 

I'm finalizing the revision of the draft. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, July 01, 2015 6:58 PM
To: Susan Hares; [email-masked]
Cc: 'Kathleen Moriarty'
Subject: [I2nsf] Questions to the draft-zhang-gap-analysis-03 - security

Thank you very much for adding  a lot of good content to the
draft-zhang-gap-analysis-03. It is really good that you introduced the
concepts of I2NSF Client, I2NSF Agent, etc. 

How about I2NSF SEP?

One minor comment:

Since I2NSF latest charter has been reduced to Flow-Based NSF (with
definition defined in I2NSF Problem Statement), Introduction Section should
remove examples of "Remote Identity Management" and "Secure Key Management".

Thanks, 

Linda

Hi all

The gap  analysis took time to really look at how the security work in the
IETF work fits together.   I published this draft, and I've received no
input on the security area gap analysis.   I'd really like feedback. 

Sue 

=========

                 PDP
      +-----+    /  \    +-----+
      |PEP1 |--/     \---|PEP2 |
      |     | ACL/policy |     |
      |     |                |     |
 
              Figure 1

                +---------+
                | I2NSF   |
                | SPDP    |
                |         |
                +---------+
      +-----+    /  \    +-----+
      | SEP |--/     \---| SEP |
      |     |            |     |
 
        Figure 2
 
   figure 3):

 

                +---------+     +------+
 
        Figure 3

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 2 Jul 2015 11:06:38 +0000

Hi Sue,

The ETSI NFV ISG has a Security WG that has a few work-items that are connected to the I2NSF goals (as attestation considerations or security monitoring), but none addressing the mechanisms being considered in I2NSF. The ISG is explicitly focused on the aspects related to the virtualization aspects (component orchestration and lifecycle management, infrastructure control...) an considers the semantics and management of the services out of scope.

Be goode,

On 2 Jul 2015, at 02:39 , Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

•         ETSI NFV ISG,  OpenStack Firewall / SaaS, CSA SaaS.

I’m finalizing the revision of the draft.

Sue

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, July 01, 2015 6:58 PM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Cc: 'Kathleen Moriarty'
Subject: [I2nsf] Questions to the draft-zhang-gap-analysis-03 - security

How about I2NSF SEP?

One minor comment:

Since I2NSF latest charter has been reduced to Flow-Based NSF (with definition defined in I2NSF Problem Statement), Introduction Section should remove examples of “Remote Identity Management” and “Secure Key Management”.

Thanks,

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, June 10, 2015 1:52 PM
To: [email-masked]<mailto:[email-masked]>
Cc: 'Kathleen Moriarty'
Subject: [I2nsf] draft-zhang-gap-analysis - security

Hi all
The gap  analysis took time to really look at how the security work in the IETF work fits together.   I published this draft, and I‘ve received no input on the security area gap analysis.   I’d really like feedback.

Sue

=========

   PEP.

                 PDP

      +-----+    /  \    +-----+

      |PEP1 |--/     \---|PEP2 |

      |     | ACL/policy |     |

      |     |                |     |

              Figure 1

                +---------+

                | I2NSF   |

                | SPDP    |

                |         |

                +---------+

      +-----+    /  \    +-----+

      | SEP |--/     \---| SEP |

      |     |            |     |

        Figure 2

   figure 3):

   pushed out via SPDP.

   agent).

                +---------+     +------+

      |client|==|         |     +------+   |

      +------+  |         |     +------+   |

                |         |     |MILES |   |

    +------+    |         |     |client|   |

    |Agent |       / \               :     |

    +------+      /   \              :     |

      +-----+    /     \    +-----+  :     |

      |     |               |     |  :     |

      |     |               |MILES|..:     |

      |     |               |Agent|        |

      |     |               |DOTS |        |

      |     |               |Agent|---------

        Figure 3

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição