Skip to main content

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 17)
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 17)
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