Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-07.txt

[Toerless Eckert <[e-mail]>]

https://github.com/anima-wg/autonomic-control-plane/issues/1

Diff to -06:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-07.txt

13.13.  draft-ietf-anima-autonomic-control-plane-07

   o  Changed author association.

   o  Improved ACP connect setion (after confusion about term came up in
      the stable connectivity draft review).  Added picture, defined
      complete terminology.

   o  Moved ACP channel negotiation from normative section to appendix
      because it can in the timeline of this document not be fully
      specified to be implementable.  Aka: work for future document.
      That work would also need to include analysing IKEv2 and describin
      the difference of a proposed GRASP/TLS solution to it.

   o  Removed IANA request to allocate registry for GRASP/TLS.  This
      would come with future draft (see above).

   o  Gave the name "ACP information" to the field in the certificate
      carrying the ACP address and domain name.

   o  Changed the rules for mutual authentication of certificates to
      rely on the domain in the ACP information of the certificate
      instead of the OU in the certificate.  Also renewed the text
      pointing out that the ACP information in the certificate is meant
      to be in a form that it does not disturb other uses of the
      certificate.  As long as the ACP expected to rely on a common OU
      across all certificates in a domain, this was not really true:
      Other uses of the certificates might require different OUs for
      different areas/type of devices.  With the rules in this draft
      version, the ACP authentication does not rely on any other fields
      in the certificate.

   o  Added an extension field to the ACP information so that in the
      future additional fields like a subdomain could be inserted.  An
      example using such a subdomain field was added to the pre-existing
      text suggesting sub-domains.  This approach is necessary so that
      there can be a single (main) domain in the ACP information,
      because that is used for mutual authentication of the certificate.
      Also clarified that only the register(s) SHOULD/MUST use that the
      ACP address was generated from the domain name - so that we can
      easier extend change this in extensions.

   o  Took the text for the GRASP discovery of ACP neighbors from Brians
      grasp-ani-objectives draft.  Alas, that draft was behind the
      latest GRASP draft, so i had to overhaul.  The mayor change is to
      describe in the ACP draft the whole format of the M_FLOOD message
      (and not only the actual objective).  This should make it a lot
      easier to read (without having to go back and forth to the GRASP
      RFC/draft).  It was also necessary because the locator in the
      M_FLOOD messages has an important role and its not coded inside
      the objective.  The specification of how to format the M_FLOOD
      message shuold now be complete, the text may be some duplicate
      with the DULL specificateion in GRASP, but no contradiction.

   o  One of the main outcomes of reworking the GRASP section was the
      notion that GRASP announces both the candidate peers IPv6 link
      local address but also the support ACP security protocol including
      the port it is running on.  In the past we shied away from using
      this information because it is not secured, but i think the
      additional attack vectors possible by using this information are
      negligible: If an attacker on an L2 subnet can fake another
      devices GRASP message then it can already provide a similar amount
      of attack by purely faking the link-local address.

   o  Removed the section on discovery and BRSKI.  This can be revived
      in the BRSKI document, but it seems mood given how we did remove
      mDNS from the latest BRSKI document (aka: this section discussed
      discrepancies between GRASP and mDNS discovery which should not
      exist anymore with latest BRSKI.

   o  Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we
      do not specify which one is to be used but that the ACP should be
      used to reach the URL included in the certificate to get to the
      CRL storage or OCSP server.

   o  Changed ACP via IPsec to ACP via IKEv2 and restructured the
      sections to make IPsec native and IPsec via GRE subsections.

   o  No need for any assigned dTLS port if ACP is run across dTLS
      because it is signalled via GRASP.