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

Brian Weis <bew.stds@gmail.com> Wed, 01 May 2024 18:22 UTC

Return-Path: <bew.stds@gmail.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 8FDC5C14F610; Wed, 1 May 2024 11:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aNn6PV-Ob0yc; Wed, 1 May 2024 11:22:35 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 6EAABC14F5EC; Wed, 1 May 2024 11:22:35 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6ea0a6856d7so1082704a34.1; Wed, 01 May 2024 11:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714587754; x=1715192554; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=nJLi1YymWXiG1zjCEo5JESSDYSWnc5G7peGgWneqoFY=; b=gKVpd0MXzOMXkrU3M1R6l+9vaHxVv0654oWCv6T+KXoquuuWnkDGL1nRZkS2PYmkMW FELKu+Opxm3kGP5kUQBtJfSjeK+xVIupqi65yE3O3xmjEOTx+yUq3RNOcNlSPxve2IFM 2W1CbUMkOzZsuunmGDD5OThTNPaQwkvEcRo2ZwDY4LLy70EBAZZkZeZdv1rdc1f3l1ox 15qdviParD4I+4WOvQmJ5CCUIxPDnAuzFFXf61ZbnDEaOd5VBhm+3H1EXGzBxjEur7Pw 7PCzw0MIzAdTTBZdLrvKZuFtdb/FBqB4vp+ZjUGSbwOkkUgLf8jFecN2pHLRfpSStQLT QRVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714587754; x=1715192554; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nJLi1YymWXiG1zjCEo5JESSDYSWnc5G7peGgWneqoFY=; b=oboQjnQ6EYpbY+F4FfBaheTG/6lMZ+A/0DBFCjrllFIl17pODCBkf3YRox93fPwTH7 hkMBMBRP8RiJOWya/hPDY0kwZwGk050Y2cq+S+96zanKmsCR7gQSUjpXyH7QOSY5LQn8 cQ2iK02sgmbFVAyHAi6vp6At+U322RaUE2d+Kj9Rz/oZubNyGyoR0I8wcpRYmhHQ5RdN BwKIf0y7H3bxV3ZmQffnewwxt/mTyL756sMMax6VQeD2vc1ypJ39LUSHUUsHwqtqmrEV 0XIy1XAXKNXQGN9DQbgopxp7mUj9P8Bq567XDfgX6dDyCv5U8Juk3ySL0eCvGYfWKlWo tUEg==
X-Forwarded-Encrypted: i=1; AJvYcCXdsmVHSH31eDoH6aKzuKlD1/GxYasZMmgjfI/+MBQmcdxwYxis3ImGFjyEoo5q5TDKepaPFMAXkRwYFqdJqp/lfekNWkMz/Mg801lvXf9tKsUip2TaOew99EIFJiewn3rKnocgJ/TxcnUzpOcGjtgS1kTAoAiQ0QJvCTfK
X-Gm-Message-State: AOJu0Yxvrrok3CU9WXMXUvPInHglDVlz1TXfXDj8vagxBx0BaJKaReq4 XBCxeYgFKwuAb0ZPc33M0ILV5jyrsBortZswgEet4XfNTNGuiIcWFTfmdTmA
X-Google-Smtp-Source: AGHT+IHX/6MgQ0DCqmvBgFuk8XX/dwvHv+aEbLMn5EYgVwVacjv3KzDCqrPZ9xPdeq/G7w0U5TlIAA==
X-Received: by 2002:a9d:7a57:0:b0:6ee:653d:1a97 with SMTP id z23-20020a9d7a57000000b006ee653d1a97mr3723548otm.0.1714587754051; Wed, 01 May 2024 11:22:34 -0700 (PDT)
Received: from smtpclient.apple ([2600:1700:65ab:5a00:bc94:7acb:c231:22ad]) by smtp.gmail.com with ESMTPSA id z7-20020a056830290700b006ee3d91389asm1163412otu.51.2024.05.01.11.22.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2024 11:22:33 -0700 (PDT)
From: Brian Weis <bew.stds@gmail.com>
Message-Id: <2990AC5A-7C46-4C18-B3A9-834D4AA55AC3@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D392CC49-88E5-424A-9BD5-AE955C828549"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Wed, 01 May 2024 11:22:22 -0700
In-Reply-To: <BL0PR05MB53160678F12C103F872C5F41AE1A2@BL0PR05MB5316.namprd05.prod.outlook.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "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>
To: Ron Bonica <rbonica@juniper.net>
References: <171444725522.55585.5132887651447845904@ietfa.amsl.com> <BL0PR05MB53160678F12C103F872C5F41AE1A2@BL0PR05MB5316.namprd05.prod.outlook.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/95PsgQuphtf5-zVb7yMedHTKcvg>
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: Wed, 01 May 2024 18:22:36 -0000

Hi Ron,

I’ve added some replies inline [BEW].

> On Apr 30, 2024, at 11:24 AM, Ron Bonica <rbonica@juniper.net> wrote:
> 
> Hi Brian,
> 
> Thanks for the review. Response inline [RB].
> 
>                                          Ron
> 
> 
> Juniper Business Use Only
> 
> From: Brian Weis via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>>
> Sent: Monday, April 29, 2024 11:20 PM
> To: secdir@ietf.org <mailto:secdir@ietf.org> <secdir@ietf.org <mailto:secdir@ietf.org>>
> Cc: draft-ietf-6man-comp-rtg-hdr.all@ietf.org <mailto:draft-ietf-6man-comp-rtg-hdr.all@ietf.org> <draft-ietf-6man-comp-rtg-hdr.all@ietf.org <mailto:draft-ietf-6man-comp-rtg-hdr.all@ietf.org>>; ipv6@ietf.org <mailto:ipv6@ietf.org> <ipv6@ietf.org <mailto:ipv6@ietf.org>>; last-call@ietf.org <mailto:last-call@ietf.org> <last-call@ietf.org <mailto: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?

[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