Re: [Drip] DIME Apex Allocation

[Alex Pershyn <[e-mail]>]

Thank you Adam, I’ll do

Sent from my iPhone

On Mar 27, 2024, at 12:26, Daniel Migault <[e-mail]> wrote:



On Wed, Mar 27, 2024 at 1:17 PM Adam Wiethuechter <[e-mail]> wrote:

All,

I am currently working through Daniels comments, thanks Dan!

I have run across this specific set of comments (spanning Section 4 and Section 4.1) and wish to engage in a discussion of the WG to see what other people think.

<mglt>

I think it would be good to clarify the meaning of the acronyms.

We should also explain what RAA/HDA differs from the generic RAAs/HDAs.

DET defines RAA and HDA as some bits, and it seems that some sort of delegation exists between RAA and HDAs. However, there are no bits for Apex and as such Figure 1 does not seem to represent that delegation induced by the DET fields but instead as a specific "administrative entity" that uses special bits values for RAA and HDA. Maybe that is clarified after, but the current description is missing to specify that it represents business entities or administrations. All of them will be encoded on the RAA and HDA bits.

</mglt>

4.1.  Apex

   The Apex is a special DIME role that holds the values of RAA=0-3 and

   HDA=0.

 It serves as the branch point from the larger DNS system in

   which DETs are defined.  The Apex is the owner of the IPv6 prefix

   portion of the DET associated with it (2001:30/28) which is assigned

   by IANA from the special IPv6 address space for ORCHIDs.

<mglt>

I think I am missing the text that explains briefly why we need to have an Apex. If that is the administrative contact of the prefix why do we need to assign a specific RAA/HDA code point.

</mglt>

The primary discussion is I wish to raise is around if the Apex needs allocations in RAA/HDA space.

The Apex is to be run by some entity. At the moment it is agreed to be IANA until ICAO can fill its place. There will obviously be X.509 certificates that we will need to shadow as mentioned in -dki.

Technically if the Apex is not given a DET out of this space there cannot be a Broadcast Endorsement for the Apex. Currently it is defined that the Broadcast Endorsement for the Apex is self-signed. If this is removed a few things happen:

1. drip-auth has one whole Broadcast Endorsement removed from its chain. This is good as then less is needed to be sent over the air. This is bad as the Apex is written into the document in Section 6.
2. RAA level Broadcast Endorsement's become self-signed, and clients must jump into the shadow X.509 PKI to confirm if the RAA is legitimate and continue up the chain to the Apex.

I think we have two options to move forward with this comment:

1. Remove the allocation of a DET for the Apex (i.e. RAA=0-3, HDA=0) and have it solely be in the X.509 (as the Root CA?) chain. Text would need to be added explaining that X.509s would be required between the Apex and RAAs to confirm legitimate registration.
2. Add text justifying the DET for the Apex.

On a technical level I believe it should stay the same, however on a conceptual level legitimacy ends, at least to most end users, at their CAA (which would be the RAA).

Thoughts?

Thanks for the question. 

I understand the role of the Apex as ensuring the delegation of a given prefix is well redirected to the legitimate entity - in other words providing the right NS. The reverse resolution goes from IANA to Apex to RAA to HAD. Of course various aggregation can exist. 

It could be I am missing something, but I do not see any reason for the Apex to be associated with an RAA/HDA. They do play an important part in the delegation but do not appear in the DNS scheme. They are like the admin of an NS server. 

X509 or DNSSEC could be used to validate the full path. RAA/HDA could also have specific RRsets that might be helpful. 

I remain of course open to other feedbacks, but I tend to favor option 1).  

Yours 

Daniel

--------

73,

Adam T. Wiethuechter

Software Engineer; AX Enterprize, LLC

--
Tm-rid mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tm-rid" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/tm-rid

--

Daniel Migault

Ericsson

--
Tm-rid mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tm-rid