[Anima] Operational Considerations for BRSKI Registrar

[Michael Richardson <[e-mail]>]

[e-mail] wrote:
    > A new version of I-D, draft-richardson-anima-registrar-considerations-05.txt
    > has been successfully submitted by Michael Richardson and posted to the
    > IETF repository.

    > Name:		draft-richardson-anima-registrar-considerations
    > Revision:	05
    > Title:		Operational Considerations for BRSKI Registrar

    > Html:           https://www.ietf.org/archive/id/draft-richardson-anima-registrar-considerations-05.html
    > Diff:           https://www.ietf.org/rfcdiff?url2=draft-richardson-anima-registrar-considerations-05

I have posted a new version of my draft on operational considerations for a
BRSKI Registrar.
The document was not renewed during 2021 due to other priorities.

I wrote this document to explore some of the design issues around using BRSKI
in a variety of network scenarios:  Tier-1 ISPs, Enterprises, and Home Networks.

The different deployment scenarios do not call for the same technologies in
the registrar, and this is part of the point of this document.

One of things in this document is the Enterprise/Tier-1 asynchronous
deployment model, where the "Northbound" BRSKI-MASA interface is not directly
connected to the "Southbound" BRSKI-EST interface.  (See figure 3).
In such a case, it may not be the case that the TLS Client Certificate used
by the BRSKI-MASA interface is identical to the Registrar/Domain certificate.

This explanation was useful in getting some of the final discuss details in
RFC8995, which were further clarified in constrainted-voucher section 4,
about pinning.

In creating Figure 1, with Denver/SanJose/NYC/Frankfurt/etc.  it was my
intention to discuss issues of onboarding, database synchronization,
certificate renewal (via EST)... in the face of network partition.
That content has not yet made it into this document.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide