IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-26
Yes
(Suresh Krishnan)
No Objection
(Adam Roach)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
Note: This ballot was opened for revision 22 and is now closed.
Roman Danyliw
(was Discuss)
No Objection
Comment
(2019-10-15 for -25)
Sent for earlier
Thank you for addressing my DISCUSS and COMMENT items.
Éric Vyncke
No Objection
Comment
(2019-09-05 for -22)
Sent
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 2.1.2.1 -- 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 4.3.1.1.1. -- C.7) Describing the use cases behind the example could help the reader. -- Section 4.3.1.2. -- 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.
Suresh Krishnan Former IESG member
Yes
Yes
(for -22)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -22)
Not sent
Alexey Melnikov Former IESG member
No Objection
No Objection
(2019-09-04 for -22)
Sent
I agree with Ben's DISCUSS. Also, BCP38 must be a Normative reference due to use in Section 7 in a SHOULD level requirement.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -22)
Not sent
Alvaro Retana Former IESG member
(was Discuss)
No Objection
No Objection
(2019-10-17 for -25)
Sent for earlier
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2019-10-10 for -25)
Sent for earlier
Thanks for addressing my comments!
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2019-10-18 for -25)
Sent
Thank you for addressing my Discuss points (including by having a discussion to clarify that some of them are in fact non-issues)! Please also consider the following comments on the -25, none of which quite rise to Discuss-level, but some of which are significant. I wonder whether we will ever want to have the HMAC protect (some of) the other TLVs associated with the SRH; the current formulation is quite rigid about what the HMAC input is (and trying to change that later, e.g., by the presence of some other TLV, seems like a bad idea). What we have here is fine for now, though, and we could always define a new "HMACplus" TLV with richer semantics if a need arises. With respect to the "changing that later seems like a bad idea" point, I do see this text in Section 2: New SIDs defined in the future MUST specify the mutability properties of the Flags, Tag, and Segment List and indicate how the HMAC TLV (Section 2.1.2) verification works. Note, that in effect these fields are mutable. I'm coming at this from a perspective of the operational considerations when an HMAC verification node might implement only [this document] and thus anything attempting to generate an HMAC according to a modified procedure specified in some future document would produce an HMAC value that would fail to verify. Section 2.1.2 has: o RESERVED: 15 bits. MUST be 0 on transmission and ignored on receipt. yet those bits are used as input to the HMAC calculation, which seems to defy the "ignored" portion. Section 2.1.2.1 has: An implementation that supports the generation and verification of the HMAC SHOULD support the following default behavior as defined in the remainder of this section. which seems like it might have some vestiges of the previous model where most of the HMAC verification procedure was up to local configuration; I think we are now at a place where the following behavior is the only behavior (not "default") and there's no need to qualify it with "SHOULD". Also, it might be possible to spend some thought and convince ourselves that the 'D' bit is not strictly needed, since an entity creating an SRH for which the 'D' bit might be needed could just choose to not use the reduced SRH in cases where verification of the first segment would be needed. But I did not spend the time to reason through this, so I'm not advocating for removing the 'D' bit at this time. Section 2.1.2.2 has: At the HMAC TLV generating node, the Text for the HMAC computation is set to the IPv6 header fields and SRH fields as they would appear at the verification node, not necessarily the same as the source node sending a packet with the HMAC TLV. Pre-shared key roll-over is supported by having two key IDs in use while the HMAC TLV generating node and verifying node converge to a new key. which implies a single verification node (my recollection is that we settled on multiple verification nodes being possible). (Section 2.1.2.1 also has "as it would be reeived at the node verifying the HMAC", in a similar vein.) Section 4.3.1.1.1 has: Example 2: For any packet received from interface I1 If first TLV is HMAC { Process the HMAC TLV } Else { Discard the packet } This shows the location of the HMAC TLV as being up to local policy. This is ... probably okay from a security point of view, but I mention it in case our previous discussions have caused us to not want to endorse this being a part of local policy.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -22)
Not sent
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2019-10-07 for -24)
Sent
Thanks for addressing my discuss.
Martin Vigoureux Former IESG member
No Objection
No Objection
(2019-09-05 for -22)
Not sent
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"?
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2019-08-29 for -22)
Sent
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).