DRIP Entity Tags (DET) in the Domain Name System (DNS)

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 31 March 2025.¶

Copyright Notice

Copyright (c) 2024 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Registries are fundamental to Unmanned Aircraft System (UAS) Remote Identification (RID). Only very limited operational information can be sent via Broadcast RID, but extended information is sometimes needed. The most essential element of information from RID is the UAS ID, the unique key for lookup of extended information in relevant registries (see Figure 4 of [RFC9434]).¶

When a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID, extended information can be retrieved from a DRIP Identity Management Entity (DIME) which manages registration of and associated lookups from DETs. In this document we assume the DIME is a function of UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but a DIME can be independent or handled by another entity as well.¶

2. Terminology

3. DET Hierarchy in DNS

[RFC9374] defines the Hierarchical Host Identity Tag (HHIT) and further specifies an instance of them used for UAS RID called DETs. The HHIT is a 128-bit value that is as an IPv6 address intended primarily as an identifier rather than locator. It's format is in Figure 1 and further information is in [RFC9374].¶

+-------------+--------------+---------------+-------------+
| IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
| (28-bits)   | (28-bits)    | (8-bits)      | (64-bits)   |
+-------------+--------------+---------------+-------------+
             /                \
            /                  \
           /                    \-----------------------------\
          /                                                    \
         /                                                      \
        +--------------------------------+-----------------------+
        | Registered Assigning Authority | HHIT Domain Authority |
        | (14-bits)                      | (14-bits)             |
        +--------------------------------+-----------------------+

The IPv6 Prefix, assigned by IANA for DETs is 2001:30::/28. The corresponding domain (nibble reversed as 3.0.0.1.0.0.2.ip6.arpa) is owned by the IAB.¶

Due to the nature of the hierarchy split and its relationship to nibble reversing of the IPv6 address, the upper level of hierarchy (i.e. RAAs) "borrows" the upper two bits of their respective HDA space for DNS delegation. As such the IPv6 prefix of RAAs are 2001:3x:xxx::/44 and HDAs are 2001:3x:xxxx:xx::/56 with respective nibble reverse domains of x.x.x.x.3.0.0.1.0.0.2.ip6.arpa and y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa.¶

Preallocations have been made based on the ISO 3166-1 Numeric Nation Code [ISO3166-1]. This is to support the initial use case of DETs in UAS RID on an international level. See Section 6.2.1 for the RAA allocations.¶

The HDA values of 0, 4096, 8192 and 12288 are reserved for operational use of an RAA (a by-product of the above mentioned borrowing of bits), specifically when to register with the Apex and endorse delegations of HDAs in their namespace.¶

The administration, management and policy for operation a DIME at any level in the hierarchy (Apex, RAA or HDA), be it external or from a parent level, is out of scope for this document. In some cases, such as the RAAs and HDAs of a nation, these are National Matters which are to be dealt with by those parties accordingly.¶

4. Public Information Registry

Per [RFC9434] all information classified, by all parties involved, as public is stored in the DNS, specifically Authoritative Name Servers, to satisfy REG-1 from [RFC9153].¶

Authoritative Name Servers use domain names as handles and data is stored in Resource Records (RR) with associated RRTypes. This document defines two new RRTypes, one for HHIT metadata (HHIT, Appendix A) and another for UAS Broadcast RID information (BRID, Appendix B). The former RRType is particularly important as it contains a URI (as part of the certificate) that point to Private Information resources.¶

DETs, being IPv6 addresses, are to be under ip6.arpa (nibble reversed per convention) with at minimum an HHIT RRType. Depending on local circumstances or additional use cases other RRTypes MAY be present. For UAS RID the BRID RRType MUST be present to provide the Broadcast Endorsements defined in [RFC9575].¶

DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher zones). When a DIME decides to use DNSSEC they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by frequency of updates, size of the zone, and policies.¶

UAS specific information, such as physical characteristics, MAY also be stored in DNS but is out of scope for this document. This specification information is currently drafted in [uas-sn-dns].¶

An example, from Apex to client, of the DNS zones in available in Appendix C.¶

Lookups of the above RRTypes are performed with the standard DNS methodology using the nibble reversed DET as the query name affixed to the ip6.arpa domain apex and asking for the specific RRType. The HHIT RRType provides the public key for signature verification and URIs via the certificate. The BRID RRType provides static Broadcast RID information such as the Broadcast Endorsements sent following [RFC9575].¶

5. Canonical Public Registration Certificate

The following is a canonical public registration certificate, generated upon successful registration and placed into Appendix A. It is defined here as X.509 and MAY be encoded as a C.509. Other X.509 or C.509 MAY exist for specific use cases and MUST placed in CERT RRTypes.¶

-----BEGIN CERTIFICATE-----
MIIBCTCBvKADAgECAhQsKjO1bWo9IQm4g6DnIDJmnQqRrDAFBgMrZXAwGTEXMBUG
A1UEAwwOMjAwMTAwM2ZmZTAwMDEwHhcNMjQwOTI1MjA0MTQ1WhcNMjQwOTI2MjA0
MTQ1WjAAMCowBQYDK2VwAyEAe9/qfhAvPzw/rWb5n4wmVfKZcUezxygo7qFDIO7z
TVejLzAtMB4GA1UdEQEB/wQUMBKHECABAD/+AAEFu+Gv+JeyXlowCwYDVR0PBAQD
AgeAMAUGAytlcANBACB7NmtdXksQDzkzVpJtl29H8g9EioEB75tNHQSSvlpjyFyO
uxKnOYUhN+fIuLhk4Inn79qbFhddGyVqFvcsfQk=
-----END CERTIFICATE-----

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            2c:2a:33:b5:6d:6a:3d:21:09:b8:83:a0:e7:20:32:66:9d:0a:91:ac
        Signature Algorithm: ED25519
        Issuer: CN = 2001003ffe0001
        Validity
            Not Before: Sep 25 20:41:45 2024 GMT
            Not After : Sep 26 20:41:45 2024 GMT
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    7b:df:ea:7e:10:2f:3f:3c:3f:ad:66:f9:9f:8c:26:
                    55:f2:99:71:47:b3:c7:28:28:ee:a1:43:20:ee:f3:
                    4d:57
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE00:105:BBE1:AFF8:97B2:5E5A
            X509v3 Key Usage:
                Digital Signature
    Signature Algorithm: ED25519
         20:7b:36:6b:5d:5e:4b:10:0f:39:33:56:92:6d:97:6f:47:f2:
         0f:44:8a:81:01:ef:9b:4d:1d:04:92:be:5a:63:c8:5c:8e:bb:
         12:a7:39:85:21:37:e7:c8:b8:b8:64:e0:89:e7:ef:da:9b:16:
         17:5d:1b:25:6a:16:f7:2c:7d:09

6. IANA Considerations

7. Security Considerations

8. Public Key Exposure

DETs are built upon asymmetric keys. As such the public key must be revealed to enable clients to perform signature verifications. [RFC9374] security considerations cover various attacks on such keys.¶

While unlikely the forging of a corresponding private key is possible if given enough time (and computational power). As such it is RECOMMENDED that the public key for any DET not be exposed in DNS (under any RRType) until it is required.¶

Optimally this requires the UAS somehow signal the DIME that a flight using a Specific Session ID will soon be underway or complete. It may also be facilitated under UTM if the USS (which may or may not be a DIME) signals when a given operation using a Session ID goes active.¶

9. Contributors

Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Consulting, LLC) for their early work on the DRIP registries concept. Their early contributions laid the foundations for the content and processes of this architecture and document. Bob Moskowitz is also instrumental in the PKIX work defined in this document with his parallel work in ICAO.¶

Appendix A. HHIT Resource Record

This appendix is normative.¶

The HHIT Resource Record is a metadata record for various bits of HHIT specific information that isn't available in the pre-existing HIP RRType. It is encoded as a CBOR array.¶

hhit-rr = [
    type: uint .size(2),
    abbreviation: tstr .size(15),
    registration-cert: bstr / #6.TBD
]

[
  0,
  "APEX",
  WQGC..uAo=
]

Appendix B. UAS Broadcast RID Resource Record

This appendix is normative.¶

The UAS Broadcast RID Resource Record type (BRID) is a format to hold public information typically sent of the UAS Broadcast RID that is static. It can act as a data source if information is not received over Broadcast RID or for cross validation.¶

bcast-rr = {
    uas_type: nibble-field,
    uas_ids: [+ uas-id-grp],
    ? auth: [+ auth-grp],
    ? self-grp,
    ? op_type: 0..3,
    ? area-grp,
    ? classification-grp,
    ? operator-grp
}
uas-id-grp = (
    id_type: &uas-id-types,
    uas_id: bstr .size(20)
)
uas-id-types = (none: 0, serial: 1, caa_id: 2, utm_id: 3, session_id: 4)
auth-grp = (
    a_type: nibble-field,
    a_data: bstr .size(1..362)
)
area-grp = (
    area_count: 1..255,
    area_radius: float,
    area_floor: float,
    area_ceiling: float
)
classification-grp = (
    ua_class: 0..8,
    eu_class: nibble-field,
    eu_category: nibble-field
)
self-grp = (
    desc_type: nibble-field,
    description: tstr .size(23)
)
operator-grp = (
    operator_id_type: nibble-field,
    operator_id: bstr .size(20)
)
nibble-field = 0..15

{
  "uas_type": 0,
  "uas_ids": [
    [4, h'012001003FFE0001056A2621D4EF572EF5']
  ],
  "auths": [
    [5, b64'AYDQ..dwo='],
    [5, b64'AYDQ..Wgs='],
    [5, b64'AYDQ..NAw='],
    [5, b64'AYDQ..7gA=']
  ]
}

Appendix C. DET DNS Zone Examples

This appendix is informative, showing an example of the DNS zone setup/content from Apex to a client.¶

For this example the following DETs are shown:¶

• Apex = 2001:0030:0000:0005:fad8:7fea:e0f6:90ad¶
• RAA = 2001:003f:fe00:0005:618a:cd8e:76d3:b790¶
• HDA = 2001:003f:fe00:0105:ad79:a278:1c10:5443¶
• Client = 2001:003f:fe00:0105:6a26:21d4:ef57:2ef5¶

The RAA allocation of 16376 and an HDA of 1 have been selected.¶

$ORIGIN 3.0.0.1.0.0.2.ip6.arpa.
0.e.f.f IN NS ns1.raa-16376.example.com
1.e.f.f IN NS ns1.raa-16376.example.com
2.e.f.f IN NS ns1.raa-16376.example.com
3.e.f.f IN NS ns1.raa-16376.example.com

$ORIGIN 5.0.0.0.0.0.0.0.0.3.0.0.1.0.0.2.ip6.arpa.
d.a.0.9.6.f.0.e.a.e.f.7.8.d.a.f IN BRID ( a368..770a )
d.a.0.9.6.f.0.e.a.e.f.7.8.d.a.f IN HHIT ( 0 APEX 5901..b80a )

$ORIGIN 0.e.f.f.3.0.0.1.0.0.2.ip6.arpa.
1.0.0 IN NS ns1.hda-1.example.com

$ORIGIN 5.0.0.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.arpa.
0.9.7.b.3.d.6.7.e.8.d.c.a.8.1.6 IN BRID ( a368..5a0b )
0.9.7.b.3.d.6.7.e.8.d.c.a.8.1.6 IN HHIT ( 0 RAA 5901..0d0c )

$ORIGIN 0.1.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.arpa.
3.4.4.5.0.1.c.1.8.7.2.a.9.7.d.a.5.0 IN BRID ( a368..340c )
3.4.4.5.0.1.c.1.8.7.2.a.9.7.d.a.5.0 IN HHIT ( 0 HDA 5901..ac0a )
5.f.e.2.7.5.f.e.4.d.1.2.6.2.a.6.5.0 IN BRID ( a368..ee00 )
5.f.e.2.7.5.f.e.4.d.1.2.6.2.a.6.5.0 IN HHIT ( 0 CHILD 5901..0306 )

Authors' Addresses