Subject: [Anima] Fwd: Re: [homenet] write up of time without clocks

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Nov 2016 15:53:36 +1300

Something over on homenet prompted me to send the following. I do have the
same concern for BRSKI - what's the disaster recovery mechanism when all
vendor MASAs are unreachable but we must restart the network anyway?

   Brian

-------- Forwarded Message --------
Subject: Re: [homenet] write up of time without clocks
Date: Wed, 2 Nov 2016 08:38:04 +1300
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: [email-masked]

On 02/11/2016 03:52, Philip Homburg wrote:
...
> Which brings me to the following: given that all code has security issues,
> maybe devices should check for updates and just shutdown if they can't
> verify that they are running the latest firmware?

That sounds absolutely dreadful for disaster recovery scenarios where
the Internet is badly broken (after a hurricane, earthquake, etc.)
and people need to restart essential systems (or they need to restart
themselves).

> So the device should have the vendor's long term TLS certicate. With possibly
> an option for the user to disable this kind of security if the device is
> not actually connected to the internet.

No, during disaster recovery the last thing you need is for ordinary people
to be faced with strange security alerts that they've never seen before.
(It's rather like advising people to go into the BIOS to change an option
while the fire alarm is ringing.)

Things need to just work during disaster recovery.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 2 Nov 2016 16:05:44 +0000

My position is that during a large scale disaster it would be foolish of us to think that security is somehow less important. 

BRSKI supports nonceless tokens that can be distributed in advance. These include the serial number of the device and the domain CA cert so it IS NOT a "master key".
	A “master key” is too similar to a “back door” for me to support it. 

BRSKI client may support physical presence (buttons etc) that put them in ‘trust on first use’ mode. 

BRSKI addresses ‘time without clocks’ through the use of nonces and section 3.1.5.

I could be persuaded toward a more generic tofu model only if devices include an integrated hardware assisted endpoint assessment (think TPM style attestation w/ runtime measurements). That technology isn’t really available yet.

The approaches provided here work with some prior planning but are not magical. 

Do you have pixie dust to suggest? 

- max

> On Nov 1, 2016, at 8:53 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Eliot Lear <[email-masked]>
Date: Wed, 2 Nov 2016 17:15:17 +0100

I myself would be concerned over a downgrade attack. 

Recall that this only impacts BRSKI in as much as the device needs to be
provisioned *during* the disaster.  While there may yet be some classes
of devices that require this, I'm going to hazard (cough) a guess that
most first responders will have trained with the equipment they have
*prior* to the disaster.  For the remaining equipment, if it is part of
critical infrastructure and requires a network, then the network needs
to be up.  The only question then is whether the MASA server needs to be
up.  It is perfectly possible to design a system where that is the case.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Nov 2016 08:09:47 +1300

Firstly, no, I have no pixie dust, and I agree that we need to preserve
security even after a disaster. But on the other hand, if autonomic
networks matter at all, they will matter then, and we can't safely assume
that network operators are available even to switch on some sort of emergency
MASA server. Also, how would a temporary tactical network used by emergency
responders configure itself if no vendor MASA server is accessible?

I'm not suggesting that the basic BRSKI mechanisms need to solve this,
but I think we need to have it on the list of issues to be tackled before
we can consider Anima complete.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 2 Nov 2016 22:18:06 +0100

Hi Brian,

> we can consider Anima complete.

Before we start imagining what the requirements in such situations are,
are they at all written somewhere?  Otherwise we run the risk of
inventing a lot of mechanism to deal with a non-existent use case.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Nov 2016 10:57:03 +1300

> inventing a lot of mechanism to deal with a non-existent use case.

Certainly. And it may be a general problem, not specific to Anima and
Homenet.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 2 Nov 2016 22:16:58 +0000

> On Nov 2, 2016, at 1:09 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I think Eliot’s point that "most first responders will have trained with the equipment they have prior to the disaster” meaning that that equipment will already have been bootstrapped. In this case MASA isn’t needed.

Any new equipment that needs to be deployed can be bootstrapped using either the nonceless audit tokens or the physical possession workarounds. In this case the MASA can be offline so long as necessary audit tokens can be brought into the area along with the replacement equipment. 

Beyond that, say a large scale network needs to be brought up, then I suspect a service like the Cisco NERV truck will be brought in to provide satellite connectivity. In which case the MASA server can be contacted. 

- max

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Nov 2016 20:54:23 +0100

> inventing a lot of mechanism to deal with a non-existent use case.

Not being Brian, but you being encumbered with more IETF/IAB
background, let me bring up the point that during anima formation,
our AD(s) where not too happy to delay progress in anima by 
"requirements" documents or the much.

 - not sure if/how this might have changed
 - written requireemnts from other WGs would be nice instead
   of us (anima) having to come up with them
 - Wasn't/isn't there some form of work in IETF bout emergency
   or the like (911)... drawing a blank here, but maybe those
   folks have requirements to draw from.

Cheers
   Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Nov 2016 21:40:24 +0100

IMHO, gear replacement after large outages is quite relevant:

I have seen equipment become unusable after bad
power situations (spike, brownout, electrical storms,..) because of
el-cheapo power supply/circuitry as well as wired interface
circuitry/protection. Certifications in Telco/IoT make that type of gear
often better, but those certifcations are a zoo.

- Large organizations will have spares. With ANIMA, those spares should
  be stored pre-enrolled to avoid MASA/registrar dependency during
  recovery/replacements: Receive gear on any site (no central provisioning
  site needed), but unpack, plug in for short period, then stash away.
  
  This is imo an easy requirement also useful without desaster requirements
  - aka: enrolled spares would likely also have better theft/abuse protection
  than non-enrolled. And yes, you will have to power up these spares
  once a year. Which IMHO is ok. And of course certs should therefore
  be somewhat longer than 1 year).

- If sparing would be cross-locations (eg: spares sent from some site to
  other sites during recovery), then its important that the ANIMA certs do
  not include any location specific attributes that would prohibit thart
  movement. So far BRSKY does not include any such attributes, but in
  discussions, three has been interest to lock into the cert some device
  role specific attributes, and for a spare piecce of equipment, those
  attributes may not be predetermined.

  Aka: Desaster sparing means domain certs need to be simple, devices
  reuseable across domain.

- If spares are done by a shared facility: vendor, FEMO (for fed networks)
  or the like, one could think of that entity offering (emergency)
  enrolment service.

  Such an entity would have desaster proof MASA connectivity on site,
  and the customers would provide it with (emergency) registrar certs.
  (emergency) meaning that the entity is only permitted to enrol during
  emergencies, and the customer could be able to verify the emergency
  entities behavior by pulling from the MASA an audit log.

  If the customer would give the emergeny registrar credentials
  cert/private/public-key to the emergeny entities, then the customer
  itself also has the cert/private-key and could ask the MASA.
  This option would work with current BRSKY text. I am just not sure
  about security BCP (having two copies of a public key pair...).

- If the shared spare storage facility is Best Buy, and the Jones
  family wants to replace some electric storm victims @home while
  their ISP takes its days (my ISP C*...*T took almost 48 hours in one case),
  then the gear should probably come with a nonceless voucher
  printed on on a scratcher piece of paper inside the box.

Beyond these BRSKY considerations, the next cool ANIMA piece to consider
for these use-cases is of course the ASA driven "re-configuration" of the
spare device, aka: In larger outages, you should not except the whole
network provisioning backend to be up and running. And its IMHO
illusionary to expect devices to ONLY be driven from intent for many
years (in complex networks... in a clean homenet they are driven by
intent today..). 

Aka: for pre-intent-only desaster proof networks, we'd need:
  - ASA to cache neighbors configs.
  - reapply neighbor stored config when replacement gear is inserted.
  - IMHO: An anima definition for a "device-role-id" which is not
    the ACP IPv6 address (which will change upon gear replacement
    without enrolment support).

Cheers
    toerless

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 4 Nov 2016 21:23:15 +0000

There is a lot here. Attempting to comment on it all. 

It would really help if we could relate these discussions to specific text sections that could be improved. Otherwise we’re just blowing into the wind. (Where it seems obvious I’ve added such notes). 

> On Nov 3, 2016, at 2:40 PM, Toerless Eckert <[email-masked]> wrote:
> 

Devices that have been brought up and are in the network post bootstrap are not relevant to the BRSKI document. 

>  be somewhat longer than 1 year).

This could be captured as a discussion: what does a device do when its credentials are out of date? Does it fall back on full bootstrapping? If so this becomes a potential attack vector wherein the attacker can convince the device it is out of date and then force it to restart bootstrapping. That would be bad. 

So, should there be an injection point into the bootstrapping state machine that says something like:

If a device fails to join the ANI after [some number] of attempts it attempts to repeat bootstrapping using its original SUDI credentials. During this bootstrapping attempt it MUST only bootstrap on a Registrar that provides both a valid voucher and an identity recognizably within the same PKI hierarchy the device was in previously. This is detected by the device by either (a) the domainCAcert is an exact match for the current domain trust anchor known to the device or (b) the EST /cacerts response includes a chain that terminates in the current domain trust anchor known to the device.  

This extends the lifetime of such a stored device beyond its own certificate (maybe 1 year) *and* beyond the current CA certificate (maybe a 2year cert) an all the way into the next CA certificate (another 2 years). That is a pretty solid lifetime (up to 4 years) for recovery.

>  Aka: Desaster sparing means domain certs need to be simple, devices

I agree that certs should include the absolute minimum information about the device. The actual ID is sufficient in my book. Attribute Certs or backend database lookups or short term tokens obtained by the device in place are all methods of distributing additional information. 

>  and the customers would provide it with (emergency) registrar certs.

Ok. So like a Cisco NERV truck that provides connectivity sufficient to rebuild a network in place. 

Issuing a new Registrar ID would mean being able to bring up the PKI infrastructure during the recovery process. But this is exactly the time period when having as much of the critical keying infrastructure offline and secured could be beneficial for longterm security. One could argue that extra attempts should be made to ensure the PKI is offline. 

>  entities behavior by pulling from the MASA an audit log.

Section 5.6 doesn’t include the Registrar identity only the domainID in the log. Do folks think the Registrar ID should be included as well?

If this was done then does it matter if the Registrar cert has role information in it? As per the above what would happen if all devices in the ANI could act as a registrar? There would be a higher chance that one of them would mess up and actually perform registrar activities incorrectly — but it would be logged so the admin could watch for that.

Thoughts? I’m worried but see the conversation going that way.

>  about security BCP (having two copies of a public key pair…).

Sorry - I can’t write text around copying a private key. If we’re going that route lets dump all the PKI stuff and just use bearer tokens and be up front about the security we’re providing. See above for different ideas. 

>  printed on on a scratcher piece of paper inside the box.

Even a nonceless voucher includes the domainCAcert so this idea doesn’t fly with the current text. What you’re looking for is some form of “bearer voucher” that contains a symmetric key. Anybody who can scan it off the box can deploy the device. 

I’d normally rail against this but am actually pleased to see it fit so well into the model. A bearer voucher sorta sucks but creating one didn’t change any of our messaging flow or anything. Interesting positive that… 

I’m thinking that it is time for a section 3.7 “Voucher types” that digs into what we’re talking about for these different voucher types. Currently the text is scattered in the other sections. 

- max

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Nov 2016 07:01:38 +0100

On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pritikin) wrote:
> It would really help if we could relate these discussions to specific text sections that could be improved. Otherwise we???re just blowing into the wind. (Where it seems obvious I???ve added such notes). 

Sure, but lets high level agree what type of content is useful and
where it would fit.

> Devices that have been brought up and are in the network post bootstrap are not relevant to the BRSKI document. 

To me the most important goal should be to provide candidate users with
deployment guidance. This should fit ANIMA goals given how its an OPS group.

Lets say we have two options:

  a) keep spares unenrolled, enrol during desaster recovery with satellite link
  b) enrol spare devices when they are stocked, deploy during desaster.

lets assume we agree both are relevant deployment options that users
should understand, compare pro/cons for their case and choose. If you think
we can not mention both in the BRSKY spec, then i think it would be better
to have a separate document where both could be discussed. 

> This could be captured as a discussion: what does a device do when its credentials are out of date? Does it fall back on full bootstrapping? If so this becomes a potential attack vector wherein the…

Haha... ;-) i just wanted to show what IMHO are the most simple
deployment options to deal with desaster recover. Now you're the one who is
opening another round of discussions trying to figure out the best
security compromise for those deployment processes.  Which is great.
Just don't blame me that there are more and more interesting details to
capture somewhere.

> If a device fails to join the ANI after [some number] of attempts it attempts to repeat bootstrapping using its original SUDI credentials.

I'd prepare a flag 'operational' set by SDN controller or ASA after 
the device is "provisioned" (config/intent applied).

> During this bootstrapping attempt it MUST only bootstrap on a Registrar that provides both a valid voucher and an identity recognizably within the same PKI hierarchy the device was in previously. This is detected by the device by either (a) the domainCAcert is an exact match for the current domain trust anchor known to the device or (b) the EST /cacerts response includes a chain that terminates in the current domain trust anchor known to the device.  
> 

Interesting thought.

a) Would like to understand how this compares to just making certs
longer-lived, eg: 3 years, but doing normal renewal after 30% time.

b) Seem like there's quite a bit of analysis to be done of how different
parameter/options will work together:
  - device with/without reliable RTC
  - what would be necessary/beneficial with nonce-less vouchers ?
    how about nonceless vouchers with sequence number... -> remember
    ownership voucher and allow for it to be replaced only with one that
    hass a higher serial number.

> I agree that certs should include the absolute minimum information about the device. The actual ID is sufficient in my book. Attribute Certs or backend database lookups or short term tokens obtaine…

Desaster recovery seems to be one good motivation to not put
more than the minimum into the certs. I was a fan of putting more
into certs in the past...

> Issuing a new Registrar ID would mean being able to bring up the PKI infrastructure during the recovery process. But this is exactly the time period when having as much of the critical keying infra…

My thought was
a) the desaster recovery registrar-IDs are preprovisioned _before_ desaster
   (contract between domain and desaster/spare recovery entity).
b) The facility to which they are allocated is shared across multiple
   domains.
c) the facility is not "desaster on-site" -> the spares will not be on-site,
   but will be stored at some central site. Enrollment would happen at
   that central site, then they'd be shipped onto-desaster-site.

> Section 5.6 doesn???t include the Registrar identity only the domainID in the log. Do folks think the Registrar ID should be included as well?

Oh, right. i confused domain-id with registrar-ID.

I definitely think registrar-ID would be necessary to log so
that audit-logs become more useful to backtrack what happened.

> If this was done then does it matter if the Registrar cert has role information in it? As per the above what would happen if all devices in the ANI could act as a registrar? There would be a higher chance that one of them would mess up and actually perform registrar activities incorrectly ??? but it would be logged so the admin could watch for that.

I don't think we need many/all devices to be registrars. I don't think
we've got a working security model to do this anyhow - eg: authenticating
all those devices against the CA. I hope we do not need to discuss other
roles beside "registrar" in this context.

> Thoughts? I???m worried but see the conversation going that way.

> >  about security BCP (having two copies of a public key pair???).
> 
> Sorry - I can???t write text around copying a private key. If we???re going that route lets dump all the PKI stuff and just use bearer tokens and be up front about the security we???re providing. See above for different ideas. 

Yepp. There should be easier options to achieve the same goal.

Eg: I create a registrar as a VM, and run it onprem of the
desaster recovery provider so that provider can enroll devices
for my domain in case there is a desaster in my domain.

> Even a nonceless voucher includes the domainCAcert so this idea doesn???t fly with the current text. What you???re looking for is some form of ???bearer voucher??? that contains a symmetric key.

Probably. Yes. I guess we have not discussed how to apply BRSKY
enrollment for home users. It's outside of scope for ANIMA anyhow,
but would be interesting. Some of those home thoughts likely equally
apply to low-end IoT devices.

>Anybody who can scan it off the box can deploy the device. 

Thats why i said "scratcher", eg: some one-time-unveil where you
can easily check that its untampered when you buy the device. 

> I???d normally rail against this but am actually pleased to see it fit so well into the model. A bearer voucher sorta sucks but creating one didn???t change any of our messaging flow or anything. Interesting positive that??? 

> I???m thinking that it is time for a section 3.7 ???Voucher types??? that digs into what we???re talking about for these different voucher types. Currently the text is scattered in the other sections. 

We could also start discussing those aspects in the submission from
Kent et. al. about vouchers and move into BRSKY when we see it fit.

Cheers
    Toerless

---

From: <[email-masked]>
Date: Mon, 7 Nov 2016 08:42:48 +0000

Hi,

Following ANIMA in fits and starts and saw the reference to BRSKY. Tried to follow up on what it was all about and found the reference to it in draft-ietf-anima-autonomic-control-plane-04. Section 5.2.4 is entitled “Discovery and BRSKY” but appears to make no reference to it and, despite three uses of the term BRSKY in the document, I find the protocol is actually the Bootstrapping Remote Secure Key Infrastructures (BRSKI).

Is the intention to rename to BRSKY or is it just that people have got into the habit of calling it that?

Jonathan

=O)

From: Toerless Eckert
Sent: 07 November 2016 06:01
To: Max Pritikin (pritikin)
Cc: Toerless Eckert; Eliot Lear; Anima WG
Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up oftime without clocks)

Interesting thought.

My thought was

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Nov 2016 18:09:04 +1300

Jonathan,

BRSKI (I not Y) is defined in draft-ietf-anima-bootstrapping-keyinfra-04
"Bootstrapping Remote Secure Key Infrastructures (BRSKI)". If there are
incomplete or incorrect references in other documents, of course they need to be
completed or corrected.

Regards
   Brian

---

From: "Jonathan Hansford" <[email-masked]>
Date: Tue, 8 Nov 2016 09:13:48 -0000

It would also be good if the correct acronym could be used in emails as it makes it easier to track down what people are referring to.

Jonathan

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 08 November 2016 05:09
> To: [email-masked]; Toerless Eckert <[email-masked]>; Max Pritikin
> (pritikin) <[email-masked]>
> Cc: Toerless Eckert <[email-masked]>; Anima WG <[email-masked]>; Eliot
> Lear <[email-masked]>
> Subject: Re: [Anima] Desaster recover...
> 
> Jonathan,
> 
> incomplete or incorrect references in other documents, of course they need
> to be completed or corrected.
> 
> Regards
>    Brian
> 
> > Following ANIMA in fits and starts and saw the reference to BRSKY. Tried to
> follow up on what it was all about and found the reference to it in draft-ietf-
> anima-autonomic-control-plane-04. Section 5.2.4 is entitled “Discovery and
> BRSKY” but appears to make no reference to it and, despite three uses of the
> term BRSKY in the document, I find the protocol is actually the Bootstrapping
> Remote Secure Key Infrastructures (BRSKI).
> >
> >> It would really help if we could relate these discussions to specific text
> sections that could be improved. Otherwise we???re just blowing into the
> wind. (Where it seems obvious I???ve added such notes).
> >
> >>> - Large organizations will have spares. With ANIMA, those spares
> >>> should  be stored pre-enrolled to avoid MASA/registrar dependency
> >>> during
> >>>  recovery/replacements: Receive gear on any site (no central
> >>> provisioning  site needed), but unpack, plug in for short period, then
> stash away.
> >>
> > To me the most important goal should be to provide candidate users
> > with deployment guidance. This should fit ANIMA goals given how its an
> OPS group.
> >
> > should understand, compare pro/cons for their case and choose. If you
> > think we can not mention both in the BRSKY spec, then i think it would
> > be better to have a separate document where both could be discussed.
> >
> >>>  - aka: enrolled spares would likely also have better theft/abuse
> >>> protection  than non-enrolled. And yes, you will have to power up
> >>> these spares  once a year. Which IMHO is ok. And of course certs
> >>> should therefore  be somewhat longer than 1 year).
> >>
> >> This could be captured as a discussion: what does a device do when its
> credentials are out of date? Does it fall back on full bootstrapping? If so this
> becomes a potential attack vector wherein the attacker can convince the
> device it is out of date and then force it to restart bootstrapping. That would
> be bad.
> >
> > deployment options to deal with desaster recover. Now you're the one
> > who is opening another round of discussions trying to figure out the
> > best security compromise for those deployment processes.  Which is great.
> > Just don't blame me that there are more and more interesting details
> > to capture somewhere.
> >
> >> If a device fails to join the ANI after [some number] of attempts it
> attempts to repeat bootstrapping using its original SUDI credentials.
> >
> >> During this bootstrapping attempt it MUST only bootstrap on a Registrar
> that provides both a valid voucher and an identity recognizably within the
> same PKI hierarchy the device was in previously. This is detected by the
> device by either (a) the domainCAcert is an exact match for the current
> domain trust anchor known to the device or (b) the EST /cacerts response
> includes a chain that terminates in the current domain trust anchor known to
> the device.
> >>
> >> This extends the lifetime of such a stored device beyond its own
> certificate (maybe 1 year) *and* beyond the current CA certificate (maybe a
> 2year cert) an all the way into the next CA certificate (another 2 years). That
> is a pretty solid lifetime (up to 4 years) for recovery.
> >
> > Interesting thought.
> >
> > b) Seem like there's quite a bit of analysis to be done of how
> > different parameter/options will work together:
> >>> - If sparing would be cross-locations (eg: spares sent from some
> >>> site to  other sites during recovery), then its important that the
> >>> ANIMA certs do  not include any location specific attributes that
> >>> would prohibit thart  movement. So far BRSKY does not include any
> >>> such attributes, but in  discussions, three has been interest to
> >>> lock into the cert some device  role specific attributes, and for a
> >>> spare piecce of equipment, those  attributes may not be
> predetermined.
> >>>
> >> I agree that certs should include the absolute minimum information about
> the device. The actual ID is sufficient in my book. Attribute Certs or backend
> database lookups or short term tokens obtained by the device in place are all
> methods of distributing additional information.
> >
> > Desaster recovery seems to be one good motivation to not put more than
> > the minimum into the certs. I was a fan of putting more into certs in
> > the past...
> >
> >>> - If spares are done by a shared facility: vendor, FEMO (for fed
> >>> networks)  or the like, one could think of that entity offering
> >>> (emergency)  enrolment service.
> >>>
> >> Issuing a new Registrar ID would mean being able to bring up the PKI
> infrastructure during the recovery process. But this is exactly the time period
> when having as much of the critical keying infrastructure offline and secured
> could be beneficial for longterm security. One could argue that extra
> attempts should be made to ensure the PKI is offline.
> >
> > My thought was
> >>>  (emergency) meaning that the entity is only permitted to enrol
> >>> during  emergencies, and the customer could be able to verify the
> >>> emergency  entities behavior by pulling from the MASA an audit log.
> >>
> >> Section 5.6 doesn???t include the Registrar identity only the domainID in
> the log. Do folks think the Registrar ID should be included as well?
> >
> > I definitely think registrar-ID would be necessary to log so that
> > audit-logs become more useful to backtrack what happened.
> >
> >> If this was done then does it matter if the Registrar cert has role
> information in it? As per the above what would happen if all devices in the
> ANI could act as a registrar? There would be a higher chance that one of
> them would mess up and actually perform registrar activities incorrectly ???
> but it would be logged so the admin could watch for that.
> >
> >
> > we've got a working security model to do this anyhow - eg:
> > authenticating all those devices against the CA. I hope we do not need
> > to discuss other roles beside "registrar" in this context.
> >
> >> Sorry - I can???t write text around copying a private key. If we???re going
> that route lets dump all the PKI stuff and just use bearer tokens and be up
> front about the security we???re providing. See above for different ideas.
> >
> > Eg: I create a registrar as a VM, and run it onprem of the desaster
> > recovery provider so that provider can enroll devices for my domain in
> > case there is a desaster in my domain.
> >
> >>> their ISP takes its days (my ISP C*...*T took almost 48 hours in one
> >>> case),  then the gear should probably come with a nonceless voucher
> >> Even a nonceless voucher includes the domainCAcert so this idea
> doesn???t fly with the current text. What you???re looking for is some form
> of ???bearer voucher??? that contains a symmetric key.
> >
> > enrollment for home users. It's outside of scope for ANIMA anyhow, but
> > would be interesting. Some of those home thoughts likely equally apply
> > to low-end IoT devices.
> >
> > Thats why i said "scratcher", eg: some one-time-unveil where you can
> > easily check that its untampered when you buy the device.
> >
> >> I???d normally rail against this but am actually pleased to see it fit so well
> into the model. A bearer voucher sorta sucks but creating one didn???t
> change any of our messaging flow or anything. Interesting positive that???
> >
> >> I???m thinking that it is time for a section 3.7 ???Voucher types??? that
> digs into what we???re talking about for these different voucher types.
> Currently the text is scattered in the other sections.
> >
> >>> Beyond these BRSKY considerations, the next cool ANIMA piece to
> >>> consider for these use-cases is of course the ASA driven
> >>> "re-configuration" of the spare device, aka: In larger outages, you
> >>> should not except the whole network provisioning backend to be up
> >>> and running. And its IMHO illusionary to expect devices to ONLY be
> >>> driven from intent for many years (in complex networks... in a clean
> >>> homenet they are driven by intent today..).
> >>>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 16:02:41 +0900

Toerless Eckert <[email-masked]> wrote:
    >> Devices that have been brought up and are in the network post
    >> bootstrap are not relevant to the BRSKI document.

    > deployment guidance. This should fit ANIMA goals given how its an OPS

Chairs, 
  I think we should add a new document to our set.  The title might be:
     Autonomic Networking in Disaster Recovery: preperation and operation

This would be a very very very operational BCP.
We won't finish this until after everything has been put to bed, but I think
we should start it soonest, so that we can capture much of this
discussion/concern.

    >   a) keep spares unenrolled, enrol during desaster recovery with
    > satellite link b) enrol spare devices when they are stocked, deploy
    > during desaster.

    > be better to have a separate document where both could be discussed.

A reason why one would have unenrolled spares is because the spares are kept
by the manufacturer in distributed warehouses, close to where they might be
needed, or perhaps even, would be in a FEMA-like entities' warehouse, to be
deployed to whichever operator needed them.

The use of Autonomic mechanisms might result in normalization much of the
configuration of some devices, so it wouldn't matter as much which vendor's
device was deployed.  Maybe this won't be for core BGP-happy BFRs, but it
could be the case that less complicated things like 24 10/100/1000s switches
would be in that category.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2016 08:04:20 +1300

>      Autonomic Networking in Disaster Recovery: preperation and operation

Yes. I don't know if rechartering is already on the agenda, because we still
have several base documents that are overdue, but this makes a lot of sense
for Anima Phase 2.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 16 Nov 2016 23:42:52 +0000

Assuming we work out the BRSKI questions such that bootstrapping during disaster recovery is clearly defined I’d imagine the rest of anima work work “magically” — in that the new equipment added to a network does what it is intended to do automatically. 

- max

> On Nov 13, 2016, at 12:02 AM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2016 13:02:16 +1300

> Assuming we work out the BRSKI questions such that bootstrapping during disaster recovery is clearly defined I’d imagine the rest of anima work work “magically” — in that the new equipment added to…

Yes, that would be the plan ;-).

It might be worth understanding how cellphone systems deal with this. After
a disaster (as this week in Kaikoura NZ) there's initially no electricity
and no link out from the base stations. How do they rebuild the trust
infrastructure so that SIM cards from anywhere in the world can connect?
Does this only work after there's a connection to the provider's infrastructure?

http://www.stuff.co.nz/business/industries/86463492/options-being-assessed-for-restoring-phone-services-to-kaikoura

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 17 Nov 2016 00:17:34 +0000

Re: questions of scope for disaster recovery

I think BRSKI needs to clarify how disaster recovery works. Perhaps a section on this or perhaps embedded in the text.
Once the network is up I don’t see how disaster’s effects Anima operations. Its just a network and runs as such. 

Continued detailed discussion in line,

> On Nov 6, 2016, at 11:01 PM, Toerless Eckert <[email-masked]> wrote:
> 

Yes, these are the two options available to a network that uses BRSKI. We can clearly state as such if we add a section on disaster recovery.

> that audit-logs become more useful to backtrack what happened.

I can see your points wrt to logging the Registrar-IDs. But I think I'll continue to push back on it for the moment. 

As currently envisioned the MASA service is providing the absolute minimum service necessary to allow the Domain to securely bootstrap devices. If we add the Registrar-ID we are adding additional features to this service. The Registrars should keep their own logs and the domain admin should be able to search them — there is no need to offload this functionality onto the MASA. 

Yes, the MASA *could* easily log this information and a Domain admin might find it very useful to have this information. If we assume they can’t (for some reason) trust their local Registrar infrastructure. I contend there is enough going on without adding extra services. 

This and the “revocation” (ick) discussion have make it clear that we should future proof the log. That way additional services/event types can be added that cover these and more scenarios. 

> for my domain in case there is a desaster in my domain.

I suggest we add this stuff to a disaster recovery section “best common practice” etc and see how it looks in black and white. (Or whatever your monitor colors are). 

> Kent et. al. about vouchers and move into BRSKY when we see it fit.

And now that Michael brought it up as an issue in the slides at ietf97 we might as well deal with it. :) 

- max