| Hi Ron,
I’ve added some replies inline [BEW]. On Apr 30, 2024, at 11:24 AM, Ron Bonica <rbonica@xxxxxxxxxxx> wrote:
Hi Brian,
Thanks for the review. Response inline [RB].
Ron
Juniper Business Use Only
[External Email. Be cautious of content]
Reviewer: Brian Weis
Review result: Has Issues
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.
[RB] What topology information can the attacker deduce? How would the attacker deduce this information?
[BEW] It depends upon what an attacker can access. I think the main point to this threat is that traditionally the information needed to create a map of a network is distributed by routing protocols and/or management protocols rather than in the data packets themselves. Those protocols are hopefully protected or otherwise unavailable to an attacker. This would be especially true when mappings are distributed from a controller as they are certainly protected by TLS. But since source routing methods distribute “routes” in the data packets themselves, an attacker obtaining enough data packets could theoretically put together a connectivity map. In the case of CRH, they would be mapping SIDs rather than IPv6 addresses, but since the IPv6 DA is updated on every hop I suppose an attacker with access to a few points in the network could begin do do the mappings of SIDs to IPv6 addresses too. I think this is summarized by the text in RFC 8754, which I believe would apply here as well: "If packets can be snooped within the SR domain, the SRH may reveal topology, traffic flows, and service usage."
— 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?
[RB] Is this problem specific to the CRH? Or is it a general limitation of ICMP? Could you criticize MPLS, SRv6 or even IP for the exact same reason?
[BEW]. No, definitely not specific to CRH. It’s a limitation to many protocols that depend on ICMP. But if the failure of ICMPs affects the state or connectivity of CRH it's worth mentioning as a concern.
— 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.
[RB] I think that we a stumbling over an important omission in RFC 4302. RFC 4302 says that AH processing will discard any packet that includes an unrecognized IPv6 extension header. RFC 4302 also describes support for the (now defunct) Routing Header Type 0. It explains that it can process RH0 because it is "predictably mutable". That is, only the hop-limit, destination address, and segments left fields can be altered in flight.
The CRH, like RH0, is predictably mutable. Only the hop-limit, destination address, and segments left fields can be altered in flight.
But now we must ask how AH processing deals with a packet that contains any Routing Extension header other than RH0. The following are possibilities:
Assume that the routing header type is predictably mutable and process the packet, exactly as it would have processed RH0 Discard the packet, Because RH0 is the only extension type mentioned in RFC 4302 Process the packet, according to some type-specific rules that are not documented in any RFC
If we assume that the unrecognized routing header type is predictably mutable, AH processing should "just work" for the CRH and for any other predictably mutable routing type. However, AH validation would fail for unrecognized and mutable types.
In the other two cases, AH processing has a problem that is not specific to the CRH. Every routing header type would have the same problem.
[BEW] Following the thread between you and Tom I see suggestions that some fields in a routing header be skipped in the ICV computation. It does seem that would require an update to AH.
[BEW[ But as I understand Section A2 of RFC 4302 regarding the Routing Header, mutable but predictable means that "The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation.” If AH is evaluated hop-by-hop then the receiver is the next hop so there’s no problem because the receiver will validate exactly the octets in the routing header and IPv6 header before re-writing the mutable fields. But if AH is end-to-end, then I interpret this text to require that the sender present to AH the set of octets that the destination will see rather than what the next hop will see. Assuming intermediate nodes are not validating the AH header and that the final CRH node creates the header contents that the sender expects to be given to the destination then it seems to me that AH actually should work. That’s a bit of extra work for the source IPv6 stack, of course. Caveat: I did not actually look at any IPv6 implementation to see what are the current semantics for dealing with Routing Headers.
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).
[RB] It is true in all cases where the Segments Left field is equal to 0.
[BEW] Maybe this should be clarified?
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.
[RB] Good catch. I can substitute the words "part of the same management domain" for the words "operated by the same party".
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.
[RB] OK. I can add a few words in the Section 7.
Thanks, Brian |
