On Tue, 25 Oct 2022 at 18:19, Dhruv Dhody <dd@xxxxxxxxxxxxxx> wrote:
Hi Tiru,Now that the document is in the RFC Editor queue, I would caution against making further updates in this document unless we have to.This document just adds another association-type and the comments are more of a generic nature. If the WG feels that any update is needed, it makes sense to do that independently. More inline...On Tue, Oct 25, 2022 at 5:56 PM tirumal reddy <kondtir@xxxxxxxxx> wrote:Reviewer: Tirumaleswar Reddy
Review result: Ready with issuesI apologize for missing the deadline for this review.
This document relies on [RFC5440], [RFC8231], [RFC8281] and [RFC8697] for security considerations. RFC5440 discusses the use of TCP-MD5 (obsoleted), TCP Authentication Option and TLS 1.2. Further, RFC5440 refers to RFC7525 for TLS recommendations.
draft-ietf-pce-vn-association says use of TLS is recommended.
My comments below:
1. Any specific reason for using "SHOULD" instead of using "MUST" for TLS. If TLS is not used in certain scenarios, how is a malicious PCEP speaker detected ?The use of TCP-AO for instance.
I am not sure how the identity of the PCEP speaker is validated using TCP-AO.
2. Do you see any challenges encouraging the use of TLS 1.3 ?It is a work in progress. See https://datatracker.ietf.org/doc/draft-dhody-pce-pceps-tls13/3. You may want to make it clear that this document does not rely on TCP-MD5.That is well established. See https://www.rfc-editor.org/rfc/rfc6952.html#section-2.54. If existing implementations are using TLS 1.2, I suggest referring to the recommendations in draft-ietf-uta-rfc7525bis instead of rfc7525. Please see Appendix A in draft-ietf-uta-rfc7525bis, it highlights the differences with rfc7525.RFC 7525 will get obsoleted by the new RFC# assigned for the bis eventually. We can also update RFC 8253 if needed. I dont think we should bury this in this small extension though.Thanks!DhruvCheers,-Tiru
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
