[I2nsf] I2NSF Interim #2: To discuss NSF facing drafts, to make it ready for WG adoption

[webex]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=webex;SENT-BY="MAILTO:linda.dun...@huawei.com":MAILTO:messenger@
 webex.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=i2nsf@iet
 f.org:MAILTO:i2nsf@ietf.org
DESCRIPTION;LANGUAGE=en-US:When: Wednesday\, October 05\, 2016 4:00 PM-6:00
  PM (UTC-06:00) Central Time (US & Canada).\nWhere: https://ietf.webex.com
 /ietf\n\nNote: The GMT offset above does not reflect daylight saving time 
 adjustments.\n\n*~*~*~*~*~*~*~*~*~*\n\n\n\n-Original Appointment-\
 nFrom: webex\nSent: Wednesday\, September 21\, 2016 10:01 PM\nTo: webex\; 
 I2NSF Working Group\nSubject: To discuss NSF facing drafts\, to make it re
 ady for WG adoption\nWhen: Wednesday\, October 05\, 2016 4:00 PM-6:00 PM (
 UTC-06:00) Central Time (US & Canada).\nWhere: https://ietf.webex.com/ietf
 \n\n\nJoin WebEx meeting\nMeeting number (access code): 649 770 059\nHost 
 key: 596746\nMeeting password:   bUgPsSrP\n\n\nJoin by phone\n1-877-66
 8-4493 Call-in toll free number (US/Canada)\n1-650-479-3208 Call-in toll n
 umber (US/Canada)\nToll-free calling restrictions\n\n\n\nCan't join the meeting? Contact suppor
 t.\n\nIMPORTANT NOTICE: Please note that t
 his WebEx service allows audio and other information sent during the sessi
 on to be recorded\, which may be discoverable in a legal matter. You shoul
 d inform all meeting attendees prior to recording if you intend to record 
 the meeting.\n\n
SUMMARY;LANGUAGE=en-US:I2NSF Interim #2: To discuss NSF facing drafts\, to 
 make it ready for WG adoption
DTSTART;TZID=Central Standard Time:20161005T16
DTEND;TZID=Central Standard Time:20161005T18
UID:7b73f1b4-b1be-4068-a914-3f990d63cb87
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161005T21Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:1474513226
LOCATION;LANGUAGE=en-US:https://ietf.webex.com/ietf
X-MICROSOFT-CDO-APPT-SEQUENCE:1474513226
X-MICROSOFT-CDO-OWNERAPPTID:0
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT5M
END:VALARM
END:VEVENT
END:VCALENDAR
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] Call for WG adoption of draft-kumar-i2nsf-client-facing-interface-req

[Linda Dunbar]

Dear WG:

This email serves as a call for WG adoption of 
draft-kumar-i2nsf-client-facing-interface-req as a WG document. The call for 
adoption will run for 2 weeks ending Oct 5, 2016.
The requirement document is one of the key deliverables specified by the  I2NSF 
charter.

Please note that this is a call for adoption, and not a last call for content 
of the document. Adopting a WG document simply means that the WG will focus its 
efforts on that particular draft going forward, and use that document for 
resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issues 
you have with the current document itself can also be raised, but they should 
be raised in the context of what should be changed in the document going 
forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that applies 
to this draft, in line with the IPR disclosure obligations for WG participants 
(see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a 
document author please respond to this email (to the chairs) whether or not you 
are aware of any relevant IPR
https://tools.ietf.org/id/draft-kumar-i2nsf-client-facing-interface-req-00.txt


Authors: there are some editorial changes needed to comply with the I2NSF 
terminologies that the WG has agreed, in particular:

-Abstract: needs to change the starting sentence to "This document 
provides a framework and requirement "

-Change all reference of "North Bound Interface" to "Client/consumer 
facing interface".

Thank you,

Linda & Adrian

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] The I2NSF WG has placed draft-kumar-i2nsf-client-facing-interface-req in state "Candidate for WG Adoption"

[IETF Secretariat]

The I2NSF WG has placed draft-kumar-i2nsf-client-facing-interface-req in
state 
Candidate for WG Adoption (entered by Adrian Farrel)

The document is available at
https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-facing-interface-req/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] Is the "Security Service Function (SSF)" in draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the I2NSF-problem-and-use-cases?

[Daniel Migault]

Hi Susan,

I deeply apology for not having read carefully the
draft-hares-i2nsf-ddos-yang-dm-00, but my understanding is that our
protocol would – for example – end up in agreeing using inter-cloud-ddos
NSF with the inter-cloud-ddos NETCONF/YANG model. The remaining
configuration NETCONF/YANG will be done outside of our protocol.

We wondered whether using YANG or JSON and we decided to use JSON as
YANG seemed to us non appropriated for our protocol. That said we
might be completely wrong and would be happy to change if necessary.
The reasoning behind was:
I saw NETCONF/YANG as one way to get operational data or to push a
configuration. In our case, the collaboration agreement seemed
different from a configuration file as a given attribute may have a
preset of values. “A”, “B”, “C” and “D”, but the cloud and the
cloudlet may have different policies regarding the attribute. For
example the cloud only accepts “A” “B” and “C” and the cloudlet only
accepts “C” and “D”. In that sense, the purpose of the our protocol is
to let the cloud announce to the cloudlet that it only accepts answers
that are in “A” “B” “C” , and let the cloudlet responds with “C”.

One way to do that in YANG would be to have attributes like:

Attribute-proposal-list and Attribute-chosen, but I am not sure that
is really appropriated.


We are happy to receive feed back on your opinion using YANG/JSON!

BR,
Daniel


On Tue, Sep 13, 2016 at 3:25 PM, Susan Hares  wrote:

> Linda and Daniel:
>
>
>
> To follow-up on Linda’s second question,  this draft appears to be similar
> to the draft-inter-cloud-DDOS Yang model (draft-hares-i2nsf-ddos-yang-dm-00).
> Is it reasonable to have to different yang models or to make one an
> augmentation of the other data model?
>
>
>
> It might make sense to have a general collaboration model for inter-domain
> SSF functions with the DDOS Yang model as a sub-function.  I’ll send some
> Yang model interactions offline.
>
>
>
> Sue
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *Linda Dunbar
> *Sent:* Monday, September 12, 2016 5:59 PM
> *To:* 'Daniel Migault'; Alireza Ranjbar; i2nsf@ietf.org
> *Subject:* [I2nsf] Is the “Security Service Function (SSF)” in
> draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the
> I2NSF-problem-and-use-cases?
>
>
>
> Daniel and Alirezza,
>
>
>
> Is the “Security Service Function (SSF)” in your draft equivalent to the
> Network Security Function (NSF) defined in https://www.ietf.org/id/draft-
> ietf-i2nsf-problem-and-use-cases-01.pdf  ?
>
>
>
>
>
> NSF: Network Security Function. An NSF is a function that detects abnormal
> activity and blocks/mitigates the effect of such abnormal activity in order
> to preserve the availability of a network or a service. In addition, the
> NSF can help in supporting communication stream integrity and
> confidentiality.
>
>
>
> Flow-based NSF: An NSF which inspects network flows according to a
>
> security policy. Flow-based security also means that packets are
>
> inspected in the order they are received, and without altering
>
> packets due to the inspection process (e.g., MAC rewrites, TTL
>
> decrement action, or NAT inspection or changes).
>
>
>
>
>
> If they are the same, can you change the terminology? If they are
> different, can you elaborate the differences in your draft?
>
>
>
>
>
> Second question:
>
> When the “Cloud based services” need network provider to enforce certain
> flow rules for the traffic destined to (originated from) the “Cloud based
> services”, do you anticipate those flow rules to be applied to specific
> SSFs belonging to different administrators?  Or can those rules be to the
> “controller” of the SSFs belonging to network providers?  As described by
> https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound-
> framework/ ?
>
>
>
>
>
> Thanks,
>
> Linda
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] Is the “Security Service Function (SSF)” in draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the I2NSF-problem-and-use-cases?

[Daniel Migault]

Hi Linda,



I apology for the delay. Please find my response and additional questions –
mostly for Susan ;-). If you are find with the response, I can also send
them on the ML.



Q1: There is no difference between SSF and NSF. We will change that in the
next version. Thanks for raising it, this is a good reminder to update our
terminology.



Q2: Our protocol defines how the two domains interconnect to have NSF
working in different domains interacting properly. In our case, the
security controller of the cloud and the security controller of the
cloudlet agree on how the cloudlet and the cloud needs to interconnect
their data plane as well as how the cloud can configure or control the NSF
in the cloudlet. The configuration of the NSF itself is not part of the
collaboration protocol typically we expect that NETCONF/YANG be used.



My understanding of draft-kumar-i2nsf-controller-northbound-framework-00
[1] is that is provides some requirements for an API to be able to manage a
whole domain of NSF provided by multiple vendors. In our case if a cloud
were using such API, we would consider the security controller of the cloud
got control over a significant part of the resource of the cloudlet. In our
case, we would like that collaboration of the cloudlet can be performed
with a reduced footprint from the cloud. The foot print is limited by the
cloudlet by limiting the interaction from the cloud to the NSF
instantiating in the cloud.



BR,

Daniel

On Mon, Sep 12, 2016 at 5:59 PM, Linda Dunbar 
wrote:

> Daniel and Alirezza,
>
>
>
> Is the “Security Service Function (SSF)” in your draft equivalent to the
> Network Security Function (NSF) defined in https://www.ietf.org/id/draft-
> ietf-i2nsf-problem-and-use-cases-01.pdf  ?
>
>
>
>
>
> NSF: Network Security Function. An NSF is a function that detects abnormal
> activity and blocks/mitigates the effect of such abnormal activity in order
> to preserve the availability of a network or a service. In addition, the
> NSF can help in supporting communication stream integrity and
> confidentiality.
>
>
>
> Flow-based NSF: An NSF which inspects network flows according to a
>
> security policy. Flow-based security also means that packets are
>
> inspected in the order they are received, and without altering
>
> packets due to the inspection process (e.g., MAC rewrites, TTL
>
> decrement action, or NAT inspection or changes).
>
>
>
>
>
> If they are the same, can you change the terminology? If they are
> different, can you elaborate the differences in your draft?
>
>
>
>
>
> Second question:
>
> When the “Cloud based services” need network provider to enforce certain
> flow rules for the traffic destined to (originated from) the “Cloud based
> services”, do you anticipate those flow rules to be applied to specific
> SSFs belonging to different administrators?  Or can those rules be to the
> “controller” of the SSFs belonging to network providers?  As described by
> https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound-
> framework/ ?
>
>
>
>
>
> Thanks,
>
> Linda
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf