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

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 1 Oct 2019 13:25:31 +0000

Hi Roman, sorry for my delay in replying to your review.  There was some overlap with others.
Please see inline.

> On Sep 4, 2019, at 2:50 PM, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 
> 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.
> 
> 

This section is overly wordy and not clear, let’s see what it looks like if we start over and focus specifically on Source Routing Attacks.

<NEW>
7.1 Source Routing Attacks

An SR domain implements distributed and per node protection as described in section 5.1. Additionally, domains deny traffic with spoofed addresses by implementing the recommendations in BCP 84. 

Full implementation of the recommended protection blocks the attacks documented in [RFC5095] from outside the SR domain, including bypassing filtering devices, reaching otherwise unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast.

Failure to implement distributed and per node protection allows attackers to bypass filtering devices and exposes the SR Domain to the attacks from nodes outside the SR domain including reaching otherwise unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast.
</NEW>

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (2) I support Ben Kaduk's DISCUSS position.

Closing these with Ben.

> 
> (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”).

Proposed text with Ben will tighten this up and leave the paragraph as 
“Local configuration determines when to check for an HMAC.”

Thanks.
  Darren

> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 15 Oct 2019 16:38:29 +0000

Hi Roman, this text is in revision 25
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-25

Can you acknowledge closure and update the discuss position?

Thanks!
  Darren

On Oct 1, 2019, at 9:25 AM, Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 4, 2019, at 2:50 PM, Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

<NEW>

Closing these with Ben.

Thanks.
 Darren

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------