Re: Questions regarding the security mechanisms//RE: CRH and RH0

Gyan Mishra <> Sat, 16 May 2020 20:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C0403A08C7 for <>; Sat, 16 May 2020 13:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VJ4qq3jc8x_a for <>; Sat, 16 May 2020 13:05:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2BEB3A08B5 for <>; Sat, 16 May 2020 13:05:28 -0700 (PDT)
Received: by with SMTP id 17so6046384ilj.3 for <>; Sat, 16 May 2020 13:05:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YNFyyl7XpJFVpAFWj17OJFXzNqOHXaglf3D8YTEa9ko=; b=NAGbDaN5YxgIlhpGVFVEhWivvSXHv/2gIVHhsBTI+Y81r3KMtmlMJvaYfBuzpsYu00 z9FQR7nAhM/xkHWAovRy0SEyj0mHhySbAisAh+WIIBW9+SyjmDiUS0Jurc3sm/8PPlv6 6H1UgzUzvuKhsWrabvzMWa/J1TIDKRli4QoGvt5tm5p/mlMRmXsN1M2JrWJClkHtFx2D +SZvE6zOfDBxvsX2NpTUh/8wt1BRfRWJvdpnec60h9LnKrm0vpzqi/E7vHW+U++orftU V1oRoUVV795IeIG4CF9D+osdYq7HQehFlKysp7X3J+xY/ttAja2aIsrSHpuHUor2noEH QvpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YNFyyl7XpJFVpAFWj17OJFXzNqOHXaglf3D8YTEa9ko=; b=brbDSqmQ9N88/m4lyFHb6Cz1P/1fwkMwz2jzN9ezP//jgN54MM+wKenka0hsi2SpsM HHQeP6oxtdL10ymcPdenJmcpzjugow2huHT9dV+6n5X2n7tkikT9/IQAyowbb21W/Ctp wOxd03nBE8MfGb+abXox4JBKM9CKlNvRP34HY7rQc6z+T4H6PJa5Lo0LeeXAHtJyNOoN OcPg4M15/vPEPcMlzI2yLwNzlXaU+T4lHOJ0yYqyEoCHbwalS+ri9fhQIMojUcaxxRvC y7HdETSVxNDZOaq5KU11BBjfdSXmTjRV5raQkKe4kUj5wJiH6uNlG9G9Ha0mFl9BKaTR FyTA==
X-Gm-Message-State: AOAM532p+pl/Q0PFEg53HZQd7oroXqFw8Pf8k/fMMjFz0wzoMDsxb5Hy WzTmDwZz49LThDVocyxLIvz0K+wIIGEwulP0ZQFEDpncG28=
X-Google-Smtp-Source: ABdhPJxGJdUlKh9Z9DYvrU0f0c/a+ZOCYjUHxRpLBTB8NEwkquVftxdsBj+5sJFAuJi5DMxNJ/p053cCaUcSsU5EdgM=
X-Received: by 2002:a05:6e02:e8c:: with SMTP id t12mr7992361ilj.186.1589659528270; Sat, 16 May 2020 13:05:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <006c01d62aa1$8c195520$a44bff60$@com> <> <> <> <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Sat, 16 May 2020 16:05:17 -0400
Message-ID: <>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0
To: Nick Hilliard <>
Cc: 6man <>, John Scudder <>
Content-Type: multipart/alternative; boundary="0000000000007f173105a5c973d9"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 May 2020 20:05:31 -0000

Very good point that from a security perspective most devices may not be
able to process CRH and to that end mentioning there CRH processing MUST be
disabled by default which drastically reduces if not eliminates any attack

Also any source CRH node wanting to steer packets over the internet or
private must be knowledgeable of the DA nodes IPv6 address hop by hop along
the steered path independent of domain specific properties as CRH has
ubiquitous use cases for traffic steering.  So in that context the each
node along the steered path must have manual enablement of CRH processing
and that in itself is your security.

All best practices of ACL Ingres and egress of domain specific security
would be maintained.

So if the CRH disabled by default and has to be purposely enabled for
steering intent based flow then I don’t think you need an infrastructure
ACL on each of the nodes along the steered path.

Kind regards


On Sat, May 16, 2020 at 3:31 PM Nick Hilliard <> wrote:

> John Scudder wrote on 16/05/2020 20:18:
> > network. For this reason, I think the “complemented per-node
> > protection” is of little value. It may be of negative value if it
> > leads to a sense of complacency on the part of the victim.
> separate to this from a security point of view, there should be a knob
> to enable CRH processing, defaulting to off.  Suggested text:
> > Routers which process CRHs MUST have a configuration knob to
> > control whether CRH processing is enabled or not.  The default value
> > of this knob MUST be to disable CRH processing.
> Nick
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

Gyan  Mishra

Network Engineering & Technology


Silver Spring, MD 20904

Phone: 301 502-1347