Re: [Anima] Homogeneous vs. heterogeneous trust domains (Re: What elements of IETF ANIMA can be used for I2NSF?)

On 31/10/2014 02:47, Michael Richardson wrote:
> Markus Stenberg <markus.stenberg@iki.fi> wrote:
> 
>     > On 29.10.2014, at 4.47, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
>     >>> I claim that there is doesn't matter where the initial imprinting occurs;
> 
>     randy> Perhaps I'm being overly literal, but aren't there situations
>     randy> where physical location might actually matter, as in setting
>     randy> DVD region codes?
> 
>     markus> I agree with mcr.
> 
> I think that Markus went into some DVD specific thing without answering the
> aim of the question.
> 
> I don't think that the physical location ought to matter at all; what I think
> matters is that the some organizations need autonomic mechanisms, but do not
> wish to do this "in the field", while other organizations have the opposite
> requirement.

Right (after scanning your examples). So let me ask a more specific
question: look at draft-pritikin-bootstrapping-keyinfrastructures and
draft-ietf-netconf-zerotouch and opine whether either or both of
them is doing what we need. Or to put it another way, what do we need
to define in a generic way for all deployments, and what has to be
defined for specific scenarios?

   Brian

> 
> Let me give two examples.  The first is made up (i.e. I have no specific
> knowledge of it), while the second is one that I experience regularly.
> 
> 1) a military and/or aid organization (think Medecin sans Frontier) receives
>    a stack of equipment to their warehouse in New Jersey.  Let's they are
>    setting up for a "MASH"-like installation.  They uncrate all the equipment,
>    and plan to put 3x "typewriters", 1x microphone, 10x
>    top-of-the-poll-loud-speaker, 2x mess-hall cash registers, 10x ventilators,
>    2x cardiac machines.. (just imaging what a 2015-edition of "MASH 4077" might have).
>    into each shipping container.
>    In each case, they will power up the machines, in the warehouse, and some
>    validation system will run once the machines are seen, and it will imprint
>    the machines with the MSF identity.  The machines go *BACK* into their
>    shipping boxes, and are distributed (mostly randomly) into shipping
>    containers, one container per installation.
>    {okay, today, we might rack mount it into the container and leave them
>    in the container, but let's ignore that bit of modern lego work}
> 
>    The equipment might sit in the container for months to *decades* before
>    it is actually deployed.  If there are any online processes that need to
>    occur for the imprinting to occr, they occur in New Jersey where there is
>    reliable power and Internet, not in Sierra Leone.
> 
>    If the equipment is stolen or redirected, etc. it likely won't trust any
>    of the "hostile" networking equipment, and it won't be autonomic with it.
>    This is good and intended.
> 
> 2) a vendor (V) of security appliances buys 1U systems (Z) from vendor X.  Vendor X
>    operates worldwide, and can provide fullfilment worldwide from local
>    inventory to customer (C).
> 
>    Due to time, cost and excise issues, it is impractical to ship units
>    from vendor X to V's office for installation and configuration.  In some
>    cases mutually exclusive frequency assignments for things like wireless
>    might even make it illegal to operate Z in V's country, and illegal for
>    equipment in V's country to operate in C's country!
>    (in the ways of 2mb/s 802.11 [no-letter] this was true)
> 
>    So the equipment is shipped by X to C, and C physically installs it in a
>    new office.  Equipment Z has core routing functions. It would be ideal if
>    equipment Z could recognize the network connections that it has, say who
>    it is on them.  The autonomic process would then imprint the system.
>    If system Z is being sold as a service, it might be that it gets imprinted
>    to V.  It might get imprinted to C.  Or it might be initially imprinted to
>    V, installed, and then ownership transfered to C.
>    The final location here might matter; it matters that it's been installed
>    at the San Jose office rather than in the New York office.
> 
>    [Today, I, as vendor V, must instruct customer C, on connecting up the
>    IPMI/ILO/iDrac, and opening a port 443, and if it's actually core routing
>    equipment, we are probably screwed anyway]
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima