Re: [IPv6] Secdir last call review of draft-ietf-6man-comp-rtg-hdr-05

Tom Herbert <tom@herbertland.com> Tue, 30 April 2024 22:47 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85899C180B73 for <ipv6@ietfa.amsl.com>; Tue, 30 Apr 2024 15:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWmTcUrtah_q for <ipv6@ietfa.amsl.com>; Tue, 30 Apr 2024 15:47:25 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD18C180B7D for <ipv6@ietf.org>; Tue, 30 Apr 2024 15:47:25 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2db17e8767cso74827061fa.3 for <ipv6@ietf.org>; Tue, 30 Apr 2024 15:47:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1714517242; x=1715122042; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=b1L8ORUGPN4GFKoZ9h1kA2OyovN1ZeKJWXVjebfTk3I=; b=UQStcD6GYDsCoHbzY6HlYqR3teq4+6chzPbvH6kSUdKL+7gbaVmpUQJX4/OUR/dLnW mgrTZSCiWbQCleXKuz2bjn6MlP3A04i/SSy+O5pUEbPYSZ9K8yDCOSiOuoo3mbf5P+jM crkiSBKBI2uEnXPZaTqk2em5qPlb8dEcg6iU60k562W3Io+HVyzEByrDDfDHlp2+jYbh pHxt+MFFraJGa1PPwgktqEFfpjEEtpVx+nsUfj+sAEQ0sM/mzHdA6BytIbEnSJ/j9+KU m8G8EL7mhrLMN632VrjeePBsyvUiNE00/E2z3sva0KskNCYqOzFhvbKke7l9qcWAC9V3 0BAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714517242; x=1715122042; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b1L8ORUGPN4GFKoZ9h1kA2OyovN1ZeKJWXVjebfTk3I=; b=FPPWF2HIXXkaHdTJRZBvc1vu9oP+S6u0g5UaJV2VB20LnQk6o9/rVnMjZL7CI5OT2g ig0a1+wITGlghOA5w7RHs+IMgF/q2fqoPT+k0wZ4607Z2Mcae9pU07WfFvIFEC6NAfHe gZnmU2rlAJuoa+KQd8r4JvNz7IHuMYXvUOn130emJgdo+ucxLEkn6rUoNlVbkQXo0PFy xJstnDEGXaRrfFfze5E+G9JBJrY09mMpIk+6dT5DuLoHl104iounsbvSkhLJczKwcEG4 jzxZFjwu3oZOE261kVfmFujQ3qpX3p8gmFTvIRAJQwiFy+A0UcJejbjR9XAqHyT7k5ru MKvg==
X-Forwarded-Encrypted: i=1; AJvYcCWkCS7D+rif5uSFmwyPyBSavgwmUx2Y4dDpDrBc0M2y8PfCZrpgOnmxOMwvvO6614MQjVEpGCrHa6sxqLKI
X-Gm-Message-State: AOJu0YywZZHZ8XDxymyGgxdgCsnbzdAABCtY9G8AyiBnzZsL5C4xJeQL UUs4acf5NFvnSGNH9SqpuUm5lbe9a+NnhbprJ3Y+JWGdbicT0ec49GTOzXAqQln5x/IGx2uNsgd TudhU6JLHqWGp/C1eYEPSOF3x4DCOoNHac14e
X-Google-Smtp-Source: AGHT+IG5cbTkDBauDYURiT4B+480y0HKEveypyjZSBWVh7RgcM+exNuOQtM6PRLs9Ih18JpKtRKwRtuFUaab3iyj100=
X-Received: by 2002:a2e:bea6:0:b0:2df:ebd2:6fdb with SMTP id a38-20020a2ebea6000000b002dfebd26fdbmr627162ljr.28.1714517242469; Tue, 30 Apr 2024 15:47:22 -0700 (PDT)
MIME-Version: 1.0
References: <171444725522.55585.5132887651447845904@ietfa.amsl.com> <BL0PR05MB53160678F12C103F872C5F41AE1A2@BL0PR05MB5316.namprd05.prod.outlook.com> <CALx6S37GX8vE8wObuKS0EEYT_-KvE49h-Jv1a5T7Lk8VcTFdhQ@mail.gmail.com> <BL0PR05MB531668DDF7947260A85C5A23AE1A2@BL0PR05MB5316.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB531668DDF7947260A85C5A23AE1A2@BL0PR05MB5316.namprd05.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 30 Apr 2024 15:47:11 -0700
Message-ID: <CALx6S35fz9ErDW_mLCgEy9GpWWjAc9ENFvry1doNPn5e9QpU1g@mail.gmail.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: "secdir@ietf.org" <secdir@ietf.org>, Brian Weis <bew.stds@gmail.com>, "draft-ietf-6man-comp-rtg-hdr.all@ietf.org" <draft-ietf-6man-comp-rtg-hdr.all@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/P-lP4PNsXzTCEECWuFqxFWXtvPY>
Subject: Re: [IPv6] Secdir last call review of draft-ietf-6man-comp-rtg-hdr-05
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2024 22:47:29 -0000

On Tue, Apr 30, 2024 at 3:28 PM Ron Bonica
<rbonica=40juniper.net@dmarc.ietf.org> wrote:
>
> 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.

Make sense.

>
> 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.

Right.

>
> 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.

Right, but at least those fields that should be excluded by ICV
calculation or easily identifiable.


>
> 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.

I'm not sure we need a separate document on this, it's not like
there's a lot of different Routing Headers. Why not just describe the
proper operation of AH in CRH and we can point future designers of
routing header to that as precedent?

Tom



>
> 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@dmarc.ietf.org>
> Sent: Tuesday, April 30, 2024 2:53 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: secdir@ietf.org <secdir@ietf.org>; Brian Weis <bew.stds@gmail.com>; draft-ietf-6man-comp-rtg-hdr.all@ietf.org <draft-ietf-6man-comp-rtg-hdr.all@ietf.org>; ipv6@ietf.org <ipv6@ietf.org>; last-call@ietf.org <last-call@ietf.org>
> 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@dmarc.ietf.org> wrote:
> >
> > Hi Brian,
> >
> > Thanks for the review. Response inline [RB].
> >
> >                                          Ron
> >
> >
> > Juniper Business Use Only
> >
> > ________________________________
> > From: Brian Weis via Datatracker <noreply@ietf.org>
> > Sent: Monday, April 29, 2024 11:20 PM
> > To: secdir@ietf.org <secdir@ietf.org>
> > Cc: draft-ietf-6man-comp-rtg-hdr.all@ietf.org <draft-ietf-6man-comp-rtg-hdr.all@ietf.org>; ipv6@ietf.org <ipv6@ietf.org>; last-call@ietf.org <last-call@ietf.org>
> > 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@ietf.org
> > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!EdXmJzrcziR7zR-VQMsR1-ZKi224GSGqCkPiehUgvehSA6vQ6ZjPc39KlpomyKfEVWWdzNyiw56ZmeFMHfvSq9c8uWhdzwM$
> > --------------------------------------------------------------------