Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-27: (with DISCUSS and COMMENT)

[Brian E Carpenter <[e-mail]>]

On 11-Aug-20 13:22, Roman Danyliw wrote:
> Hi Toerless!
> 
> Thanks for your detailed follow-up both in the form of the -28 and the helpful explanations below.  I think everything is cleaned up but the last discuss, I will update my ballot so it's easier to manage.
> 
> Roman
> 
>> -----Original Message-----
>> From: Toerless Eckert <[e-mail]>
>> Sent: Tuesday, July 28, 2020 11:38 AM
>> To: Roman Danyliw <[e-mail]>
>> Cc: The IESG <[e-mail]>; draft-ietf-anima-autonomic-control-
>> [e-mail]; [e-mail]; [e-mail]; Sheng Jiang
>> <[e-mail]>
>> Subject: Re: Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-
>> plane-27: (with DISCUSS and COMMENT)

...

> 
>>> ** Section 11.  Per the list of factors on which ACP depends, it seems
>>> like the following are missing:
>>>
>>> -- the security properties of the enrollment protocol
>>>
>>> -- that the security considerations of EST and BRSKI apply (or if not,
>>> why not)
>>
>> Resolution:
>>
>> No change, but the following explanations:
>>
>> The ACP is explicitly defined to be a set of nodes with ACP domain certificates,
>> enrollment/BRSKI is really out of scope. Normative ACP nodes start their
>> existance with an ACP cert. How they got it is part of a prior life. BRSKI security
>> properties are covered in BRSKI draft.
>>
>> I struggled long how to well define registrars given that ACP does not mandate/
>> specify any specific protocol.  The solution in the document is that there is only
>> a very abstract definition of the normative requirements against registrars in
>> 6.10.7, pretty much simple requirements against the resulting certificates such
>> as registrar MUST NOT assign same addresses to multiple nodes for example.
>>
>> Think of a registrar abstractely as this:
>>
>> https://datatracker.ietf.org/meeting/102/materials/slides-102-dinrg-dinrg-
>> anima-toerless-eckert-00
>> Slide 10
>>
>> While funny, its not far away from a possible reality of a network operator
>> being a registrar, provisioning ACP certificates manually into ACP nodes, and
>> performing all the backend operations (CA, MASA, adressing database).
>>
>> BRSKI is of course the ANIMA preferred enrollment protocol, and if it is used,
>> an ACP node is called an ANI node (ACP+BRSKI). Section 3.2 makes the security
>> property of the ACP for any such bootstrap protocol. For example in
>> communities outside of ANIMA, NetConf ZeroTouch might be preferred over
>> BRSKI.
>>
>> The only mandatory ACP part of your above list is EST ONLY for renewal of
>> certificates, an that of course is specified in the normative section.
>>
>> The BRSKI draft itself defines how it integrates with ACP (GRASP objective etc.).
>>
>> Hope this answers satisfactory the concern.
> 
> I reread the Section 11 with your explanation in mind and see your perspective -- it's difficult to be specific without mandating a specific protocol.  However, there seems to be two concrete, normative elements of this architecture -- EST and GRASP.  The latter for bootstrapping and the formal for renewal.  It isn't clear then why their Sec Considerations don't apply.  Furthermore, the protocols and practices of the bootstrapping process are out of scope of this document but seem like a security building block on which ACP is being built.

The use of GRASP for adding a node to the ACP must not rely on the ACP for security, but in "normal life" GRASP must rely on the ACP for security. Although GRASP has been sitting in the RFC queue for >2 years, I think it does cover this fairly clearly:

     2.5.  GRASP Protocol Basic Properties and Mechanisms  . . . . .  12
       2.5.1.  Required External Security Mechanism  . . . . . . . .  12 [that's the ACP]
       2.5.2.  Discovery Unsolicited Link-Local (DULL) GRASP . . . .  13 [that's for booting the ACP]

In other words, GRASP section 2.5.1 depends on ACP security, and ACP security depends on GRASP section 2.5.2. Would a cross reference from ACP to GRASP in the last paragraph of ACP section 11 help?

Also, three paragraphs above, there is this:

   In combination with BRSKI, ACP enables a resilient, fully zero-touch
   network solution...

Would another reference to draft-ietf-anima-bootstrapping-keyinfra there help?

The three documents (ACP, BRSKI, GRASP) really do chase each other's tails.

Regards
   Brian