Hi Adrian! > -----Original Message----- > From: Adrian Farrel <[email protected]> > Sent: Wednesday, August 26, 2020 5:09 PM > To: Roman Danyliw <[email protected]>; 'The IESG' <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > 'Julien Meuric' <[email protected]> > Subject: RE: Roman Danyliw's No Objection on draft-ietf-pce-pcep-flowspec-10: > (with COMMENT) > > 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.
Right. I concur on the implementation status of TCP-AO. I was a too flip with the use of the word legacy. To re-state my point, TCP-AO and MD5 don't get us anything for this privacy issue. Let's just point to IPSec and TLS guidance (from the references already cited). > > ** 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. Exactly, and my prose was just showing an example of if circumstance where an attacker might exploit that. Roman > Thanks again, > Best, > Adrian _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
