Hi Roman, > COMMENT: > > ** Section 12. To refine what Ben Kaduk noted about the applicability of > [RFC6952], Section 2.5 seems to apply for me.
Yes, that it the relevant section, and I've added an explicit section pointer. > ** Section 12. Per “Therefore, implementations or deployments concerned with > protecting privacy MUST apply the mechanisms described in the documents > referenced above.”, it might be helpful to explicitly call out the specific > guidance to follow. I believe that it’s to use either IPSec per Section 10.4 > – > 6 of RFC5440 or TLS per RFC8523 to provide transport security properties. The > legacy references to TCP-AO and TCP MD5 in those documents don’t help here. You're right about the advice and we can make it clear. MD5 obviously doesn't buy you much privacy and we can say that, too. Understanding that TCP-AO is "not widely implemented" if it is truly legacy, I wish someone would toggle the status to Historic or write some guidance on its non-use. > ** Section 12. Per “Although this is not directly a security issue per se, > the > confusion and unexpected forwarding behavior may be engineered or exploited by > an attacker. Therefore, implementers and operators SHOULD pay careful > attention to the Manageability Considerations described in Section 13.”, I > completely agree. I would say it a bit more strongly that this complexity > could be a security issue. I’m envisioning a situation where the complex > forwarding behaviors might create gaps in the monitoring and inspection of > particular traffic or provide a path that avoids expected mitigations. Right. So, to be clear, the threat here is "user error caused by confusion resulting from complexity." Yes, I can clarify that. Thanks again, Best, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
