Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
(1) Section 126.96.36.199 says: Local configuration determines when to check for an HMAC and potentially indicates what the HMAC protects, and a requirement on where the HMAC TLV must appear (e.g. first TLV), and whether or not to verify the destination address is equal to the current segment. I'm uncomfortable about leaving so much of the semantics of a security mechanism up to the local configuration. Specifically, the "potentially indicates what the HMAC protects" and "whether or not to verify the destination address is equal to the current segment", which leaves some of the key security properties of the system in the hands of someone that is potentially quite inexperinced in reasoning about the relevant security properties. I do think we can still specify something useful and interoperable that still allows flexibility about when to check and where the TLV can appear. (This may in practice also allow flexibility about what it protects, if the semantics are something like "it protects everything prior to it" and we allow for other TLVs to appear after it, but the actual *rules* for what it protects would be well-specified.) (2) I also think we should discuss what is protected by the HMAC. I note in the COMMENT that this seems to be more about protecting the SRH contents than the packet payload, but at present there is no binding at all to the containing packet or flow, which seems to in effect present the SRH as a self-contained, "signed", policy blob, which can be detached from packet data and transferred at will. It's probably also best practice to include a fixed "contxt string" like "IPv6 SRH HMAC" even though the risk of key reuse and cross-protocol attacks seems quite small here. It's also pretty tempting to pull in the representation of the "immutable TLVs", though there are probably some tricky details to describing how to do that, and that can present complexity challenges if/when nodes not trusted with HMAC keys are expected to apply varying TLVs at runtime. (The lack of defined TLVs other than HMAC and padding make it hard for an outsider to gague the intent for TLV usage.) (3) I'm concerned that this mechanism may not be consistent with BCP 107's guidance on automated vs. manual key management, with respect to directly using the long-term HMAC key to key the HMAC. Most modern designs will introduce an intermediate key-derivation step that mixes some message- or flow-specific data into the intermediate key that is then used to key the per-message MAC. Section 5.5 seems to suggest that the IPv6 flow label may be usable (i.e., fixed within the domain for a given flow) for this purpose, but I may be missing a subtlety about intra- vs. inter-domain traffic, and it may not be feasible to involve a central controller into flow identifier assignment. If the HMAC is solely intended to make self-contained "authorized policy blobs" that are infrequently changing, then the direct use of the long-term key may not be as problematic as it first seems. Additionally, if the SDN-oriented or "trusted key distribution protocol such as [RFC6407]" cases are used, then this is somewhat less of a concern, though there may still be key usage lifetime considerations to worry about and potentially force somewhat-rapid key turnover (i.e., weeks or months). (4) I'm not sure that the scoping of key IDs per destination node is consistent with the use cases depcicted. I mention this in the COMMENT section in a few places, but the short version is roughly "if the HMAC is fixed for the life of the packet, then we can either have the key ID namespaced by destination address but only have one verifier, or we can have multiple verifiers on the path but the key ID space is global". We do currently have text that talks about verification being performed at multiple points on the path, so I'm not sure which scenario is intended. (5) I think we need to have some discussion about key revocation/rotation. The mode of operation for the HMAC TLV that appears to be envisioned by this document is that there is a central trusted service that computes "blessed" segment routes with an accompanying HMAC "signature" (not a real signature, but a sign of aproval in some sense), and that the resulting token of (SRH including HMAC TLV) is distributed by SDN configuration. These SRH tokens are treated by many nodes as opaque blobs, applied to outgoing traffic according to the procedure configured alongside the token. Some other (trusted) nodes in the network may look inside the SRH to verify the MAC, and check that the rout in question should be coming from that direction, but those nodes may be a minority of nodes. In this scenario, we need to consider the behavior when the central controller changes what routes are to be used, and effectively wants to "revoke" the old ones and ensure that the deprecated routes are not in use in the SR domain. The only mechanism for doing so seems to be to rotate the HMAC key in question so as to discard all HMACs generated by the key in question (since keeping something akin to a CRL of "revoked" HMAC values seems infeasible in general); I think we should have some discussion about needing to do a key rotation to effectuate such "revocation" (that is, cryptographically ensure that previously configured/"blessed" routes are no longer in use). It would also be pretty easy to tie this in to text about recovering from a compromised HMAC key.
As something of a general note, this document (specifically, the HMAC portions) was initially challenging for me to read, since in the security community we tend to have HMAC (or MACs in general) apply to specific messages and protect the content from end to end. The usage here seems rather different, in that the HMAC is protecting not the packet payload, but (essentially) just the SRH, which is to a large extent a fixed (e.g., per-flow) artifact that reflects routing policy. So the MAC is serving to authenticate policy, more than messaging, and there was very little in the document that tried to make that distinction. I've tried to indicate some locations/changes that would improve readability in this regard. Section 1 The Segment Routing Architecture [RFC8402] describes Segment Routing and its instantiation in two data planes MPLS and IPv6. nit: we need some form of punctuation after "data planes". Section 2 o Tag: tag a packet as part of a class or group of packets, e.g., packets sharing the same set of properties. When tag is not used at source it MUST be set to zero on transmission. When tag is not used during SRH Processing it SHOULD be ignored. Tag is not used when processing the SID defined in Section 4.3.1. It may be used when processing other SIDs which are not defined in this document. The allocation and use of tag is outside the scope of this document. At what scope does its use need to be defined? Can it be defined on a per-segment basis or must it be deployment-global? The mutability of the TLV value is defined by the most significant bit in the type, as specified in Section 2.1. It seems like this presents the design as one where we rely on the participants to be trusted to properly respect the (im)mutability, and there are not external mechanisms (e.g., cryptography) to enforce them. So, we have SR nodes that are in a hybrid state of not being trusted with HMAC keys (and thus to generate routing policy) but are trusted to "be implemented correctly" and not mutate fields that are supposed to be immutable. This multi-tier trust system should probably be discussed in the security considerations. Section 2.1 An implementation MAY limit the number and/or length of TLVs it processes based on local configuration. It MAY: [...] Is this list an exhaustive enumeration of the granted permissions or are other limitations possible? o Limit the number of consecutive Pad1 (Section 188.8.131.52) options to 1, if padding of more than one byte is required then PadN (Section 184.108.40.206) should be used. nit: comma splice Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. Length: The length of the Variable length data. Do we want to give a pointer to (e.g.) the registry for these type values? I see we say in the next entry that Length measures bytes, though perhaps it is more natural to mention it here. Type Length Value (TLV) contain OPTIONAL information that may be used by the node identified in the Destination Address (DA) of the packet. nit: there seems to be a singular/plural mismatch of sorts here, in that the current TLV incarnation mostly acts as a singular. I'd suggest adding another word like "entries" or "structures" after the parenthetical, as a resolution. The highest-order bit of the TLV type specifies whether or not the TLV data of that type can change en route to the packet's final destination: For clarity: that's bit '0' in the above figure? Section 2.1.1 Padding TLVs are used for meeting the alignment requirement of the subsequent TLVs. [...] Padding TLVs are used for alignment. Is there some redundancy here we could deduplicate? Section 220.127.116.11 required. If more than one byte of padding is required a Pad1 TLV MUST NOT be used, the PadN TLV MUST be used. nit: comma splice Section 18.104.22.168 Padding: Length octets of padding. Padding bits have no semantics. They MUST be set to 0 on transmission and ignored on [Elsewhere in the document we've used "semantic" as a singular; it might be worth a pass to check for consistency of usage] Section 2.1.2 I echo the sentiments already expressed about this HMAC format being likely to reflect substantial wasted space in much common usage. (Unless the intent is that since TLV support is optional, it's unlikely to be implemented at all, in which case the wastefulness of a nonexistent feature doesn't matter?) In particular, having to specify the details of which bits of the 'HMAC' field have significance when the HMAC algorithm in use has fewer than 32 bytes of output seems to be just as much effort as making the field variable length. Four octets of Key ID also seems like far more than will be needed, though we don't really discuss the scope (in space/topology and time) in which it needs to be unique -- we should probably talk about that here! (I do see a bit of discussion in Section 22.214.171.124 that seems to say that the key-ID is scoped by the destination IP address.) On the other hand, this much Key ID space could be used if there was a desire to have very fine-grained routing policy and revocation ability (see below), but it's still unclear that even in a high-churn fine-grained situation there would be the will to store millions of HMAC keys on the controller/verifier. The HMAC TLV is used to verify the source of a packet is permitted to use the current segment in the destination address of the packet, and ensure the segment list is not modified in transit. I'd suggest some revisions to this along the lines of: % The HMAC TLV is used to verify that the SR applied to a packet was % selected by an authorized party, and to ensure that the segment list is % not modified after generation. This also allows for verification that % the current segment (by virtue of being in the authorized segment list) % is an authorized use. since the expected usage seems to not be to give the keys (and thus the choice of segment lists) to the actual source of the packet, and we are detecting modification of the Segment List since the HMAC generation, which could span a broader period of time than just when the packet carrying the HMAC is "in transit". Section 126.96.36.199 For HMAC algorithms producing digests less than 32 octets, the digest is placed in the lowest order octets of the HMAC field. Remaining octets MUST be set to zero. To keep me from second-guessing myself, are these the "lowest order octets" if we are treating the field as a 32-byte big-endian integer? (As opposed to an array of bytes enumerated in order per the figure.) If HMAC verification is successful, the packet is forwarded to the next segment. Does this really mean "processing proceeds as normal", to allow for the possibility of local action/modification before forwarding? Section 188.8.131.52 The HMAC Key ID field is opaque, i.e., it has neither syntax nor semantic except as an identifier of the right combination of pre- shared key and hash algorithm, and except that a value of 0 means that there is no HMAC field. "No HMAC field" or "the HMAC field is filled entirely with zeros"? The previous diagram/discussion does not suggest that the HMAC field is sometimes omitted. At the HMAC TLV verification node the Key ID uniquely identifies the pre-shared key and HMAC algorithm. At the HMAC TLV generating node the Key ID and destination address uniquely identify the pre-shared key and HMAC algorithm. Utilizing This decision to make the key-ID space scoped to the destination address seems to have some potentially substantial consequences that I don't see discussed in the draft. Specifically, since the destination address will change on every hop, it would seem to preclude a model where the HMAC TLV is generated by the sender and not modified subsequently (which itself would probably have knock-on effects). Is the additional scoping by IP address of key-ID necessary even with the 4-octet key-ID, or would scoping the key-ID to be globally unique within a SR domain suffice? Unless the intent is that there is only a single verification node in a given path? The desired usage remains quite unclear to me. Section 3.2, 3.3 nit(?): We seem to talk about "an IPv6 packet" when we really mean "an IPv6 packet with SRH", "an SR IPv6 packet", "an SRv6" or similar. Section 4.1 A Source node steers a packet into an SR Policy. If the SR Policy results in a segment list containing a single segment, and there is no need to add information to SRH flag or TLV, the DA is set to the single segment list entry and the SRH MAY be omitted. nit: "to the SRH flags or to add TLVs" HMAC TLV may be set according to Section 7. Do we want to say anything about other, to-be-specified, TLVs here? Like "HMAC (or other) TLVs may be set" or "TLVs (including HMAC) may be set according to their specifications"? 4.1.1. Reduced SRH A reduced SRH does not contain the first segment of the related SR Policy (the first segment is the one already in the DA of the IPv6 header), and the Last Entry field is set to n-2 where n is the number of elements in the SR Policy. This seems to imply that Segments Left is not constrained to point inside the Segment List (and can point one past it); is that correct? Section 4.3.1 This document, and section, defines a single SRv6 SID. Future documents may define additional SRv6 SIDs. In which case, the entire content of this section will be defined in that document. nit: perhaps this is just me, but I tend to read "defines a single SRv6 SID" as "defines a single SRv6 SID value"; the intent here seems to be more along the lines of "SID behavior" or "SID processing algorithm". The second sentence could also be phrased similarly to "Such documents will need to specify the analogous behavior as is described in this section and subsections". Section 184.108.40.206 Is this pseudocode normative, or the text of the following subsections? Section 5.1 Nodes outside the SR Domain are not trusted: they cannot directly use the SID's of the domain. This is enforced by two levels of access nit: "SIDs" (no apostrophe) 1. Any packet entering the SR Domain and destined to a SID within the SR Domain is dropped. This may be realized with the following logic, other methods with equivalent outcome are considered compliant: nit: comma splice (also in (2)) * Failure to implement this method of ingress filtering exposes the SR Domain to source routing attacks as described and referenced in [RFC5095] nit: this doesn't seem like a bullet point in the list, but rather a standalone paragraph of commentary. It may also be worth reiterating that failure to do so on even a single edge node puts the entire network at risk. Section 5.2 Consider a top of rack switch (T) connected to host (H) via interface (I). H receives an SRH (SRH1) with a computed HMAC via some SDN method outside the scope of this document. H classifies traffic it sources and adds SRH1 to traffic requiring a specific SLA. T is I'm having a hard time parsing how the SRH1 that H receives via SDN can be the same SRH1 that H adds to traffic. The key insight seems to be that the SRH received via SDN is not attached to an IPv6 packet as a "live" routing header, but is rather a piece of configuration data to be applied as the SRH on flows sent on a given SR. (The formalism is slightly weird, as "receiving an SRH" includes the "next header" value, which is arguably artificially limiting, but this is probably minor enough to ignore.) So perhaps we want to say that "H receives, along with the configuration for applying SR to a given flow, an SRH (SRH1) with pre-computed HMAC that reflects that SR flow, via some SDN method outside the scope fo this document." An operator of the SR Domain may choose to have all segments in the SR Domain verify the HMAC. This mechanism would verify that the SRH segment list is not modified while traversing the SR Domain. As partially covered above, this seems inconsistent with having the HMAC key-ID be scoped by the destination SID when the destination SID changes from segment to segment. Section 5.4 For the source of an invoking packet to process the ICMP error message, the correct destination address must be determined. The "correct" in what sense/for what operation? * If routing header is type 4 (SRH) (This is still "TBD", formally, right?) + Use the SID at Segment List as the destination address of the invoking packet. Similarly to the first comment on this section, do we want some language about how this is "use"d "for processing by the upper layer transport"? Section 5.6 I'm slightly tempted to add a sentence along the lines of "the mechanisms in this document are known to not be directly transferrable to multi-domain deployment models without substantial impact on these properties", but (1) it's an absolute statement that seems like it would be hard to be 100% confident in, and (2) it's not entirely clear that it adds much value to the general reader (as opposed to providing a security disclaimer to make the security AD happy). So I'm curious to hear about how much thought has already gone into this, pointers to ongoing documents on the topic, etc. Section 6.1 I a little bit wonder if mixing zero-based (Segments Left; Last Entry) and one-based (S1, S2, S3) indexing is going to cause undue cognitive load for anyone. Section 6.2 o The SR domain is secured as per Section 5.1 and no external packet can enter the domain with a destination address equal to a segment of the domain. I'd suggest using "firewalled" rather than "secured", since "secured" can mean many different things and we have a more-precise term available. Section 6.3.2 Is it worth calling out that P5 does not have an SRH? Section 6.9 This section describes how a function may be delegated within the SR Domain to non SR source nodes. [...] I'm kind of confused about what "non SR source node" means in the context of a source node that is adding an SRH for verification elsewhere. Section 6.6.1 An operator may prefer to add the SRH at source 8, while 5 verifies the SID list is valid. I note that "add" here means "apply a fixed bitstring to the packet", not "compute the value of"... For illustration purpose, an SDN controller provides 8 an SRH terminating at node 9, with segment list <S5,S7,S6,A9>, and HMAC TLV computed for the SRH. The HMAC key is shared with 5, node 8 does not know the key. Node 5 is configured with an IACL applied to the ... since the SRH value is computed by the controller and distributed to 8 as almost an opaque token. It would be good if we could reword this to be more clear about how the mechanics work such that 5 does not need the HMAC key. Node 8 originates packets with the received SRH with HMAC TLV. nit: I suggest s/with HMAC TLV/including HMAC TLV/ Section 7.1 Does the ability to create traffic loops or near-loops (that span the same links dozens or hundreds of times) merit a specific mention outside of "DOS/DDOS"? Section 7.5 The SR Domain is a trusted domain, as defined in [RFC8402] Section 2 and Section 8.2. The SR Source is trusted to add an SRH (optionally verified via the HMAC TLV in this document), and segments advertised I suggest s/verified/verified as having been generated by a trusted configuration source/. The use of SRH with AH by an SR source node, and processing at a SR segment endpoint node, is not defined in this document. Future documents may define use of SRH with AH and its processing. It's not entirely clear to me what this is intended to convey. It this saying "SRH MUST NOT be used in the same packet as AH" or something more like "we make no statements about the use of SRH in combination with AH"? Section 8 RFC will be published. The Designated expert will post a request to the 6man WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. nit: this wording makes it sound like either the DE includes an I-D in the body of the mail or is the author of the I-D in question; I assume we just want a pointer or link to the draft requesting the allocation(s). Section 12.2 I-D.filsfils-spring-srv6-interop and I-D.matsushima-spring-srv6-deployment-status are only referenced from the Implementation Status section (that is to be removed); should the references be removed as well? I think RFCs 2104, 6437, and 6438 need to be normative.
The new "Segment Routing Header TLVs" registry (§8.2) includes a range "for TLVs that may change en route". However, I couldn't find a specification for these types of TLVs. The only clues come from §4.3.1 (FIB Entry Is Locally Instantiated SRv6 SID), where it says: Processing this SID modifies the Segments Left and, if configured to process TLVs, it may modify the "variable length data" of TLV types that change en route. Therefore Segments Left is mutable and TLVs that change en route are mutable. The remainder of the SRH (Flags, Tag, Segment List, and TLVs that do not change en route) are immutable while processing this SID. I am balloting DISCUSS because the description of "TLVs that may change en route" is not clear or specific enough. I would like to see a clear specification of what "TLVs that may change en route" are, *AND* corresponding instructions to the Designated Experts-to-be. Some related questions that come to mind include: Where can these TLVs be processed/changed? If the data is modified, what about the alignment, should the Padding TLVs be also changed? If no data is left, can the TLV be removed? The instructions above (for the SRV6 SID) seem generic enough to apply to other potential future SIDs, what type of variation is expected?
(1) I support Ben's DISCUSS. Adding to his HMAC concerns, §2.1 says that when "processing the SID defined in Section 4.3.1, all TLVs are ignored unless local configuration indicates otherwise (Section 220.127.116.11.1). Thus, TLV and HMAC support is optional for any implementation..." This seems to indicate that, regardless of the HMAC security properties, it will be ignored by default. (2) §4.1.1: "When a source does not require the entire SID list to be preserved in the SRH, a reduced SRH may be used." When does a source require the entire SID list to be preserved? Please provide an example of these cases. (3) §8.1: Given that the SRH Flags Bits are limited, I would like to see instructions to the DEs-to-be about the type of information that may need to be encoded in the Header.
Thank you for addressing my DISCUSS and COMMENT items.
I have a couple of questions/comments: 1) Given this is an IP header extension that would need to be added to every single packet when used, I would have expected a more byte-conserving design for the HMAC TLV. It doesn't seems that the RESERVED field is actually needed (as padding can be done by the padding TLVs) and the HMAC TLV could even be variable length based on the actual output of the HMAC algorithm used. Why was the current design chosen instead? 2) I agree with the TSV-ART review (Thanks Joe!) that MTU discussion in section 5.3 is not sufficient and at least a pointer to draft-ietf-intarea-tunnels would be good. 3) Sec 5.6: I would rather like to see a clear applicability state at the beginning of this document that the statement in section 5.6 at the end of the document. E.g. use of the HMAC TLV also assumes some kind of common (centralised/SDN-based) pre-configuration. I think it would be important to state these kind of constraints upfront. I think this point does not raise discuss level, however, I think it would be really important to address because it becomes clear when ready the document that certain deployment scenario was assumed and I think it would be appropriate to restrict the applicability of this spec to this scenario. Otherwise I think it would not be acceptable to have some of the "out-of-scope" statements in this doc. 4) I also agree with the TSV-ART review that the registration procedure for the Flags should be "IETF review". Alternatively I actually recommend to not create this registry now and leave this decision to the first RFC that will assign a flag (which would anyway need to update this RFC).
Thanks for addressing my comments!
I agree with Ben's DISCUSS. Also, BCP38 must be a Normative reference due to use in Section 7 in a SHOULD level requirement.
Hi, thank you for this document. I have a couple of questions on the definition of an SR segment endpoint node. Maybe I'm missing something obvious, but I read: A SR segment endpoint node is any node receiving an IPv6 packet where the destination address of that packet is locally configured as a segment or local interface. and then, in 4.3: A FIB entry that represents a non-local route No Match it seems to me that if we happen to be in such situations then the node doing the LPM is not an SR Segment Endpoint Node for that specific packet. As such, I'm not sure why these cases are being described in 4.3 and subsections. Also, 4.3.2 says: If the FIB entry represents a local interface, not locally instantiated as an SRv6 SID, the SRH is processed as follows: If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing Header. If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type. This is the exact same text as what 8200 specifies when the Routing Header type is unknown. That makes me wonder if a "node receiving an IPv6 packet where the destination address of that packet is locally configured as a [...] local interface" is effectively an SR segment endpoint node. nits: Padding TLVs are ignored by a node processing the SRH TLV. did you mean SRH's TLV(s) IPv6 headers are represented as the tuple of (source, destination). For example, a packet with source address A1 and destination address A2 is represented as (A1,A2). But then we find (SA,DA) ... o Source Address is SA, Destination Addresses is DA, ... Why not keep the formalism defined above and write it as (A1,A2) ? For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. If an RFC is really what the WG expects why not choose "RFC Required"?
Thank you for the hard work put into this easy to read document. Happy to see how this document has improved since the first drafts, years ago while I contributed to those first drafts. Regards, -éric == COMMENTS == -- Section 2 -- C.1) Unsure whether the use of multiple "U" to indicate unused bit is useful, most RFC states that this field is reserved. C.2) An explanation about why segments are in the reverse order would be helpful for the reader. -- Section 2.1 -- C.3) " an implementation adding or parsing TLVs MUST support PAD TLVs" is it just 'parsing' == read them ? -- Section 2.1.2 -- C.4) it is possibly already in the security AD DISCUSSes, but, I would make the HMAC field variable length as it depends on the HMAC algorithm being used. -- Section 18.104.22.168 -- C.5) "It may be based on ..., HMAC Key ID, or other packet fields." seems to contradict the opaque quality of the HMAC Key ID. I suggest to remove the mention of 'HMAC Key ID' here. C.6) See also C.4 (so please address either C.6 or C.4), need to specify what to truncate: most significant or least significant bytes. -- Section 22.214.171.124.1. -- C.7) Describing the use cases behind the example could help the reader. -- Section 126.96.36.199. -- C.8) rather a question of mine, is this behavior applicable for all SID on the paths? (i.e. on all SRv6-capable routers where the current DA matches the locally configured interface addresses/SID ?) I would have guessed that decapsultion only happen at the last segment as explained in 4.3.2. == NITS == -- Section 2.1.1 -- s/to verify the source of a packet/to verify whether the source of a packet/ -- Section 5.4 -- Please add a note to change the '4' to the IANA allocated value.
Thanks for addressing my discuss.