Re: [Drip] DIME Apex Allocation

On Wed, Mar 27, 2024 at 1:17 PM Adam Wiethuechter <
adam.wiethuechter@axenterprize.com> 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
> Tm-rid@ietf.org
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
Daniel Migault
Ericsson