Re: [secdir] secdir review of draft-ietf-pce-wson-routing-wavelength-14

[OSCAR GONZALEZ DE DIOS <[e-mail]>]

Hi Dan,

    I recently worked in the PCEP extensions for GMPLS security section,
where I did an analysis on the threats on adding PCEP in GMPLS networks.
This particular draft in last call,
draft-ietf-pce-wson-routing-wavelength-14, is focused on the support of
PCE for Wavelength Switched optical networks. I think the analysis done
for GMPLS networks, with some modifications may be valid for this case of
WSON networks. Please find bellow the text of
http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-10.

   GMPLS controls multiple technologies and types of network elements.
   The LSPs that are established using GMPLS, whose paths can be
   computed using the PCEP extensions to support GMPLS described in this
   document, can carry a high amount of traffic and can be a critical
   part of a network infrastructure.  The PCE can then play a key role
   in the use of the resources and in determining the physical paths of
the LSPs and thus it is important to ensure the identity of PCE and
   PCC, as well as the communication channel.  In many deployments there
   will be a completely isolated network where an external attack is of
   very low probability.  However, there are other deployment cases in
   which the PCC-PCE communication may be more exposed and there could
   be more security considerations.  Three main situations in case of an
   attack in the GMPLS PCE context could happen:

   o  PCE Identity theft: A legitimate PCC could requests a path for a
      GMPLS LSP to a malicious PCE, which poses as a legitimate PCE.
      The answer can make that the LSP traverses some geographical place
      known to the attacker where some sniffing devices could be
      installed.  Also, the answer can omit constraints given in the
      requests (e.g. excluding certain fibers, avoiding some SRLGs)
      which could make that the LSP which will be later set-up may look
      perfectly fine, but will be in a risky situation.  Also, the
      answer can lead to provide a LSP that does not provide the desired
      quality and gives less resources tan necessary.

   o  PCC Identity theft: A malicious PCC, acting as a legitimate PCC,
      requesting LSP paths to a legitimate PCE can obtain a good
      knowledge of the physical topology of a critical infrastructure.
      It could get to know enough details to plan a later physical
      attack.

   o  Message deciphering: As in the previous case, knowledge of an
      infrastructure can be obtained by sniffing PCEP messages.

   The security mechanisms can provide authentication and
   confidentiality for those scenarios where the PCC-PCE communication
   cannot be completely trusted.  Authentication can provide origin
   verification, message integrity and replay protection, while
   confidentiality ensures that a third party cannot decipher the
   contents of a message.

   The document [I-D.ietf-pce-pceps
<http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-10#ref-I-D
.ietf-pce-pceps>] describes the usage of Transport
   Layer Security (TLS) to enhance PCEP security.  The document
   describes the initiation of the TLS procedures, the TLS handshake
   mechanisms, the TLS methods for peer authentication, the applicable
   TLS ciphersuites for data exchange, and the handling of errors in the
   security checks.

   Finally, as mentioned by [RFC7025 <http://tools.ietf.org/html/rfc7025>]
the PCEP extensions to support
   GMPLS should be considered under the same security as current PCE
   work and this extension will not change the underlying security
   issues.  However, given the critical nature of the network
   infrastructures under control by GMPLS, the security issues described
   above should be seriously considered when deploying a GMPLS-PCE based
control plane for such networks.  For more information on the
   security considerations on a GMPLS control plane, not only related to
   PCE/PCEP, [RFC5920 <http://tools.ietf.org/html/rfc5920>] provides an
overview of security vulnerabilities
   of a GMPLS control plane.



Do you think a similar analysis for WSON networks may be useful?

Best Regards,

        Óscar

El 28/10/14 16:50, "Leeyoung" <[e-mail]> escribió:

>Hi Dan,
>
>Thanks a lot for your review and providing comments.
>
>Would the following work for you in Security Section to add:
>
>"Solutions that address the requirements in this document need to verify
>that existing PCEP security mechanisms adequately protect the additional
>network capabilities and must include new mechanisms as necessary."
>
>Best regards,
>Young
>
>-----Original Message-----
>From: Dan Harkins [mailto:[e-mail]]
>Sent: Monday, October 27, 2014 12:04 PM
>To: [e-mail]; [e-mail];
>[e-mail]
>Subject: secdir review of draft-ietf-pce-wson-routing-wavelength-14
>
>
>  Hello,
>
>  I have reviewed draft-ietf-pce-wson-routing-wavelength 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 is a requirements document for additions to the PCEP protocol to
>support path computation in a wavelength-switched optical network. It
>describes what needs to be added to requests/responses to support routing
>and wavelength assignment to a path computation element (that supports
>both functions) for a path computation client.
>
>  The security considerations are basically a punt. There's information
>that an operator may not want to disclose and "[c]onsideration should be
>given to securing this information." That seems a little thin. At the
>very least some explanation of how this should be done. Do only the TLVs
>that represent these required additions require confidentiality?
>Is KARP a potential solution to this problem? If so it might be nice to
>explain that; if not, then why and what else would be required?
>
>  It is a well-organized and well-written document. I would say it is
>"ready with nits", my nits being the thinness of the Security
>Consideration section.
>
>  regards,
>
>  Dan.
>
>


________________________________

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