Last Call Review of draft-ietf-6man-comp-rtg-hdr-05
review-ietf-6man-comp-rtg-hdr-05-secdir-lc-weis-2024-04-29-00
Request | Review of | draft-ietf-6man-comp-rtg-hdr |
---|---|---|
Requested revision | No specific revision (document currently at 10) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2024-04-29 | |
Requested | 2024-04-15 | |
Authors | Ron Bonica , Yuji Kamite , Andrew Alston , Daniam Henriques , Luay Jalil | |
I-D last updated | 2024-04-29 | |
Completed reviews |
Secdir Telechat review of -06
by Brian Weis
(diff)
Genart Last Call review of -05 by Elwyn B. Davies (diff) Secdir Last Call review of -05 by Brian Weis (diff) Opsdir Last Call review of -05 by Susan Hares (diff) Tsvart Last Call review of -05 by Gorry Fairhurst (diff) |
|
Assignment | Reviewer | Brian Weis |
State | Completed | |
Request | Last Call review on draft-ietf-6man-comp-rtg-hdr by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/Q-WaS5JR79DoY8XWkk7rujErtcs | |
Reviewed revision | 05 (document currently at 10) | |
Result | Has issues | |
Completed | 2024-04-29 |
review-ietf-6man-comp-rtg-hdr-05-secdir-lc-weis-2024-04-29-00
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.