Re: [icnrg] RG Last call on the NRS documents

["Pouyan Fotouhi Tehrani" <[e-mail]>]

Hi everyone,

here is my (late) review for

[1] Architectural Considerations of ICN using Name Resolution Service
(draft-irtf-icnrg-nrsarch-considerations-02)
[2] Design Guidelines for Name Resolution Service in ICN
(draft-irtf-icnrg-nrs-requirements-02)

*Disclaimer*: we have recently published a paper on namespace management
in ICN (The Missing Piece: On Namespace Management in NDN and How DNSSEC
Might Help / ACM ICN '19) [3] which elaborates and addresses a number of
following points in detail.

Terminology:
- namespace/name space:
It is not clear what a namespace exactly refers to, is it an
administrative entity? or set of all possible names in an ICN instance?
Respectively, its use in plural (possibly referring to various naming
schemes), e.g., "resolve names between different name spaces" [S 5.2.,
1] or "ICN name spaces are separated into more than two name spaces" [S
6., 2], is somehow confusing. An example would be helpful.

- resolution/binding/mapping:
It seems that these terms are used interchangeably throughout the
documents without further distinction. A formal definition, e.g., as a
binary functional relation, could help to clarify the concept and also
benefit the future implementation. Surely, it is also necessary to
explicitly separate bindings from the resolution process.

- There is a single reference to "authoritative NRS server" [S 2., 1]
without describing it in detail. As the term "authoritative name server"
has already a well-defined meaning in DNS context, it would be really
helpful to highlight the similarities and distinctions.

Management scope:
- It is not clear if or how name resolution is divided between
authoritative NRS servers. Is the namespace divided into smaller
management units (similar to DNS zones) which are controlled by
authoritative names servers or are the servers authoritative as they are
authorized to take part in NRS?

- Who is allowed to operate an authoritative name server? Can anyone
register any arbitrary domain? These may be policy questions and out of
the technical scope, yet integral for global deployment of ICN.

- Is an authoritative name server responsible only for a subset of
global namespace? If yes, how can be define this subset for flat names,
e.g., hashes as names, without enumerating all member names? At the same
time, how can be map a given name to its authoritative name server?

- How is the "global ICN network domain" [S 5.2., 1] managed? Is there a
(logically) centralized entity responsible for management of the global
domain? How can we recognize and address possible conflicting bindings
between different local/global domains?

- If NRS is to operate on a global scale, it is imperative to have a
logically centralized architecture which can be realized in a
distributed manner (similar to DNS).

Use cases:
-  Use cases of NRS in ICN is elaborated in [S 4.1., 2]. A possible
missing use case is the producer authentication: given a name, it should
be possible to verify if the publisher, identified by its digital
credentials, is authorized to publish NDOs under that name or not.


Security:
- Bindings which cannot be authenticated are useless [S 7. 1], [S 6.,
2]. If so, maybe we should also discuss adequate means to
establish trust required for binding authentication.

- A trust model should be defined to show how a consumer, for
example, can verify the authenticity of bindings provided by NRS or
detect a bogus binding spoofed by a malicious ICN node.

- Deploying NRS on a global ICN domain implies a logically centralized
trust model (similar to DNS). There are, however, strong opinions in the
community regarding advantageous and disadvantageous of such "single
rooted" trust anchors (cf. trust schemata in NDN). Experiences from the
previous 30 years of DNS can guide us on deciding an appropriate trust
model.

- Regardless of selected trust model for NRS, its implications for
consumers and general performance sacrifices on the network should be
argued.

I'm looking forward for your feedback.

Kind regards,

Pouyan Fotouhi Tehrani

[3] Tehrani, P. F., Osterweil, E., Schiller, J., Schmidt, T. C., and
Wählisch, M. "The Missing Piece: On Namespace Management in NDN and How
DNSSEC Might Help." In Proc. of 6th ACM ICN (2019), ACM.


> <Chair Hat ON>
>
> Folks, we have not received the necessary reviews we need to finish last
> call on:
>
> https://datatracker.ietf.org/doc/draft-irtf-icnrg-nrsarch-considerations/
> and
> https://datatracker.ietf.org/doc/draft-irtf-icnrg-nrs-requirements/
>
> Please get these done, as Last Call officially ended last week. We
> can’t advance these important documents without substantially more
> review.
>
> Thanks!
>
> DaveO
>