1. Just Say No: Authenticated Denial for ICN Copyright (c) 2015 by Cisco Systems Inc.1 Mark Stapp, Cisco ICNRG meeting at IETF 92, Dallas, 3/2015

2. ICN without Denial Interest Name: /example/x/w/c/a [Time passes...] [ ] Copyright (c) 2015 by Cisco Systems Inc.2

3. Motivation Just dropping Interests doesn’t seem like much of a solution – Not helpful to applications – No opportunity for routers to clean up their PITs, which may represent a DOS vector A naive approach: – Interest for non-existent name arrives at a producer – Producer creates some TBD message using that name, and signs it – TBD message returns to client along reverse path Don't expect producers to sign client-supplied input on demand – c.f. recent Compagno, Conti, Ghali, Tsudik analysis Improved, explicit signalling in ddos situations – Only the focus/target of an attack actually aware of it – Distribute information to improve network-wide response (a la DOTS) Copyright (c) 2015 by Cisco Systems Inc.3

4. Objectives Examine a number of approaches, try to gauge suitability Understand cost at 'producer' – Reduce per-request load Understand cost at router – Distributing work may be beneficial overall – up to a point Different types of content – Static data publication – Dynamic, 'real-time' publication Expose or hide names? – Has been raised as an issue for DNSSEC Assess security risks – Avoid introducing new problems Still very much work-in-progress Copyright (c) 2015 by Cisco Systems Inc.4

5. Simple Denial for ICN Interest Name: /example/x/w/c/a Nak: No Such Name Name: /example/x/w/c/a NakSignedContext: NameGapStart: /example/x/w NameGapEnd: /example/x/w/d SignedInfo: Algo,KeyName,Timestamp,Expiration Digest(NakSignedContext|SignedInfo) SignatureBits: S(Digest) Copyright (c) 2015 by Cisco Systems Inc.5

6. What’s a “Name Gap”? /example/x/w /example/x/w/d /example/x/w/e /example/z/a /example/z/b /example/z/b/c Copyright (c) 2015 by Cisco Systems Inc.6 } Name Gap

7. ICN Simple Denial The NakSignedContext signs a gap in the sorted producer namespace – There are some interesting issues at various sorts of prefix boundaries The producer can generate the NakSignedContext in advance – And maintain the NakContexts as it adds and removes actual object names The NakContext is cacheable – If it only represents a single gap, usefulness is limited Cache would have to maintain some suitable data structure for negative cache Copyright (c) 2015 by Cisco Systems Inc.7

8. Hashed “Name Gap” /example/x/w /example/x/w/d /example/x/w/e /example/z/a /example/z/b /example/z/b/c Copyright (c) 2015 by Cisco Systems Inc.8 } Name Gap /example/H1 /example/H2 /example/H3 /example/H4 /example/H5 /example/H6 /example/H3 /example/H1 /example/H5 /example/H2 /example/H6 /example/H4 HashedSorted The sorted hashed names – Don’t reveal much about the actual names – Can be pre-computed – Per-pair salt to raise cost of dictionary attack (?) If the hash of an Interest’s name falls into a “gap”, the name isn’t present

9. ICN Hashed Name Denial The NakSignedContext signs a gap in the hashed version of the producer namespace The NakContext is still cacheable – If it only represents a single hash gap, usefulness is limited – Actual-name gap may be more useful Cache would have to maintain a suitable data structure for negative cache – LPM less obviously useful without additional info Could be enhanced to include a record for the “closest encloser,” a la DNSSEC – Improving usefulness of negative cache The producer is obliged to hash the Interest name field – And maintain some data struct to help it find the corresponding namespace gap – But not do any public-key crypto on it Copyright (c) 2015 by Cisco Systems Inc.9

10. Hashed Denial for ICN Interest Name: /example/x/w/c/a Nak: No Such Name Name: /example/x/w/c/a NakSignedContext: NameGapStart: H1 NameGapEnd: H5 NameGapSalt: S1 SignedInfo: Algo,KeyName,Timestamp,Expiration Digest(NakSignedContext|SignedInfo) SignatureBits: S(Digest) Copyright (c) 2015 by Cisco Systems Inc.10

11. Client-supplied Name Hash Servers/producers may not want to be obliged to compute hashes If client wants proveable denial, it computes and includes a hash for producer’s use – Using whatever H algorithm is specified/standard – Not clear how to transmit salt value, however Server may just drop instead of performing hash itself, or may Nak without including proof Malicious client could supply bogus hash – But result would just be a denial for some other, unrelated name – If client-supplied hash isn’t in a gap --> drop Copyright (c) 2015 by Cisco Systems Inc.11

12. Hashed Denial with Client-Supplied Hash Interest Name: /example/x/w/c/a NameHash: H(/example/x/w/c/a) Nak: No Such Name Name: /example/x/w/c/a NakSignedContext: [...] Copyright (c) 2015 by Cisco Systems Inc.12

13. Things We can do with Hashes The thing about hashes is that they're uncorrelated to the "real", hierarchical namespace But we can use hashes to make assertions about "subtrees" – The only 3-component names are Hx and Hy – No names with >5 components exist below Hx – These may remain valid even with dynamic changes in some parts of the producer's namespace Copyright (c) 2015 by Cisco Systems Inc.13

14. Manifest-based Denial Could manifests have a role in denial? – We’d like them to be distinguished, cacheable Name-hiding may be less important in ICN Subtle shift from “these are some names” to “these are the only names” – Implicitly provides denial along with the catalog – Add meta-data marker for terminal/childless names (“there are no children below this point”) – Add meta-data marker for comprehensive list of children (“there are no other children below this point”) Copyright (c) 2015 by Cisco Systems Inc.14

15. Manifest Example <!–- Establish a ‘base name’ for a series of children. All of the children share the base, and any associated properties such as hash algorithm or signature parameters. --> <!–- Indicates that this block contains the complete set of names below the 'basename', possibly recursively. We'd expect that these child names would be self-certifying. --> [...] Copyright (c) 2015 by Cisco Systems Inc.15

16. Dedicated Denial Manifest If name-hiding is important Combine the virtual namespace and manifest concepts – Create hashed version of the namespace – Construct a manifest using the hashed names Exposes little about the actual namespace Producer could return name of denial manifest in NAK message Cached denial manifest provides negative cache for an entire section of namespace – Rather than just a single gap in the ‘simple’ approach – Combine with “closest encloser” concept to support prefix- level denial Limited to fewer salt values Copyright (c) 2015 by Cisco Systems Inc.16

17. Denial Manifest Example <!–- Manifest contains hashed names, not actual (routeable, etc.) names. Given the hash parameters, a client/cache can hash a target name and determine whether it falls into a gap in the hashed version of the namespace. --> <!–- Hashed version of actual names, sorted, and/or references to child manifests --> [...] Copyright (c) 2015 by Cisco Systems Inc.17

18. Caching Denial Information Are denial-of-existence messages different from 'real' data? – Expose new security risks? – Need short/fixed cache lifetimes? How to use cached information efficiently – E.g. to resist dDOS – High value in prefix-level or 'encloser' information, to resist random name suffixes – Routers may need dedicated LPM-oriented data structures Copyright (c) 2015 by Cisco Systems Inc.18

19. Next Steps and Questions Is denial necessary, or should producers just drop? – Can we at least agree that on-demand signed denial is a non-starter? Is "simple" gap-based denial adequate (for static content)? Do there need to be special solutions for dynamic content? Can denial information be cached? – If so, what risks are involved? What data structures are effective for producers, routers? Is name-hiding important? What do manifests look like? – And what is their role? Copyright (c) 2015 by Cisco Systems Inc.19