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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 26 Aug 2020 12:57:55 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-pce-pcep-flowspec-10: No Objection

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-pcep-flowspec/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for an approachable document.

Thank you to the SECDIR reviewer (Scott G. Kelly)

** Section 12.  To refine what Ben Kaduk noted about the applicability of
[RFC6952], Section 2.5 seems to apply for me.

** 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.

** 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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Aug 2020 22:08:43 +0100

Hi Roman,

> [RFC6952], Section 2.5 seems to apply for me.

Yes, that it the relevant section, and I've added an explicit section pointer.

> 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.

> 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

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 26 Aug 2020 21:13:45 +0000

Hi Adrian!

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Aug 2020 22:26:27 +0100

Lovely, thanks.

I have this captured in the working copy.

Best,
Adrian

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

Hi Adrian!

Roman