|
Tom,
There is an argument to be made that AH processing should treat all unrecognized Routing Types as predictably mutable. That is, the only fields that can change in flight are the hop-limit, destination address and segments left. Therefore, the ICV can be calculated
over all remaining fields.
If AH processing were to do this, packets containing unrecognized but predictably mutable routing header types would pass validation. Packets containing unrecognized but not predictably mutable routing types would fail validation.
The SRH is a example of a routing type that is not predictably mutable. A few additional fields can change in flight and AH processing needs to know which fields those are so it can exclude them when calculating the ICV.
In any event, this discussion is not specific to the CRH. It applies to all routing header types except for the (now deprecated) RH0. While this discussion is interesting, it is beyond the scope of the CRH document. We should introduce a separate AH document
concerning the processing of unrecognized Routing Header Types.
Brian, Tom, do either of you have any interest in working with me on this?
Ron
Juniper Business Use Only From: Tom Herbert <tom=40herbertland.com@xxxxxxxxxxxxxx>
Sent: Tuesday, April 30, 2024 2:53 PM To: Ron Bonica <rbonica@xxxxxxxxxxx> Cc: secdir@xxxxxxxx <secdir@xxxxxxxx>; Brian Weis <bew.stds@xxxxxxxxx>; draft-ietf-6man-comp-rtg-hdr.all@xxxxxxxx <draft-ietf-6man-comp-rtg-hdr.all@xxxxxxxx>; ipv6@xxxxxxxx <ipv6@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> Subject: Re: [IPv6] Secdir last call review of draft-ietf-6man-comp-rtg-hdr-05 [External Email. Be cautious of content]
On Tue, Apr 30, 2024 at 11:24 AM Ron Bonica <rbonica=40juniper.net@xxxxxxxxxxxxxx> wrote: > > Hi Brian, > > Thanks for the review. Response inline [RB]. > > Ron > > > Juniper Business Use Only > > ________________________________ > From: Brian Weis via Datatracker <noreply@xxxxxxxx> > Sent: Monday, April 29, 2024 11:20 PM > To: secdir@xxxxxxxx <secdir@xxxxxxxx> > Cc: draft-ietf-6man-comp-rtg-hdr.all@xxxxxxxx <draft-ietf-6man-comp-rtg-hdr.all@xxxxxxxx>; ipv6@xxxxxxxx <ipv6@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> > Subject: Secdir last call review of draft-ietf-6man-comp-rtg-hdr-05 > > [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? > > — 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? > > — 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. Hi Ron, I would point out that for Segment Routing, RFC8754 states "the SR domain does not rely on the Authentication Header (AH) as defined in [RFC4302] to secure the SRH.". I believe this is their way of saying that AH cannot be used when SRH is present in an IPv6 packet. I, and others on the 6man list objected to that. SRH, like HBH, RH0, and presumably CRH are predictably mutable, so making them compatible with AH is just a matter of specifying the requirements for ignoring mutable fields for the respective protocol header when computing ICV. So IMO, AH should be usable with CRH. Also, I'm trying to wrap my head around the idea that an extension header could be _unpredicatably_ mutable. It seems like that wouldn't be very robust protocol. Do you know any examples of that? Tom > > > 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. > > 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. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@xxxxxxxx > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!EdXmJzrcziR7zR-VQMsR1-ZKi224GSGqCkPiehUgvehSA6vQ6ZjPc39KlpomyKfEVWWdzNyiw56ZmeFMHfvSq9c8uWhdzwM$ > -------------------------------------------------------------------- |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
