Subject: [icnrg] BoF Proposal - Forwarding Using Names - FUN BOF

From: Ignacio Solis <[email-masked]>
Date: Wed, 25 May 2016 10:47:32 -0700

Forwarding Using Names - FUN BOF

The work in ICN protocols has advanced to the point where we need to
consider the creation of a Working Group. For this reason we would like to
request a Forwarding Using Names BoF (FUN BoF) to be scheduled for the
Berlin meeting. The FUN BoF would be used to gauge the level of interest
from the community, define the scope of a potential WG, determine what
items from ICNRG we’re going to carry over and in what form, discuss a
possible charter and talk about where and how this work fits in the IETF.

For this purpose I would like to present a draft charter and agenda.
Feedback is requested and welcome.

======================

Proposed agenda for the FUN BoF:

1) Objective and agenda bashing
2) Problem statement
3) State of current documents and technology
3a) draft-irtf-icnrg-ccnxsemantics-02
3b) draft-irtf-icnrg-ccnxmessages-02
3c) draft-mosko-icnrg-ccnxurischeme-01
3d) draft-tschudin-icnrg-flic-00
3e) draft-wood-icnrg-ccnxoverudp.txt
3f) others?
4) Scoping
5) Charter discussion
6) Next steps

Proposed WG Charter:
Name:
 Forwarding Using Names Working Group (FUNWG)

Chairs:
 TBD

Area:
 Transport/Internet (?)

AD:
 ?

Description of WG:

The purpose of the Forwarding Using Names Working Group (FUNWG) is to
specify protocols and mechanisms for forwarding packets using names.
Network nodes produce or request packets based on names (explicit or
implicit). Networks that use named pieces of content as the main
communication abstraction have been labeled as Information Centric
Networks. As the name implies, this Working Group specifically focuses on
using names to forward packets; that is, layer 3.

Forwarding packets using names is the cornerstone of the predominant ICN
approaches and has been the focus of most academic and industrial research.
The CCN and NDN protocols use a request-response object protocol to provide
an adaptable, resilient and secure communication environment that doesn’t
suffer from some of the drawbacks introduced by the IP/TCP/HTTP/TLS
combination.

Work on ICN started in 2007 at PARC with the creation of CCN. In 2009 the
NDN project was formed using CCN as a base. At the same time a number of
European projects (NetINF, Pursuit) also started evaluating different ICN
techniques. The NetINF project for example produced “Naming Things with
Hashes” [RFC 6920]. In 2012 the IRTF chartered a Research Group to do work
on ICN, the ICNRG. The community consensus settled on the CCN approach with
most ICNRG work and discussions revolving around it.

The CCN protocol is a request-response protocol made up of 2 core network
messages; Interests and ContentObjects. Interests request content by name.
ContentObjects are named pieces of content. Forwarders us the name in the
messages to determine where to forward them. Interests follow a FIB doing
prefix matching on the name. ContentObjects follow the reverse path.

Forwarding packets using names has a number of implications, specifically
it allows the network to name each piece of data. Once you can name each
piece of data and request the data by name you can get a number of benefits
including object-based security, decoupling of producer and sender,
improved flow control, native indirection, caching, etc.

Work items for this Working Group
- Define a set of coherent core protocols that communicate by forwarding
using names.
- Define a set of transport protocols built on top of the core protocols
that communicate at the level of application data units.
- Define a set of overlay protocols to transport named objects over UDP and
Ethernet.

There are some areas that while very related, are out of scope for this
Working Group.
These include routing, key distribution, novel security techniques, etc.

Expected documents:
9 months - core protocol
15 months - transport protocol
6 months - overlay protocol (xxx-over-UDP, xxx-over-IP)
9 months - native protocol (xxx-over-Ethernet, ??)

-- 
Nacho - Ignacio Solis - [email-masked]

---

From: [email-masked]
Date: Wed, 25 May 2016 19:54:08 +0000

> Feedback is requested and welcome.

Sorry but that last puzzles me. If there are no current ICN confidentiality services, how can novel ones be out of scope? 

Ta, 
S.

---

From: Ignacio Solis <[email-masked]>
Date: Wed, 25 May 2016 13:14:05 -0700

The comment wasn't because we don't need more work in security (novel,
current or ancient), it was because the idea was for that work to remain at
ICNRG.   I personally don't have a strong objection to bringing it in as
long as ADs are ok with that.

If we're all on the same page about the BoF I'm happy to figure out the
details about the proposed charter and then clean things up at the BoF.

Nacho

On Wed, May 25, 2016 at 12:54 PM, <[email-masked]> wrote:

> Sorry but that last puzzles me. If there are no current ICN
> confidentiality services, how can novel ones be out of scope?
>
> Ta,
> S.
>
> >
> > Expected documents:
> > 9 months - core protocol

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 May 2016 22:18:32 +0100

Hiya,

> long as ADs are ok with that.

Personally speaking, I would have a problem with an IETF WG
being formed on the basis that an IRTF RG was still needed
to figure out the answers to basic security questions.

> details about the proposed charter and then clean things up at the BoF.

So I'm kinda in two minds about this.

We have IETF BCPs (e.g. BCP61, BCP188) that basically call for strong
security to be well-defined for IETF standards track protocols. I don't
see that we have any currently well-defined schemes for e2e or transport
security for ICN, that adhere to ICN principles. (For all but a few
services such as name-data integrity I mean.)

So an IETF WG would either seem to require a) defining how to do ICN
security for ICN by falling back to host based security (as current
proposals do), which seems to call into question the idea of WG, or
else b) solve what seems to me to be the very hard problem of security
for ICN, done in a way that makes sense in an ICN.

I'd like to see (b) happen but that might take a long time. However,
doing (a) can also be significantly time consuming - talk to folks
about the history of the roll WG on this topic for example. Not having
a real answer and punting on that over and over was what happened
there and still hasn't resulted in a satisfactory outcome (from my
POV anyway).

There were similar issues with LISP as well I think, though there
were also other things going on there. In that case, the attempt
wasn't to punt, but to first develop experimental IETF track RFCs,
(which I guess made sense to someone at the time;-) but given that
there's an RG, I'm not sure another route to producing experimental
RFCs is very useful.

So my overall initial reaction is that this'd be a fine proposal if
the ICN-security solutions were much better developed. Absent that,
this part of the work is liable to be quite tricky, and could be
time consuming and lead to nasty blockages later in the IETF
process. (*)

In any case, I think this is about much more than wordsmithing.

Cheers,
S.

(*) In case anyone considers the above some kind of personal
threat, see [1] :-) I'd be fairly sure that most SEC ADs would be
of the same mind though.

[1] https://www.ietf.org/mail-archive/web/saag/current/msg07057.html

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

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Thu, 26 May 2016 13:45:29 +0000

Hi Ignacio and all,

These items mentioned below in the first email are really crucial for ICN to see the light and to be deployed. And the only place to bring solutions to these items is in IETF (so handing off these items from ICNRG to an IETF WG makes perfect sense to me). Security is a very important topic as well, but we need to know first how the core and transport protocols (and overlay protocols and naming) will look like first. Then security can be a part of the IETF WG but not the first milestone or can continue in ICNRG until advancing with the mentioned items then handed off to the WG after that.

> - Define a set of overlay protocols to transport named objects over UDP and

That’s my 2 cents.

Thanks
Hassnaa

From: icnrg [mailto:[email-masked]] On Behalf Of Ignacio Solis
Sent: Wednesday, May 25, 2016 1:14 PM
To: [email-masked]
Cc: Nacho Solis <[email-masked]>; [email-masked]
Subject: Re: [icnrg] BoF Proposal - Forwarding Using Names - FUN BOF

The comment wasn't because we don't need more work in security (novel, current or ancient), it was because the idea was for that work to remain at ICNRG.   I personally don't have a strong objection to bringing it in as long as ADs are ok with that.

If we're all on the same page about the BoF I'm happy to figure out the details about the proposed charter and then clean things up at the BoF.

Nacho

On Wed, May 25, 2016 at 12:54 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Ta,
S.

> Nacho - Ignacio Solis - [email-masked]<mailto:[email-masked]>
>

--
Nacho - Ignacio Solis - [email-masked]<mailto:[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 May 2016 17:12:22 +0100

On 26/05/16 14:45, Moustafa, Hassnaa wrote:
> 
> These items mentioned below in the first email are really crucial for
> ICN to see the light and to be deployed. And the only place to bring
> solutions to these items is in IETF (so handing off these items from
> ICNRG to an IETF WG makes perfect sense to me). Security is a very
> important topic as well, but we need to know first how the core and
> transport protocols (and overlay protocols and naming) will look like
> first. Then security can be a part of the IETF WG but not the first
> milestone or can continue in ICNRG until advancing with the mentioned
> items then handed off to the WG after that.

So there is a danger in that approach that work in a putative IETF
WG gets quite far along and then hits issues when there are no good
answers about security and privacy. I figure that delayed the roll
WG for a couple of years. Checking the history of RFC 7416 [1] may
provide a good example of that - it took 5 years from the 1st WG
document to RFC, mainly IMO because the WG punted on figuring out
security until it was too late to do much that made sense after
they had finalised RFC6550 which is the base RPL protocol. That is
really not the best plan.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/rfc7416/

---

From: "Moustafa, Hassnaa" <[email-masked]>
Date: Thu, 26 May 2016 16:29:34 +0000

No opposition on that. What I meant is to support the approach of building a charter to take ICN from research to deployment (routing, transport, naming, control/signaling management,.......) and of course this should be secured. So how security intercepts in terms of timing (first milestone or second or .....) is the point. 

Thanks
Hassnaa

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, May 26, 2016 9:12 AM
To: Moustafa, Hassnaa <[email-masked]>; 'Ignacio Solis' <[email-masked]>
Cc: [email-masked]
Subject: Re: [icnrg] BoF Proposal - Forwarding Using Names - FUN BOF

Cheers,
S.

---

From: Ravi Ravindran <[email-masked]>
Date: Thu, 26 May 2016 19:43:56 +0000

We would certainly like have these two icnrg submissions as part of the BoF agenda as well.

Regards,
Ravi

https://datatracker.ietf.org/doc/draft-ravi-ccn-forwarding-label/

https://tools.ietf.org/html/draft-ravi-ccn-notification-01

From: icnrg [mailto:[email-masked]] On Behalf Of Ignacio Solis
Sent: Wednesday, May 25, 2016 10:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [icnrg] BoF Proposal - Forwarding Using Names - FUN BOF

The work in ICN protocols has advanced to the point where we need to consider the creation of a Working Group. For this reason we would like to request a Forwarding Using Names BoF (FUN BoF) to be scheduled for the Berlin meeting. The FUN BoF would be used to gauge the level of interest from the community, define the scope of a potential WG, determine what items from ICNRG we’re going to carry over and in what form, discuss a possible charter and talk about where and how this work fits in the IETF.

For this purpose I would like to present a draft charter and agenda. Feedback is requested and welcome.

======================

Proposed WG Charter:
Name:

Chairs:
 TBD

Area:
 Transport/Internet (?)

AD:
 ?

Description of WG:

The purpose of the Forwarding Using Names Working Group (FUNWG) is to specify protocols and mechanisms for forwarding packets using names. Network nodes produce or request packets based on names (explicit or implicit). Networks that use named pieces of content as the main communication abstraction have been labeled as Information Centric Networks. As the name implies, this Working Group specifically focuses on using names to forward packets; that is, layer 3.

Forwarding packets using names is the cornerstone of the predominant ICN approaches and has been the focus of most academic and industrial research. The CCN and NDN protocols use a request-response object protocol to provide an adaptable, resilient and secure communication environment that doesn’t suffer from some of the drawbacks introduced by the IP/TCP/HTTP/TLS combination.

Work on ICN started in 2007 at PARC with the creation of CCN. In 2009 the NDN project was formed using CCN as a base. At the same time a number of European projects (NetINF, Pursuit) also started evaluating different ICN techniques. The NetINF project for example produced “Naming Things with Hashes” [RFC 6920]. In 2012 the IRTF chartered a Research Group to do work on ICN, the ICNRG. The community consensus settled on the CCN approach with most ICNRG work and discussions revolving around it.

The CCN protocol is a request-response protocol made up of 2 core network messages; Interests and ContentObjects. Interests request content by name. ContentObjects are named pieces of content. Forwarders us the name in the messages to determine where to forward them. Interests follow a FIB doing prefix matching on the name. ContentObjects follow the reverse path.

Forwarding packets using names has a number of implications, specifically it allows the network to name each piece of data. Once you can name each piece of data and request the data by name you can get a number of benefits including object-based security, decoupling of producer and sender, improved flow control, native indirection, caching, etc.

Work items for this Working Group
- Define a set of coherent core protocols that communicate by forwarding using names.
- Define a set of transport protocols built on top of the core protocols that communicate at the level of application data units.
- Define a set of overlay protocols to transport named objects over UDP and Ethernet.

There are some areas that while very related, are out of scope for this Working Group.
These include routing, key distribution, novel security techniques, etc.

Expected documents:
9 months - core protocol