I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Has Issues.

RFC 8200 defined a Routing Header, of which a few types have been
defined, most notably the Segment Routing Header (SRH). This draft
defines two new Compact Routing Header (CRH) types, which instead
of passing a list of IPv6 address as a “source route” passes smaller
identities (SIDs) of size 32 octets or 16 octets. The SIDs are
mapped 1-to-1 to IPv6 addresses through a new CRH “forwarding base”
(FIB). The mapping for the CRH FIB is distributed to each router
in one of several existing ways, so the distribution of the mappings
is out of scope of this I-D.

The new items defined in the draft are (1) new Routing Header payload
structures, and (2) the structure of the CRH FIB stored on the
router.

Security Considerations considers threats of receiving a CRH from
an untrusted router, and of receiving a CRH from a trusted router
but for which the packet headers fails a routing path analysis.
These are good, but I believe the authors should also consider the
issues addressed in Security Considerations of RFC 8754 (SRH) and
mention ones that apply. In particular:

— Topology Disclosure. If an attacker can deduce the topology based
on CRH headers then the privacy benefit mentioned in Section 7 of
this I-D is compromised.

— Dependance on ICMP messages. If an on-path node initiates ICMP
messages to the source (S) but they are discarded or modified within
the network (e.g., by an attacker or network fault) then S may
continue to send CRH headers that cause the IPv6 packet to be
discarded by the on-path node. How to mitigate this failure should
be considered. For example, it would be good to discuss how S is
expected to choose a different set of SIDs toward its ultimate
destination. Will routing or a management station learn of the
failure and distribute a new set of SIDs for the ultimate destination?

— Use of AH. It would be worth mentioning that an Authentication
Header (AH) cannot be included in an IPv6 packet containing a CRH.
This is due to the dynamic nature of the IP Destination and CRH
header “Segments Left” field, which will cause a failure in the AH
validation.

Following are a few additional comments.

Section 5, first bullet. This states that “The IPv6 address in the
IPv6 Header's Destination Address field is that of the ultimate
recipient.” I could see this being true on the source router as it
initially generates the CRH header, but is it true on the on-path
nodes as well? It seems when they receive the IPv6 packet that the
IP Destination will have been re-written from the CRH-FIB entry
(see the 9th bullet in the list).

Section 11, first sentence: “one node trusts another only if both
nodes are operated by the same party”. It would be good to mention
how a node might know which other nodes are “operated by the same
party”, e.g. because they are part of the same management domain.

One general comment is that I would expect the network operators
in some networks  to deploy packet inspection devices (e.g., firewall,
intrusion detection) at choke points within the network. Because
the IPv6 Destination Address is changed hop-by-hop they cannot
simply compare the packets SA and DA to {source, destination} rules
simply by extracting the SA an DA from the packet. In order for
these packet inspection devices to validate based on endpoint
addresses they will need to be aware of the mapping of SIDs to IP
addresses. I think this issue is worth mentioning in Security
Considerations.