Subject: [icnrg] I-D Action: draft-irtf-icnrg-evaluation-methodology-04.txt

From: [email-masked]
Date: Mon, 21 Mar 2016 05:04:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Information-Centric Networking of the IETF.

        Title           : Information-centric Networking: Evaluation and Security Considerations
        Authors         : Kostas Pentikousis
                          Borje Ohlman
                          Elwyn Davies
                          Spiros Spirou
                          Gennaro Boggia
	Filename        : draft-irtf-icnrg-evaluation-methodology-04.txt
	Pages           : 34
	Date            : 2016-03-11

Abstract:
   This document presents a number of considerations regarding
   evaluating Information-centric Networking (ICN) and sheds some light
   on the impact of ICN on network security. It also surveys the
   evaluation tools currently available to researchers in the ICN area
   and provides suggestions regarding methodology and metrics.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-icnrg-evaluation-methodology/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-evaluation-methodology-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dirk Kutscher <[email-masked]>
Date: Mon, 21 Mar 2016 13:14:19 +0000

Let's do another RG last call for this.

Please let us know of any comments until Monday, March 28th, 23:59 PST.

Best regards,
Dirk

> -----Original Message-----
> From: icnrg [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Montag, 21. März 2016 13:05
> To: [email-masked]
> Cc: [email-masked]
> Subject: [icnrg] I-D Action: draft-irtf-icnrg-evaluation-methodology-04.txt
> 
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Nikos Fotiou <[email-masked]>
Date: Tue, 29 Mar 2016 13:34:41 +0300

Hi all,
In ICN 2014 (Paris) there was a paper titled "Analyzing Cacheable Traffic
in ISP Access Networks for Micro CDN Applications via Content-Centric
Networking" (http://conferences2.sigcomm.org/acm-icn/2014/papers/p57.pdf).
I believe the content of the paper fits in section 2.2 ( disclaimer, I am
not affiliated with this paper).

Moreover, in section 3.2 there is the following text:
"An authorization
 delegation scheme has been proposed [ACDICN] but this requires access
 to a server controlled by the publisher to obtain an access token
 making it essentially just an out-of-band key distribution system"

Being the main author of [ACDICN] I would say that this statement is not
accurate. The access token is not delivered out of band, neither is used as
an encryption key. Moreover, the access control provider (i.e., the
"server" mentioned in the text) is not controlled by the publisher but it
is trusted by the publisher; in terms of currently used architectures, a
publisher can be any user, the access control provider can be facebook, and
the access control mechanism would be an enhanced version of facebook
connect. The goal of the scheme is to allow a semi-trusted entity (e.g., a
cache, a CDN node) to evaluate if a subscriber is authorized to access a
publication, without having access to the user management system of the
publisher. Therefore, encryption of the publication is orthogonal to this
scheme.

If you want, a more accurate description of [ACDICN] is the following:
An authorization delegation scheme has been proposed [ACDICN]. This scheme
allows semi-trusted entities (such as caches, CDN nodes) to delegate access
control decisions to 3rd party access control providers that are trusted by
the content publisher. The former entities have no access to subscriber
related information and should respect the decisions of the access control
providers.

Finally, in the same section there is the following text
"One possible technique that could allow for providing access control
 to heterogeneous groups and still allow for a single encrypted object
 representation that remains cacheable is Attribute Based Encryption
 (ABE). A first proposal for this is presented in [ABE]"

I believe this statement is not very accurate. With Attribute Based
Encryption , all attributes (and the corresponding cryptographic keys) must
be derived by the same entity. Therefore, the group of users cannot be
heterogeneous, instead users should belong to the same administrative
domain (e.g., users of the same social network). Moreover, although
probably out of the scope of this draft, it should be kept in mind that
Attribute Based Encryption suffers from key escrow problems and key
revocation posses non-negligible overhead.

Best,
Nikos

On 21 March 2016 at 15:14, Dirk Kutscher <[email-masked]> wrote:

> > Subject: [icnrg] I-D Action:
> draft-irtf-icnrg-evaluation-methodology-04.txt
> >
> >
> >         Title           : Information-centric Networking: Evaluation and
> Security
> > Considerations

---

From: Dirk Kutscher <[email-masked]>
Date: Tue, 29 Mar 2016 11:31:54 +0000

Thanks, Nikos.

Let's hear the authors on this.

--
Best regards,
Dirk

Am 29.03.2016 um 12:35 schrieb Nikos Fotiou <[email-masked]<mailto:[email-masked]>>:

Hi all,
In ICN 2014 (Paris) there was a paper titled "Analyzing Cacheable Traffic in ISP Access Networks for Micro CDN Applications via Content-Centric Networking" (http://conferences2.sigcomm.org/acm-icn/2014/papers/p57.pdf). I believe the content of the paper fits in section 2.2 ( disclaimer, I am not affiliated with this paper).

Being the main author of [ACDICN] I would say that this statement is not accurate. The access token is not delivered out of band, neither is used as an encryption key. Moreover, the access control provider (i.e., the "server" mentioned in the text) is not controlled by the publisher but it is trusted by the publisher; in terms of currently used architectures, a publisher can be any user, the access control provider can be facebook, and the access control mechanism would be an enhanced version of facebook connect. The goal of the scheme is to allow a semi-trusted entity (e.g., a cache, a CDN node) to evaluate if a subscriber is authorized to access a publication, without having access to the user management system of the publisher. Therefore, encryption of the publication is orthogonal to this scheme.

If you want, a more accurate description of [ACDICN] is the following:
An authorization delegation scheme has been proposed [ACDICN]. This scheme allows semi-trusted entities (such as caches, CDN nodes) to delegate access control decisions to 3rd party access control providers that are trusted by the content publisher. The former entities have no access to subscriber related information and should respect the decisions of the access control providers.

I believe this statement is not very accurate. With Attribute Based Encryption , all attributes (and the corresponding cryptographic keys) must be derived by the same entity. Therefore, the group of users cannot be heterogeneous, instead users should belong to the same administrative domain (e.g., users of the same social network). Moreover, although probably out of the scope of this draft, it should be kept in mind that Attribute Based Encryption suffers from key escrow problems and key revocation posses non-negligible overhead.

Best,
Nikos

On 21 March 2016 at 15:14, Dirk Kutscher <[email-masked]<mailto:[email-masked]>> wrote:
Let's do another RG last call for this.

Best regards,
Dirk

> From: icnrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of internet-
> [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg