[Teas] Roman Danyliw's No Objection on draft-ietf-teas-rfc3272bis-26: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-teas-rfc3272bis-26: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rfc3272bis/



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

Thanks to Shawn Emery for the SECDIR review.

** Section 6.6.  With the context that I don’t have a clear sense of what was
chosen to be included in this document on traffic engineering, it seemed liked
a few common traffic engineering design patterns related to survivability were
not included.  I could also see discussion of these in the Security
Considerations:

-- traffic filtering/scrubbing of any/every kind at the edge to prevent attacks
from entering the network or leaving (a very primitive form of traffic
engineering)

-- choosing optional security features in control plane protocols such as
authentication to harden the control plan

-- relying on external packet scrubbing services to mitigate DDoS attacks

** Section 9
   In general, TE
   mechanisms are security-neutral: they may use tunnels which can
   slightly help protect traffic from inspection and which, in some
   cases, can be secured using encryption; they put traffic onto
   predictable paths within the network that may make it easier to find
   and attack; they increase the complexity or operation and management
   of the network; and they enable traffic to be steered onto more
   secure links or to more secure parts of the network.

Saying that TE mechanisms are security neutral” seems incongruent to the rest
of the text.  For example, noting that a path “can be secured using encryption”
doesn’t seem neutral at all and changes the security properties of the traffic
carries.  Poorly configured traffic engineering seems like it could have
disastrous consequences on security or “survivability” as discussed in Section
6.