Network Working Group P. M. Hallam-Baker Internet-Draft ThresholdSecrets.com Intended status: Informational 13 January 2021 Expires: 17 July 2021 Mathematical Mesh 3.0 Part VI: Mesh Discovery Service draft-hallambaker-mesh-discovery-01 Abstract A naming service for the Mathematical Mesh is described. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 July 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Hallam-Baker Expires 17 July 2021 [Page 1] Internet-Draft Mesh Discovery Service January 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Name Registry . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Name Entries . . . . . . . . . . . . . . . . . . . . 4 3.2. Name syntax . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Name Assignment . . . . . . . . . . . . . . . . . . . . . 5 4. Business Model . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Names do not expire . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 9. Informative References . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Mesh Discovery Service allows Mesh users to change Mesh Service Providers without the switching costs associated with usual naming schemes. The Mesh Discovery System is distinct from the DNS in several important respects: * Mesh Names are intended to be the personal property of the assignee and use of the name MUST NOT require payment of ongoing rents, fees etc. of any kind. * The DNS combines the functions of name delegation and discovery of services provided under those names into a single protocol. The MNS only supports name delegation. The limitation on scope allows MDS to provide all the functionality of a traditional DNS TLD with almost none of the costs. While the DNS functionality exposed by a DNS TLD is limited to information that changes very rarely (i.e. discovery of the IP addresses of the authoritative DNS servers), the protocol used to deliver that functionality is designed to support real time publication of service configurations. Hallam-Baker Expires 17 July 2021 [Page 2] Internet-Draft Mesh Discovery Service January 2021 Another costly aspect of the DNS design is that there is no mechanism for invalidation of cached data. Instead every record has a predetermined expiry time and TLDs advise relying parties of updates to DNS records by publishing a new record. As a result, the vast bulk of (valid) TLD traffic consists of requests to check if the information has changed since the last time the party making the request checked. This approach makes the DNS infrastructure vulnerable to Denial of Service attack. If the DNS were ever to suffer a prolonged outage, the cached records would expire and the Internet would cease functioning. The MNS Name Registry is an append only log containing a complete history of every change made. Every registry update is authenticated by means of a Merkle Tree, the apex of which is signed once a minute. The Name Registry does not respond to discovery queries. Instead, every Mesh Service Provider is required to maintain a 'reasonably current' copy of the MNS Name Registry log and use this to respond to queries from the community it serves. This approach eliminates the almost all the costs associated with a DNS TLD registry and provides a 'fail safe' approach to design. Should the Name Service cease functioning for days or even weeks, only the ability to publish updates to existing configurations would be lost. Requirements for Mesh Names, should meet the expectations of the user. Unambiguous The signifier should unambiguously identify the referent. Consistent The binding between the signifier and the signified should be consistent with the reasonable expectations of the user. Freehold There MUST be no ongoing costs associated with the continued use of an existing name under an existing configuration. Charges for publishing changes to configurations should be strictly limited to cost recovery. 2. Definitions This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language. Hallam-Baker Expires 17 July 2021 [Page 3] Internet-Draft Mesh Discovery Service January 2021 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Defined Terms 2.3. Related Specifications 2.4. Implementation Status The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer]. 3. Architecture 3.1. Name Registry The name registry is implemented as a Mesh Catalog. 3.1.1. Name Entries A name entry consists of the following information: Name The unique identifier the entry describes. Profile Identifier The UDF fingerprint of the profile to which the name is bound. Assignment Type Describes the means by which the name is assigned. Mesh Service Provider DNS or Mesh name of the Mesh Service Provider servicing the associated account. DNS Resolver Addresses (Optional) IP addresses of the authoritative name servers for a DNS server servicing the Mesh name. Bindings (Optional) A list of signed assertions binding additional names and/or logographical representations to the profile specified by the name. 3.2. Name syntax A Mesh name consists of a sequence of Unicode characters. Hallam-Baker Expires 17 July 2021 [Page 4] Internet-Draft Mesh Discovery Service January 2021 To prevent homograph type attacks, only characters from selected Unicode alphabet are permitted and mixing of characters from different alphabet s is prohibited with the exception of special characters that are permitted in any name. The only special characters currently permitted are the digits 0-9, underscore (_) and dash(-). The only alphabet currently supported is Extended Latin. Canonicalization rules are applied within an alphabet to avoid ambiguity. For the Extended Latin alphabet, canonicalization causes case to be ignored, and ligatures to be mapped according to the prevailing rules applied in circumstances where accented characters are unavailable. 3.3. Name Assignment The first time a name is assigned, the assignment type is 'Initial'. 4. Business Model 4.1. Names do not expire 5. Security Considerations 6. IANA Considerations This document requires no IANA actions. 7. Acknowledgements 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9. Informative References [draft-hallambaker-mesh-developer] Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, Internet-Draft, draft- hallambaker-mesh-developer-10, 27 July 2020, . Hallam-Baker Expires 17 July 2021 [Page 5]