Last Call Review of draft-ietf-opsawg-teas-attachment-circuit-15
review-ietf-opsawg-teas-attachment-circuit-15-secdir-lc-kivinen-2024-08-15-00
Request | Review of | draft-ietf-opsawg-teas-attachment-circuit-14 |
---|---|---|
Requested revision | 14 (document currently at 16) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2024-08-25 | |
Requested | 2024-08-04 | |
Requested by | Mahesh Jethanandani | |
Authors | Mohamed Boucadair , Richard Roberts , Oscar Gonzalez de Dios , Samier Barguil , Bo Wu | |
I-D last updated | 2024-08-15 | |
Completed reviews |
Rtgdir Last Call review of -11
by Donald E. Eastlake 3rd
(diff)
Rtgdir Early review of -07 by Donald E. Eastlake 3rd (diff) Yangdoctors Early review of -03 by Ebben Aries (diff) Secdir Last Call review of -15 by Tero Kivinen (diff) Yangdoctors Last Call review of -14 by Ebben Aries (diff) |
|
Comments |
The YANG doctors reviewed -03 version of this document as part of an early review. Since the document has had several revisions after that, it would be worthwhile re-reviewing it for correctness both in itself and the examples provided. SECDIR should review this document because the document is trying to specify how and where the security should be enabled for services requested by the customer. It is trying to specify that data plane traffic between two Service Access Points (SAP) should be enabled by specifying the security profile specified by the customer. See Section 5.2.5.5. |
|
Assignment | Reviewer | Tero Kivinen |
State | Completed | |
Request | Last Call review on draft-ietf-opsawg-teas-attachment-circuit by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/O7SDF7G1VeDW6E2QHvqGyxs6uKQ | |
Reviewed revision | 15 (document currently at 16) | |
Result | Has issues | |
Completed | 2024-08-15 |
review-ietf-opsawg-teas-attachment-circuit-15-secdir-lc-kivinen-2024-08-15-00
This is YANG model providing configuration and information about Attachment Circuits. The section 5.2.5.5 describes the security parts, but it is mostly content free, I mean I have no idea what it would mean if you say encryption is enabled on L2, or L3. What protocol is going to provide that security? On L2 it will depend on the link type, but also on L3 I think there can be multiple options. What does the encryption-profile-reference mean? Where does it provide reference to? I would assume that reference would point quite different places depending whether your encryption is provided by L2 or L3 etc. I have no idea how someone would implement security based on the data available on 5.2.5.5 security tree... On the other hand usually security is not configured through YANG models anyways as security people do not want to put their config in YANG models. This means it might better to just remove extra configuration based stuff from this YANG model and just say that security configuration comes from somewhere else, than try to add so much stuff here that it would actually allow configuring the security layer. -- In the security considerations it already lists customer-point as one of those subtrees that might include sensitive information, but I think locations subtree can also include similar data than customer-point and should be listed as sensitive. -- Nits: 1.1. Scope and Intended Use Connectivity services are provided by networks to customers via dedicated terminating points, such as Service Functions (SFs) [RFC****], Customer Edges (CEs), peer Autonomous System Border ... This document adheres to the definition of an Attachment Circuit as provided in Section 1.2 of [RFC****], especially: ... For people who are not familiar of all mappings from the random RFC numbers to titles of the RFCs it would be better to make sure that each any RFC number is referenced you also expand the short title for the document. Same is true throughout the whole document. There are several cases where the RFC titles are already there, but some cases they are missing, so adding them in all cases would be good. -- exposed in the AC service model. However, these details are exposed at the network model per [I-D.xxxx]. [I-D.yyyyy] specifies augmentations to the Same for the internet draft names, as those might get changed to RFC numbers in the future. -- 5.2.5.5. Security encryption to be applied to traffic for a given AC. Tthe model can Typo Tthe