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

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

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

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

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

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.

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?)