Re: [xml2rfc] Some problems with idnits checks on V3 document
"David R. Oran" <daveoran@orandom.net> Thu, 02 April 2020 14:00 UTC
Return-Path: <daveoran@orandom.net>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121C03A12EA for <xml2rfc@ietfa.amsl.com>; Thu, 2 Apr 2020 07:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zdPM2gxz5fh for <xml2rfc@ietfa.amsl.com>; Thu, 2 Apr 2020 07:00:03 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8607C3A12F5 for <xml2rfc@ietf.org>; Thu, 2 Apr 2020 06:59:58 -0700 (PDT)
Received: from [192.168.15.102] ([IPv6:2601:184:407f:80ce:c105:8cce:5bc6:3a67]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 032Dxm7P008125 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2020 06:59:50 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: Henrik Levkowetz <henrik@levkowetz.com>
Cc: xml2rfc@ietf.org
Date: Thu, 02 Apr 2020 09:59:42 -0400
X-Mailer: MailMate (1.13.1r5680)
Message-ID: <0F30FE8F-15D8-410B-9615-0FE9615148FA@orandom.net>
In-Reply-To: <b6272617-e32a-9e22-8099-0f144605b180@levkowetz.com>
References: <F8AD51EB-6957-4C87-8701-ECB160FC6615@orandom.net> <b6272617-e32a-9e22-8099-0f144605b180@levkowetz.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_CEA6EA1B-A29A-455E-AFB3-5FC5B40E6AB8_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/0Gla6PPs14ypacPb4plfV0n5YJs>
Subject: Re: [xml2rfc] Some problems with idnits checks on V3 document
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 14:00:10 -0000
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. >> - 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. >> 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. > > 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: daveoran@orandom.net >> >> 1353 Dirk Kutscher >> 1354 University of Applied Sciences Emden/Leer >> 1355 Constantiapl. 4 >> 1356 26723 Emden >> 1357 Germany >> >> 1359 Email: ietf@dkutscher.net >> 1360 URI: https://dirk-kutscher.info >> >> >> >> >> >> >> >> >> >> >> DaveO >> >> >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> DaveO
- [xml2rfc] Some problems with idnits checks on V3 … David R. Oran
- Re: [xml2rfc] Some problems with idnits checks on… David R. Oran
- Re: [xml2rfc] Some problems with idnits checks on… Henrik Levkowetz
- Re: [xml2rfc] Some problems with idnits checks on… Henrik Levkowetz