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

[Roman Danyliw <[e-mail]>]

Hi Brian!

> -----Original Message-----
> From: Brian E Carpenter <[e-mail]>
> Sent: Monday, August 10, 2020 10:12 PM
> To: Roman Danyliw <[e-mail]>; Toerless Eckert <[e-mail]>
> Cc: [e-mail]; [e-mail];
> The IESG <[e-mail]>; [e-mail]; Sheng Jiang
> <[e-mail]>
> Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-
> control-plane-27: (with DISCUSS and COMMENT)
> 
> 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-d
> >> inrg-
> >> 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.

Perhaps I've made it seem that I looking for something more complicated than I really mean.  Sorry I wasn't clearer.  Section 11 makes a list of these dependencies (i.e., "However, the security of the ACP depends on a number of other factors") -- all helpful.  All I was looking for was an explicit acknowledge that the choice of the enrollment protocol and associated practices impact the ACP.  Exactly like you proposed above, reiterate the normative link to the SecCons of BRKSI and EST (since that is also normative for re-enrollment) and let's call this resolved.

Regards,
Roman

> Regards
>    Brian