Eric - Thanx for the review. V14 has been published and it attempts to address the Security concerns raised by you and others. Look forward to your feedback.
Inline. > -----Original Message----- > From: Eric Rescorla [mailto:[email protected]] > Sent: Wednesday, December 13, 2017 12:10 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Eric Rescorla's No Objection on draft-ietf-spring-segment-routing- > 13: (with COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-spring-segment-routing-13: 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-spring-segment-routing/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I (think I) share the concerns that Alissa and Adam have raised here. > To that end, I am balloting no-obj but I support Alissa's DISCUSS. > > The following comments may help get clarity here as well. It seems to me > that the MPLS variant relies on the security properties of MPLS but that the > IPv6 variant can potentially route packets over the public Internet and relies > on the HMAC defines in draft-ietf-6man-segment-routing-header to protect > the SRH from modification. Is that correct? To that end, the various nodes in > the system must all be within one domain but you can have an untrusted > IPv6 path in between them. Is that correct? [Les:] We have reemphasized the point that SR is designed to operate within a trusted domain. Forwarding over an untrusted portion of the network would violate that constraint. > The HMAC doesn't seem to be mandatory? When we look at that other > document should it be mandatory under some conditions? [Les:] The architecture document does not discuss use/non-use of HMAC. This point is discussed in draft-ietf-6man-segment-routing-header. This would then be the logical context in which to make your comments. > > I had some trouble understanding the algorithm in S 3.1.2. Let me see if I can > reconstruct the scenario. We have a list of i ranges, > R(i) each of which is identified by L(Ri), N(Ri), so for instance, so for > instance, > we might have two ranges: > > R0 -> L=10, N=2 -> labels 10, 11 > R1 -> L=20, N=3 -> labels 20, 21, 22 > > And then these are indexed by treating these as one contiguous array A = > [10, 11, 20, 21, 22] and then label(X) = A(X). Is that right? > [Les:] Yes - your understanding is correct. Note this description has been removed from the latest version of the architecture document. You will find equivalent text in https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-11#section-2.4 > Nit: I found a bunch of examples of "e.g.:". The correct form is "e.g., " [Les:] Fixed. Les > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
