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

From: Roman Danyliw <[email-masked]>
Date: Tue, 11 Aug 2020 01:22:22 +0000

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 <[email-masked]>
> Sent: Tuesday, July 28, 2020 11:38 AM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; draft-ietf-anima-autonomic-control-
> [email-masked]; [email-masked]; [email-masked]; Sheng Jiang
> <[email-masked]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-
> plane-27: (with DISCUSS and COMMENT)
> 
> Thanks a lot, Roman, very helpfull review.
> 
> Diff:
> 
> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draf
> t-ietf-anima-autonomic-control-plane-
> 27.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-
> 28.txt
> 
> Inline
> 
> On Tue, Jul 14, 2020 at 08:03:00PM -0700, Roman Danyliw via Datatracker
> wrote:
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-anima-autonomic-control-plane-27: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> 
> Btw: WG members asked me how to determine if reviews like your raise up to
> the level of a DISCUSS or just to the level of very good editorial feedback.
> 
> As an author, i am not interested in that meta-discussion, but with the root
> cause for the concern, which is the timely closure of the DISCUSS.
> 
> To that end, the authors think all DISCUSS worthy points raised have been
> resolved or satisfatory answered and would therefore hope for a timely closure
> of the DISCUSS ;-))
> 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-pl
> > ane/
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > ** As normative behavior is specific for BRSKI (e.g., Section 6.1.5
> > and 6.1.5.5), please make it a normative reference
> 
> Hmmm... Right. At an earlier stage, we intentionally downgraded BRSKI from
> normative to informational, when we started to rewrite ACP so its clear how to
> implement it with non-BRSKI registrars and BRSKI became fully optional.
> 
> Resolution:
> 
> I have changed BRSKI to normative.

Thanks!
 
> Let me know if informative wold still be corect given the optional naure of
> BRSKI for ACP.
>
> > ** Figure 2???s definition of acp-address is ???acp-address = 32HEXLC
> > | "0"???.  The following text references a 32HEXDIG but that isn???t
> > in the definition of acp-address.
> >
> > -- Section 6.1.2.  ???Nodes complying with this specification MUST be
> > able to receive their ACP address through the domain certificate, in
> > which case their own ACP domain certificate MUST have the 32HEXDIG "acp-
> address" field.???
> >
> > -- Section 6.1.3.  ???The candidate peer certificate's acp-node-name
> > has a non-empty acp-address field (either 32HEXDIG or 0, according to Figure
> 2).???
> 
> Resolution:
> 
> Thank you so much. Embarrassing inconsistant edit in -23 to move from
> 32HEXDIG to lower case 32HEXLC. Fixed.

Makes sense.  I figured it was something simple.  Thanks.

> > ** Precision in bounding the cipher selection.
> >
> > -- Section 6.7.2.  Per ???Symmetric encryption for the transmission of
> > secure channel data MUST use encryption schemes considered to be
> > security wise equal to or better than AES256???, which property of
> > AES-256 is being considered for this assessment?
> 
> Key strength.
> 
> Resolution:
> 
> ... considered to be security wise equal to or better than 256 bit key strength,
> such as AES256
> 
> > -- Section 6.8.2.  Per ???TLS for GRASP MUST offer
> > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
> > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer
> options
> > with less than 256bit AES or less than SHA384???, please state this more
> precisely.
> 
> Also  key strength.
> 
> Resolution:
> 
> MUST NOT offer options with less than 256 bit symmetric key strength or hash
> strength of less han SHA384
> 
> > -- Is it that AES-128 shouldn???t be used or that that AES-256 has a
> > certain key strength to which to adhere to?
> >
> > -- Is it that SHA-224 or SHA256 shouldn???t be used (staying in the
> > SHA-2 family) or is it a certain number of bits of security ?
> 
> Note:
> 
> If my proposed text does not fix it according to what a security expert would
> write, could you be so kind and propose text ? This polishing of security
> sentences has been going on a lot, mostly because i do not get proposed better
> text but just rejections of the text i attempt to write after reading a lot of
> security RFCs, and probably wastig a lot of time in the process.

The proposed edits work for me and provide the needed clarification. 

> > ** The text specifies the need for physical controls.  Please be more
> > specific on the appropriate degree of that physical control or how
> > that decision should be made; and explicitly explain threat of concern.
> >
> > -- Section 8.1.1.  ???Thus, the ACP connect interface and NOC systems
> > connected to it needs to be physically controlled/secured.???
> 
> Resolution:
> 
> <t>Physical controlled/secured means that attackers can gain no access to the
> physical device hosting the ACP Edge Node, the physical interfaces and links
> providing the ACP connect link nor the physical equipment constituing the NOC
> Device. In a simple case, ACP Edge node and NOC Device are co-located in a
> physcially access controlled room, such as a NOC, to which attackers can not
> gain physical access to.</t>

Thanks.

> > -- Section 8.1.5.  ?????? the ACP connect link and the nodes connecting to it
> must
> > be in a contiguous secure   environment, hence assuming there can be no
> > physical attack against the devices.???
> 
> Resolution:
> 
> Text replaced with:
> 
> See <xref target="acp-connect"/>.
> 
> Aka: removed text,
> replaced with pointer to above enhanced text so as not to duplicate the
> explanatory text.

Thanks.

> > ** (???discuss discuss???) Section 8.1.2.  What is the normative
> > behavior being specified in this section?  Specifically, what is the
> > additional or more restrictive behavior for the circumstance is where an ACP
> node is virtualized.
> 
> Resolution:
> 
> No text change, but following explanation:
> 
> The difference is that in the case of two physcial devices conneced with a non-
> encrypted link, the effort of "physical security"/access-control is a
> problem/requirement that makes ACP-connect a "workaround", because the
> overhead of physical security is higher than that of a cryptographically secured
> channel between the ACP nodes.
> 
> When ACP-Edge-Router and NOC-Device are just e.g.: two VMs running on the
> same device, and the ACP connect link is a virtual linux bridge link, then this is
> not a workaround anymore but a good solution because:
> 
> a) There is no need for physical security anymore (locked room, authenticate
>    people who get access, etc. pp)
> 
> b) it does not have to be set up manually (bysically create access protected
>    room, wire up two devices), but can be orchestrated automatically by
>    software.
> 
> c) The remaining security problem of how to ensure that all the software
>    components within the systems are protected against attack, including
>    the virtual link between the NOC software component and the ACP Edge
> node
>    sotware component is no different than securing the software on any
>    ACP node.
> 
> I was hoping the text was making this clear. If there is additional text you want
> to propose for the document to support this explanation, pls. do so, but i
> already felt the existing tex was a good, more compact representation of what i
> elaborated above. If that is not the case, then it is easier for someone like you
> (reader) than me to suggest text that could be better understood.

Ok.  Thanks for that explanation.

> > ** Section 8.2.1.  (I???m no ABNF expert ???) Per the ABNF in Figure 17, the
> ???//=???
> > notation isn???t valid.  I think you want:
> >
> > OLD
> >      method //= [ "DTLS",    port ]
> >
> > NEW
> >      method =/ [ "DTLS",    port ]
> 
> Resolution: fixed text
> 
> Thanks a lot. No idea how this happened. Maybe i was confused with CDDL...
> Too many formal languages all slightly different *sigh*

Thanks.  I had to look-up the ABNF syntax rules just to be sure :-)

> > ** Section 10.2.1.  Per ???An attacker will not be able to join the
> > ACP unless having a valid domain certificate, also packet injection
> > and sniffing traffic will not be possible due to the security provided
> > by the encryption protocol.???, please be clearer:
> >
> > -- on path attacker = no packet injection
> > -- on path attacker = only traffic analysis when sniffing
> 
> Resolution:
> 
> Proposed fixed text:
> 
>                        <t>Attacker will not be able to join the ACP unless they have a
> valid ACP domain certificate. On-path attackers without a valid ACP domain
> certificate can not inject packets into the ACP due to ACP secure channels. They
> can also not decrypt ACP traffic except if they can crack the encryption. They
> can attempt behavioral traffic analysis on the encrypted ACP traffic.</t>
> 
> > -- compromised node = can inject traffic
> 
> Actually, we aim higher.
> 
> Resolution:
> 
> <t>The degree to which compromised ACP nodes can impact the ACP depends
> on the implementation of the ACP nodes and their impairment. When an
> attacker has only gained administrative privileges to configure ACP nodes
> remotely, the attacker can disrupt the ACP only through one of the few
> configuration options to disable it, see <xref target="enabling-acp"/>, or by
> configuring of non-autonomic ACP options if those are supported on the
> impaired ACP nodes, see <xref target="workarounds"/>. Injecting or ectracting
> traffic into/from an impaired ACP node is only possible when an impaired ACP
> node supports ACP connect (see <xref target="ACPconnect"/>) and the attacker
> can control traffic into/from one of the ACP nodes interfaces, such as by having
> physical access to the ACP node.</t>
> 
> This should be a fair assessment. Of course this is not inclusive of attacks
> against aspects of the node which are outside the AP spec.
> 
> [ Note that there are of course ideas for extension work to overcome these
> issues. ]

This works for me.  Thanks.

> > ** Section 11.  Per ???an ACP is self-protecting and there is no need
> > to apply configuration to make it secure???, if this assertion is going to be
> made:
> 
> Proposed rewrite of this paragraph:
> 
> <t>A set of ACP nodes with ACP certificates for the same ACP domain and with
> ACP functionaliy enabled is automatically "self-building": The ACP is
> automatically established between neighboring ACP nodes. It is also "self-
> protecting": The ACP secure channels are authenticated and encrypted.</t>
> 
> Aka: removed reference to registrar etc... (see explanation below), and "no
> configuration required".
> Primarily because "no configuration required" is somewhat duplicate from
> "automatically".
>
 >
> > -- please specify the security services/properties in a normative
> > section (not in the informative text in Section 10).
> 
> Statements of high level security properties do IMHO not have to be normative
> text because they are an assessment, not a definition. I think this is quite
> common for security consideration sections from what i read in other RFCs. The
> definitions of protocol machinery and properties of data objects like certificates
> to achieve those claimed properties on the other hand have to be normative,
> and they are - in section 6.>
> 
> >
> > -- please also be clear on what configuration is being referenced.
> >
> 
> Much easier to remove as done above. I was thinking of the typical config that
> would be required to create an ACP on a non-ACP device, e.g.:
> VRF (lite), virtual/loopback interfaces, IPv6 addressing, IPSec config, RPL routing
> config, but not enough value IMHO to elaborate about this here.
> 
> Of course, not 100% the same, non-autonomic nodes would not have the new
> GRASP protocol for discovery. But for the rest, you could get pretty cloe on an
> existing non-ACP capable router through config. After all thats the idea of
> ANIMA being in OPS - reuse what we have experience with.

The new text defines "self-protecting" which is the clarity I was (really) seeking.  This current text works.

> > ** 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.

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > (Preliminary ballot.  Need to double check that all of ekr's discusses
> > were
> > cleared)
> >
> > The style of explaining the design choice after describing an element
> > of the protocol was informative and helpful.  Thanks.
> >
> > The this document has undergone a significant amount of security
> > review.  Thank you for incorporating all of this feedback.
> 
> Thanks. If the feedack from the security reviewers would have included more
> proposed text it would have been faster. Maybe i wouldn't have learned as
> much about security as i did this way, but it was kinda painfull for the WG
> because it was lengthy.
> 
> > ** Section 6.  It doesn???t seem appropriate to call a protocol
> ???indestructible???
> > unless you are going to enumerate the resiliency properties more precisely
> ???
> > ???many inadvertent changes??? is vague.
> 
> ACP is not a protocol. Its a system and node-wide design with the goal to be
> "indestructible". Obviously, this is a name-calling to summarize a wide range of
> benefits, hence it is in parenthesis.
> 
> Proposed text:
> 
> <t>This section describes the components and steps to set up an ACP and
> highlights the key properties which make it "indestructible" against most
> changes to the Data-Plane, including misconfigurations of routing, addressing,
> NAT, firewall or any other traffic policy filters that inadvertently or otherwise
> unavoidably would also impact the management plane traffic, such as the
> actual operator CLI session or controller NetConf session through which the
> configuration changes to the data-plane are executed. Physical
> misconfiguration of wiring between ACP nodes will also not break the ACP as
> long as there is a transitive path between ACP nodes, the ACP should be able to
> recover given that it automatically operates across all interfaces of a ACP
> nodes. Attacks against the network via incorrect routing or addressing
> information for the data-plane will not impact the ACP. Even impaired ACP
> nodes will have a significantly reduced attack surface against malicious
> misconfiguration because only very limited ACP or interface up/down
> configuration can affect the ACP, and pending on their specific designs these
> type of attacks could also be eliminated. See more in <xref target="enabling-
> acp"/> and <xref target="security"/>.</t>
> 
> > ** Section 6.  Per ???An ACP node can be ??? or any other IP a capable
> > node???, should this be ???IPv6 capable node????
> 
> Fixed.
> 
> I was coming from practical experience, where devices are sold as IPv4 only for
> price/market differentiation. Those devices could typically easily add the IPv6-
> only ACP even though the Data-Plane was IPv4 only. I hope by now those
> sales/marketing models are not possible anymore ;-)
> 
> > ** Section 6.1.1.  Per ?????? it is beneficial to copy the device
> > identifying fields of the node's IDevID certificate into the ACP
> > domain certificate ??????, is there a ACP-recommended approach for that?
> 
> No, because its part of what the registrar does, and even though ANIMA
> defines BRSKI to be the preferred registrar protocol, ACP itself and to be be
> widely reuseable describes registrar behavior as abstract as possible.
> 
> For example, IETF also has NetConf zerotouch, which could be used or any
> proprietary mechanism. Its IMHO easy in all cases given how the expectation is
> that the registrar needs to knows the pledges IDevID to securely identify the
> pledge, and in all protocols i have seen, the registrar is in the position to make
> sure the pledges pledges certificate has components in it that are needed. For
> BRSKI this is specified in BRSKI.
> 
> > ** Section 6.1.3.1. Per ???In the absence of implementing a secured
> > mechanism, such an ACP node MAY use a current time learned in an
> > insecured fashion in the ACP domain membership check.???, please be
> > clearer on how this current time is learned in the domain membership check.
> 
> Proposed text:
> 
> <t>Current time MAY for example be learned via NTP (<xref
> target="RFC5905"/>) over the same link-local IPv6 addresses used for the ACP
> from neighboring ACP nodes.
> ACP nodes that that do provide NTP insecure over their link-local addresses
> SHOULD primarily run NTP across the ACP and provide NTP time across the ACP
> only when they have a secure time source. Details for such NTP procedures are
> beyond the scope of this specification.</t>
> 
> There is obviously a chicken&egg problem: If you have a bunch of cheap no-RTC
> routers waking up from total power faillure and trying to get together again,
> the best outcome to have is to build ACP  like it is Jan 1 1970. If at least one of
> those devices does have an RTC, it would start NTP across the ACP and the
> others would sync to it.
> 
> The details of all of this are another extension RFC to ACP, although i guess it
> can become quite convoluted to describe the autoconfig and all corner cases.
> Hence i tried to avoid going down this path in this doc too much.
> 
> The text above is roughly what i've used in practice with enterprise IPsec VPN
> setups where alas a lot of spoke routers didn't hve RTC.
> 
> > ** Section 6.1.5.  Per ???ACP nodes SHOULD be able to remember the
> > IPv6 locator parameters ...???, what happens if they don???t remember?
> 
> ACP is meant to support many, even uncoordinated registrars. That is why the
> addressing scheme has a registrar-ID in the client addresses so that registrars
> can independently of each other assign ACP addresses to clients via their certs
> without conflicting with each other.
> 
> If you only do renewal via EST then it is purely a simplification of diagnostic
> that you are doing renewal always with the registrar you originally got your
> cert from. The renewal would easily be the same going to any other registrar,
> but the logs on the registrar would then not nicely have only the info about the
> clients that they initially enrolled.
> 
> When clients expire their certs and need to re-enroll, it gets harder to get the
> same ACP address again if you do not go to the same original registrar.
> There is text for that later in the doc explaining how registrars can still attempt
> to honor the original cert ACP address, but this functionality is probably
> something we need anothre extension document for with LAMPS involved
> (registrars honoring expired certs for the purpose of renewal).
> 
> Changing ACP address under such circumstances is fine for ACP itself, but more
> work for a backend system having to track such change of addresses (having to
> keep track of e.g.: IDevID and changing LDevID/ACP-address).
> 
> > ** Section 6.1.5.3.  Per ???The connecting ACP node SHOULD verify that
> > the CRLDP certificate used during the HTTPs connection has the same
> > ACP address as indicated in the CRLDP URL ??????, why is this not a MUST?
> 
> Unlike non-CRL setups, i have no practical deployment experience with CRL.
> To the best of my understanding, the content of a CRL itself is protected such
> that you can have it relayed through e.g.: caches or the like.
> Hence the additional address is just another layer of security whose added
> value vs the additional limitations for deployability it may bring are unclear.
> Hence a SHOULD.
> 
> Eg.: In one example, i had to build an ACP connect through IPv6/IPv4 NAT
> because some backend in customers NOC did not support IPv6.
> 
> > ** Section 6.1.5.5.  Per ???An ACP node may determine that its ACP
> > domain certificate has expired ??? [i]n this case, the ACP node SHOULD
> > convert to a role of a re-enrolling candidate ACP node???, what is the
> > alternative if it wants to connect back to the network?  Shouldn???t this be a
> MUST?
> 
> This goes back to above mentioned IMHO more desirable, but not yet not
> documented or well enough discussed option of simply permitting renewal
> instead of re-enrollment with an expired cert. Logically the argument for that is
> that the lifetime in a cert does not necessarily have to be a limiter to the
> registrar+CA renewal operations because that is not a normal "use" of the
> certificate, and that is whats to be imited by the lifetime.
> 
> When i was operating an enterprise VPN headend for a while i recurringly had
> the eperience that long-time switched off VPN spokes where reactivated, then
> the user asked in email why his VPN router does not work, and then in the
> absence of better options i had to disable lifetime checks for this cert on the
> headend temporarily to get renewal working. (obviuosly, the phone call was
> the additional attestation for the node with the expired cert to be assumed to
> be still "trusted").
> 
> Re-enrollment can vary widely in complexity based on the registrar used - even
> with BRSKI, there are lot of MASA options, So it can be ACP career limiting for
> specific type of registrars if this was a MUST.
> 
> There is one specifically preferred option which would have to go into a
> followup document, which is to use BRSKI and BRSKI proxy together with the
> expired cert to renew. This exactly would only involve the registrar having to
> honor the expired cert, but not the ACP. So its not really re-enrolling (which
> would use the IDevID and MASA), but it would use the BRSKI enrollment infra
> (BRSKI-proxy).
> 
> > ** Section 6.5.  It seems misplaced to describe MacSec as an option
> > for channel security even when it is not a profiled in this document.
> 
> I disagree. It is IMHO important to provide important fundamental explanations
> of the extension points of the ACP architecture, and that is most easily done
> through examples.
> 
> MacSec is a highly desirable extension option because it is the most widely
> cross-platform HW-accelerated encryption option, so it is a good example to
> use in a sentence.
> 
> Remember, this is an OPS area system specification where operational and
> architecture aspects are important. Also we where asked not to have a
> separate architecture document by the initial AD to the WG.
> 
> > ** Section 6.7.2. Per ???Signaling of TA certificates may not be
> > appropriate when the deployment is relying on a security model when
> > the TA certificate content is considered confidential???, where is the
> > requirement to signal TA certificates discussed.  How would this
> > selection of signaling a TA work?  The entire paragraph prior seemed
> > to explicitly discuss that the TA doesn???t need to be shared.
> 
> The previous paragraph to the one you are citing explicitly says:
> 
> | Nevertheless, for use with ACP secure channel setup, there SHOULD be
> | the option to include the TA certificate in the signaling to aid
> | troubleshooting, see <xref target="ta-troubleshoot"/>.
> 
> I had exhaustive discussions about this on the ipsec mailing list to derive at the
> acceptable option, whose details are in the IPsec section of the ACP
> (aka: including the TA in the signalled IKEv2 messages without having to
> extend IKEv2, but just relying on permissible existing IKEv2 options).
> 
> > ** Section 6.7.2.  Per ???When introducing the profile for security
> > association protocol ??????, I recommend being clearer to whom you are
> providing this advice.
> > This seems to for operators of ACP infrastructure technology (not
> > implementers/vendors of ACP technology)
> 
> Actually it is definition of extension point requirements for implementers, so i
> am sad to learn it is misreadable as an operator related text.
> 
> Proposed fix:
> 
> <t>When specifying additional security association protocol for ACP secure
> channel use beyond those covered in this document, protocol options SHOULD
> be eliminated that are not necessary to support devices that are expected to be
> able to support the ACP.
> 
> > ** Section 6.7.3.  Per ???The ACP usage of IPsec and IKEv2 mandates a
> > profile with a narrow set of options of the current standards-track usage
> guidance for
> > IPsec    [RFC8221] and IKEv2 [RFC8247]???, should there be normative
> wording use
> > (MUST) instead of a ???mandates????
> 
> The actual normative (rfc2119) requirements of the IPsec profile are later in the
> section.
> This initial text gives just the overview.
> 
> Saying something like "you MUST comply with the normative requirements
> described later on in this text" would be only confusing and not helpfull.
> 
> > ** Section 6.7.3.1.1.  Per ENCR_CHACHA20_POLY1305, ???[t]herefore this
> > algorithm is only recommended???, shouldn???t it read as RECOMMENDED?
> 
> Again avoiding IMHO unhelpfull duplication of rfc2119 language. The
> normative requirement was earlier in the section:
> 
> | ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher
> | performance than ENCR_AES_GCM_16. If that performance is not feasible, it
> MAY be supported.
> 
> The paragraph you mention is explanation of that prior normative requirement.
> 
> > ** Section 6.7.3.1.2.  Per ???[RFC8247] provides a baseline recommendation
> for
> > mandatory to   implement ciphers, integrity checks, pseudo-random-functions
> and
> > Diffie-Hellman mechanisms.  Those recommendations, and the
> > recommendations of subsequent documents apply well to the ACP.???, it
> > seems like normative language should be used to adhered to.
> 
> Oops. With the rewrite of this section in the last revisions, the MUST 8247
> actually vanished. Great catch.
> 
> The text above is introduction, the proposed fix is after that paragraph:
> 
> | ACP Nodes supporting IKEv2 MUST comply with <xref target="RFC8247"/>
> | amended by the following requirements which constitute a policy
> | statement as permitted by <xref target="RFC8247"/>.
> 
> > ** Section 6.10.7.3.  The paragraph/sentence starting with ???ACP
> > registrars that are aware of can use ?????? doesn???t parse.  The guidance
> isn???t clear as a result.
> 
> Apologies. trash left fixing the sentence. Fixed text and added explanation:
> 
> ACP registrars that are aware of the IDevID certificate of a candidate ACP
> device...
> 
> ... The PID for example could identify type of devices allowing for specialized
> ASA requiring multiple addresses or non-autonomic VMs for services and those
> nodes could receive Vlong sub-address scheme ACP addresses.</t>
> 
> > ** Section 6.10.7.3.  Per ???In a simple allocation scheme, an ACP
> > registrar remembers persistently across reboots ??????, what???s the
> > recover step if it loses that state?
> 
> Proposed added text:
> 
> <t>If allocated addresses can not be remembered by registrars, then it is
> necessary to either use a new value for the Register-ID field in the ACP
> addresses, or determine allocated ACP addresses from polling the ACP network
> nodes.  Non-tracked ACP addresses can be reclaimed by revoking or not
> renewing their certificates and instead handing out new certificate with new
> addresses (for example with a new Registrar-ID value). Note that such
> strategies may require coordination amongst registrars.</t>
> 
> > ** Section 6.11.1.1.2.  Not clear what ???DODAG Information Objects
> > (DIOs) SHOULD be sent 2 .. 3 times??? means ??? can ???2 .. 3??? please be
> clarified.
> 
> proposed fix:
> 
> SHOULD be sent 2 or 3 times
> 
> (actual value 2 or 3 left for experimentation, this seems to be a necessary and
> sufficient  range from similar protocol experiences).

All of the above proposed changes makes sense.  Thank you for them.  Also, where no changes were made, I appreciated the explanaition.

> > ** Section 6.11.1.1.2.  A mechanism for failed ACP detected using a
> > secure channel protocol is noted for IPSec (with IKEv2 Dead Peer
> > Detection).  What is the equivalent for DTLS?
> 
> Good question. If you know someone who could suggest an equivalent, please
> bring her in. Given how this is a performance optimization, i don't think we
> need to bother too much. I hope we can learn from
> implementation/deployment experience (i only hve that for IPsec) and then
> write update text later with such refinements.

Sorry, I too don't have citable reference.  Let's leave it as is.

> > ** Section 9.  The section notes that Section 9.1 is ???derived from
> > diagnostic of a commercially available ACP implementation???.  The
> > shepherd report from
> > 03/2019 notes that there are no implementations of ACP.  If this is
> > documented somewhere, it would be very compelling to cite it.
> 
> I have deleted that sentence again.  This was not appropriate for the RFC, we
> can discuss this on the list or offline.
> 
> > ** Section 9.1. Per ???The basic diagnostics [sic] is support of
> > (yang) data models representing the complete (auto-)configuration and
> > operational state of all components ??????, are these YANG models defined?
> Are there references?
> 
> Changed to:
> 
> Basic standardized diagnostics would require support for (yang) models ...
> 
> Wrt to the question: The existing components used by ACP should have YANG
> models given how long they have been in use, but they don't necessarily seem
> to have them.
> Eg there as some IPSECME targeted draft like draft-tran-ipsecme-yang-01.txt,
> not sure why that died, one could maybe use rfc8049 to represent the VRF for
> ACP (not sure), there is an initial dradt for RPL (draft-ietf-roll-mpl-yang-02).
> From talking to Kent Watson, the situation for certificates looks better, e.g.:
> draft-ietf-netconf-trust-anchors.
> 
> Once we have these ACP/GRASP/BRSKI specification RFCs out, we'll be looking
> for interested Yang geeks to help with ACP/GRASP yang models. The existing
> spec intends to be an informal starting point towards such future  yang work,
> but there will no more detailling of what is or is not available in IETF yang
> world.
> Thts a job by itself best done fofr an acp yang rfc. I have some work i started
> from 3 years ago lying around...
> 
> > ** Section 9.3.1.  Per ???Whenever this document refers to enabling an
> > interface for ACP ??? it only requires to permit [sic] the interface
> > ??????, this seems like normative behavior in an informative section.
> 
> What is the purpose of the [sic] notation ?
> 
> IETF does not allow to raise normative requirements against informal operator
> interface decription, which is what this section is. I guess that would require a
> formal CLI model which we don't have.  Hence the normative requirements
> could only come from a YANG model.
> 
> Hence this section is informational. It is also good to not formalize a normative
> operator interface without first having enough experience collected IMHO.
> 
> > ** Section 9.3.2.  That this is an information section is noted.  It
> > would benefit from describing what precisely can and cannot be done in
> > the three states proposed ??? up, down and admin down.
> 
> Hmm... i think it says everything it can say, except... see your following point.
> 
> > ** Section 9.3.2.1.  What is the proposed threat that using admin down
> > is intended to mitigate?  Under what circumstance should it be invoked?
> 
> Great. I remember we went several times through this text especially with
> routing directorate, but nobody noticed that the simple core example was not
> explicitly written down. Instead we had good discuss about the proposed how
> (separartion of down insto adin-down/physcial down). Which is a good reason
> too not to have this section normative yet. But i digress.
> 
> I added the following paragraph to the section. The configuration summary
> section actually already summarizes this core reason as well, but it really needs
> to be in this section.
> 
> <t>One of the common problems of remote management is for the operator or
> SDN controller to cut its own connectivity to the remote node by a
> configuration impacting its own management connection into the node. The
> ACP itself should have no dedicated configuration other than aforementioned
> enablement of the ACP on brownfield ACP nodes. This leaves configuration that
> can not distinguish between ACP and Data-Plane as sources of configuration
> mistakes as these commands will impact the ACP even though they should only
> impact the Data-Plane. The one ubiquitous type of commands that do this on
> many type of routers are interface "down" commands/configurations. When
> such a command applied on the interface through which the ACP provides
> access for remote management it would cut the remote management
> connection through the ACP because (as outlined above), the "down"
> commands typically impact the physical layer too and not only the Data-Plane
> services.</t>
> 
> <t>To provide ACP/ANI resilience against such operator misconfiguration, ...

Thanks for this clarifying text.  I lacked the history.

> > ** Section 9.3.2.1.  Per ???"Admin down" state as described above
> > provides also a high level of security because it only permits ACP/ANI
> > operations which are both well secured???, to what is the ???both???
> > referring? I suspect this is editorial (but just in case, noting here).
> 
> Added sentence in before for more missing explanation:
> 
> <t>An example of non-ACP but ANI traffic that should be permitted to pass
> even in "admin-down" state is BRSKI enrollment traffic between BRSKI pledge
> and a BRSKI proxy.</t>
> 
> Now the answer to your question is that the "both" in the sentence you ask
> about refers to ACP/ANI (both ACP and ANI).  If this is not good english, pls. let
> me know.

Works for me.

> > ** Section 10.2.2.  Per ???For example, management plane functions
> > (transport
> > ports) should only be reachable from the ACP but not the
> > Data-Plane???, this seems like good guidance.  Is there a reason not
> > to upgrade this informative statement and put it the Security Considerations
> as normative guidance?
> 
> Give it time. We're in round 1:
> 
> Existing router management plane host stacks may have severe issues
> separating out access by VRF context. I remember some of the per-VRF SMI
> work.
> 
> Enterprise operators may have severe issues with this short-term. For example,
> the typical solution would be for network admins to have to VPN back into
> some headend from where the ACP is accessible. That is a lot of pain especially
> when you are trying to troubleshoot locally and the headend is remote.
> 
> To make future network admin staff work not more convoluted because of
> ACP, but actually more secure AND easier, we need some easily useable ACP-
> access method for e.g. network admin notebooks. Given how i at times had 4
> VPNs on my notebook and at most 2 VPN would work at the same time, i am
> not sure if this documents IPsec spec would be good for operator notebooks.
> But maybe an ACP acces method via 802.1x... TBD.
> 
> > ** Section 10.2.2.  Per ???Protection across all potential attack
> > vectors is typically easier to do in devices whose software is
> > designed from the ground up with security in mind than with legacy
> > software based systems where the ACP is added on as another
> > feature???, no argument on the general principle.  However, as it relates to
> ACP:
> 
> Changed text "security in mind" -> "ACP in mind".
> 
> I think there a initiatives looking at secure devices, but thats not the same as
> stricter isolation between ACP and the rest of the system.
> 
> > --what???s an example of the legacy software?
> 
> I had a presentation about designs for ACP a few years back in an IEEE
> conference touching those aspects.
> 
> To me, legacy is probably most router software infra today, where you would
> need to implement ACP as one of many VRFs that the software may already
> already support as part of e.g.: L3VPN or similar services.
> 
> Non-legacy is something where the router is actually a VM or container running
> on a hypervisor. And ACP would be part of the hypervisor (e.g.: linux). Or where
> ACP does not even run on the same CPU/FPE as the router, but on e.g.: BMC
> HW/software (OpenBoot etc..). Lots of interesting design choices possible.
> 
> > -- as noted in the shepherd report from 03/2019, there are no
> > implementations, so is there reason to believe that this is going to put on
> ???legacy??? platforms?
> 
> Lets use different mail threads to discuss this.
> 
> > ** Section 10.2.2.  Per ???As explained above, traffic across the ACP
> > SHOULD still ??????, is RFC2119 language really intended in this informative
> section?
> 
> Fixed to lower case. Thanks.
> 
> > ** Section 11.  Per ???Security can be compromised by implementation
> > errors (bugs), as in all products???, given the generic nature of this
> > statement, couldn???t it also be a configuration error in the product too?
> 
> ;-) Not really because the claim of ACP is that all the core parts of ACP have no
> configuration. See section 9.5.

Short of some formally verified systems, this statement seems true of almost every system.  I didn't consider it actionable and would have removed it (again just editorial feedback in this case).

> Given how more than 50% of the whole document to me feel like talking about
> security, i do have a hard time figuring out a mandatory logic of what belongs
> into section 11. My solution  was that it is a mixture of important summaries
> and then tidbits that didn't have a better place to be explained.
> 
> Given how the topic of configuration and misconfiguration of ACP was
> exhaustively discussed in prior sections, i didn't feel the need to add it here
> again.
> 
> But always happy to consider proposed text.
> 
> > ** Section 11.  Per ???Higher layer service built using ACP domain
> > certificates should not rely on undifferentiated group security ??????
> > is there a reason not to make this a normative SHOULD?
> 
> section 11 is not normative, and actual normative requirements for new stuff
> across the ACP is something that was not in charter when we defined this
> document,
> aka: i wouldn't have a logical place in this doc for this beside as a general
> security considerartion.
> 
> Writing normative about ASA IMHO just became possible after recharter of WG
> last year, so i would want to put normative requirements about this probably
> into ASA docs we are starting to write.
> 
> > ** Editorial
> >
> > -- Recommend being consistent on either ???ACP domain certificates???
> > or ???ACP certificates???
> 
> ACP certificates.
> 
> > -- Section 1.  Editorially.  The two sentences ???Section 7 defines
> > normative how to ?????? and ???Section 8 explain normative how ??????
> > don???t parse as the adjective normative needs a noun to modify.
> 
> Fixed by putting (normative) at the end of the sentences.
> 
> > -- Section 6.1.4.  Editorial.  s/These requirements can be achieved by
> > using TA private/These requirements can be achieved by using a TA
> > private/
> 
> fixed
> 
> > -- Section 6.2.  Editorial. s/does intentionally not/intentionally
> > does not/
> 
> fixed
> 
> > -- Section 6.5.  Editorial.  Per ???Note that MacSec is not required
> > by any profiles of the ACP in this specification but just mentioned as
> > a likely next interesting secure channel protocol.???, does not parse.
> 
> Fixed by separating sentences: Instead, MacSec is mentioned as ...
> >
> > -- Section 6.10.7.  Per ???ACP registrars are responsible to enroll
> > candidate ACP nodes with ACP domain certificates and associated trust
> point(s)???, is a trust
> > point the same thing as a trust anchor?    If so, I recommend being consistent.
> >  If not, then please define it.
> 
> Oops. how did that slip through. Thought i had fied all points to be anchors.
> Fixed now.
> 
> > -- Section 6.11.1.  Please make draft-ietf-roll-applicability-template
> > a reference.
> 
> Already in -27.
> 
> > -- Section 6.11.1.5.  Editorially.  It might be worth framing the path
> > metric in the form of sentence.
> 
> Fixed to:
> Use Hopcount according to xref target="RFC6551"
> >
> > -- Section 11. s/enemy plegdes/rogue pledges/
> 
> Was already fixed in -27 to "malicious registrar"
> (on prior reviewer suggestion i think)
> 
> > -- Section 11. Per ???Fundamentally, security depends on avoid
> > operator and network automation mistakes ??????, this paragraph is not
> > actionable.  Recommend removal.
> 
> Fixed with proposed replacement paragraph:
> 
> <t>Operators and provisioning software developers need to be aware of how
> the provisioning/configuration of network devices impacts the ability of the
> operator / provisioning software to remotely access the network nodes. By
> using the ACP, most of the issues  of configuration/provisioning caused loss of
> connectivity for remote provisioning/configuration will be eliminated, see <xref
> target="self-creation"/>. Only few exceptions such as explicit physical interface
> down configuration will be left <xref target="admin-down"/>.</t>
> 
> First sentence should now be actionable to operators/developers.
> Second summarizes benefits of ACP. Third gives example of limitations.
> 
> Core value proposition of ACP hence useful to not just eliminate in security
> section (assuming certain readers will primarily read security section).
> 
> This answers the actionable point. whether or not misconfiguration that makes
> a network become unmanage is a security issue, i can't judge, because i am not
> sure i know a precise definition of "security"
> 
> 
> > ** Typos
> > Section 1.  Typo. s/parth/path/
> > Section 1.  Typo. s/seperately/separately/ Section 1.  Typo.
> > s/automaticically/ automatically/ Section 1.  Typo. s/managemenet/
> > management/ Section 1.  Typo. s/absene/absence/ Section 1.1.  Typo.
> > s/solution:/solution/ Section 2.  Typo. s/netork/network/ Section 2.
> > Typo. s/physcially/physically/ Section 5.  Typo. s/(see (see/(see/
> > Section 5. Typo. s/loopack/loopback/ Section 6.1.1.  Typo.
> > s/e.g.:signing/e.g., signing/ Section 6.1.1.  Typo.
> > s/signalled/signaled/g Section 6.1.1.  Typo. s/bei/by/ Section 6.1.2.
> > Typo. s/simpy/simply/ Section 6.1.2.  Typo. s/readible/readable/
> > Section 6.1.2.  Typo. s/Adresses/Addresses/ Section 6.1.2.  Typo.
> > s/manadatory/mandatory/ Section 6.1.2. Typo.
> > s/inapproprite/inappropriate/ Section 6.1.3.1.  Typo. s/as as/as/
> > Section 6.1.3.1.  Typo. /insecured/insecure/ Section 6.1.3.1.  Typo.
> > s/likley/likely/ Section 6.2. Typo. s/IKEv2 has am/IKEv2 has an/
> > Section 6.7.2.  Typo. s/successfull/successful/ Section 6.7.3.1.1.
> > Typo.  s/superceed/superseded/ (I stopped documenting spelling errors
> > at Section 6.7.3.1.1.  Please run a spell checker before handing this
> > off to the RFC Editor)
> 
> Sorry for this editorial trouble. I was hoping that you would not spend time on
> this. Yes, of course i will do a more thorough check before RFC editor. My
> excuse for not doing it on every rev is quite lame, but i have not found a spell
> checker that remembers all the non-standard words correctly, so a few changes
> in a 160 page document is terrible each time...
> 
> Thanks so much for the excellent review! Please consider removing the discuss.
> 
> Cheers
>     Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Aug 2020 14:11:33 +1200

>> plane-27: (with DISCUSS and COMMENT)

...

> 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, norm…

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

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 12 Aug 2020 15:30:45 +0000

Hi Brian!

> From: Brian E Carpenter <[email-masked]>
> Sent: Monday, August 10, 2020 10:12 PM
> To: Roman Danyliw <[email-masked]>; Toerless Eckert <[email-masked]>
> Cc: [email-masked]; [email-masked];
> The IESG <[email-masked]>; [email-masked]; Sheng Jiang
> <[email-masked]>
> Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-
> control-plane-27: (with DISCUSS and COMMENT)
> 
> > 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
> >
> >>> ** Section 11.  Per the list of factors on which ACP depends, it
> >>> seems like the following are missing:
> >>>
> >>> -- that the security considerations of EST and BRSKI apply (or if
> >>> not, why not)
> >>
> >> Resolution:
> >>
> >> 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.
> >>
> >> 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.
> >>
> > 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:
> 
> 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?
> 

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 15 Aug 2020 21:18:35 -0700

> Sorry, I too don't have citable reference.  Let's leave it as is.

DTLS heartbeats (RFC 6520) would probably be the closest thing to IKE dead
peer detection, but it's not a perfect match.
(Also, openssl removed all support for heartbeats recently-ish, even for
DTLS; I guess heartbleed left too many painful memories.)

-Ben