[v6ops] Re: Traffic control protocols (PCP and UPnP IGD)

Daryll Swer <contact@daryllswer.com> Fri, 26 July 2024 16:25 UTC

Return-Path: <contact@daryllswer.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8398EC14F5E2 for <v6ops@ietfa.amsl.com>; Fri, 26 Jul 2024 09:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=daryllswer.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 akI0gkwMyONJ for <v6ops@ietfa.amsl.com>; Fri, 26 Jul 2024 09:25:39 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 15AAFC14F702 for <v6ops@ietf.org>; Fri, 26 Jul 2024 09:25:05 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-70d18112b60so834399b3a.1 for <v6ops@ietf.org>; Fri, 26 Jul 2024 09:25:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daryllswer.com; s=google; t=1722011104; x=1722615904; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=L0Lx71O/KYc4A7MArDxUgx+wBfzi1JLlbIQvNNbFFQI=; b=WKUGAM/7M4NTEqUOb9flk0laW2FNhL45kGiCl3s7TFgfBRzutZDk6A7u03SODC0rkH Ypt8fZMYLfFaGQtM7aZNWuaw62XFSWQR6MOuDX40oDyncRBM5w5gY533S6UwdzAkwpDU sDdMR74IoAas2E8MYPqBFeyDwtZVVcvGwfjULUm1zMflhvpAu9ZQ+zaNobrqgFaJo2zK PvhOvRr5G0WB7six6UxOTEoY/gq0ptAZNNbO6dn6BN0mZSKBww2UlnPzfKBdVS4BHOYm KjJvp1YyEEa1uPmidvpyQckpOZSmV75dplYN4lLSXpb/CocTYcsVcGEZZ4lB2mDxv+eo fgeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722011104; x=1722615904; h=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=L0Lx71O/KYc4A7MArDxUgx+wBfzi1JLlbIQvNNbFFQI=; b=SfKxHu5u8KgqWSsRLjmofXIJN3xB5SRroezZw03AWQEh1x43oI2DTEYrxaUqLmvyYa xRs7sz/1dcUqGV91m+9Ngoh31tSZzx7w1nBzJoGhgvMtS3cJLJGGoEx+0GyV+GWYfWk4 uZICMYAs9B/WhkBlXHbeoyNX18jOhm1BR3/Wpcu6IF+UbrIEwOR8IChtshUCsWBvG8RY IWB6XVt/Ojo6cDa/94vtAkPDjkdZDS/QzhELd+9ZZp996ySmHOyVH0bOtTxvbqnCEJVI +uMHy6Pcgs9UBrw7F1PyegVL9NeM+jlqAVO8kav5HWzTr6DSGNLCI8Co0r6z1W+zCgkU IDyQ==
X-Forwarded-Encrypted: i=1; AJvYcCU4yuPsMzYw4Hq9xGxsQwPpJHKkPsRN4lj+N9Rr1TYfOQnkRbhBJhWtxHl3ySb32tG9kPre7kD+wmp3/w6tXQ==
X-Gm-Message-State: AOJu0Yy1Vjw7eU2cwaYoGSkuLaR9A+h4Af4IeHYiMy0+XVpqB3vAwfE+ dYMx/96rmWlkx08m9fdPVeePJzzh7pzTOGj5D1/30W3pVtnDHfTN/V/H1L02AydL551Tz6PYkmf bxLE=
X-Google-Smtp-Source: AGHT+IGor2KvpwIvtfkkucRBVWgu/670HUeezWmX7PODcQdJ7ay9bmsNB/TXgpHkQj9IfDRYigNXLQ==
X-Received: by 2002:a05:6a21:819d:b0:1c4:6a84:275 with SMTP id adf61e73a8af0-1c4a11695cbmr97306637.25.1722011103939; Fri, 26 Jul 2024 09:25:03 -0700 (PDT)
Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com. [209.85.210.174]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70ead8af7f3sm2871340b3a.204.2024.07.26.09.25.03 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jul 2024 09:25:03 -0700 (PDT)
Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-70d316f0060so764151b3a.1 for <v6ops@ietf.org>; Fri, 26 Jul 2024 09:25:03 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCV2IKHr+z98NfpDjAHueLa2+J9uhyDrbbM4/hBinMU6rFja0Dpzuh2ko11HwDjNIdE+D08pSARLiIMWEfoCtg==
X-Received: by 2002:a17:90b:1a86:b0:2c8:2236:e2c3 with SMTP id 98e67ed59e1d1-2cf7cf7fdb3mr131167a91.17.1722011103103; Fri, 26 Jul 2024 09:25:03 -0700 (PDT)
MIME-Version: 1.0
References: <73141FE4-DA01-4B9F-88F3-EE68FBD2A0CB@apple.com> <TYVPR01MB10750A78CA08E3D2EB6CCEB37D2AB2@TYVPR01MB10750.jpnprd01.prod.outlook.com> <CAPt1N1mhViWNxWw1XKQZyMwFWWdUQ3doh-u6pezYoFhpA8b8Qg@mail.gmail.com> <TYVPR01MB10750FB6A5FA4EB034F9B5B8AD2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com> <CAPt1N1kA9KETiVsK744m5AaXvCnspsN8zkdqRR1OcMo-ftkNfA@mail.gmail.com> <TYVPR01MB10750B17554096318B8C49BACD2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com> <BF9C2E26-E49C-4764-9CEA-8E7738801819@employees.org> <TYVPR01MB1075001C9D2EC290201284F66D2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com>
In-Reply-To: <TYVPR01MB1075001C9D2EC290201284F66D2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com>
From: Daryll Swer <contact@daryllswer.com>
Date: Fri, 26 Jul 2024 21:54:26 +0530
X-Gmail-Original-Message-ID: <CACyFTPH7XJ=fV9jW0h59UH-TDL7OGWw_ifehPvbFzzoH2Ln0Ng@mail.gmail.com>
Message-ID: <CACyFTPH7XJ=fV9jW0h59UH-TDL7OGWw_ifehPvbFzzoH2Ln0Ng@mail.gmail.com>
To: "Kawashima Masanobu(川島 正伸)" <kawashimam=40nec.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001999e7061e28f4ef"
Message-ID-Hash: 7K2WBD7LPMOHFZ2WTFOICWUP5IJGOEC4
X-Message-ID-Hash: 7K2WBD7LPMOHFZ2WTFOICWUP5IJGOEC4
X-MailFrom: contact@daryllswer.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Ole Troan <otroan=40employees.org@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VEaPzuNif8mmwpNM6J-peJbOuhY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

For security, this is how I'd like my IPv6 router to behave:

Default factory firewall rules are stateful:
Accept established, related, untracked (we NoTrack LAN BUM traffic for
example for performance reasons)
Accept ICMPv6
Accept UDP Traceroute ports
Drop the rest, from WAN.

PCP (or UPnP?) comes in:
My MacBook has an app that utilises PCP, makes a request to the router, to
open port 9000. Router dynamically injects a firewall rule below the
established,related,untracked whereby it has dst-port=9000, dst-IP=the IPv6
SLAAC temp/secured address of the MacBook, protocol TCP+UDP (or potentially
we should support opening ports for SCTP, DCCP, UDP-Lite), action=accept.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/0473389dbb82260cca6d690bab14455e4786efbc?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=2526b133696a57bf>


On Fri, 26 Jul 2024 at 21:39, Kawashima Masanobu(川島 正伸) <kawashimam=
40nec.com@dmarc.ietf.org> wrote:

>
> Hi Ole,
>
> I agree with you.
>
> If we consider that the IPv6 CE router acts as a firewall, we should
> consider
> not only RFC 6887 but also RFC 7652.
> When CE router acts as a firewall, security consideration is also
> important.
>
> Just FYI, UPnP IGDv2 also has security mechanism that is called
> 'DeviceProtection'.
>
> There is a choice of firewall control protocol, NAT-PMP, UPnP, PCP, etc.
> IMHO, CSA Matter is the appropriate protocol for the future.
> If we use Matter, Node to Node messages are secured, authenticated,
> and provide replay protection, etc.
> However, the problem is that we need to join CSA membership if we want to
> implement Matter spec.
>
> Regards,
> Masanobu
>
> ========================
>  NEC Platforms, Ltd.
>  KAWASHIMA Masanobu
>  kawashimam@nec.com
>  https://www.necplatforms.co.jp/en/
> ========================
>
>
>
> > -----Original Message-----
> > From: Ole Troan <otroan=40employees.org@dmarc.ietf.org>
> > Sent: Friday, July 26, 2024 7:36 PM
> > To: "Kawashima Masanobu(川島 正伸)"
> > <kawashimam=40nec.com@dmarc.ietf.org>
> > Cc: v6ops@ietf.org
> > Subject: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
> >
> > If there is a desire that the IPv6 CE router acts as a firewall, just
> requiring PCP
> > RFC6887 may not be enough.
> > At least RFC6887 opens up quite a few security trust issues. At least if
> we have to
> > deal with the threat that an inside client is not under the control of
> the party
> > interested in security.
> > Then something like RFC7652 would be required.
> > (Which leads one to wonder if it isn’t simpler to configure this through
> a UI on the
> > IPv6 CE router instead of a through a protocol…)
> >
> > Ole
> >
> > > On 26 Jul 2024, at 03:34, Kawashima Masanobu(川島 正伸)
> > <kawashimam=40nec.com@dmarc.ietf.org> wrote:
> > >
> > >  It’s clear now. Thank you.  Regards, Masanobu   From: Ted Lemon
> > <mellon@fugue.com>
> > > Sent: Friday, July 26, 2024 10:12 AM
> > > To: Kawashima Masanobu(川島 正伸) <kawashimam@nec.com>
> > > Cc: v6ops@ietf.org
> > > Subject: Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
> > > I think it should be fine to do that, yes.
> > >  Op do 25 jul 2024 om 17:15 schreef Kawashima Masanobu(川島 正伸)
> > > <kawashimam@nec.com>
> > >
> > > Ted,
> > >
> > > Thank you for your reply.  It’s almost clear now. :-)
> > >
> > > How about RFC 6970((UPnP IGD-PCP IWF)?
> > > It is ‘Standard Track’. Should we mention something? Regards, Masanobu
> > ========================  NEC Platforms, Ltd.
> > KAWASHIMA Masanobu               kawashimam@nec.com
> > https://www.necplatforms.co.jp/en/    ========================
> > >    From: Ted Lemon <mellon@fugue.com>
> > > Sent: Friday, July 26, 2024 8:59 AM
> > > To: Kawashima Masanobu(川島 正伸) <kawashimam@nec.com>
> > > Cc: v6ops@ietf.org
> > > Subject: Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
> > > As a router vendor, you have more than one set of requirements you
> need to
> > satisfy. Nobody's saying "don't do uPNP." We're saying "do PCP." We're
> saying "the
> > IETF is not asking you to do uPNP," not "the IETF is telling you not to
> do uPNP."
> > >  On Thu, Jul 25, 2024 at 4:50 PM Kawashima Masanobu(川島 正伸)
> > <kawashimam=40nec.com@dmarc.ietf.org> wrote:
> > >
> > > Hi all,
> > >
> > > > In today’s v6ops meeting there was mention of UPnP. Having a way for
> > > > client devices to signal to network infrastructure what traffic they
> > > > want to receive is a good idea. However, doing that using the UPnP
> > > > IGD protocol would be a disastrously bad idea.
> > >
> > > I agree with having a way for client devices to signal to network
> infrastructure.
> > > However, I'm still not sure UPnP IGD is bad idea.
> > >
> > > As you may know, Broadband Forum has released TR-124 issue 9 on July
> 2024.
> > > https://rg-device-requirements.broadband-forum.org/index.htm
> > >
> > > Related parts are as follows.
> > >
> > > [WAN.PCP.1]
> > >  The RG MUST support Port Control Protocol (PCP) Client as specified
> > > in RFC 6887
> > >
> > > [WAN.PCP.7]
> > >  The RG MUST embed an interworking function to ensure interworking
> > > between the UPnP IGD (Internet Gateway Device) used by CPE LAN devices
> > > in the LAN and PCP as defined in RFC 6970
> > >
> > > [MGMT.UPnP.IGD.ACRF.1]
> > > The RG MUST support UPnP Internet Gateway Device:2 root device. This
> > > specification is available for download at
> > > http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
> > >
> > > As one of CE router vendor, what should I do?
> > > Should I ignore TR-124 because UPnP will be deprecated soon?
> > > or should we mention UPnP in some form in RFC 7084bis?
> > >
> > > As I commented on v6ops WG meeting a while ago, UPnP IGDv2(for IPv6) is
> > increasing in Japan.
> > > Because our CE router support it, and some gaming title support UPnP
> controll
> > point as well.
> > > Syncthing(file sharing app) has also supported UPnP IGDv2.
> > > Addition to this, we also recognized UPnP IGDv2 implementation
> increasing in
> > some countries.
> > >
> > > Please let me know your opinion.
> > >
> > > Regards,
> > > Masanobu
> > >
> > > ========================
> > >  NEC Platforms, Ltd.
> > >  KAWASHIMA Masanobu
> > >  kawashimam@nec.com
> > >  https://www.necplatforms.co.jp/en/
> > > ========================
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Stuart Cheshire <cheshire=40apple.com@dmarc.ietf.org>
> > > > Sent: Friday, July 26, 2024 5:33 AM
> > > > To: v6ops@ietf.org
> > > > Subject: [v6ops] Traffic control protocols (PCP and UPnP IGD)
> > > >
> > > > In today’s v6ops meeting there was mention of UPnP. Having a way for
> > > > client devices to signal to network infrastructure what traffic they
> > > > want to receive is a good idea. However, doing that using the UPnP
> > > > IGD protocol would be a disastrously bad idea.
> > > >
> > > > For a list of the many flaws of UPnP IGD see RFC 6886:
> > > >
> > > > <https://datatracker.ietf.org/doc/html/rfc6886#section-9>
> > > >
> > > > This is why the IETF needed to create a robust reliable protocol for
> > > > doing this, Port Control Protocol:
> > > >
> > > > <https://datatracker.ietf.org/doc/html/rfc6887>
> > > >
> > > > If an IETF document is going to recommend or require a way of doing
> > > > this, it should be using RFC 6887, both because that is an IETF
> > > > Standards Track protocol, and (more importantly) because of the
> technical
> > merits of that protocol.
> > > >
> > > > If the UPnP organization still existed then maybe they could try to
> > > > design a replacement for IGD that works reliably, but what would be
> > > > the point when the IETF has already done that?
> > > >
> > > > Stuart Cheshire
> > > >
> > > > _______________________________________________
> > > > v6ops mailing list -- v6ops@ietf.org To unsubscribe send an email to
> > > > v6ops-leave@ietf.org
> > > _______________________________________________
> > > v6ops mailing list -- v6ops@ietf.org
> > > To unsubscribe send an email to v6ops-leave@ietf.org
> > > _______________________________________________
> > > v6ops mailing list -- v6ops@ietf.org
> > > To unsubscribe send an email to v6ops-leave@ietf.org
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list -- v6ops@ietf.org
> > To unsubscribe send an email to v6ops-leave@ietf.org
> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org
>