RE: Does RFC9000 allow endpoints to reuse CIDs when NAT rebinding happens?
"Lubashev, Igor" <ilubashe@akamai.com> Wed, 27 September 2023 10:28 UTC
Return-Path: <ilubashe@akamai.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D665C151092 for <quic@ietfa.amsl.com>; Wed, 27 Sep 2023 03:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
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 Ogz_izyRekhF for <quic@ietfa.amsl.com>; Wed, 27 Sep 2023 03:28:30 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DDEC151540 for <quic@ietf.org>; Wed, 27 Sep 2023 03:28:24 -0700 (PDT)
Received: from pps.filterd (m0050098.ppops.net [127.0.0.1]) by m0050098.ppops.net-00190b01. (8.17.1.22/8.17.1.22) with ESMTP id 38RARvO3030270; Wed, 27 Sep 2023 11:27:57 +0100
Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3taygjrqxp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Sep 2023 11:27:57 +0100 (BST)
Received: from pps.reinject (m0050098.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.22/8.17.1.22) with ESMTP id 38RARs0u030038; Wed, 27 Sep 2023 11:27:55 +0100
Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3taygry0dr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Sep 2023 19:39:18 +0100 (BST)
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.17.1.19/8.17.1.19) with ESMTP id 38QHIwSF020164; Tue, 26 Sep 2023 14:39:17 -0400
Received: from email.msg.corp.akamai.com ([172.27.50.204]) by prod-mail-ppoint3.akamai.com (PPS) with ESMTPS id 3tacwxrudf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Sep 2023 14:39:17 -0400
Received: from ustx2ex-dag4mb3.msg.corp.akamai.com (172.27.50.202) by ustx2ex-dag4mb5.msg.corp.akamai.com (172.27.50.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.25; Tue, 26 Sep 2023 11:39:16 -0700
Received: from ustx2ex-dag4mb3.msg.corp.akamai.com ([172.27.50.202]) by ustx2ex-dag4mb3.msg.corp.akamai.com ([172.27.50.202]) with mapi id 15.02.1258.025; Tue, 26 Sep 2023 11:39:16 -0700
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Christian Huitema <huitema@huitema.net>, Eric Kinnear <ekinnear=40apple.com@dmarc.ietf.org>, Willy Tarreau <w@1wt.eu>
CC: "???(Personal)" <fryang@outlook.com>, Ian Swett <ianswett@google.com>, "quic@ietf.org" <quic@ietf.org>
Thread-Topic: Does RFC9000 allow endpoints to reuse CIDs when NAT rebinding happens?
Thread-Index: AQHZ76UcqrysSSRKzUeKuwHYaLD8xbAsVR4AgACNUQCAAAk2AIAA50GAgAASIQD//4uq4A==
Date: Tue, 26 Sep 2023 18:39:16 +0000
Message-ID: <43619c425df8487d95ddf957437f604d@akamai.com>
References: <OS3P286MB05333638A3EB858FAB4B8B4FD9FCA@OS3P286MB0533.JPNP286.PROD.OUTLOOK.COM> <CAKcm_gMfYsWxFLjXt9wBnVma03BQLMgOkF_Kdp09paEhTy4Vdw@mail.gmail.com> <OS3P286MB053391507A417C28F7E31639D9C3A@OS3P286MB0533.JPNP286.PROD.OUTLOOK.COM> <20230926033738.GC22132@1wt.eu> <4B0156AC-FF34-46D2-8EF3-EDB2972B0A41@apple.com> <da075be6-1c02-8730-2505-d8c7c3e726f4@huitema.net>
In-Reply-To: <da075be6-1c02-8730-2505-d8c7c3e726f4@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.27.164.43]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-09-26_13,2023-09-26_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=81 spamscore=81 phishscore=0 malwarescore=0 mlxscore=81 bulkscore=0 mlxlogscore=-63 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2309260162
X-Proofpoint-GUID: 47Sgkqd18ih-EYn1SwrWHj9McVgA9hNK
X-Proofpoint-ORIG-GUID: 47Sgkqd18ih-EYn1SwrWHj9McVgA9hNK
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-09-26_13,2023-09-26_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=spam policy=default score=56 priorityscore=1501 adultscore=0 spamscore=56 mlxlogscore=-9 malwarescore=0 mlxscore=56 suspectscore=0 phishscore=0 bulkscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2309180000 definitions=main-2309260161
subject: RE: Does RFC9000 allow endpoints to reuse CIDs when NAT rebinding happens?
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rb_1YtIDoAXWofVBWf5_bEN9Ytk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Sep 2023 10:28:35 -0000
> On Tuesday, September 26, att 2023 2:30 PM Christian Huitema wtote:
>
> There was quite a bit of discussion about the usage of CID in the
> context of QUIC Multipath, which uses CID to identify paths. The basic
> rules for managing incoming packets are:
>
> 1) Packet arrives with a new CID:
> - if same four tuple as an existing path, treat as CID renewal
> - if different four tuple, process as new path
> 2) Packet arrives with already used CID:
> - if same four tuple as an existing path, process on that path.
> - if different four tuple, process NAT rebinding as new path
>
> If client would keeps sending packets with the same CID and different IP
> addresses, it will cause a lot of "NAT rebinding", causing a lot of
> overhead on the server. Servers may well treat that as an attack and
> drop the connection.
Does it mean that an on-path observer that is able to race packets to the server is able to force any connection to close by racing copies of the packets with random source addresses? I believe in similar cases, we've decided that servers should not close connections due to unexpected source addresses, but they can drop packets with unexpected source addresses.
Best,
- Igor
> -- Christian Huitema
>
> On 9/26/2023 10:25 AM, Eric Kinnear wrote:
> > That said, if the server notices that the client is coming from a different
> address and using the same destination CID, which would not be allowed if
> the client knew that it was using a different network path, it’s nice if it does
> change CID. This provides a signal to a client that a NAT rebinding may have
> occurred, and the client might choose to take action on that in some way.
> >
> > Since you’re allowed to change CID at any time on the same path, there’s no
> need for additional text that explicitly allows this, but the most straightforward
> implementation that just says “yup, you’re on a different remote address, I’ll
> use a different CID” and doesn’t check whether the remote peer rotated CID is
> likely the best answer.
> >
> > Thanks,
> > Eric
> >
> >
> >> On Sep 25, 2023, at 8:37 PM, Willy Tarreau <w@1wt.eu> wrote:
> >>
> >> On Tue, Sep 26, 2023 at 11:04:40AM +0800, "???(Personal)" wrote:
> >>> Is it allowed for a server to reuse the current CID when it notices a NAT
> >>> rebinding? I wonder if the text ("...., in which case it MAY continue to use
> >>> the current connection ID with the new remote address while still sending
> >>> from the same local address.") indicates that the server can reuse the
> >>> current CID?
> >>
> >> If the spec says "MAY", then yes, it's allowed to.
> >>
> >> Willy
> >>
> >
- Does RFC9000 allow endpoints to reuse CIDs when N… "杨馥榕(Personal)"
- Re: Does RFC9000 allow endpoints to reuse CIDs wh… Ian Swett
- Re: Does RFC9000 allow endpoints to reuse CIDs wh… "杨馥榕(Personal)"
- Re: Does RFC9000 allow endpoints to reuse CIDs wh… Willy Tarreau
- Re: Does RFC9000 allow endpoints to reuse CIDs wh… Eric Kinnear
- Re: Does RFC9000 allow endpoints to reuse CIDs wh… Christian Huitema
- Re: Does RFC9000 allow endpoints to reuse CIDs wh… "杨馥榕(Personal)"
- RE: Does RFC9000 allow endpoints to reuse CIDs wh… Lubashev, Igor
- Re: Does RFC9000 allow endpoints to reuse CIDs wh… Christian Huitema