Subject: [Pce] Stephen Farrell's No Objection on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 14 Sep 2016 04:45:52 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-pce-pcep-service-aware-12: No Objection

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-pcep-service-aware/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- You're missing a reference for TCP-AO (RFC5925 I
guess)

- My understanding is that TCP-AO is not widely
deployed. If it is expected that PCEPS will be, then
it'd maybe be good to indicate that in section 9. 

- I would have thought that these extensions would
provide new ways in which networks could lie about
things in order to influence what paths are chosen.
Is that new or was it already considered in the
referenced RFCs? (Sorry, didn't have time to check
right now.) If it is new, maybe it's worth a mention?
Note: I'm not suggesting that this document specify
the one true way to deal with that, just that it be
noted, if it's useful to do that, but given one
motivation offered is financial services, presumably
not everyone trusts everyone to be entirely honest;-)

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 14 Sep 2016 17:55:33 +0000

Hi Stephen, 

Thanks for your review. Please see inline...

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: 14 September 2016 17:16
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Pce] Stephen Farrell's No Objection on
> draft-ietf-pce-pcep-service-aware-12: (with COMMENT)
> 
> 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
[Dhruv] Added! 

> - My understanding is that TCP-AO is not widely deployed. If it is expected
> that PCEPS will be, then it'd maybe be good to indicate that in section
> 9.
> 
> - I would have thought that these extensions would provide new ways in which
> networks could lie about things in order to influence what paths are chosen.
> Is that new or was it already considered in the referenced RFCs? (Sorry,
> didn't have time to check right now.) If it is new, maybe it's worth a mention?
> Note: I'm not suggesting that this document specify the one true way to
> deal with that, just that it be noted, if it's useful to do that, but given
> one motivation offered is financial services, presumably not everyone trusts
> everyone to be entirely honest;-)
>
[Dhruv] Updated security consideration section reads - 
OLD
   This document defines new METRIC types, a new BU object, and new OF
   codes which does not add any new security concerns beyond those
   discussed in [RFC5440] and [RFC5541] in itself.  Some deployments may
   find the service aware information like delay and packet loss to be
   extra sensitive and thus should employ suitable PCEP security
   mechanisms like TCP-AO or [PCEPS].
NEW
   This document defines new METRIC types, a new BU object, and new OF
   codes which does not add any new security concerns beyond those
   discussed in [RFC5440] and [RFC5541] in itself.  Some deployments may
   find the service aware information like delay and packet loss to be
   extra sensitive and could be used to influence path computation and
   setup with adverse effect.  Additionally snooping of PCEP messages
   with such data may give an attacker sensitive information about the
   operations of the network.  Thus, such deployment should employ
   suitable PCEP security mechanisms like TCP Authentication Option
   (TCP-AO) [RFC5925] or [PCEPS].  The Transport Layer Security (TLS)
   based procedure in [PCEPS] is considered as a security enhancement
   and thus much better suited for the sensitive service aware
   information.

Let me know if you would like some change in wordings. 

Thanks! 
Dhruv
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce