Hi Acee and Martin! Thanks for the quick edits and additional explanation. This text addressed all of my IESG review feedback. I've cleared my ballot.
Regards, Roman > -----Original Message----- > From: Acee Lindem (acee) <a...@cisco.com> > Sent: Monday, January 25, 2021 2:28 PM > To: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> > Cc: draft-ietf-spring-sr-y...@ietf.org; spring-cha...@ietf.org; > spring@ietf.org; > Joel Halpern <j...@joelhalpern.com> > Subject: Re: Roman Danyliw's Discuss on draft-ietf-spring-sr-yang-29: (with > DISCUSS and COMMENT) > > Hi Roman, > > Please see inline. > > > On 1/20/21, 10:13 PM, "Roman Danyliw via Datatracker" <nore...@ietf.org> > wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-spring-sr-yang-29: 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-spring-sr-yang/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 9. The primary impact of the manipulating writable nodes appears > to be > characterized as DoS. Don’t the possible consequences also include the > ability > to leak traffic outside the trusted domain or to route traffic through > arbitrary paths of the attackers choosing potentially enable on-path > inspection > or manipulation of traffic; or avoidance of security controls? > > We have revised the writable nodes in the -30 version: > > /segment-routing/mpls/bindings - Modification to the local > bindings could result in a Denial of Service (DoS) attack. An > attacker may also try to create segment conflicts (using the same > segment identifier for different purposes) to redirect traffic > within the trusted domain. However, the traffic will remain > within the trusted domain. Redirection could be used to route the > traffic to compromised nodes within the trusted domain or to avoid > certain security functions (e.g., firewall). Refer to section 8.1 > [RFC8402] for a discussion of the SR-MPLS trusted domain. > > /segment-routing/mpls/srgb - Modification of the Segment Routing > Global Block (SRGB) could be used to mount a DoS attack. For > example, if the SRGB size is reduced to a very small value, a lot > of existing segments could no longer be installed leading to a > traffic disruption. > > /segment-routing/mpls/srlb - Modification of the Segment Routing > Local Block (SRLB) could be used to mount a DoS attacks similar to > those applicable to the SRGB. > > /segment-routing/mpls/label-blocks - Modification of the Segment > Routing label blocks could be used to mount a DoS attack. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** Section 9. Thanks for using the templated YANG Security > Considerations. > A > nit on the references s/[RFC6536]/[RFC8341]/ > > ** Section 9. The following caution around readable nodes didn’t parse > for > me. > Was the intent as follows: > > OLD > The exposure of both local > bindings and SID database will exposure segment routing paths that > may be attacked. > > NEW > The exposure of either the local bindings or SID database would provide an > attacker the segment routing paths and related topology information. > > ** Section 9. Typo. s/a a/a/ > > ** Section 9. Typo. s/rediection/redirection/ > > We've incorporated all your comments into the -30 version. > > Thanks, > Acee > > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
