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

[Stephen Farrell <[e-mail]>]

Hiya,

On 25/05/16 21:14, Ignacio Solis wrote:
> 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.

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.

> 
> 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.

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


> 
> Nacho
> 
> On Wed, May 25, 2016 at 12:54 PM, <[e-mail]> wrote:
> 
>>
>>
>> On Wed May 25 18:47:32 2016 GMT+0100, Ignacio Solis wrote:
>>> 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.
>>
>> 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
>>> 15 months - transport protocol
>>> 6 months - overlay protocol (xxx-over-UDP, xxx-over-IP)
>>> 9 months - native protocol (xxx-over-Ethernet, ??)
>>>
>>> --
>>> Nacho - Ignacio Solis - [e-mail]
>>>
>>
> 
> 
> 
> 
> 
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg
>