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

From: "Dan Harkins" <[email-masked]>
Date: Mon, 27 Oct 2014 10:03:44 -0700 (PDT)

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Oct 2014 14:17:30 -0000

Hi Dan,

Thanks for taking the time.

> explain that; if not, then why and what else would be required?

As you say, it's a requirements document, so it may be a bit harsh to ask the
authors to describe how security should be provided.

We could possibly add a little text to the Security Considerations section to
explain who is supposed to catch the ball when we punt it.

I'll talk to the authors,

Cheers,
Adrian

---

From: Leeyoung <[email-masked]>
Date: Tue, 28 Oct 2014 15:50:12 +0000

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:[email-masked]] 
Sent: Monday, October 27, 2014 12:04 PM
To: [email-masked]; [email-masked]; [email-masked]
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.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 28 Oct 2014 09:24:50 -0700 (PDT)

Hi Young,

On Tue, October 28, 2014 8:50 am, Leeyoung wrote:
> "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."

  Yes, that's fine. Adrian had a good point (it's a requirements document)
and this puts the requirements where they should be-- on the solution
that addresses the requirements.

  thanks,

  Dan.

> To: [email-masked]; [email-masked];
> [email-masked]
>   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.
>
> 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?
>   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.
>
>
>

---

From: Leeyoung <[email-masked]>
Date: Tue, 28 Oct 2014 16:28:50 +0000

Hi Dan,

Thanks. We will address PCEP security mechanisms in the solution draft. We will also factor in Oscar's suggestion in this thread.

Best regards,
Young

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Tuesday, October 28, 2014 11:25 AM
To: Leeyoung
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: secdir review of draft-ietf-pce-wson-routing-wavelength-14

  Hi Young,

On Tue, October 28, 2014 8:50 am, Leeyoung wrote:
> "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."

  Yes, that's fine. Adrian had a good point (it's a requirements document) and this puts the requirements where they should be-- on the solution that addresses the requirements.

  thanks,

  Dan.

> WG chairs should treat  these comments just like any other last call comments.
>
> to support path computation in a wavelength-switched optical network. 
> It describes what needs to be added to requests/responses to support 
>   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?
>

---

From: OSCAR GONZALEZ DE DIOS <[email-masked]>
Date: Tue, 28 Oct 2014 16:24:29 +0000

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" <[email-masked]> escribió:

>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.
>

________________________________

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