Re: [xml2rfc] Some problems with idnits checks on V3 document

[Henrik Levkowetz <[e-mail]>]

Hi Dave,

On 2020-04-02 15:59, David R. Oran wrote:
> On 2 Apr 2020, at 9:53, Henrik Levkowetz wrote:
> 
>> Hi Dave,
>>
>> On 2020-03-31 15:58, David R. Oran wrote:
>>> 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?)
>>
>> Yes, that's right.  Will see what can be done.
>>
>>> - 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?
>>
>> Will investigate, and if possible provide a fix in the next release,
>> due tomorrow.
>>
> I looked more carefully and this is because the author address is so
> long it looks like it’s only one character away from the status, and
> hence is parsed as part of that. Probably need to figure out how to
> split long right-justified lines that over-run to the left.

Ack on that.  I've adjusted idnits; will do a new release shortly.

>>> - 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?
>>
>> Huh.  I'll check the code.
>>
> On further investigation, I think this is a boggie due to the
> intended status getting defaulted to Proposed Standard when
> incorrectly parse above.

Ah.  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)
>>
>> Understood.
>>
>>> Let me know of any followup I should do - would like to get this
>>> submitted in the next couple of days.
>>
>> Ack.  Will follow up when I have more information.
>>
> Many thanks!
> I decided to try to submit anyway and am now being done in by “Failed
> decoding the uploaded file: "'ascii' codec can't decode byte 0xc3 in
> position 69240: ordinal not in range(128)"
> 
> Time to go count characters in the .txt file. Sigh.

Saw your other post on this, good that the workaround worked.


Best,

	Henrik
> 
> 
>>
>> Best regards,
>>
>> 	Henrik
>>
>>
>>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> xml2rfc mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>>
> 
> DaveO
>