'Toerless Eckert' <t...@cs.fau.de> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima