Re: [secdir] Updated rev posted [Re: Review of draft-ietf-mpls-ldp-yang-07]

["Shawn M. Emery" <[e-mail]>]

Thank you for the major update, the Security Consideration section looks
much better.  Here are my comments with rev 08:

1. In section 10.1.2, it states that LDP peer authentication can be
augmented via a key generated with an algorithm such as MD5.  I know it may
be out of scope from this document, but why is MD5 given as an example
rather than scrypt or is the assumption that the keys are based on high
entropy?

2. In section 10.1.3, it states:

These are the operations and their sensitivity/vulnerability:
...

but the vulnerabilities were listed before this statement.  Should reorder.

Regards,

Shawn.
--

On Thu, Feb 27, 2020 at 11:26 PM Kamran Raza (skraza) <[e-mail]>
wrote:

> Thanks for your review and comments.
>
> We have just posted a new rev -08 that takes care of your comments and
> comments from other IESG reviewers.
>
> On behalf of authors, please see inline [skraza]:
>
>
>
> *From: *"Shawn M. Emery" <[e-mail]>
> *Date: *Monday, November 25, 2019 at 5:34 PM
> *To: *secdir <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Cc: *Shawn Emery <[e-mail]>
> *Subject: *Review of draft-ietf-mpls-ldp-yang-07
> *Resent-From: *<[e-mail]>
> *Resent-To: *<[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <[e-mail]>,
> Nicolai Leymann <[e-mail]>, Tarek Saad <[e-mail]>
> *Resent-Date: *Monday, November 25, 2019 at 5:33 PM
>
>
>
> Reviewer: Shawn M. Emery
> Review result: Ready with nits
>
>
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
>
>
> This draft specifies a YANG model for the Multi-Protocol Label
>
> Switching (MPLS) Label Distribution Protocol (LDP).  Network
>
> Configuration Protocol (NETCONF) and RESTCONF is used
>
> to mange network devices based on this model.
>
>
>
> The security considerations section does exist and for security
>
> and privacy concerns, discusses that the MTI for NETCONF is
>
> SSH and TLS for RESTCONF.  For authorization, NETCONF
>
> and RESTCONF uses the Network Configuration Access Control
>
> Model (NACM).
>
>
>
> The section goes on to state that some data nodes
>
> and RPC operations in the YANG module are considered sensitive
>
> to various operations, but does not give guidance on which nodes
>
> or subtrees that would be affected.  In the past, module specifications
>
> that I've reviewed have outlined each of these relevant items.
>
>
>
> [skraza]: Enhanced this section significantly and have added the relevant
> items to this section. See draft rev -08.
>
>
>
> The section finishes with the statement that the security
>
> properties of the base specifications, LDP, LDP IPv6, etc., also applies
>
> to this draft.  I agree with the above assertions.
>
>
>
> General comments:
>
>
>
> None.
>
>
>
> Editorial comments:
>
> [skraza]: Fixed all the listed.
>
>
>
> s/into following/into the following/
>
> s/means and be read/should be read/
>
> s/family"/family"./
>
> s/VPN Forwarding and Routing/VPN Routing and Forwarding/
>
> s/provides a mean/provides a means/
>
> s/Neibgbor/Neighbor/
>
> s/pereference/preference/
>
> s/creatable\/ deletable/creatable\/deletable/
>
>
>
> RESTCONF should be expanded on first ocurence.
>
> [skraza]: I could not find the expansion – even in the RESTCONF RFC 8040 .
>
>
>
> Shawn.
>
> --
>