[IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert

Mark Smith <markzzzsmith@gmail.com> Tue, 18 June 2024 04:25 UTC

Return-Path: <markzzzsmith@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 1CC89C19330B; Mon, 17 Jun 2024 21:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.304
X-Spam-Level:
X-Spam-Status: No, score=-6.304 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.3, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=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 8cpJglCa6RJv; Mon, 17 Jun 2024 21:25:31 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 E9F2DC1930B6; Mon, 17 Jun 2024 21:25:25 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2eaa89464a3so56962651fa.3; Mon, 17 Jun 2024 21:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718684723; x=1719289523; 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=5j0V72hbdkTq/yao1Theyb3slzUOOCKNVsSyOrXUPvM=; b=Kc/zkivZXrPChYCDDEkmeKbSZ4h93Yj11fSmhmBVt4viiAgUwPTPiyKyR4NIuRWgi0 +ZjvPHJHOxbrDcjCfvQHvUx07Uglfr7/syX/3E+1weQ1p82RFogEUSvDTfEguhxGETiD PrIURY+edersZayASTwR74bZmBcOIpCd4nkpUDtsZEgOpMdENtFHPvnTrmc6rG43JSrD kZeIiLCSfTKYO3/dkJ1TTvjFOUgz1oVer8FunEZJaTSExoDepXoCujhIlaUs1NghSbRu JdRBUj0z9sMB7ke7dd0LZjzYtGVbUGkZ2dy1p70adI/AczGW/uZjwGIPZglAMYPC3pAk tuOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718684723; x=1719289523; 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=5j0V72hbdkTq/yao1Theyb3slzUOOCKNVsSyOrXUPvM=; b=oHfW5zH+0GqekvJcYYhZq5GDhMsAoR2KaVyC3gN7MzuPK2FsfUjZt0P2SZBmUm1Zwc T1Uz0IfrOc14fagQAVI3BhBUWU+Yp5oT4vlCl80nsR1jw+rPLNv/FTC8gB4OYP+gCuhX IrQKgl9Hwi+j/ulED/+UAK2lWbP2Oe7Yag7iRLbL+KFdVe7ov/pOWUr+9QGJIBJzJ4TZ XvdoE719mN343tgOXXYBUJJZ38ajPo0tvFS7w+DnXKcfqSDWGdsxREcK4cmmgd+MmFcz qtb1iUlKJLFfPt2jso1MvvKFErfjaRTGOXXvDloop42pvFATyJO7jtGqx0D3Mv1QhW3v Ctgg==
X-Forwarded-Encrypted: i=1; AJvYcCWzXmJJJsSHG6RNHGl3WfCyFKTGGIL6y9ERBfdyGqhhcHMvtJNs6zo2RBgiQYFvB6zJ33Z7A07tqDUthxmUYG4+cxA9e1WViOqOM5N45BukoMwE7fPG0b/QWhHo0ydpxxZphMCsTerQCI+g/sTHoUuy4szbZBA7MmP0dvJFUyxJ4WRMiGFfnw==
X-Gm-Message-State: AOJu0YwH60sSxspk23MYKn+c1oMIzq4+ojRgKejpfp445M83ZHmSry+K YRTokkSPciGd4bYZ/uHCLjbGdHptOs4TKHYF7yhrBncDqMT9d0CkqAd11N+/edrM+bNQQ8154st VVEl1C/bPNh4AMOmoyZL1njlpRjs=
X-Google-Smtp-Source: AGHT+IEdHHAcxEtL/ifunKMraprPGnE05GDGAMWz63rdQJmxlc8a3zzJPMHQtnScKS+RAp7PP6Mw8e2s+PU5EC36X7Y=
X-Received: by 2002:a2e:b052:0:b0:2ec:174b:75c1 with SMTP id 38308e7fff4ca-2ec174b77e7mr64137271fa.38.1718684723230; Mon, 17 Jun 2024 21:25:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BAQDP-+bOZOphnxwJopikYxoW=Bvo_1S7czfXmq=2UT2zg@mail.gmail.com> <1C4203A2-9298-414F-A0A2-00BB87A7A2EA@gmail.com> <BL0PR05MB531671B165FE15E2CB5387E0AEC02@BL0PR05MB5316.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB531671B165FE15E2CB5387E0AEC02@BL0PR05MB5316.namprd05.prod.outlook.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 18 Jun 2024 14:24:56 +1000
Message-ID: <CAO42Z2xbhm28wiJe4tG9fF4b4mAkWp+NCRi-DvXSFjgxdGcRYQ@mail.gmail.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: HLTZ4MNAH4UKNZUFGBOHX5ZLUP7TAYO4
X-Message-ID-Hash: HLTZ4MNAH4UKNZUFGBOHX5ZLUP7TAYO4
X-MailFrom: markzzzsmith@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, "draft-bonica-6man-deprecate-router-alert@ietf.org" <draft-bonica-6man-deprecate-router-alert@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Mdl9wIVN2S1YOePNHRMn1107a3c>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>

Hi,

On Thu, 13 Jun 2024 at 01:11, Ron Bonica
<rbonica=40juniper.net@dmarc.ietf.org> wrote:
>
> Bob,
>
> Thanks for posing the most interesting architectural question!
>
> The HBH Processing draft positions the HBH Options Extension Header as a clean mechanism for signaling through the IPv6 forwarding plane without touching the control plane or exposing it to additional vulnerabilities. The Router Alert option compromises that architectural goal by allowing packets to weave in and out, between the forwarding and control planes.
>
> If a new protocol needs to weave in and out between the control and forwarding planes, it can do so by addressing its packets to the node whose control plane it needs to touch. This strategy has been demonstrated by RSVP-TE. Its benefits are:
>
> It has been deployed on the global internet (i.e., across domains)
> It can be ACL'd by simply examining the destination address and next (non-IPv6) header. There is no need for the ACL mechanism to parse the HBH Options header
>
>

I think another advantage of encoding the service, function or
protocol into packets' DAs is that it would also make implementing
layer 2 packet filtering of those packets easier, since the DA is in
always in a fixed location in the frame, and can't be hidden behind a
chain of EHs, a vulnerability that RA Guard has to deal with c.f. RFC
7113.

For example, if RAs were multicast to a well-known RA specific
multicast address such ("all RA receivers"), rather than the all-nodes
multicast address, then RA Guard would be simpler to implement by
matching on the packet's IPv6 DA and nothing else.

For unicast RAs back to a individual node, a well-known RA specific
IPv6 anycast address could be defined that all RA receivers listen on
(although don't reply to NSes for), and then the router link-layer
unicast's the RA to the individual receiving node, with the link-layer
address for this anycast response having being learned using the
corresponding RS's source IPv6 LLA address. The layer 2 device could
then filter on this well known RA specific anycast DA.

Regards,
Mark.



>                                                                                                           Ron
>
>
> Juniper Business Use Only
>
> ________________________________
> From: Bob Hinden <bob.hinden@gmail.com>
> Sent: Tuesday, June 11, 2024 11:55 AM
> To: IPv6 List <ipv6@ietf.org>
> Cc: Bob Hinden <bob.hinden@gmail.com>; 6man Chairs <6man-chairs@ietf.org>; draft-bonica-6man-deprecate-router-alert@ietf.org <draft-bonica-6man-deprecate-router-alert@ietf.org>
> Subject: Re: Adoption call for draft-bonica-6man-deprecate-router-alert
>
> [External Email. Be cautious of content]
>
>
> Hi,
>
> With no hats on.
>
> My thoughts on deprecating Router Alert is what was written in Section 5.2.1 of the HBH Processing draft (now in RFC Editor queue):
>
>       DISCUSSION
>
>       The function of a Router Alert Option can result in the processing
>       that this specification is proposing to eliminate, that is, to
>       instruct a router to process the packet in the control plane.
>       This results in the concerns discussed in section 4.  One approach
>       would be to deprecate this, because current usage beyond the local
>       network appears to be limited, and packets containing Hop-by-Hop
>       options are frequently dropped.  Deprecation would allow current
>       implementations to continue and its use could be phased out over
>       time.
>
>       The Router Alert Option could have a potential for use with new
>       functions that have to be processed in the control plane.  Keeping
>       this as the single exception for processing in the control plane
>       with the following restrictions is a reasonable compromise to
>       allow future flexibility.  These restrictions are compatible with
>       Section 5 of [RFC6398].
>
> My question is do we want to disable the possibility of any new functions that need Router Alert in the future.
>
> Bob
>
>
>
> > On Jun 10, 2024, at 4:23 PM, Jen Linkova <furry13@gmail.com> wrote:
> >
> > This email starts 6MAN adoption call for the following document:
> >
> > Title : Deprecation Of The IPv6 Router Alert Option
> > Authors : Ron Bonica
> > Date : 2024-02-19
> >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-deprecate-router-alert/__;!!NEt6yMaO-gk!CmCegd8V41HWGLJly2mqXbYx0AwGFa6dv4knJdVkLfmlQRCdNqHTUVtGQ5yfA2rqkdAZnI3aY_VTaJ06BDI$
> >
> > Substantive comments, statements of support for adopting this
> > document or objections to the adoption should be sent to the mailing
> > list.  Editorial suggestions can be sent to the authors.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:
> --------------------------------------------------------------------