Re: [secdir] Secdir review of draft-ietf-pce-rfc6006bis

[Dhruv Dhody <[e-mail]>]

Hi Charlie,

Thanks for your review and comments. Eric also raised similar concerns and
I proposed this as the updated text as what can be a part of a bid document
for a PCEP extension -

5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements that specifically help
   to minimize or negate unauthorized P2MP path computation requests and
   denial of service attacks.  These mechanisms include:

   o  Securing the PCEP session requests and responses is RECOMMENDED
      using TCP security techniques such as TCP Authentication Option
      (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [I-
      D.ietf-pce-pceps], as per the recommendations and best current
      practices in [RFC7525].

   o  Authenticating the PCEP requests and responses to ensure the
      message is intact and sent from an authorized node using TCP-AO or
      TLS is RECOMMENDED.

   o  Providing policy control by explicitly defining which PCCs, via IP
      access-lists, are allowed to send P2MP path requests to the PCE.

   PCEP operates over TCP, so it is also important to secure the PCE and
   PCC against TCP denial of service attacks.

   As stated in [RFC6952], PCEP implementations should support TCP-AO
   [RFC5925] and not use TCP-MD5 because of the known vulnerabilities
   and weakness.

You can see the diff at - https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-
rfc6006bis-03&url2=https://raw.githubusercontent.com/
dhruvdhody-huawei/ietf/master/draft-ietf-pce-rfc6006bis-04.txt

Let me know if you have any modification suggestions here.

See inline...


On Sun, Aug 13, 2017 at 8:54 AM, Charlie Kaufman <[e-mail]
> wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
>
>
> Summary: No significant security issues
>
>
> This document is a "refreshing" of rfc6006 (Extensions to PCEP for
> Point-to-Multipoint Traffic Engineering Label Switched Paths) to
> incorporate errata that have accumulated over the last seven years. There
> may be some small additional changes.
>
>
> One minor change was made to Security considerations, and it was a good
> change, but I fear makes the security considerations somewhat internally
> inconsistent. That change was to change a recommendation to use TCP-AO to a
> recommendation to use TLS. TLS is a more logical protocol to use in this
> context, but the security considerations also references RFC5440, what
> mandates TCP-MD5 and recommends TCP-AO (which was not available when
> RFC5440 was written).
>
>
> I'm not sure the best way to resolve this... probably to leave it as is.
> Someday, RFC5440 should be updated.
>
>
> Security considerations in this document discusses that dangers of
> someone impersonating a client for the purpose of denying service or
> learning about the network configuration, and RFC5440 talks about that
> dangers of eavesdropping in learning what the client is doing. It does
> not discuss whether there are important threats posed by someone
> impersonating a PCEP server and returning bad routing information. I
> suspect that might be a more serious threat then either of the other
> attacks, but don't know enough about how the protocol is used to know for
> sure.
>
>
> ​RFC5440 has this text -

   Attacks on PCEP may result in damage to active networks.  If path
   computation responses are changed, the PCC may be encouraged to set
   up inappropriate LSPs.  Such LSPs might deviate to parts of the
   network susceptible to snooping, or might transit congested or
   reserved links.  Path computation responses may be attacked by
   modification of the PCRep message, by impersonation of the PCE, or by
   modification of the PCReq to cause the PCE to perform a different
   computation from that which was originally requested.

​


> In any case, all the considerations mentioned above probably belong in
> RFC5440 (PCEP) rather than this document concerning extensions.
>
>
>
​Agreed. ​



> --Charlie Kaufman
>
>
> ​Thanks for your review.

Regards,
Dhruv​