Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-hpce-13: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hello Dhruv!

-14 addresses my concerns.  Thank you for making these edits.

> -----Original Message-----
> From: Dhruv Dhody [mailto:[e-mail]]
> Sent: Tuesday, September 24, 2019 10:06 AM
> To: Roman Danyliw <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; Adrian
> Farrel <[e-mail]>; pce-chairs <[e-mail]>;
> [e-mail]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-pce-stateful-hpce-13:
> (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> Thanks for your review.
> 
> On Wed, Sep 18, 2019 at 7:45 PM Roman Danyliw via Datatracker
> <[e-mail]> wrote:
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-pce-stateful-hpce-13: 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-stateful-hpce/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > ** Section 4.  Per “The security considerations listed in [RFC8231],
> > [RFC6805] and [RFC5440] apply to this document as well. As per
> > [RFC6805], it is expected that the parent PCE will require all child
> > PCEs to use full security when communicating with the parent.”, the
> > references make sense, thanks for making them.  My concern is in the
> > definition of “use full security”.  I can see those words come from
> > RFC6805, however, I can't find where that set of practices is defined.  Can
> this please be clarified.
> >
> 
> How about we update to "..full security (i.e. the highest security mechanism
> available for PCEP)"?

The -14 text addresses my concerns.  Thank you.

> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > ** Section 4.  Per the recommendation to use TLS _or_ TCP-AO.
> > -- I take the point from the SECDIR (thanks Stephen Farrell) about the
> > (lack
> > of) deployment of AO.  My caution would be that TLS and TCP-AO provide
> > different security mechanism and therefore imbue different security
> > properties and this should be noted. (i.e., this isn’t a choice
> > between like options)
> >
> 
> How about I make at "..and/or.."? RFC8253 encourages the use of TCP-AO
> alongside TLS. This could do the trick of removing the sense of choice
> without adding more text.
> 
> > -- As an editorial nit, it would be worth saying that guidance for
> > implementing using TLS with PCEP can be found in RFC8232.
> >
> 
> You mean RFC 8253 right? Updated text -

Oops. Yes, RFC8253.

>    Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE
>    and the C-PCE) using Transport Layer Security (TLS) [RFC8446] (per
>    the recommendations and best current practices in [RFC7525]) and/or
>    TCP Authentication Option (TCP-AO) [RFC5925]. The guidance for
>    implementing PCEP with TLS can be found in [RFC8253].
> 
> > ** Editorial Nits:
> > Title.  Is the period at the end of the title necessary?
> >
> >
> 
> Removed.

Regards,
Roman

> Thanks!
> Dhruv