Subject: Re: [Last-Call] Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10

From: <[email-masked]>
Date: Fri, 3 Sep 2021 08:17:01 +0000

Hi Rifaat, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Rifaat Shekh-Yusef via Datatracker [mailto:[email-masked]]
> Envoyé : dimanche 25 juillet 2021 22:55
> À : [email-masked]
> Cc : [email-masked]; [email-masked];
> [email-masked]
> Objet : Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10
> 
> Reviewer: Rifaat Shekh-Yusef
> Review result: Has Issues
> 
> 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 document defines an L3VPN Network YANG Model (L3NM) that can be
> used for the provisioning of Layer 3 Virtual Private Network (VPN)
> services within a service provider network.  The model provides a
> network-centric view of L3VPN services.
> 
> 
> Issues:
> 
> 1. The following is a quote from Security Consideration section:
>     "Several data nodes defined in the L3NM rely upon [RFC8177] for
>      authentication purposes."
> 
> I think it would be helpful to elaborate on which nodes need the
> mechanism defined in RFC8177 and why?
> 

[Med] 8177 is used here to ease the mapping with underlying device modules, particularly routing protocols.

Updated the text to cite the nodes. NEW:

"Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely upon ..."

> 
> 2. The summary bullets:
> 
>    o  Malicious clients attempting to delete or modify VPN services.
> 
> Why 'create' and 'read' are not part of the risks in this case?
> 

[Med] because 'create' is covered in the next bullet: 

   o  Unauthorized clients attempting to create/modify/delete a VPN
      service.

And 'read' in the third one: 

   o  Unauthorized clients attempting to read VPN service related
      information.

After re-reading the text to check your comment, I figured out that we don't actually need this list as it is redundant with the risks cited for both write and read nodes. The bullet list will be removed.

Your review will be ACKed in the next iteration of the document. Thank you. 

Cheers,
Med

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Oscar González de Dios <[email-masked]>
Date: Fri, 3 Sep 2021 08:51:44 +0000

Hi Rifaat, Med, further comments inline

-----Mensaje original-----
De: [email-masked] <[email-masked]>
Enviado el: viernes, 3 de septiembre de 2021 10:17
Para: Rifaat Shekh-Yusef <[email-masked]>; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
Asunto: RE: Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10

Hi Rifaat,

Please see inline.

Cheers,
Med

> Envoyé : dimanche 25 juillet 2021 22:55 À : [email-masked] Cc :
> [email-masked]; [email-masked];
> [email-masked] Objet : Secdir last call review of
> draft-ietf-opsawg-l3sm-l3nm-10
>
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>

[Oscar] Complementing, the main intention of the bullet was to highlight that, in this case, there can be a direct impact on a running service (and the impact can potentially be huge). Read is different, gets knowledge, but does not hit the service. Create also does not impact directly running services.

[Oscar] The original aim of the bullets was to briefly summarize and highlight the different intentions and impacts of the risks, one for malicious clients that can impact running services, so the customer of the service could be directly hit (huge problem), other someone creating a service and making use of the network without authorization  (but does not impact other services)  and unauthorized clients that don't impact directly the service, but just gain knowledge of it (the data can be used for malicious purposes, but at the moment of the attack, the service is not hit). Even though it is true it can be redundant for the risks already cited before for read and write nodes, I see no harm in explicitly adding the classification (network models are a powerful tool, use them wisely :-) ).

Cheers,
Med

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: <[email-masked]>
Date: Fri, 3 Sep 2021 08:55:52 +0000

Hi Ben, all, 

Glad to see that you found the text where explain why MD5 is supported in the model. 

Added this NEW text to the security considerations section: 

   As discussed in Section 7.6.3, the module supports MD5 to basically
   accommodate the installed BGP base.  MD5 suffers from the
   security weaknesses discussed in Section 2 of [RFC6151] or
   Section 2.1 of [RFC6952].

Cheers,
Med

> De : last-call [mailto:[email-masked]] De la part de
> Benjamin Kaduk
> Envoyé : mardi 3 août 2021 06:21
> À : tom petch <[email-masked]>
> Cc : [email-masked]; [email-masked];
> Rifaat Shekh-Yusef <[email-masked]>; [email-masked]
> Objet : Re: [Last-Call] Secdir last call review of draft-ietf-
> opsawg-l3sm-l3nm-10
> 
> Hi Tom,
> 
> On Thu, Jul 29, 2021 at 05:10:00PM +0100, tom petch wrote:
> > Reading this I-D, I wondered what the secdir view is of
> recommending
> > the use of MD5 to secure the session as this I-D does for BGP.
> (Such
> > a use in NTP did generate a comment).
> 
> This part:
> 
>       'authentication':  The module adheres to the recommendations
> in
>          Section 13.2 of [RFC4364] as it allows enabling TCP-AO
>          [RFC5925] and accommodates the installed base that makes
> use of
>          MD5.  In addition, the module includes a provision for the
> use
> 
> seems to be about as good as we can do given the current state of
> deployment and implementation.
> 
> I will probably suggest adding some additional discussion of the
> weakness of MD5 to the security considerations in my ballot
> comments, if no such text appears before then.
> 
> Thanks,
> 
> Ben
> 
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call