Subject: [I2nsf] What elements of IETF ANIMA can be used for I2NSF?

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Oct 2014 17:26:20 +0000

I2NSF is to develop application /user oriented policies (the attributes,  the profiles, or the descriptors ) of the network security functions that clients can request/query from 3rd party  providers.

ANIMA (Autonomic Networking Integrated Model and Approach) introduces a control paradigm where network processes, driven by objectives (or intent), coordinate their local decisions, autonomically translate them into local actions, and adapt them automatically according to various sources of information including external information and protocol information bases.

ANIMA will develop protocols to achieve auto discovery among management system and devices. The listed drafts proposed the "The Configuration Discovery and Negotiation protocol designed to be a generic platform, which is independent from the negotiation contents." There is also the Security aspects being discussed in the ANIMA drafts (like secure messages, or keys, among the parties (to be discovered).

Are there some elements developed by ANIMA that can be used by I2NSF?

Linda

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Oct 2014 08:33:39 +1300

Linda,

> Are there some elements developed by ANIMA that can be used by I2NSF?

I think the short answer is that it's too soon to answer that question.
The long answer is that I suppose I2NSF would need to identify how
it could be described as a use case for autonomic networking (rather
than as a top-down management use case). For example could the
autonomic discovery mechanism be used to find the I2NSF provider,
even if a specific mechanism was used to download the security
policy itself?

One issue is the trust boundary. We assume that participants in an
autonomic network have a common trust anchor. How can we trust a
"3rd party" provider?

   Brian

On 24/10/2014 06:26, Linda Dunbar wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 24 Oct 2014 01:45:26 +0000

The email from Melinda : http://www.ietf.org/mail-archive/web/nsaas/current/msg00001.html stated that PCP is relevant to I2NSF. 

I used to join the security work in PCP and would like to provide some information about it.  

The Port Control Protocol (PCP) enables an IPv4 or IPv6 host to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communication with remote hosts.

However, compared with I2NSF, PCP only tries to address a single problem--the management of port and address information.

Cheers

Dacheng

---

From: Melinda Shore <[email-masked]>
Date: Thu, 23 Oct 2014 18:05:28 -0800

On 10/23/14 5:45 PM, Zhangdacheng (Dacheng) wrote:
> However, compared with I2NSF, PCP only tries to address a single
> problem--the management of port and address information.

Yes, because that's how the IETF specifies on-the-wire protocols.
There are a number of existing IETF protocols that communicate
filtering and other policies to security and other devices.
Some of those protocols are management-y and some of them are
transport-y and some are internet-y.

It seems pretty ridiculous to me to try to do a "gap analysis"
when there aren't any requirements.  The participating devices
haven't been identified, the deployment hasn't been described,
and the policy under discussion is extremely high-level.

At any rate it is impossible to do a gap analysis without
requirements, and those don't exist here.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 24 Oct 2014 15:16:47 +0000

Melinda, 

Is it better to call it "Relevant Existing work study"? 

Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Thursday, October 23, 2014 9:05 PM
To: [email-masked]
Subject: Re: [I2nsf] Gaps between PCP and I2NSF

Yes, because that's how the IETF specifies on-the-wire protocols.
There are a number of existing IETF protocols that communicate filtering and other policies to security and other devices.
Some of those protocols are management-y and some of them are transport-y and some are internet-y.

It seems pretty ridiculous to me to try to do a "gap analysis"
when there aren't any requirements.  The participating devices haven't been identified, the deployment hasn't been described, and the policy under discussion is extremely high-level.

At any rate it is impossible to do a gap analysis without requirements, and those don't exist here.

Melinda

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

---

From: Melinda Shore <[email-masked]>
Date: Fri, 24 Oct 2014 09:05:38 -0800

> Is it better to call it "Relevant Existing work study"? 

What problem are you trying to solve by writing this document?

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 24 Oct 2014 19:18:16 +0000

Melinda, 

The work is for the 4th item on the agenda sent out from Dan:

        4. Relationship with IETF existing work (SACM, midcom, nsis, pcp, ANIMA, etc.)

Linda

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Friday, October 24, 2014 12:06 PM
To: Linda Dunbar; [email-masked]
Subject: Re: [I2nsf] Gaps between PCP and I2NSF

Melinda

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 24 Oct 2014 12:27:40 -0700

I expect that the use cases we discuss will involve areas where the IETF
has done some work already or has work in progress.  This work may be
directly related to i2nsf or it may be tangential, however, it would be
useful to know how the use cases and proposed items could interact with the
existing work.

Cheers,

Joe

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 24 Oct 2014 21:33:26 +0200

> Sent: Friday, October 24, 2014 7:06 PM

Sorry that I jump into this threat. I guess this is helpful  for:
1- Understanding the scope of different groups to avoid any conflict scopes
2- possibility to re-use the work item of one of groups and build the work
item of this group based on some of their works

Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 24 Oct 2014 21:35:45 +0200

Threat = thread... :-/

---

From: Melinda Shore <[email-masked]>
Date: Fri, 24 Oct 2014 11:45:08 -0800

> item of this group based on some of their works

That, of course, makes a lot of sense once a problem has been identified
that needs to be solved.  That's not the case here, yet.

I've been trying to get a handle on why it's taking so long to get so
much work through the IETF, and I think we're seeing some of the
reasons reflected here, in this group.  There's no clear, tightly-
scoped agreed-upon problem, as nearly as I can tell.  This is, in
very large part, why I think a BOF is terribly premature.  I'm
going to miss the BOF this time because I'm leaving early, but
my guess is that much time is going to spent trying to figure out
what to work on.  My personal bias is that that sort of question
needs to be resolved before publishing drafts, before requesting a
BOF, and so on.  As much as I enjoy fishing, I do not like standards
fishing expeditions at all.

Melinda

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 28 Oct 2014 00:24:20 +0100

Hi Melinda,

Thanks for your message
> That, of course, makes a lot of sense once a problem has been identified
that
> needs to be solved.  That's not the case here, yet.
> 
> I've been trying to get a handle on why it's taking so long to get so much
work
> through the IETF, and I think we're seeing some of the reasons reflected
here,
> in this group.  There's no clear, tightly- scoped agreed-upon problem, as
> nearly as I can tell.  This is, in very large part, why I think a BOF is
terribly
> premature.  I'm going to miss the BOF this time because I'm leaving early,
but
> my guess is that much time is going to spent trying to figure out what to
work
> on.  My personal bias is that that sort of question needs to be resolved
before
> publishing drafts, before requesting a BOF, and so on.  As much as I enjoy
> fishing, I do not like standards fishing expeditions at all.
> 

I just followed this non-WG list. I think Linda and others tried to identify
the problems in their messages and clarify the scope. BoF is also not
necessarily lead to WG but it is more identify the scope of the problem and
also might lead to a WG. For doing that, having good information of the
current works is helpful. Because it is possible to specify the scope based
on one of available solutions. Furthermore, NFV and SDN based work are new
technologies and it is necessary to have standards otherwise there is no
possibility for offering services from different service providers to end
users.

Best,
Hosnieh