[xml2rfc] Some problems with idnits checks on V3 document

["David R. Oran" <[e-mail]>]

One of these seem to be xml2rfc rendering problem; others may be idnit 
glitches that only show up on V3 docs:

- The too long line 1551 is in fact not too long - the length 
computation seems to be screwed up by the non-ascii characters (probably 
idnit problem?)

- somehow xml2rfc elided part of an author name into the updates head 
field and author address into the Intended Status header field. This 
only happens in the .txt output, not the HTML or PDF. xml2rfc bug?

- idnits says this has a downref, but I believe that an I.D. marked 
experimental saying it updates an experimental RFC isn’t a downref, 
right?

I include the idnits output below and the xml file as an attachment 
(note that this is still a bit private - we haven’t submitted yes)

Let me know of any followup I should do - would like to get this 
submitted in the next couple of days.

Thanks! DaveO.

————————————

idnits 2.16.03


tmp/draft-oran-icnrg-reflexive-forwarding.txt:
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1491): Found non-ascii 
character (�) in position 18.
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1500): Found non-ascii 
character (�) in position 16.
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Line is too long: 
the offending characters are 'ch,'
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Found non-ascii 
character (�) in position 16.
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1597): Found non-ascii 
character (�) in position 67.


   Checking boilerplate required by RFC 5378 and the IETF Trust (see
   https://trustee.ietf.org/license-info):
   ----------------------------------------------------------------------------

      No issues found here.

   Checking nits according to 
https://www.ietf.org/id-info/1id-guidelines.txt:
   ----------------------------------------------------------------------------

    == There are 4 instances of lines with non-ascii characters in the 
document.


   Checking nits according to https://www.ietf.org/id-info/checklist :
   ----------------------------------------------------------------------------

   ** There is 1 instance of too long lines in the document, the longest 
one
      being 3 characters in excess of 72.


   Miscellaneous warnings:
   ----------------------------------------------------------------------------

   == Unrecognized Status in 'Intended status: Experimental  University 
of
      Applied Sciences Emden/Leer', assuming Proposed Standard

      (Expected one of 'Standards Track', 'Full Standard', 'Draft 
Standard',
      'Proposed Standard', 'Best Current Practice', 'Informational',
      'Experimental', 'Informational', 'Historic'.)

   == Couldn't figure out when the document was first submitted -- there 
may
      comments or warnings related to the use of a disclaimer for 
pre-RFC5378
      work that could not be issued because of this.  Please check the 
Legal
      Provisions document at https://trustee.ietf.org/license-info to 
determine
      if you need the pre-RFC5378 disclaimer.


   Checking references for intended status: Proposed Standard
   ----------------------------------------------------------------------------

      (See RFCs 3967 and 4897 for information about using normative 
references
      to lower-maturity documents in RFCs)

   ** Downref: Normative reference to an Experimental RFC: RFC 8569

   ** Downref: Normative reference to an Experimental RFC: RFC 8609


      Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 0 comments 
(--).

--------------------------------------------------------------------------------


2	ICNRG                                                            D. 
Oran
3	Internet-Draft                       Network Systems Research and 
Design
4	Updates: 8569, 8609 (if approved)                            D. 
Kutscher
5	Intended status: Experimental  University of Applied Sciences 
Emden/Leer
6	Expires: 2 October 2020                                    31 March 
2020

8	            Reflexive Forwarding for CCNx and NDN Protocols
9	                draft-oran-icnrg-reflexive-forwarding-00

11	Abstract

13	   Current Information-Centric Networking protocols such as CCNx and 
NDN
14	   have a wide range of useful applications in content retrieval and
15	   other scenarios that depend only on a robust two-way exchange in 
the
16	   form of a request and response (represented by an _Interest-Data
17	   exchange_ in the case of the two protocols noted above).  A number 
of
18	   important applications however, require placing large amounts of 
data
19	   in the Interest message, and/or more than one two-way handshake.
20	   While these can be accomplished using independent Interest-Data
21	   exchanges by reversing the roles of consumer and producer, such
22	   approaches can be both clumsy for applications and problematic 
from a
23	   state management, congestion control, or security standpoint.  
This
24	   specification proposes a _Reflexive Forwarding_ extension to the 
CCNx
25	   and NDN protocol architectures that eliminates the problems 
inherent
26	   in using independent Interest-Data exchanges for such 
applications.
27	   It updates RFC8569 and RFC8609.

29	Status of This Memo

31	   This Internet-Draft is submitted in full conformance with the
32	   provisions of BCP 78 and BCP 79.

34	   Internet-Drafts are working documents of the Internet Engineering
35	   Task Force (IETF).  Note that other groups may also distribute
36	   working documents as Internet-Drafts.  The list of current 
Internet-
37	   Drafts is at https://datatracker.ietf.org/drafts/current/.

39	   Internet-Drafts are draft documents valid for a maximum of six 
months
40	   and may be updated, replaced, or obsoleted by other documents at 
any
41	   time.  It is inappropriate to use Internet-Drafts as reference
42	   material or to cite them other than as "work in progress."

44	   This Internet-Draft will expire on 2 October 2020.

46	Copyright Notice

48	   Copyright (c) 2020 IETF Trust and the persons identified as the
49	   document authors.  All rights reserved.

51	   This document is subject to BCP 78 and the IETF Trust's Legal
52	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
53	   license-info) in effect on the date of publication of this 
document.
54	   Please review these documents carefully, as they describe your 
rights
55	   and restrictions with respect to this document.

57	Table of Contents

59	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  
  3
60	     1.1.  Problems with pushing data  . . . . . . . . . . . . . . .  
  4
61	     1.2.  Problems with utilizing independent exchanges . . . . . .  
  5
62	   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .  
  6
63	   3.  Overview of the Reflexive Forwarding design . . . . . . . . .  
  6
64	   4.  Naming of Reflexive Interests . . . . . . . . . . . . . . . .  
10
65	   5.  Forwarder operation for Reflexive Interests . . . . . . . . .  
11
66	   6.  State coupling between producer and consumer  . . . . . . . .  
12
67	   7.  Use cases for Reflexive Interests . . . . . . . . . . . . . .  
12
68	     7.1.  Achieving Remote Method Invocation with Reflexive
69	           Interests . . . . . . . . . . . . . . . . . . . . . . . .  
12
70	     7.2.  RESTful Web Interactions  . . . . . . . . . . . . . . . .  
15
71	     7.3.  Achieving simple data pull from consumers with reflexive
72	           Interests . . . . . . . . . . . . . . . . . . . . . . . .  
15
73	   8.  Implementation Considerations . . . . . . . . . . . . . . . .  
19
74	     8.1.  Forwarder implementation considerations . . . . . . . . .  
19
75	       8.1.1.  Forwarding Information Base (FIB) . . . . . . . . . .  
19
76	       8.1.2.  Interactions with Interest Lifetime . . . . . . . . .  
20
77	       8.1.3.  Interactions with Interest aggregation  . . . . . . .  
21
78	     8.2.  Consumer Implementation Considerations  . . . . . . . . .  
21
79	       8.2.1.  Data objects returned by the consumer to reflexive 
name
80	               Interests arriving from a producer  . . . . . . . . .  
21
81	       8.2.2.  Terminating unwanted reflexive Interest exchanges . .  
22
82	       8.2.3.  Interactions with caching . . . . . . . . . . . . . .  
22
83	     8.3.  Producer Implementation Considerations  . . . . . . . . .  
22
84	   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  
23
85	   10. Mapping to CCNx and NDN packet encodings  . . . . . . . . . .  
24
86	     10.1.  Packet encoding for CCNx . . . . . . . . . . . . . . . .  
24
87	     10.2.  Packet encoding for NDN  . . . . . . . . . . . . . . . .  
24
88	   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  
24
89	   12. Security Considerations . . . . . . . . . . . . . . . . . . .  
25
90	     12.1.  Collisions of reflexive Interest names . . . . . . . . .  
25
91	     12.2.  Additional resource pressure on PIT and FIB  . . . . . .  
26
92	     12.3.  Privacy Considerations . . . . . . . . . . . . . . . . .  
26
93	   13. Normative References  . . . . . . . . . . . . . . . . . . . .  
27
94	   14. Informative References  . . . . . . . . . . . . . . . . . . .  
27
95	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  
30

97	1.  Introduction

99	   Current ICN protocols such as CCNx [RFC8569] and [NDN] have a wide
100	   range of useful applications in content retrieval and other 
scenarios
101	   that depend only on a robust two-way exchange in the form of a
102	   request and response.  These ICN architectures use the terms
103	   "consumer" and "producer" for the respective roles of the 
requester
104	   and the responder, and the protocols directly capture the 
mechanics
105	   of the two-way exchange through the "Interest message" carrying 
the
106	   request, and the "Data message" carrying the response.  Through 
these
107	   constructs, the protocols are heavily biased toward a pure _pull-
108	   based_ interaction model where requests are small (carrying 
little or
109	   no user-supplied data other than the name of the requested data
110	   object), and responses are relatively large - up to an 
architecture-
111	   defined maximum transmission unit (MTU) on the order of kilobytes 
or
112	   tens of kilobytes.

114	   A number of important applications however require interaction 
models
115	   more complex than individual request/response interactions in the
116	   same direction (i.e. between the same consumer and one or more
117	   producers).  Among these we identify three important classes 
which
118	   are the target of the proposed enhancements defined in this
119	   specification.  These are described in the following paragraphs.

121	   *Remote Method Invocation (RMI, aka RPC):*  When invoking a 
remote
122	      method, it is common for the method to require arguments 
supplied
123	      by the caller.  In conventional TCP/IP style protocols like 
CORBA
124	      or HTTP "Post", these are pushed to the server as part of the
125	      message or messages that comprise the request.  In ICN-style
126	      protocols there is an unattractive choice between inflating 
the
127	      request initiation with pushed arguments, or arranging to have 
one
128	      or more independent request/responses in the opposite 
direction
129	      for the server to fetch the arguments.  Both of these 
approaches
130	      have substantial disadvantages.  Recently, a viable 
alternative
131	      emerged through the work on RICE [Krol2018] which pioneered 
the
132	      main design elements proposed in this specification.

134	   *Phone-Home scenario:*  Applications in sensing, 
Internet-of-things
135	      (IoT) and other types where data is produced unpredictably and
136	      needs to be _pushed_ somewhere create a conundrum for the pure
137	      pull-based architectures considered here.  If instead one 
eschews
138	      relaxing the size asymmetry between requests and responses, 
some
139	      additional protocol machinery is needed.  Earlier efforts in 
the
140	      ICN community have recognized this issue and designed methods 
to
141	      provoke a cooperating element to issue a request to return the
142	      data the originator desires to push, essentially "phoning 
home" to
143	      get the responder to fetch the data.  One that has been 
explored
144	      to some extent is the _Interest-Interest-Data_ exchange
145	      [Carzaniga2011], where an Interest is sent containing the 
desired
146	      request as encapsulated data.  CCNx-1.0 Bidirectional Streams
147	      [Mosko2017] are also based on a scheme where an Interest is 
used
148	      to signal a name prefix that a consumer has registered for
149	      receiving Interests from a peer in a bidirectional streaming
150	      session.

152	   *Peer state synchronization:*  A large class of applications,
153	      typified by those built on top of on reliable order-preserving
154	      transport protocols, require initial state synchronization 
between
155	      the peers.  This is accomplished with a three-way (or longer)
156	      handshake, since employing a two-way handshake as provided in 
the
157	      existing NDN and CCNx protocols exposes a number of well-know
158	      hazards, such as _half-open connections_. When attempted for
159	      security-related operations such as key exchange, additional
160	      hazards such as _man-in-the-middle_ attacks become trivial to
161	      mount.  Existing alternatives, similar to those used in the 
two
162	      examples above, instead utilize either overlapping 
Interest-Data
163	      exchanges in opposite directions (resulting in a four-way
164	      handshake) or by adding initialization data to the initial 
request
165	      and employing an Interest-Interest-Data protocol extension as
166	      noted in the Phone-home scenarios above.

168	   All of the above application interaction models present 
interesting
169	   challenges, as neither relaxing the architecture to support 
pushing
170	   large amounts of data, nor introducing substantial complexities
171	   through multiple independent Interest-Data exchanges is an 
attractive
172	   approach.  The following subsections provide further background 
and
173	   justification for why push and/or independent exchanges are
174	   problematical.

176	1.1.  Problems with pushing data

178	   There are two substantial problems with the simple approach of 
just
179	   allowing arbitrary amounts of data to be included with requests.
180	   These are:

182	   1.  In ICN protocols, Interest messages are intended to be small, 
on
183	       the order the size of a TCP ACK, as opposed to the size of a 
TCP
184	       data segment.  This is because the hop-by-hop congestion 
control
185	       and forwarder state management requires Interest messages to 
be
186	       buffered in expectation of returning data, and possibly
187	       retransmitted hop-by-hop as opposed to end-to-end.  In 
addition,
188	       the need to create and manage state on a per-Interest basis 
is
189	       substantially complicated if requests in Interest messages 
are
190	       larger than a Path MTU (PMTU) and need to be fragmented 
hop-by-
191	       hop.

193	   2.  If the payload data of a request is used for invoking a
194	       computation (as in the RMI case described above) then 
substantial
195	       bandwidth can be wasted if the computation is either refused 
or
196	       abandoned for any number of reasons, including the requestor
197	       failing an authorization check, or the responder not having
198	       sufficient resources to execute the associated computation.

200	   These problems also exist in pure datagram transport protocols 
such
201	   as those used for legacy RMI applications like NFS [RFC7530].  
More
202	   usual are application protocols like HTTP(s) which rely on the 
TCP or
203	   QUIC 3-way handshake to establish a session and then have 
congestion
204	   control and segmentation provided as part of the transport 
protocol,
205	   further allowing sessions to be rejected before large amounts of 
data
206	   are transmitted or significant computational resources expended.

208	1.2.  Problems with utilizing independent exchanges

210	   In order to either complete a three-way handshake, or fetch data 
via
211	   a pull from the original requestor, the role of consumer and 
producer
212	   need to be reversed and an Interest/Data exchange initiated in 
the
213	   direction opposite of the initiating exchange.  When done with an
214	   independent Interest/Data request and response, a number of
215	   complications ensue.  Among them are:

217	   1.  The originating consumer needs to have a routable name prefix
218	       that can be used for the exchange.  This means the consumer 
must
219	       arrange to have its name prefix propagated in the ICN routing
220	       system with sufficient reach that the producer issuing the
221	       interest can be assured it is routed appropriately.  While 
some
222	       consumers are generally online and act as application 
servers,
223	       justifying the maintenance of this routing information, many 
do
224	       not.  Further, in mobile environments, a pure consumer that 
does
225	       not need to have a routable name prefix can benefit from the
226	       inherent consumer mobility support in the CCNx and NDN 
protocols.
227	       By requiring a routable name prefix, extra mobile routing
228	       machinery is needed, such as that proposed in KITE 
[Zhang2018] or
229	       MAPME [Auge2018].

231	   2.  The consumer name prefix in item (1) above must be 
communicated
232	       to the producer as a payload, name suffix, or other field of 
the
233	       initiating Interest message.  Since this name in its entirety 
is
234	       chosen by the consumer, it is highly problematic from a 
security
235	       standpoint, as it can recruit the producer to mount a 
reflection
236	       attack against the consumer's chosen victim.

238	   3.  The correlation between the exchanges in opposite directions 
must
239	       be maintained by both the consumer and the producer as
240	       independent state, as opposed to being architecturally tied
241	       together as would be the case with a conventional 3-way 
handshake
242	       finite state machine.  While this can of course be 
accomplished
243	       with care by both parties, experience has shown that it is 
error
244	       prone (for example see the checkered history of interactions
245	       between the SIP [RFC3261] and SDP Offer-Answer [RFC6337])
246	       protocols.  When employed as the wrapper for a key management
247	       protocol such as with TLS [RFC8446] state management errors 
can
248	       be catastrophic for security.

250	2.  Requirements Language

252	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT",
253	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 
and
254	   "OPTIONAL" in this document are to be interpreted as described in
255	   [RFC2119].

257	3.  Overview of the Reflexive Forwarding design

259	   This specification defines a _Reflexive Forwarding_ extension to 
CCNx
260	   and NDN that avoids the problems enumerated in Sections 1.1 and 
1.2.
261	   It straightforwardly exploits the hop-by-hop state and symmetric
262	   routing properties of the current protocols.

264	   Figure 1 below illustrates a canonical NDN/CCNx forwarder with 
its
265	   conceptual data structures of the Content Store (CS), Pending
266	   Interest Table (PIT) and Forwarding Information Base (FIB).  The 
key
267	   observation involves the relation between the PIT and the FIB.  
Upon
268	   arrival of an Interest, a PIT entry is created which contains 
state
269	   recording the incoming interface on which the Interest.  If the
270	   Interest is not immediately satisfied by cached data in the CS, 
the
271	   forwarder looks up the name in the FIB to ascertain the 
_next-hop_ to
272	   propagate the Interest onward upstream toward the named producer.
273	   Therefore, a chain of forwarding state is established during 
Interest
274	   forwarding that couples the PIT entries of the chain of 
forwarders
275	   together conceptually as _breadcrumbs_. These are used to forward 
the
276	   returning Data Message over the inverse path through the chain of
277	   forwarders until the Data message arrives at the originating
278	   consumer.  The state in the PITs is _unwound_ by destroying it as
279	   each PIT entry is _satisfied_. This behavior is *critical* to the
280	   feasibility of the reflexive forwarding design we propose.

282	    
+-----------------------------------------------------------------+
283	    |                                                      ICN Node  
  |
284	    | Send data to all                                     ========  
  |
285	    | interfaces that                                                
  |
286	    | requested it                                                   
  |
287	    |                  YES +------------------+                      
  |
288	   <------------------------| Pending Interest |  
<---------------------
289	    |              |       |    Table (PIT)   |               Data   
  |
290	    |              |       +------------------+  1) Find     
(Signed) |
291	    |              | 2) Save         |              Name             
  |
292	    |              V    Data         | NO            in              
  |
293	    |   +---------------+            |              PIT?             
  |
294	    |   | Content Store |            |                               
  |
295	    |   |      (CS)     |            |                               
  |
296	    |   +---------------+            |                               
  |
297	    |                                |                               
  |
298	    |                                V                               
  |
299	    |                             Drop Data                          
  |
300	    |                                                                
  |
301	    
+-----------------------------------------------------------------+
302	    
+-----------------------------------------------------------------+
303	    |                                                      ICN Node  
  |
304	    |                                                      ========  
  |
305	    |                                                                
  |
306	    |                                           
+====================+|
307	    |                                           |Forwarding Strategy 
||
308	    |                                           
+====================+|
309	    |                                                                
  |
310	    |   1) Find name          2) Matching        3) Find matching    
  |
311	    |        in CS?              name in PIT?       entry in FIB?    
  |
312	    |                    NO                   NO                   
YES|
313	    |  +---------------+   +----------------+   
+-------------------+ |
314	    |  | Content Store |   |   Pending      |   |  Forwarding       
| |
315	   --->|      (CS)     |-->|   Interest     |-->|  Information Base 
|-->
316	    |  |               |   |   Table (PIT)  |   |     ( FIB)        
| |
317	    |  +---------------+   +----------------+   
+-------------------+ |
318	    | Return   | YES           YES | NO               NO |           
  |
319	    |  Data    |          Add      |   Add               |  Drop     
  |
320	    |          |          Incoming |   new               |   or      
  |
321	    |   <------|          Itf.     |   Interest          |  NACK     
  |
322	    |                              V                     V           
  |
323	    |                                                                
  |
324	    
+-----------------------------------------------------------------+

326	                     Figure 1: ICN forwarder structure

328	   Given the above forwarding properties for Interests, it should be
329	   clear that while an Interest is outstanding and ultimately 
arrives at
330	   a producer who can respond to it, there is sufficient state in 
the
331	   chain of forwarders to route not just a returning Data message, 
but
332	   potentially another Interest directed through the inverse path to 
the
333	   unique consumer who issued the original Interest.  (Section 8.1.3
334	   describes how Interest aggregation interacts with this scheme.)  
The
335	   key question therefore is how to access this state in a way that 
it
336	   can be used to forward Interests.

338	   In order to achieve this _Reflexive Interest_ forwarding on the
339	   inverse path recorded in the PIT of each forwarder, we need a few
340	   critical design elements.  These are as follows:

342	   1.  The Reflexive Interest needs to have a Name.  This name is 
what
343	       the originating consumer will use to match against the Data
344	       object (or objects - more on this later) it wishes the 
producer
345	       to fetch by issuing the Reflexive Interest.  This cannot be 
just
346	       any name, but needs to essentially name the state already
347	       recorded in the PIT and not allow the consumer to manufacture 
an
348	       arbitrary name and mount a reflection attack as pointed out 
in
349	       Section 1.2, Paragraph 2, Item 2.

351	   2.  There has to be a FIB entry at each forwarder for this name
352	       prefix so that when the reflexive interest arrives, the 
forwarder
353	       can forward it downstream toward the originating consumer.  
This
354	       FIB entry points directly to the incoming interface on which 
the
355	       corresponding original Interest arrived.  The FIB entry needs 
to
356	       be created as part of the forwarding of the original Interest 
so
357	       that it is available in time to catch any reflexive Interest
358	       issued by the producer.  It usually makes sense to destroy 
this
359	       FIB entry when the Data message satisfying the original 
Interest
360	       arrives since this avoids any dangling stale state.  Given 
the
361	       deign details documented later in this specification, stale 
FIB
362	       state does not represent a correctness hazard and hence can 
be
363	       done lazily if desired in an implementation.  See Section 5 
for
364	       more details on FIB operation considerations.

366	   3.  There has to be coupling of the state between the originating
367	       Interest-Data exchange and the enclosed Reflexive 
Interest-Data
368	       exchange at both the consumer and the producer.  In our 
design,
369	       this accomplished by the way reflexive interest names are 
chosen.

371	   The following sections provide the normative details on each of 
these
372	   design elements.  The overall interaction flow for reflexive
373	   forwarding is illustrated below in Figure 2.

375	   +-----------+    +-----------+                  +-----------+
376	   | Consumer  |    | Forwarder |                  | Producer  |
377	   +-----------+    +-----------+                  +-----------+
378	         |                |                              |
379	         | I1             |                              |
380	         |--------------->|                              |
381	         |--------------\ |                              |
382	         || Install RNP |-|                              |
383	         || in FIB      | |                              |
384	         ||-------------| |                              |
385	         |                |                              |
386	         |                | I1                           |
387	         |                |----------------------------->|
388	         |                |                              | 
-----------\
389	         |                |                              |-| Create  
  |
390	         |                |                              | | RI 
state |
391	         |                |                              | 
|----------|
392	         |                |                              |
393	         |                |                           RI |
394	         |                |<-----------------------------|
395	         |                | --------------------\        |
396	         |                |-| lookup RNP in FIB |        |
397	         |                | |-------------------|        |
398	         |                |                              |
399	         |             RI |                              |
400	         |<---------------|                              |
401	         |                |                              |
402	         | D2             |                              |
403	         |--------------->|                              |
404	         |                |                              |
405	         |                | D2                           |
406	         |                |----------------------------->|
407	         |                |                              | 
------------\
408	         |                |                              |-| answer 
I1 |
409	         |                |                              | 
|-----------|
410	         |                |                              |
411	         |                |                           D1 |
412	         |                |<-----------------------------|
413	         |                | -----------------------\     |
414	         |                |-| remove RNP FIB entry |     |
415	         |                | |----------------------|     |
416	         |                |                              |
417	         |             D1 |                              |
418	         |<---------------|                              |
419	         |                |                              |

421	       Legend:
422	       I1: Interest #1 containing the Reflexive Name Prefix TLV
423	       RI: Reflexive Interest with Reflexive Name Prefix Component
424	       RNP: Reflexive Name Prefix
425	       D1: Data message, answering initiating I1 Interest
426	       D2: Data message, answering RI

428	                      Figure 2: Message Flow Overview

430	4.  Naming of Reflexive Interests

432	   A consumer may have one or more objects for the producer to 
fetch,
433	   and therefore needs to communicate enough information in their
434	   initial Interest to allow the producer to construct properly 
formed
435	   reflexive Interest names.  For some applications the set of _full
436	   names_ (see [I-D.irtf-icnrg-terminology]) is known a priori, for
437	   example through compile time bindings of arguments in interface
438	   definitions or by the architectural definition of a simple sensor
439	   reading.  In other cases the full names of the individual objects
440	   must be communicated in the original Interest message.  In all 
cases
441	   enough state must be provided by the consumer for the forwarders 
to
442	   construct a FIB entry (as noted in Section 3, Paragraph 6, Item 
2).
443	   This is accomplished through the following naming construct.

445	   We define a new typed name component, identified by a registered 
name
446	   component type in the IANA registry for [RFC8569].  We call this 
the
447	   _Reflexive Interest Name Component type_. It MUST be the first 
(i.e.
448	   high order) name component of any Reflexive Interest issued by a
449	   producer.  Its value is a random 64 bit number, assigned by the
450	   consumer, which provides the entropy required to uniquely 
identify
451	   the issuing consumer for the duration of any outstanding 
Interest-
452	   Data exchange.  The consumer SHOULD choose a different random 
value
453	   for each Interest message it constructs, for two reasons:

455	   1.  If stale FIB sate is present, the randomness prevents 
potential
456	       mis-routing of reflexive interests (see Section 8.1.1 below 
for
457	       more details), and

459	   2.  Re-use of the same reflexive interest name over multiple
460	       interactions might reveal linkability information that could 
be
461	       used by surveillance adversaries for tracking purposes.

463	   This initial name component is either communicated by itself 
through
464	   a _Reflexive Name Prefix TLV_ in the originating Interest, or
465	   prepended to any object names the consumer wishes the producer to
466	   fetch explicitly where there is more than one object needed by 
the
467	   producer for the current Interest-Data interaction.  There are 
four
468	   cases to consider:

470	   1.  The reflexive _fullname_ of a single object to fetch.

472	   2.  A single reflexive name prefix out of which the producer can 
(by
473	       application-specific means) construct a number of _fullnames_ 
of
474	       the objects it may want to fetch,

476	   3.  The reflexive _fullname_ of a FLIC Manifest 
[I-D.irtf-icnrg-flic]
477	       enumerating the suffixes that may be used by the producer to
478	       construct the necessary names,

480	   4.  Multiple reflexive name TLVs MAY be included in the Interest
481	       message if none of the above 3 options covers the desired use
482	       case.

484	   The last of the four options above, while not explicitly 
outlawed,
485	   SHOULD NOT be used.  This is because it results in a longer 
Interest
486	   message and requires extra FIB resources.  Hence, it is more 
likely a
487	   forwarder will reject the Interest for lack of resources.  A
488	   forwarder MAY optimize for the case of a single Reflexive Name 
TLV at
489	   the expense of those with more than one.

491	   A producer, upon receiving an Interest with one or more Reflexive
492	   Name TLVs, may decide it needs the pull the associated data
493	   object(s).  It therefore can issue one or more Reflexive 
Interests by
494	   appending the necessary name components needed to form valid full
495	   names of the associated objects present at the originating 
consumer.
496	   These in fact comprise conventional Interest-Data exchanges, with 
no
497	   alteration of the usual semantics with regard to signatures, 
caching,
498	   expiration, etc.  When the producer has retrieved the required
499	   objects to complete the original Interest-Data exchange, it can 
issue
500	   its Data response, which unwinds all the established state at the
501	   producer, the consumer, and the intermediate forwarders.

503	5.  Forwarder operation for Reflexive Interests

505	   The forwarder operation for CCNx and/or NDN is changed in three
506	   respects when supporting Reflexive Interests.

508	   1.  The forwarder MUST create short-lifetime FIB entries for any
509	       Reflexive Interest Name prefixes communicated in an Interest
510	       message.  If the forwarder does not have sufficient resources 
to
511	       do so, it MUST reject the Interest with the 
T_RETURN_NO_RESOURCES
512	       error - the same error used if the forwarder were lacking
513	       sufficient PIT resources to process the Interest message.

515	   2.  Those FIB entries MUST be queried whenever an Interest 
message
516	       arrives whose first name component is of the type _Reflexive
517	       Interest Name Component_

519	   3.  The FIB entry MUST be removed eventually, after the 
corresponding
520	       Data message has been forwarded.  One option would be to 
remove
521	       the FIB directly after the Data message has been forwarded.
522	       However, the forwarder MAY do lazy cleanup.

524	   The PIT entry for the Reflexive Interest is consumed per regular
525	   Interest/Data message forwarding requirements.  The PIT entry for 
the
526	   originating Interest (that communicated the Reflexive Interest 
Name)
527	   is also consumed by a final Data message from the producer to the
528	   original consumer.

530	6.  State coupling between producer and consumer

532	   A consumer that wishes to use this scheme MUST utilize one of the
533	   reflexive naming options defined in Section 4 and include it in 
the
534	   corresponding Interest message.  The Reflexive Name TLV _and_ the
535	   full name of the requested data object (that identifies the 
producer)
536	   identify the common state shared by the consumer and the 
producer.
537	   When the producer responds by sending Interests with the 
Reflexive
538	   Name Prefix, the original consumer therefore has sufficient
539	   information to map these Interests to the ongoing Interest-Data
540	   exchange.

542	   The exchange is finished when the producer who received the 
original
543	   Interest message responds with a Data message (or an Interest 
Return
544	   message in the case of error) answering the original Interest.  
After
545	   sending this Data message, the producer SHOULD destroy the
546	   corresponding shared state.  It MAY decide to use a timer that 
will
547	   trigger a later state destruction.  After receiving this Data
548	   message, the originating consumer MUST destroy the corresponding
549	   Interest-Data exchange state.

551	7.  Use cases for Reflexive Interests

553	7.1.  Achieving Remote Method Invocation with Reflexive Interests

555	   RICE (Remote Method Invocation in ICN) [Krol2018] uses the 
Reflexive
556	   Interest Forwarding scheme that inspired the design specified in 
this
557	   document.

559	   In RICE, the original Interest denotes the remote method (plus
560	   potential parameters) to be invoked at a producer (server).  
Before
561	   committing any computating resources, the server can then request
562	   authentication credentials and (optional) parameters using 
reflexive
563	   Interest-Data exchanges.

565	   When the server has obtained the necessary credentials and input
566	   parameters, it can decide to commit computing resources, starts 
the
567	   compute process, and returns a handle ("Thunk") in the final Data
568	   message to the original consumer (client).

570	   The client would later request the computation results using a
571	   regular Interest-Data exchange (outside the Reflexive-Interest
572	   transaction) -- using the Thunk as a name for the computation 
result.

574	   Figure 3 depicts an abstract message diagram for RICE.  In 
addition
575	   to the 4-way Reflexive Forwarding Handshake (see Figure 2 for the
576	   details of the interaction), RICE adds another (standard) ICN
577	   Interest/Data exchange for transmitting the RMI result.  The 
Thunk
578	   name is provided to the consumer in the D1 DATA message 
(answering
579	   the initial I1 Interest).

581	   +-----------+              +-----------+
582	   | Consumer  |              | Producer  |
583	   +-----------+              +-----------+
584	         |                          |
585	         | I1                       |
586	         |------------------------->|
587	         |                          | ---------------------\
588	         |                          |-| Requesting request |
589	         |                          | | parameters         |
590	         |                          | | and credentials    |
591	         |                          | |--------------------|
592	         |                          |
593	         |                       RI |
594	         |<-------------------------|
595	         |                          |
596	         | D2                       |
597	         |------------------------->|
598	         |                          | --------------------\
599	         |                          |-| Commit compute    |
600	         |                          | | resources,        |
601	         |                          | | return Thunk name |
602	         |                          | |-------------------|
603	         |                          |
604	         |                       D1 |
605	         |<-------------------------|
606	         |                          | ----------------\
607	         |                          |-| Invoke Remote |
608	         |                          | | Method        |
609	         |                          | |---------------|
610	         | -------------------\     |
611	         |-| After some time, |     |
612	         | | request result   |     |
613	         | |------------------|     |
614	         |                          |
615	         | I3                       |
616	         |------------------------->|
617	         |                          |
618	         |                       D3 |
619	         |<-------------------------|
620	         |                          |
621	       Legend:
622	       I1: Interest #1 containing the Reflexive Name Prefix TLV
623	       D1: Data message, answering initiating I1 Interest,
624	           returning Thunk name
625	       D2: Data message, answering RI (parameters, credentials)
626	       I3: Regular Interest for Thunk (compute result)
627	       D3: Data message, answering I3
628	                        Figure 3: RICE Message Flow

630	7.2.  RESTful Web Interactions

632	   In todays HTTP-based web, RESTful (Representational State 
Transfer)
633	   web interactions are realized by sending requests in a 
client/server
634	   interaction, where the requests provides the application context 
(or
635	   a reference to it).  It has been noted in [Moiseenko2014] that
636	   corresponding requests often exceed the response messages in 
size,
637	   and that this raises the problems noted in Section 1.1 when
638	   attempting to map such exchanges directly to CCNx/NDN.

640	   Another reason not to include all request parameters in a 
(possibly
641	   encrypted) Interest message is the fact that a server (that is
642	   serving thousands of clients) would be obliged to receive, 
possibly
643	   decrypt and parse the complete requests before being able to
644	   determine whether the requestor is authorized, whether the 
request
645	   can be served etc.  Many non-trivial requests could thus lead to
646	   computational overload attacks.

648	   Using Reflexive Interest Forwarding for RESTful Web Interactions
649	   would encode the REST request in the Original request, together 
with
650	   a Reflexive Interest Prefix that the server could then use to get
651	   back to the client for authentication credentials and request
652	   parameters, such as cookies.  The request result (response 
message)
653	   could either be transmitted in the Data message answering the
654	   original request, or -- in case of dynamic, longer-running
655	   computations -- in a seperate Interest/Data exchange, potentially
656	   leveraging the Thunk scheme described in section Section 7.1.

658	   Unlike approaches where clients have to signal a globally 
routable
659	   prefix to the network, this approach would not require the client
660	   (original consumer) to expose its identity to the network (the
661	   network only sees the temporary Reflexive Name Prefix), but it 
would
662	   still be possible to authenticate the client at the server.

664	7.3.  Achieving simple data pull from consumers with reflexive 
Interests

666	   An oft-cited use case for ICN network architectures is _Internet 
of
667	   Things_ (IoT), where the sources of data are limited-resource 
sensor/
668	   actuators.  Many approaches have been tried (e.g.  
[Baccelli2014],
669	   [Lindgren2016], [Gundogan2018]) with varying degrees of success 
in
670	   addressing the issues outlined in Section 1.1.  The reflexive
671	   forwarding extension may substantially ameliorate the documented
672	   difficulties by allowing a different model for the basic 
interaction
673	   of sensors with the ICN network.

675	   Instead of acting as a producer (either directly to the Internet 
or
676	   indirectly through the use of some form of application-layer
677	   gateway), the IoT device need only act as a consumer.  When it 
has
678	   data to provide, it issues a "phone-home" Interest message to a 
pre-
679	   configured rendezvous name (e.g. an application-layer gateway or 
ICN
680	   Repo [Chen2015]) and provides a reflexive name prefix TLV for the
681	   data it wishes to publish.  The target producer may then issue 
the
682	   necessary reflexive Interest message(s) to fetch the data.  Once
683	   fetched, validated, and stored, the producer then responds to the
684	   original Interest message with a success indication, possibly
685	   containing a Data object if needed to allow the originating 
device to
686	   modify its internal state.  Alternatively, the producer might 
choose
687	   to not respond and allow the original Interest to time out, 
although
688	   this is NOT RECOMMENDED except in cases where the extra message
689	   transmission bandwith is at a premium compared to the persistence 
of
690	   stale state in the forwarders.  We note that this interaction
691	   approach mirrors the earlier efforts using Interest-Interest-Data
692	   designs.

694	   Figure 4 depicts this interaction with the OPTIONAL D1 message.  
See
695	   Figure 2 for the details of the general Reflexive Forwarding
696	   interaction.

698	                +-----------+ +-----------+
699	                | Consumer  | | Producer  |
700	                +-----------+ +-----------+
701	        ------------\ |             |
702	        | new IoT   |-|             |
703	        | data item | |             |
704	        | produced  | |             |
705	        |-----------| |             |
706	     ---------------\ |             |
707	     | "phone home" |-|             |
708	     | by notifying | |             |
709	     | producer     | |             |
710	     |--------------| |             |
711	                      |             |
712	                      | I1          |
713	                      |------------>|
714	                      |             | --------------------\
715	                      |             |-| generate Interest |
716	                      |             | | for IoT data      |
717	                      |             | |-------------------|
718	                      |             |
719	                      |          RI |
720	                      |<------------|
721	   -----------------\ |             |
722	   | send requested |-|             |
723	   | data object    | |             |
724	   |----------------| |             |
725	                      |             |
726	                      | D2          |
727	                      |------------>|
728	                      |             | -----------------------\
729	                      |             |-| finalize interaction |
730	                      |             | | with optional        |
731	                      |             | | Data message         |
732	                      |             | |----------------------|
733	                      |             |
734	                      |          D1 |
735	                      |<------------|
736	                      |             |
737	       Legend:
738	       I1: Interest #1 containing the Reflexive Name Prefix TLV
739	       D1: Data message (OPTIONAL), finalizing interaction
740	       D1: Data message, answering RI, returning IoT data object

742	                    Figure 4: "Phone Home" Message Flow

744	   There are two approaches that the IoT device can use for its 
response
745	   to a reflexive Interest.  It can simply construct a Data Message
746	   bound through the usual ICN hash name to the reflexive Interest 
name.
747	   Since the scope of any data object bound in this way is only the
748	   duration of the enclosing Interest-Data exchange (see Section 
8.2)
749	   the producer would need to itself construct any persistent Data
750	   object, name it, and sign it.  This is sometimes the right 
approach,
751	   as for some applications the identity of the originating IoT 
device
752	   is not important from an operational or security point of view; 
in
753	   contrast the identity of the gateway or Repo is what matters.

755	   If alternatively, the persistent Data object should be bound from 
a
756	   naming and security point of view to the originating IoT device, 
this
757	   can be easily accomplished.  Instead of directly placing the 
content
758	   in a Data object responding to the reflexive Interest as above, 
the
759	   consumer encapsulates a complete CCNx/NDN Data message (which
760	   includes the desired name of the data) as in the response to the
761	   reflexive Interest message.

763	   The interaction model described above brings a number potential
764	   advantages, some obvious, some less so.  We enumerate a few of 
them
765	   as follows:

767	   *  By not requiring the IoT device to be actively listening for
768	      Interests, it can sleep and only wake up if it has something 
to
769	      communicate.  Conversely, parties interested in obtaining data
770	      from the device do not need to be constantly polling in order 
to
771	      ascertain if there is new data available.

773	   *  No forwarder resources are tied up with state apart from the
774	      actual reflexive forwarding interactions.  All that is needed 
is
775	      enough routing state in the FIB to be able to forward the 
"phone
776	      home" Interest to an appropriate target producer.  While this
777	      model does not provide all the richness of a full Pub/Sub 
system
778	      (like that described in [Gundogan2018]) we argue it is 
adequate
779	      for a large subclass of such applications.

781	   *  The reflexive interest, through either a name suffix or 
Interest
782	      payload, can give the IoT device useful context from which to
783	      craft its Data object in response.  One highly useful 
parameter
784	      would be a robust clock value for the device to use as a 
timestamp
785	      of the data, possibly as part of its name to correctly place 
it in
786	      a time seres of sensor readings.  This substantially 
alleviates
787	      the need for low-end devices to have a robust time base, as 
long
788	      as they trust the producer they contact to provide it.

790	8.  Implementation Considerations

792	   There are a number of important aspects to the reflexive 
forwarding
793	   design which affect correctness and performance of existing
794	   forwarder, consumer, and producer implementations desiring to 
support
795	   it.  This section discusses the effect on each of these elements 
of
796	   the CCNx/NDN protocol architecture.

798	8.1.  Forwarder implementation considerations

800	8.1.1.  Forwarding Information Base (FIB)

802	   The FIB is a performance-critical data structure in any 
forwarder, as
803	   it needs to support relatively expensive longest name prefix 
match
804	   (LNPM) lookup algorithms.  A number of well-known FIB data 
structures
805	   are heavily optimized for read access, since for normal Interest
806	   message processing the FIB changes slowly - only after 
topological
807	   changes or routing protocol updates.  Support for reflexive names
808	   changes this, as FIB entries are created and destroyed rapidly as
809	   Interest messages containing reflexive name TLVs are processed 
and
810	   the corresponding Data messages come back.

812	   While it may be feasible, especially in low-end forwarders 
handling a
813	   low packet forwarding rate to ignore this problem, for high-speed
814	   forwarders there are a number of hazards, including:

816	   1.  If the entire FIB needs to be locked in order to insert or 
remove
817	       entries, this could cause inflated forwarding delays or in
818	       extreme cases, forwarding performance collapse.

820	   2.  A number of high-speed forwarder implementations employ a 
sharded
821	       PIT scheme to better parallelize forwarding across processing
822	       cores.  The FIB, however, is still a shared data structure 
which
823	       is either read without read locks across cores, or explicitly
824	       copied such that there is a separate copy of the FIB for each 
PIT
825	       shard.  Clearly, a high update rate without read locks and/or
826	       updating many copies of the FIB are unattractive 
implementation
827	       options.  (Note: with this reflexive name scheme it is not
828	       feasible to force reflexive interests to be hashed or be
829	       otherwise directed to the PIT shard holding the original 
Interest
830	       state).

832	   There are any number of alternative FIB implementations that can 
work
833	   well however.  The most straightforward is to simply implement a
834	   "special" FIB for just reflexive name lookups.  This is feasible
835	   because reflexive names deterministically contain the 
distinguished
836	   high-order name component type of T_REFLEXIVE_NAME, whose content 
is
837	   a 64-bit value that can be easily hashed to a FIB entry directly,
838	   avoiding the more expensive LNPM lookup.  Inserts and deletes 
then
839	   devolve to the well-understood problem of hash table maintenance.

841	8.1.2.  Interactions with Interest Lifetime

843	   If and when a producer decides to fetch data from the consumer 
using
844	   one or more reflexive Interest-Data exchanges, the total latency 
for
845	   the original Interest-Data exchange is inflated, potentially by
846	   multiple RTTs.  It is difficult for a consumer to predict the
847	   inflation factor when issuing the original Interest, and hence 
there
848	   can be a substantial hazard of that Interest lifetime expiring 
before
849	   completion of the full multi-way exchange.  This can result in
850	   persistent failures, which is obviously highly undesirable.

852	   There is a fairly straightforward technique that can be employed 
by
853	   forwarders to avoid these "false" Interest lifetime expirations.  
In
854	   the absence of a superior alternative technique, it is 
RECOMMENDED
855	   that all forwarders implement the following algorithm.

857	   When processing an Interest containing the reflexive name TLV and
858	   creating the necessary FIB entry (see Section 8.1.1 above), the
859	   forwarder also creates a _back pointer_ from that FIB entry to 
the
860	   PIT entry for the Interest message that created it.  This PIT 
entry
861	   contains the current value of the remaining Interest lifetime or
862	   alternatively a value from which the remaining Interest lifetime 
can
863	   be easily computed.  Call this value _IL_(t)_.

865	   If and when a reflexive Interest arrives from upstream matching 
the
866	   reflexive FIB entry, the forwarder examines the Interest lifetime 
of
867	   the arriving reflexive Interest.  Call this value _IL_(r)_. The
868	   forwarder computes MAX(_IL_(t), (IL_(r) * 1.5)_), and replaces
869	   _IL_(t)_ with this value.  This in effect ensures that the 
remaining
870	   Interest lifetime of the original Interest accounts for the
871	   additional 1.5 RTTs that may occur as a result of the reflexive
872	   Interest-Data exchange.

874	   If the above algorithm is implemented naively as described above, 
it
875	   may run afoul of a sharded PIT forwarder implementation, since 
the
876	   PIT entry for the reflexive Interest and the PIT entry for the
877	   original Interest may be in different shards.  Therefore, if the
878	   update is done cross-shard on each reflexive Interest arrival,
879	   performance may suffer, perhaps dramatically.  Instead, the 
following
880	   approach to updating the Interest lifetime after computing the 
new
881	   value is RECOMMMENDED for sharded-PIT forwarders.

883	   When creating the reflexive FIB entry as above in Section 8.1.1, 
copy
884	   the remaining Interest lifetime from the PIT entry.  Do the PIT
885	   update if and only if this value is about to expire, thus paying 
the
886	   cross-shard update cost only if the original Interest is about to
887	   expire.  A further optimization at the cost of modest extra
888	   complexity is to instead _queue_ the update to the core holding 
the
889	   shard of the original PIT entry rather than doing the update
890	   directly.  If the PIT entry expires or is satisfied, instead of
891	   removing it the associated core checks the update queue and does 
the
892	   necessary update.

894	   While the above approach of inflating the interest lifetime of 
the
895	   original Interest to accommodate the additional RTTs of reflexive
896	   Interest-Data exchanges, this does introduce a new vulnerability 
that
897	   must be dealt with.  A Producer, either through a bug or 
malicious
898	   intent, could keep an originating Interest-Data exchange alive by
899	   continuing to send reflexive Interests back to the consumer, 
while
900	   the consumer had no way to terminate the enclosing interaction 
(there
901	   is no "cancel Interest" function in either NDN nor CCNx).  To
902	   eliminate this hazard, if the consumer rejects a reflexive 
interest
903	   with a T_RETURN_PROHIBITED error, the forwarder(s), in addition 
to
904	   satisfying the coresponding PIT entry, MUST also delete the
905	   associated reflexive FIB entry, thereby preventing any further
906	   reflexive Interests from reaching the consumer.  This allows the
907	   enclosing Interest-Datsa exchange to either time out or be 
correctly
908	   ended with a Data message or Interest Return from the Producer.

910	8.1.3.  Interactions with Interest aggregation

912	   As with numerous other situations where multiple Interests for 
the
913	   same named object arrive containing different parameters (e.g.
914	   Interest Lifetime, QoS, payload hash) the same phenomenon occurs 
for
915	   the reflexive Name TLV.  If such Interests collide, the forwarder
916	   MUST NOT aggregate these Interest messages and instead MUST 
create a
917	   separate PIT entry for each.

919	8.2.  Consumer Implementation Considerations

921	8.2.1.  Data objects returned by the consumer to reflexive name
922	        Interests arriving from a producer

924	   The Data objects returned to the producer in response to a 
reflexive
925	   Interest are normal CCNx/NDN data objects.  It is therefore worth
926	   noting that the object is bound to the reflexive Interest full 
name
927	   via the hash and hence the scope of the object is under most
928	   circumstances meaningful only for the duration of the enclosing
929	   Interest-Data interaction.  This property is ideal for naming and
930	   securing data that is "part of" the enclosing interaction - 
things
931	   like method arguments, authenticators, and key exchange 
parameters,
932	   but not for the creation and naming of objects intended to 
survive
933	   outside the current interaction's scope (c.f.  Section 7.3, which
934	   describes how to provide globally-named objects using 
encapsulation).
935	   In general, the consumer should use the following guidelines in
936	   creating Data messages in response to reflexive Interest messages
937	   from the producer.

939	   (a)  Set the recommended cache time (T_CACHETIME) either to zero, 
or
940	        a value no greater than the Interest lifetime (T_INTLIFE) of 
the
941	        original Interest messsage.

943	   (b)  Set the payload type (T_PAYLDTYPE) according to the type of
944	        object being returned (e.g. object, link, manifest)

946	   (c)  Set the expiry time (T_EXPIRY) to a value greater than 
_now_,
947	        and less than or equal to the _now_ + Interest lifetime
948	        (T_INTLIFE) of the original Interest messsage.

950	8.2.2.  Terminating unwanted reflexive Interest exchanges

952	   A consumer may wish to stop receiving reflxive Interests due to
953	   possible erors or malicious behavior on the part of the producer.
954	   Therefore, if the consumer receives an unwanted reflexive 
Interest,
955	   it SHOULD reject that interest with a T_RETURN_PROHIBITED error.
956	   This will provoke the forwarders to prevent further reflexive
957	   Interests from reaching the consumer, as described above in
958	   Section 8.1.2, Paragraph 7.

960	8.2.3.  Interactions with caching

962	   The reflexive named objects provide "local", temporary names that 
are
963	   only defined for one specific interaction between a consumer and 
a
964	   producer.  Corresponding Data objects MUST NOT be shared between
965	   multiple consumers (violating this would require specail 
gyrations by
966	   the producer since the reflexive Name utilizes per-consumer/per-
967	   interaction random values).  A producer MUST NOT issue an 
Interest
968	   message for any reflexive name after it has sent the final Data
969	   message answering the original Interest.

971	   Forwarders SHOULD still cache reflexive Data objects for
972	   retransmissions within a transactions, but they MUST remove them 
from
973	   the content store when they forward the final Data message 
answering
974	   the original Interest.

976	8.3.  Producer Implementation Considerations

978	   Producers receiving an Interest with a Reflexive Name Component, 
MAY
979	   decide to issue Interests for the corresponding Data objects.  
All
980	   Reflexive Interest message that a producer sends MUST be sent 
over
981	   the face that the original Interest was received on.

983	9.  Operational Considerations

985	   This extension represents a substantial enhancement to the 
CCNx/NDN
986	   protocol architecture and hence has important forward and 
backward
987	   compatibility effects.  The most important of these is that 
correct
988	   operation of the scheme requires an unbroken chain of forwarders
989	   between the consumer and the desired producer that support the
990	   Reflexive Name TLV and the corresponding forwarder capabilities
991	   specified in Section 5.  When this invariant is not satisfied, 
some
992	   means is necessary to detect and hopefully recover from the 
error.
993	   We have identified three possible approaches to handling the lack 
of
994	   universal deployment of forwarders supporting the reflexive
995	   forwarding scheme.

997	   The first approach simply lets the producer detect the error by
998	   getting a "no route to destination" error when trying to send an
999	   Interest to a reflexive name.  This will catch the error, but 
only
1000	   after forwarding resources are tied up and the producer has done 
some
1001	   work on the original Interest message.  Further, the producer 
would
1002	   need a bit of smarts to determine that this is a permanent error 
and
1003	   not a transient to be retried.  In order for the consumer to 
attempt
1004	   recovery, there might be a need for some explicit error returned 
for
1005	   the original interest to tell the consumer what the likely 
problem
1006	   is.  This approach does not enable an obvious recovery path for 
the
1007	   consumer either, since while we might envision a way to steer a
1008	   subsequent Interest onto a working path as proposed in
1009	   [I-D.oran-icnrg-pathsteering], there is no capability to force
1010	   Interest routing away from an otherwise working path not 
supporting
1011	   the reflexive name TLV.

1013	   A second approach is to bump the CCNx/NDN protocol version to
1014	   explicitly indicate the lack of comparability.  Such Interests 
would
1015	   be rejected by forwarders not supporting this protocol 
extension.  A
1016	   consumer wishing to use the reflexive name TLV would use the 
higher
1017	   protocol version on those Interest messages (but could of course
1018	   continue to use the current version number on other Interest
1019	   messages).  This is a big hammer, but may be called for in this
1020	   situation because:

1022	   (a)  it detects the problem immediately and deterministically, 
and

1024	   (b)  one could assume an ICN routing protocol that would only 
forward
1025	        to a next hop that supports the updated protocol version 
number.
1026	        The supported forwarder protocol versions would have been
1027	        communicated in the routing protocol ahead of time.

1029	   A third option is to, as a precondition utilizing the protocol 
in a
1030	   deployment, create and deploy a neighbor capability exchange 
protocol
1031	   which will tell a downstream forwarder if the upstream can 
handle the
1032	   new TLV.  This might avoid the large hammer of updating the 
protocol
1033	   version, but of course this puts a pretty strong dependency on
1034	   somebody actually designing and publishing such a protocol!  On 
the
1035	   other hand, a neighbor capability exchange protocol for CCNx/NDN
1036	   would have a number of other substantial benefits, which makes 
it
1037	   worth seriously considering anyway.

1039	10.  Mapping to CCNx and NDN packet encodings

1041	10.1.  Packet encoding for CCNx

1043	   For CCNx[RFC8569] there is one new Name Component TLV type 
defined in
1044	   this specification.

1046	     
+------------------+----------------+--------------------------+
1047	     |      Abbrev      |      Name      |       Description        
|
1048	     
+==================+================+==========================+
1049	     | T_REFLEXIVE_NAME | Reflexive Name | Name component to use as 
|
1050	     |                  | Component      | name prefix in Reflexive 
|
1051	     |                  |                | Interest Message         
|
1052	     
+------------------+----------------+--------------------------+

1054	                       Table 1: Reflexive Name TLV

1056	10.2.  Packet encoding for NDN

1058	   TBD based on [NDNTLV].  Suggestions from the NDN team greatly
1059	   appreciated.

1061	11.  IANA Considerations

1063	   Please add the T_REFLEXIVE_NAME component TLV to the CCNx Name 
types
1064	   TLV types registry of [RFC8609], with Length 9 bytes and type of 
64
1065	   bit random integer.

1067	                        1                   2                   3
1068	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1069	   
+---------------+---------------+---------------+---------------+
1070	   |         T_REFLEXIVE_NAME      |               8               
|
1071	   
+---------------+---------------+---------------+---------------+
1072	   |                                                               
|
1073	   |       64bit Integer randomly assigned by consumer             
|
1074	   
+-------------------------------+-------------------------------+

1076	                  Figure 5: Reflexive Name component type

1078	12.  Security Considerations

1080	   One of the major motivations for the reflexive forwarding 
extension
1081	   specified in this document is in fact to enable better security 
and
1082	   privacy characteristics for ICN networks.  The main 
considerations
1083	   are presented in Section 1, but we briefly recapitulate them 
here:

1085	   *  Current approaches to authentication and data transfer often 
use
1086	      payloads in Interest messages, which are clumsy to secure
1087	      (Interest messages must be signed) and as a consequence make 
it
1088	      very difficult to ensure consumer privacy.  Reflexive 
forwarding
1089	      moves all sensitive data to the Data messages sent in 
response to
1090	      reflexive Interests, which are secured in the same manner as 
all
1091	      other Data messages in the CCNx and NDN protocol designs.

1093	   *  In many scenarios, consumers are forced to also act as 
producers
1094	      so that data may be fetched by either a particular, or 
arbitrary
1095	      other party.  The means the consumer must arrange to have a
1096	      routable name prefix and that prefix be disseminated by the
1097	      routing protocol or other means.  This represents both a 
privacy
1098	      hazard (by revealing possible important information about the
1099	      consumer) and a security concern as it opens up the consumer 
to
1100	      the full panoply of flooding and crafted Interest denial of
1101	      service attacks.

1103	   *  In order to achieve multi-way handshakes, in current designs 
a
1104	      consumer wishing a producer to communicate back must inform 
the
1105	      producer of what (globally routable) name to use.  This gives 
the
1106	      consumer a convenient means to mount a variety of reflection
1107	      attacks by enlisting the producer to send Interests to 
desired
1108	      victims.

1110	   As a major protocol extension however, this design brings its 
own
1111	   potential security issues, which are discussed in the following
1112	   subsections.

1114	12.1.  Collisions of reflexive Interest names

1116	   Reflexive Interest names are constructed using 64-bit random 
numbers.
1117	   This is intended to ensure an off-path attacker cannot easily
1118	   manufacture a matching reflexive Interest and either masquerade 
as
1119	   the producer, or mount a denial of service attack on the 
consumer.
1120	   It also limits tracking through the linkability of Interests
1121	   containing a re-used random value.

1123	   Therefore consumers MUST utilize a robust means of generating 
these
1124	   random values, and it is RECOMMENDED that a pseudo-random number
1125	   generator (PRNG) approved for use with cryptographic protocols 
be
1126	   employed.

1128	12.2.  Additional resource pressure on PIT and FIB

1130	   Normal Interest message processing in CCNx and NDN needs to 
consider
1131	   effect of various resource depletion attacks on the PIT, 
particularly
1132	   in the form of Interest flooding attacks (see [Gasti2012] for a 
good
1133	   overview of DoS and DDoS mitigation on ICN networks).  Interest
1134	   messages utilizing this reflexive forwarding extension can place
1135	   additional resource pressure on the PIT, and additionally cause
1136	   otherwise stable FIB resources to be subject to highly dynamic 
usage.

1138	   While this does not represent a new DoS/DDoS attack vector, the
1139	   ability of a malicious consumer to utilize this extension in an
1140	   attack does represent an increased risk of resource depletion,
1141	   especially if such Interests are given unfair access to PIT and 
FIB
1142	   resources.  Implementers SHOULD therefore protect PIT and FIB
1143	   resources by weighing requests for reflexive forwarding 
resources
1144	   appropriately relative to other Interests.

1146	12.3.  Privacy Considerations

1148	   ICN architectures like CCNx and NDN provide a rich tapestry of
1149	   interesting privacy issues, which have been extensively explored 
in
1150	   the research literature.  The fundamental tradeoffs for privacy
1151	   concern the risk of exposing the names of information objects to 
the
1152	   forwarding elements of the network, which is a necessary 
property of
1153	   any name-based routing and forwarding design.  Numerous 
approaches
1154	   have been explored with varying degrees of success, such as 
onion
1155	   routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), and 
name
1156	   obfuscation ([Arianfar2011]) among others.

1158	   Reflexive forwarding does not change the overall landscape of 
privacy
1159	   tradeoffs, nor seem to introduce additional hazards.  In fact, 
the
1160	   privacy exposures are confined to the inverse path of forwarders 
from
1161	   the producer to the consumer, through which the original 
Interest
1162	   forwarding may have already exposed names on path.  Similar name
1163	   privacy techniques to those cited above may be equally applied 
to the
1164	   names in reflexive Interests.

1166	   While the individual reflexive Interest-Data exchanges have 
similar
1167	   properties to those in any NDN or CCNx exchange, the target 
usages by
1168	   applications may have interaction patterns that are subject to
1169	   relatively straightforward fingerprinting by adversaries.  For
1170	   example, a particular RMI invocation may fingerprint simply 
through
1171	   the count of arguments fetched by the producer and their sizes.  
The
1172	   attacker must however be on path, which somewhat ameliorates the
1173	   exposure hazards.

1175	13.  Normative References

1177	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1178	              Requirement Levels", BCP 14, RFC 2119,
1179	              DOI 10.17487/RFC2119, March 1997,
1180	              <https://www.rfc-editor.org/info/rfc2119>.

1182	   [RFC8569]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
1183	              Networking (CCNx) Semantics", RFC 8569,
1184	              DOI 10.17487/RFC8569, July 2019,
1185	              <https://www.rfc-editor.org/info/rfc8569>.

1187	   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
1188	              Networking (CCNx) Messages in TLV Format", RFC 8609,
1189	              DOI 10.17487/RFC8609, July 2019,
1190	              <https://www.rfc-editor.org/info/rfc8609>.

1192	14.  Informative References

1194	   [Arianfar2011]
1195	              Arianfar, S., Koponen, T., Raghavan, B., and S. 
Shenker,
1196	              "On preserving privacy in content-oriented networks, 
in
1197	              ICN '11: Proceedings of the ACM SIGCOMM workshop on
1198	              Information-centric networking",
1199	              DOI https://doi.org/10.1145/2018584.2018589, August 
2011,
1200	              <https://dl.acm.org/doi/10.1145/2018584.2018589>.

1202	   [Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, 
L.,
1203	              Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less
1204	              Producer Mobility in Content-Centric Networks, in 
IEEE
1205	              Transactions on Network, Volume 15, Issue 2",
1206	              DOI 10.1109/TNSM.2018.2796720, June 2018,
1207	              <https://ieeexplore.ieee.org/document/8267132>.

1209	   [Baccelli2014]
1210	              Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and 
M.
1211	              Wählisch, "Information centric networking in the 
IoT:
1212	              experiments with NDN in the wild, in ACM-ICN '14:
1213	              Proceedings of the 1st ACM Conference on Information-
1214	              Centric Networking", DOI 10.1145/2660129.2660144,
1215	              September 2014,
1216	              <https://dl.acm.org/doi/abs/10.1145/2660129.2660144>.

1218	   [Carzaniga2011]
1219	              Carzaniga, A., Papalini, M., and A.L. Wolf, 
"Content-Based
1220	              Publish/Subscribe Networking and Information-Centric
1221	              Networking", DOI 10.1145/2018584.2018599, September 
2011,
1222	              
<https://conferences.sigcomm.org/sigcomm/2011/papers/icn/
1223	              p56.pdf>.

1225	   [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data 
Storage
1226	              System, in International Conference on Cloud and 
Autonomic
1227	              Computing", DOI 10.1109/ICCAC.2015.12, September 
2014,
1228	              <https://ieeexplore.ieee.org/document/7312154>.

1230	   [DiBenedettoGTU12]
1231	              DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun,
1232	              "ANDaNA: Anonymous Named Data Networking Application, 
in
1233	              NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2, 
2102,
1234	              
<https://www.ndss-symposium.org/ndss2012/andana-anonymous-
1235	              named-data-networking-application>.

1237	   [Gasti2012]
1238	              Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang, 
"DoS
1239	              and DDoS in Named Data Networking, in 22nd 
International
1240	              Conference on Computer Communication and Networks
1241	              (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August 
2013,
1242	              <https://ieeexplore.ieee.org/document/6614127>.

1244	   [Ghali2017]
1245	              Tsudik, G., Ghali, C., and C. Wood, "When encryption 
is
1246	              not enough: privacy attacks in content-centric 
networking,
1247	              in ICN '17: Proceedings of the 4th ACM Conference on
1248	              Information-Centric Networking",
1249	              DOI https://doi.org/10.1145/3125719.3125723, 
September
1250	              2017,
1251	              <https://dl.acm.org/doi/abs/10.1145/3125719.3125723>.

1253	   [Gundogan2018]
1254	              Gündoğan, C., Kietzmann, P., Schmidt, T., and M. 
Wählisch,
1255	              "HoPP: publish-subscribe for the constrained IoT, in 
ICN
1256	              '18: Proceedings of the 5th ACM Conference on 
Information-
1257	              Centric Networking", DOI 10.1145/3267955.3269020,
1258	              September 2018,
1259	              <https://dl.acm.org/doi/abs/10.1145/3267955.3269020>.

1261	   [I-D.irtf-icnrg-flic]
1262	              Tschudin, C., Wood, C., Mosko, M., and D. Oran, 
"File-Like
1263	              ICN Collections (FLIC)", Work in Progress, 
Internet-Draft,
1264	              draft-irtf-icnrg-flic-02, 4 November 2019,
1265	              
<https://tools.ietf.org/html/draft-irtf-icnrg-flic-02>.

1267	   [I-D.irtf-icnrg-terminology]
1268	              Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., 
Oran,
1269	              D., and C. Tschudin, "Information-Centric Networking
1270	              (ICN): CCNx and NDN Terminology", Work in Progress,
1271	              Internet-Draft, draft-irtf-icnrg-terminology-08, 17
1272	              January 2020, 
<https://tools.ietf.org/html/draft-irtf-
1273	              icnrg-terminology-08>.

1275	   [I-D.oran-icnrg-pathsteering]
1276	              Moiseenko, I. and D. Oran, "Path Steering in CCNx and
1277	              NDN", Work in Progress, Internet-Draft, 
draft-oran-icnrg-
1278	              pathsteering-00, 21 October 2019,
1279	              <https://tools.ietf.org/html/draft-oran-icnrg-
1280	              pathsteering-00>.

1282	   [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I.
1283	              Psaras, "RICE: Remote Method Invocation in ICN, in
1284	              Proceedings of the 5th ACM Conference on Information-
1285	              Centric Networking - ICN '18",
1286	              DOI 10.1145/3267955.3267956, September 2018,
1287	              
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/
1288	              icn18-final9.pdf>.

1290	   [Lindgren2016]
1291	              Lindgren, A., Ben Abdessiem, F., Ahlgren, B., 
Schlelén,
1292	              O., and A.M. Malik, "Design choices for the IoT in
1293	              Information-Centric Networks, in 13th IEEE Annual 
Consumer
1294	              Communications and Networking Conference (CCNC)",
1295	              DOI 10.1109/CCNC.2016.7444905, January 2016,
1296	              
<https://ieeexplore.ieee.org/abstract/document/7444905>.

1298	   [Moiseenko2014]
1299	              Moiseenko, I., Stapp, M., and D. Oran, "Communication
1300	              patterns for web interaction in named data 
networking",
1301	              DOI 10.1145/2660129.2660152, September 2014,
1302	              <https://dl.acm.org/doi/10.1145/2660129.2660152>.

1304	   [Mosko2017]
1305	              Mosko, M., "CCNx 1.0 Bidirectional Streams",
1306	              arXiv 1707.04738, July 2017,
1307	              <https://arxiv.org/abs/1707.04738>.

1309	   [NDN]      "Named Data Networking", 2020,
1310	              <https://named-data.net/project/execsummary/>.

1312	   [NDNTLV]   "NDN Packet Format Specification", 2016,
1313	              <http://named-data.net/doc/ndn-tlv/>.

1315	   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., 
Johnston,
1316	              A., Peterson, J., Sparks, R., Handley, M., and E.
1317	              Schooler, "SIP: Session Initiation Protocol", RFC 
3261,
1318	              DOI 10.17487/RFC3261, June 2002,
1319	              <https://www.rfc-editor.org/info/rfc3261>.

1321	   [RFC6337]  Okumura, S., Sawada, T., and P. Kyzivat, "Session
1322	              Initiation Protocol (SIP) Usage of the Offer/Answer
1323	              Model", RFC 6337, DOI 10.17487/RFC6337, August 2011,
1324	              <https://www.rfc-editor.org/info/rfc6337>.

1326	   [RFC7530]  Haynes, T., Ed. and D. Noveck, Ed., "Network File 
System
1327	              (NFS) Version 4 Protocol", RFC 7530, DOI 
10.17487/RFC7530,
1328	              March 2015, 
<https://www.rfc-editor.org/info/rfc7530>.

1330	   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) 
Protocol
1331	              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 
2018,
1332	              <https://www.rfc-editor.org/info/rfc8446>.

1334	   [Zhang2018]
1335	              Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, 
"KITE:
1336	              Producer Mobility Support in Named Data Networking, 
in
1337	              Proceedings of the 5th ACM Conference on Information-
1338	              Centric Networking - ICN '18",
1339	              DOI 10.1145/3267955.3267959, September 2018,
1340	              
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/
1341	              icn18-final23.pdf>.

1343	Authors' Addresses

1345	   Dave Oran
1346	   Network Systems Research and Design
1347	   4 Shady Hill Square
1348	   Cambridge, MA 02138
1349	   United States of America

1351	   Email: [e-mail]

1353	   Dirk Kutscher
1354	   University of Applied Sciences Emden/Leer
1355	   Constantiapl. 4
1356	   26723 Emden
1357	   Germany

1359	   Email: [e-mail]
1360	   URI:   https://dirk-kutscher.info










DaveO