Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)

Thanks for the review, please see inline

Best Regards,
Cyril

On Thu, 11 Apr 2019 at 00:13, Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-pce-gmpls-pcep-extensions-14: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> (1) Section 6, Per “The answer can make that the LSP traverses some
> geographical place known to the attacker where some sniffing devices could
> be
> installed”, this is a concern.  Good that it is here.  However, it seems
> like
> the consequences could be even more expansive – confidentiality (sniffing),
> integrity (modifying the traffic) or availability (choose to drop it).
>
>
Would the following change cover those consequences:

NEW:
      PCE Identity theft: A legitimate PCC could request 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 confidentiality (sniffing), integrity
      (traffic modification) or availability (traffic drop) attacks
      could be performed by use of an attacker-controlled  device.

(2) Section 6, [RFC8253] is mentioned a few times as having a variety of
> capabilities to mitigate the described threats.  This is the right
> reference.
> However, the current text doesn’t explicitly state whether and how this
> guidance should be followed (should, must, is recommended?)
>
>
>
Would the following be appropriate?

NEW:
  The document [RFC8253] 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.
   PCE and PCC SHOULD use [RFC8253] mechanism to protect against
   malicious PCC and PCE.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) Section 2.3, Nit (missing commas and periods),
> s/(SDH/SONET, G.709, ATM, MEF etc)/
> (SDH/SONET, G.709, ATM, MEF, etc.)/
>
> (2) In a few section.  Typo (duplicate “section Section”).  Recommend
> global
> s/section Section/Section/g
>
>
Thanks for catching those, I did not find the duplicated against though.

> (3) Section 6.  Duplicate word.  s/against against/against/
>
>
>

> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>