Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
I ended up reading draft-ietf-6man-segment-routing-header in tandem with this document, and I have a question arising out of that. The trust model for SRv6 outlined in this document appears to be one of reliance on the fact that an SRH will only ever be inserted and appear within a single administrative domain. But Section 5.2.2 of draft-ietf-6man-segment-routing-header talks about an SRH being inserted by a device outside of the segment routing domain. Which is correct? I think this is an important question because the whole trust model for the SR information seems to rely on out-of-band trust between participating nodes. I also think this is important because there is no discussion in this document of the impact of the inclusion of the SR metadata on the fingerprinting of the device that inserted it. Section 5.1.4 of draft-ietf-6man-segment-routing-header sort of alludes to this but seems to equate the capabilities of an active attacker (who can conduct a traceroute) with a passive attacker who could passively collect topology/fingerprinting information simply by observing SRHes flowing by on the network. If the limitation to a single administrative domain is meant to prevent such a passive attack (not sure if that is really true, but perhaps the document assumes it?), that's another reason that the existence of such a limitation needs to be clarified.
Per my DISCUSS comment, I think this document needs to include some considerations concerning the additional metadata that SRv6 adds to the packet. This has implications not just for passive observers but also for any node that logs the SRH.
While I understand the assumption that following the capabilities of existing protocols that incorporate similar functionality is okay, I'd like to walk through the security properties left off in the security considerations section to prevent tampering and see what can be done to correct that or minimally to list out the considerations. There's a few places in the security considerations section to call out specifically. Section 8.1: "The received information is validated using existing control plane protocols providing authentication and security mechanisms. Segment Routing does not define any additional security mechanism in existing control plane protocols." For MPLS what "security mechanisms" are referred to in this text? It would be helpful to list any properties explicitly or drop this phrase if there are no additional security mechanisms. Since segment routing lists an explicit list of segments (I see that this can be done with MPLS labels and you note it is already exposed), why is there no mention of integrity protection and origin authentication to prevent tampering? I think EKR's comment is already hinting at this with his comments on IPv6, but I'd like to see explicit text to preferably fix this gap in the architecture, but minimally to document it and the associated security threats that result from this gap for MPLS and IPv6. Section 8.2: "From a network protection standpoint, there is an assumed trust model such that any node adding an SRH to the packet is assumed to be allowed to do so. Therefore, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain. Segment Routing extensions that have been defined in various protocols, leverage the security mechanisms of these protocols such as encryption, authentication, filtering, etc." This document focuses on the same threats as the MPLS use cases with no mention of tampering or mitigations. Text should be added to describe how origin authentication and integrity are provided in the source routing header for IPv6 with the associated threats or to describe this gap if a solution does not exist. I have not read the draft referred to at the start of this section, so I don't know if it addresses the concern or not. In any case, this document isn't complete without some text on tampering considerations within your trusted domain. Thank you.
Substantive Comments: - I support Alissa's discuss and Adam's major comment. - Requirements Language: There are lower case instances of 2119 keywords. Unless you mean for those to also be normative, please use the boilerplate from RFC 8174. -3.1.1, last paragraph: Why are the SHOULDs not MUSTs? -12.2: The citations to the following references seem to be used normatively: I-D.ietf-6man-segment-routing-header I-D.ietf-isis-segment-routing-extensions I-D.ietf-ospf-ospfv3-segment-routing-extensions I-D.ietf-ospf-segment-routing-extensions Editorial Comments and Nits: -1, 2nd paragraph: s/"referred by"/"referred to by" -2, definition of "Active Segment" : "The segment that MUST be used..." The MUST seems like a statement of fact. (If that is actually intended to define a requirement, please state it more directly.) -8, 2nd paragraph, first sentence: s/on/to -8.2, 2nd paragraph, first sentence: s/on/to
The good news is that, whenever you have ingested the terminology section, you pretty much understand how the protocols works. :-) 1. Good to see that this new protocol spec. has a "manageability considerations". However, a major comment (not sure if this should be a DISCUSS, so help me understand). I have the same questions as Warren regarding: "In addition to the allocation policy/tooling that the operator will have in place, an implementation SHOULD protect the network in case of conflict detection by providing a deterministic resolution approach." I guess you want to start by stressing the SID uniqueness in the different scenario: distributed, centralized, hybrid. And from there, explain where this apply. I guess the sentence only applies to the hybrid scenario, right? Then you should explain how an implementation should first detect a conflict and then protect. 2. Section 3.1.1 The ingress node of an SR domain SHOULD validate that the path to a prefix, advertised with a given algorithm, includes nodes all supporting the advertised algorithm. This is only in the distributed scenario, right? This is what you mean by "advertised with a given algorithm" In other words, you mean "advertised with a given IGP algorithm". In hybrid or centralized scenarios, the ingress node might not know. See In a centralized scenario, ... The SR architecture allows these SR controllers to discover which SID's are instantiated at which nodes and which sets of local (SRLB) and global labels (SRGB) are available at which node. Editorial: NETCONF would benefit from a reference to RFC6241
I'm not surprised to see additional security alarm bells going off for the SRv6 variant - this is quite similar to the additional congestion awareness alarm bells that went off when we were evaluating MPLS (which is usually pretty well contained) over UDP (which can get around the Internet with a lot less effort than MPLS without UDP). That's an opportunity to rethink the impact of changes to an underlying technology. Which leads me to the point I should be making as a TSV AD. I'm not seeing any obvious mechanism that would tell you that you've managed to set up your segment routing so that some paths will undergo persistent congestion. You might consider whether it's worth recommending that people doing segment routing take a look at https://datatracker.ietf.org/doc/rfc8084/ and decide how much, if anything, would be useful to say about that. https://tools.ietf.org/html/rfc7510#section-5 is an early example of the kind of thing I'm talking about.
I support Alissa and Kathleen's DISCUSSes and look forward to their resolution.
Firstly, thank you for writing this, and including a manageability section. I'm a little confused by one sentence in this section: "In addition to the allocation policy/tooling that the operator will have in place, an implementation SHOULD protect the network in case of conflict detection by providing a deterministic resolution approach." Ok, great -- but I'm not at all sure how an implementation would **detect** that conflict in order to resolve it in any manner. I hope I'm being dumb or missing something obvious - are you able to help me understand?
I support Alissa's and Kathleen's discusses and I would also like to add on to Spencer's comment: Given this is an architecture document, I think it would be appropriate to at least add a note about path selection and congestion management. This can be as simple as saying that if all traffic is assumed to best effort, it is expected that congestion control is implemented by the endpoints, or if resources are reserved it might make sense to monitor the incoming traffic and e.g. apply traffic shaping.
I agree with Alissa/Adam.
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? The HMAC doesn't seem to be mandatory? When we look at that other document should it be mandatory under some conditions? 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? Nit: I found a bunch of examples of "e.g.:". The correct form is "e.g., "
Thanks to everyone who put in work on this document. I do note that the list of authors is over the five-author recommended limit. I checked both the ballot and the shepherd write-up, and was a little surprised not to find an explanation of why this document is exceptional in this regard. I have one major comment and a handful of editorial comments. The major comment regards the treatment of trust assumptions in the security section. The SR-MPLS section asserts: "[T]here is an assumed trust model such that any node imposing a label stack on a packet is assumed to be allowed to do so"; the SRv6 section has a similar assertion: "[T]here is an assumed trust model such that any node adding an SRH to the packet is assumed to be allowed to do so." I leave it to the security area directors to speak to whether it is okay in 2017 to publish documents that forego integrity protection of source routing information based on assumptions of perfectly secured networks. Irrespective of the answer to that question, I'm perplexed that the security section does not go into detail about the consequences that arise when these assumptions are violated. I think a clear description of these consequences is relevant and necessary to include, as it informs the level of care that is appropriate for both implementation and deployment of these protocols. I want to be clear that I consider this a major flaw in the document, and am on the fence regarding whether it should constitute a blocking DISCUSS. I would support anyone else in issuing a DISCUSS on this topic. Editorial comments follow. Section 2 contains the following text: Active Segment: the segment that MUST be used by the receiving router to process the packet. I really don't think you want to use normative language in the terminology section. I strongly recommend moving this requirement down to a section that bears more directly on implementation. Section 3.4.2: These extensions are defined in IGP SR extensions documents. Please add a citation to the relevant documents. Section 3.5: ABRs G and J will propagate the prefix and its SIDs into the backbone area by creating a new instance of the prefix according to normal inter-area/level IGP propagation rules. Please expand the term "ABR" on first use.