[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 >
- [v6ops] Traffic control protocols (PCP and UPnP I… Stuart Cheshire
- [v6ops] Re: Traffic control protocols (PCP and UP… jordi.palet@consulintel.es
- [v6ops] Re: Traffic control protocols (PCP and UP… Kawashima Masanobu(川島 正伸)
- [v6ops] Re: Traffic control protocols (PCP and UP… Ted Lemon
- [v6ops] Re: Traffic control protocols (PCP and UP… Kawashima Masanobu(川島 正伸)
- [v6ops] Re: Traffic control protocols (PCP and UP… Ted Lemon
- [v6ops] Re: Traffic control protocols (PCP and UP… Kawashima Masanobu(川島 正伸)
- [v6ops] Re: Traffic control protocols (PCP and UP… Ole Troan
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Ted Lemon
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Ted Lemon
- [v6ops] Re: Traffic control protocols (PCP and UP… mohamed.boucadair
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Kawashima Masanobu(川島 正伸)
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Kawashima Masanobu(川島 正伸)
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Brian Candler
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Kawashima Masanobu(川島 正伸)
- [v6ops] Re: Traffic control protocols (PCP and UP… Kawashima Masanobu(川島 正伸)
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… jordi.palet@consulintel.es
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Kawashima Masanobu(川島 正伸)
- [v6ops] Re: Traffic control protocols (PCP and UP… Brian Candler
- [v6ops] Re: Traffic control protocols (PCP and UP… Gert Doering
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Ted Lemon
- [v6ops] Re: Traffic control protocols (PCP and UP… Gert Doering
- [v6ops] Re: Traffic control protocols (PCP and UP… Ted Lemon
- [v6ops] Re: Traffic control protocols (PCP and UP… Gert Doering
- [v6ops] Re: Traffic control protocols (PCP and UP… Ted Lemon
- [v6ops] Re: Traffic control protocols (PCP and UP… Gert Doering
- [v6ops] Re: Traffic control protocols (PCP and UP… Ted Lemon
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Dan Wing
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer
- [v6ops] Re: Traffic control protocols (PCP and UP… Dan Wing
- [v6ops] Re: Traffic control protocols (PCP and UP… Daryll Swer