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

["Kamran Raza (skraza)" <[e-mail]>]

Hi Shawn,

Thanks for your comments. Please see inline [skraza2]

From: "Shawn M. Emery" <[e-mail]>
Date: Saturday, February 29, 2020 at 5:57 PM
To: "Kamran Raza (skraza)" <[e-mail]>
Cc: secdir <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Updated rev posted [Re: Review of draft-ietf-mpls-ldp-yang-07]

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?
[skraza2]: MD5 is specified as the authentication mechanism in base LDP spec RFC 5036 and hence special mention here. Infact, in prev revision, we were only covering md5 and changed the model to make it more generic to cover other types, including MD5.

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.

[skraza2]: Rephrased. Will be part of rev -09 update.

Regards,

Shawn.
--

On Thu, Feb 27, 2020 at 11:26 PM Kamran Raza (skraza) <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Monday, November 25, 2019 at 5:34 PM
To: secdir <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Shawn Emery <[e-mail]<mailto:[e-mail]>>
Subject: Review of draft-ietf-mpls-ldp-yang-07
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Nicolai Leymann <[e-mail]<mailto:[e-mail]>>, Tarek Saad <[e-mail]<mailto:[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.
--