Hi Stephen, Thanks for your review. Please see inline...
> -----Original Message----- > From: Pce [mailto:[email protected]] On Behalf Of Stephen Farrell > Sent: 14 September 2016 17:16 > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected] > Subject: [Pce] Stephen Farrell's No Objection on > draft-ietf-pce-pcep-service-aware-12: (with COMMENT) > > 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) > [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 protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
