Re: [Anima] verification of manufacturer in BRSKI

[Michael Richardson <[e-mail]>]

'Toerless Eckert' <[e-mail]> wrote:
    >> Now when a pledge wants to validate the JRC, he simply needs to verify
    >> the signature of MI on the invoice. No communication with MASA or even
    >> MASA itself is not required.

    > Yes. I have this picture in my head of a guy (called Scotty ;-) holding
    > a printed sales receipt with QR-code and trying to show it to his new
    > router/equipment.

("But, Dr. McCoy how do ya know this guy isn't the guy who invented secure enrollment?")

    > The classicial representation of an offline voucher is a USB stick and a
    > pair of sneakers to represent the physcial media and transport channel,
    > but i like the QR-code too to represent the potential complexities of
    > offline vouchers.

The voucher-on-USB-stick case is represented in the NETCONF work.

    >> It is just like the way, JRC verifies the pledge using the IDevID certificate issued by MI.

    > If you have a side-channel to get the voucher into the pledge, yes. But
    > very often in "professionally managed networks" (ANIMA charter), the guy who
    > gets the sales receipt could be (hundreds of) miles away from the pledge,
    > so in those environments its much more likely that any type of offline
    > voucher can easily be injected into the Registrar first than through a side
    > channel physcially into the pledge.

Additionally, equipement is often shipped directly to the data center where
it will be installed.

Upon arrival, the *data center* staff can be paid to remove it from the box
and physically install it.  This is called "remote hands".
       http://searchdatacenter.techtarget.com/definition/remote-hands
       http://www.365datacenters.com/services/remote-hands-services/

Remote hands can often be instructed to do things, but it requires a very
senior engineer to guide them, because they have to know PRECISELY what
should appear and all the situations that could go wrong.  I've worked this
kind of thing.  Too often an operational engineer flies there and does it
directly.  That's the kind of thing we are working to deal with.

Usually all one has the remote hands do is to configure some kind of
connectivity.
This means today:
     a) a "lights out" (iLO, iDRAC, etc.) network connection if it's a server.
     b) a craft (serial) console if it's a router.

The ACP document goes into this at length... the point is that BRSKI can
bootstrap that equipment even if it's the core routing equipment, as long as
the long-haul fiber goes into a compatible optical module.
(And the right lambda is used... I'd like to write a specification for
auto-detecting that part.  I suspect it doesn't need standardization)

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-