Subject: Roman Danyliw's Discuss on draft-ietf-6man-segment-routing-header-22: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 04 Sep 2019 11:50:21 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-6man-segment-routing-header-22: Discuss

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-6man-segment-routing-header/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 7.1.  This section seems to be enumerating the attacks possible
with source routing, and noting that the scope of these are limited to nodes
inside the SR domain because of SRH requires ingress filtering.  No issue with
this position.  This feedback is around the clarity of the attacks in question.
 The text currently says:

(a) (from the CanSecWest reference in from RFC5095) “Such attacks include
bypassing filtering devices, reaching otherwise unreachable Internet systems,
network topology discovery, bandwidth exhaustion, and defeating anycast”

(b) In addition, “other known attacks on an IP network (e.g.  DOS/DDOS,
topology discovery, man-in-the-middle, traffic interception/siphoning)” are
also noted.

-- Per (a), the issue is broader than “bypassing filtering devices”, it’s also
the “bypassing of network management, auditing or security devices”.

-- Per (b), the enumeration of attacks using the parenthetical suggested that
these attacks are generically possible on “IP networks” and not SRH specific. 
If that is the appropriate read, then somewhere in the earlier text it should
be noted that SRH can also facilitate traffic steering for DDoS, eavesdropping
and traffic manipulation through the manipulation (deletion, re-ordering) of
the SRHs.  If (b) is a complementary list to (a) on SRH specific list of
attacks, then it needs to be reconciled for duplication with (a) (e.g., per
“bandwidth exhaustion” of (a) and “DOS/DDOS” of (b), are they the same?).  I
think it is important to make clear what new attacks TTPs are possible with SRH
even if the attack type is already possible through another TTPs on a generic
IP network.

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

(2) I support Ben Kaduk's DISCUSS position.

(3) Section 2.1.2.1.  Per “Local configuration determines when to check for an
HMAC and potentially indicates what the HMAC protects”, can you clarify on how
the local config changes the fields/input/content of what is protected by the
HMAC?  Subsequent text in this section seems to be clear on what gets passed as
input to the HMAC (i.e., the definition of “Text”).