Re: [Pce] Roman Danyliw's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)

[Adrian Farrel <[e-mail]>]

Lovely, thanks.

I have this captured in the working copy.

Best,
Adrian

-----Original Message-----
From: Roman Danyliw <[e-mail]> 
Sent: 26 August 2020 22:14
To: [e-mail]; 'The IESG' <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; 'Julien Meuric' <[e-mail]>
Subject: RE: Roman Danyliw's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)

Hi Adrian!

> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: Wednesday, August 26, 2020 5:09 PM
> To: Roman Danyliw <[e-mail]>; 'The IESG' <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> 'Julien Meuric' <[e-mail]>
> 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