1. A Reference Model for Autonomic Networking draft-ietf-anima-reference-model-03.txt
97th IETF, Nov 2016
Michael Behringer (editor), Brian Carpenter, Toerless Eckert, Laurent Ciavaglia, Pierre Peloso, Bing Liu, Jefferson Nobre, John Strassner
not published yet

2. State Machine: ANIMA Device
Factory default
This is BRSKI, as seen from pledge; see separate state machine
auto-conf interfaces
draft-ietf-anima-bootstrapping-keyinfra
Bootstrapping
open items: see BRSKI draft
if not
if successful
Device has a domain certificate
Enrolled
ANIMA Neighbor discovered (mDNS)
Join ACP
draft-ietf-anima-autonomic-control-plane
decision needed on mDNS / GRASP
ACP “up”
In ACP
GRASP Discovery an ACP: Registrar found
need to specify GRASP message format
draft-ietf-anima-bootstrapping-keyinfra
stop bootstrap proxy
start bootstrap proxy
This is BRSKI, as seen from proxy
Registrar
lost
Proxy Mode
MUST send discovery messages (because the pledge MAY send)
: More work needed

3. State Machine: BRSKI Pledge
Factory default
A factory default device (pledge) is in one of these modes, hard coded:
join any domain (first come first join)  No MASA required
require audit token  MASA required, audit mode
require authentication token  MASA required, ownership tracking mode
auto-conf interfaces
Discovery
MUST listen
MAY send
receive: “invite from <neighbour> to <domain>”
(handle received messages fifo, until “enrol” state)
Request-Join
(neighbour, domain)
Max: “Identify is a separate step”
receive:
“reject
<info>?”
receive: “accept (<domain trust anchor> <enrolment info>)|( <audit_token>)|(<auth_token>)”
Validation:
If <I require auth_token>:
if <auth_token> valid: next state: Enrolling
else: blacklist <domain>; next state: Discovery
elseif <I require audit_token>:
if <audit_token> valid: next state: Enrolling
else: next state: Enrolling.
Validation
validation failed
(provide feedback)
validation successful
Does device accept either token type or require a specific one?
Enrolling
enrolment failed
(provide feedback)
enrolment successful
Enrolled
: More work needed
Device has a domain certificate

4. State Machine: ACP Enrolled Device has a domain certificate
If we make this a separate ASA...
start ACP ASA
Discovery
MUST listen
MUST send
Need to define packet format.
Discover <node>;<domain>
Check policy for <domain>:
Should we establish ACP?
For now, default policy:
“If in same domain”.
Later we can have other policies. n y
for each discovered AN adjacency
Authenticate <node>
Set up secure channel
was this the first ACP tunnel? n y
last ACP tunnel going down
enable ACP routing and addressing
Device is in the ACP.
(Note: This does not mean it sees a registrar or other services. Just that there is an ACP.)
In ACP
: More work needed

5. Open questions / items State machines:
describe ANIMA SM in reference draft, the other ones in the respective draft?
Is “proxy mode” a separate state? (mcr: No!)
Should we describe the RPL state machine in more detail? (probably! – see mail from mcr)
In which draft? Probably BRSKI
Define “factory reset” (should go into reference model)
type 1: erase all but LDevID  Device doesn’t need to re-enrol
type 2: erase all, including LDevID

6. Open questions / items Discovery protocols:
Currently the drafts say:
ACP draft: insecure GRASP. M_FLOOD
BRSKI: mDNS. (Brian: If we use mDNS, ANI is not “self-contained”)
Current discussion on list: (mail from mcr)
Discovery of proxy by pledge:
- GRASP M_FLOOD (MUST for proxy, SHOULD for Pledge)
- mDNS (SHOULD for proxy, MAY for Pledge)
Should it say:
BRSKI may run in ANIMA context, or in different context (IoT)
if “ANIMA” then use insecure GRASP
if “other” then use mDNS (or other)
But then we have insecure and secure GRASP concurrently, potential security concern.

7. Open questions / items
In ACP draft: Clarify: ACP draft does NOT require BRSKI to run first. Keys could come for example from SIM cards.
Discovery, general questions:
should the discovery packet contain the domain info?
Need to specify packet formats
Follow-up security review from Nancy
Complete section 7.3 (ASAs)
Complete sections for bootstrap ASAs.
Do we want to define the ACP as an ASA?
Argument “for”: allows modularity
Argument “against”:
BRSKI:
Feedback to the pledge? (specifically: Reason for rejection / retry?)