[Nsaas] Comparing NSIS and the work to be done by NSaaS

[Linda Dunbar <[e-mail]>]

Melinda,

Thank you for listing those related exiting work by IETF for NSaaS. I did some study on NSIS. Here is my finding, please let me know if my findings miss anything:

- Differences between NSIS and NSaaS:

      NSIS is for standardizing an IP signaling protocol (RSVP) along data path for end points to request its unique QoS characteristics, unique FW policies or NAT needs (RFC5973) that are different from the FW/NAT original setting. The requests are communicated directly to the FW/NAT devices. NSIS is like east-west protocols that requires all involved devices to fully comply to make it work.

      NSaaS has three potential aspects:
      - Define the standard mechanisms for clients (applications) to request/negotiate/validate security functions that are not physically located on the local premises. It is more than SFC that treats all “Functions” as black box. NSaaS is targeted to define the semantics (the actual rules & policies) of the security functions needed and the negotiation scheme.  The requests don’t usually goes to FW devices, but instead to controller that can disseminate to the involved devices in the interface that they support.


      - Define the mechanism for formulating virtual security functions on physical appliances ( in a similar way to how VPN virtualizes the carrier network)

      - Specify concrete rules (policies or attributes) for instantiating VMs for virtual security functions (NFV initiative).   This is on the service fulfillment side.



- Why we believe NSaaS has higher chance to be deployed than NSIS:

1.      OpenStack already has preliminary implementation, but the specification is not complete. IETF can play an active role to make the specification complete. Extend what OpenStack has to a more comprehensive specifications that can meet operators requirement, and then have operators encourage their suppliers to contribute open source per IETF specifications to the OpenStack community. As the software development cycle: Architecture, Design specification, and coding: IETF can take the ownership of the first two steps.

2.      The requests are to controllers, instead of to devices. It doesn’t require all middle boxes to be changed to make it work. The security can be better controlled by the controllers.

3.      There is very strong momentum to make virtualized network functions to be deployed by operators (NFV initiative).


Linda


-----Original Message-----
From: Melinda Shore [mailto:[e-mail]]
Sent: Tuesday, August 12, 2014 11:56 AM
To: Linda Dunbar; [e-mail]
Subject: Re: [Nsaas] 答复: Existing work, other things

On 8/12/14 8:51 AM, Linda Dunbar wrote:
> [Linda] I've seen IETF work on general control <-> agent, but not
> specifically to Security functions, like FW policies, negotiations,
> and validations of security functions that are not physically located
> in the customer premises but accessed via remotely.

midcom, nsis, pcp, (arguably) SOCKS.

Melinda