The IPv6 Compact Routing Header (CRH)
draft-ietf-6man-comp-rtg-hdr-10

Access Control Lists (ACLs) are mentioned in the Introduction and in the Security Considerations sections and no where in between.  This draft does not explain/clarify why or how an ACL helps the security posture of this draft.  

I'm making these comments non-blocking because of the way the term 'ACL' is used here.  In the security world, an ACL usually applies to permissions given (or not given) to processes or people to establish access control, or least privilege.  If that is what is intended here, then there needs to be information given on how to construct the ACL.

A few additional comments (I have included line numbers from idnits for the latest version):

18	   This document describes an experiment in which two new IPv6 Routing
19	   headers are implemented and deployed.  Collectively, they are called
20	   the Compact Routing Headers (CRH).  Individually, they are called
21	   CRH-16 and CRH-32.

Jim> This first paragraph seems to overlap with the second paragraph with its discussion of implementation and deployment. Perhaps reword it as follows as the second paragraph is clear enough as to the purpose of the experiment.

	   This document describes an experiment in which two new IPv6 Routing
	   headers are defined; Collectively called the Compact Routing Headers 
           (CRH).  Individually, they are called CRH-16 and CRH-32.

89	1.  Introduction

91	   IPv6 [RFC8200] source nodes use Routing headers to specify the path
92	   that a packet takes to its destination.  The IETF has defined several
93	   Routing header types [IANA-RH].  This document defines two new

Jim> [IANA-RH] defines ‘Routing Types’ not ‘Routing header types’. It would be more precise to just say ‘Routing Types’.

107	   *  Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely
108	      reliable, many IPv6 hosts refrain from sending packets larger than
109	      the IPv6 minimum link MTU (i.e., 1280 bytes).  When packets are
110	      small, the overhead imposed by large Routing Headers is excessive.

Jim> The above text is making a statement that may or may not be true dependent upon who one talks to ;-) I would suggest to say, ‘large Routing Headers may be excessive’.

207	   The topological function specifies how the processing node forwards
208	   the packet to the interface identified by the IPv6 address.  The
209	   following are examples:

Jim> Is this an exhaustive list? If not, please specify that.

232	   The above-mentoned mechanisms are not defined here and are beyond the

Jim> s/above-mentoned/above-mentioned

250	   *  If L is greater than Hdr Ext Len, discard the packet and send an
251	      ICMPv6 Parameter Problem, Code 0, message to the Source Address,
252	      pointing to the Segments Left field.

Jim> Why would the ICMPv6 message point to the Segments Left field? Shouldn’t it point to the Hdr Ext Len field?

332	8.  Applications And SIDs

Jim> s/Applications And SIDs/Applications and SIDs

Thank you to Elwyn Davies for the GENART review.

** Section 12.  The abstract said “another purpose is to demonstrate that the security considerations, described in this document, can be addressed with access control lists.”  Based on the text in this section it isn’t clear what the unknown (requiring an experiment) is around implementing these Security Considerations.

** Section 14.  The nature of the experiment isn’t clear in the following cases:
-- At the highest level, how do we know the experiment was a success?

-- Per “Effort required to secure”, what is the units of this effort?

-- Per “Effectiveness of risk mitigation with ACLs”, how is one expected to answer this question?  

-- Per “Effectiveness and sufficiency of OAM mechanism
      -  Did PING work?
      -  Did TRACEROUTE work?
      -  Did Wireshark work?
      -  Did TCPDUMP work?”

In what way is support in these tools an open-ended question requiring experimentation on a production network?  Can’t one check functionality/support per a given version number of these tools?

Thanks for the discussion!

# Éric Vyncke, INT AD, comments for draft-ietf-6man-comp-rtg-hdr-09

Thank you for the work put into this document. I do like the idea of compressing SRH-like header. Thanks also for addressing my previous blocking DISCUSS points at:
https://mailarchive.ietf.org/arch/msg/ipv6/a_RdmiI3iYk6Sk6mamrppoLTvnc/

I have kept open non-blocking COMMENT points as I think that they would improve the document, up to the authors and the 6MAN WG of course to decide.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Bob Hinden for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status (and IMHO experimental is the right one).

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Abstract

Can we really write `deployed` for an experimental I-D?


## Section 3

Any recommendation on when to do `The first CRH SID in the path can be omitted from the list.`?

What is the expected behavior of any CRH-aware router and final node(s) when `the Type- specific data field MUST be padded with zeros` is not respected ?

## Section 5

While wasting octets with too large CRH (i.e., larger than the minimum length) is a bad thing, does it deserve to discard the packet on transit ? Why not requesting the source to enforce this mimimum length?

`If the search does not return a CRH-FIB entry` is the code 0 the most suitable code ? If not, why not creating one ? Or even using ICMPv6 code 1 'destination unreachable' ?

`If Segments Left is greater than 0` this will always be the case per first bullet `If Segments Left equals 0` ;-)


## Section 6

I guess that this is linked to RFC 4302 (AH), so, please state this clearly.

## Section 9

While not a real DISCUSS criteria, I am really surprised to see an IPv4-like notation for CRH SID.

## Section 10

`The Source Address does not identify an interface on a trusted node.` is there any hint how this can be done ? How will it scale if all CRH-enabled router must know all the specific address of all trusted nodes ? The same scalability issue for `The ACL discards packets whose source address identifies an interface on a trusted node.`

## Section 11

If the Wireshark/tcpdump modifications (cited in section 9) are public, then references to code will be welcome.

`Interoperability among these implementations has not yet been demonstrated.` should rather be in section 14 'experimental results'

## Section 14

I am indeed very curious to see the experimental result of
```
Mechanism used to populate the FIB
Scale of deployment
```
even if the text states in one year after publication as an RFC, this work started back in 2019 and was adopted in 2023, do we already have some results ?

What are the possible next steps as seen by the authors / 6MAN WG is the experiment is assumed to be successful ? And what are the criteria to declare a successful experiment ?

# NITS (non-blocking / cosmetic)

## Section 12

s/This is becasue /This is because/