Skip to main content

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).