Re: [radext] Fwd: New Version Notification for draft-dekok-radext-reverse-coa-01.txt

Alexander Clouter <alex+ietf@coremem.com> Tue, 08 August 2023 23:22 UTC

Return-Path: <alex+ietf@coremem.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36918C15C52D for <radext@ietfa.amsl.com>; Tue, 8 Aug 2023 16:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=coremem.com header.b="QExlOuSV"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="qofXD6Xp"
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 sU-72D5HtPgS for <radext@ietfa.amsl.com>; Tue, 8 Aug 2023 16:22:12 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 C9A39C151077 for <radext@ietf.org>; Tue, 8 Aug 2023 16:22:12 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 750FA3200684 for <radext@ietf.org>; Tue, 8 Aug 2023 19:22:10 -0400 (EDT)
Received: from imap46 ([10.202.2.96]) by compute5.internal (MEProxy); Tue, 08 Aug 2023 19:22:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1691536929; x=1691623329; bh=ct nVGrarsfyVxf1HlCH4lcCH9y8l0YjOuiNcoj1K/Rc=; b=QExlOuSVtPxxt3wPC7 csLuP/5VUCQOku8fZfGzudZ875VIUPCcK+ajmW3kKpQJc9OhPMNIhPPcre0TommB PY4iHGTKz5kMXQ+WIXrPZiomtWIZvqx+N4uQC+c4qABzdNX8z38pa97bOJxtMQnA +48gooSHqNGdeGpTZA0dsTcwfMOYb6iqWWbahxPmfSKK3+4Bv965DrNtB/elnCZd u7qdqn5ihfHPhkGiygZfm/W7bYUXfpEbK567vgOE+8rDSWHMEZMeaRP9FmtO6sXq hfsxpLr0VzZIDlb2r09dSbjhBUJrbXRf9diow5xdPZz9cDpi/HlvBQ2G1xxZHyoZ 28kA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1691536929; x=1691623329; bh=ctnVGrarsfyVx f1HlCH4lcCH9y8l0YjOuiNcoj1K/Rc=; b=qofXD6XpZrHToVlxeXXg9ZkW3ciGB +kl6tPRb8yVCN4/Qti946NoMCp9DWmwzG72NZjYPpLzkvg1CbhzgMYRN9fMVBhQU SDFFe7biyxKInoS6hlyF9iORCYk05uTNQEAiw7dgjhCwEABgm0lwBR9HcjmJP7Gv WJzUIMI8pMKh0LBMqpJInf1LGKxIDQrK3rJ54bQ6vrpPzT+q5LvFu4oxIRkpCSyY iU5Hmhu7NqL0up2qVNZRPHt8r1I9yV4lzPsJ+QG3+pwDMcwpPpYgeKSozmlYiQUS s30G4zCAZWvoDTS7uvLKm7us4IGd2V6qXwndqn/no7/A+6jkAq4jZOsnQ==
X-ME-Sender: <xms:Ic7SZIza_rd3gn8D_SPZXWf2BvbeMW2n-bMNLJiPXD0-RGdPN4ZzfQ> <xme:Ic7SZMTx4ng-PJPqIMZgZJjiDpyF0k8EVhDzpWAAKrARu9AhLbYAu4I6X-bUkYY77 MjIUNd_mPo8mut7eQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleefgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigrnhguvghrucevlhhouhhtvghrfdcuoegrlhgv gidoihgvthhfsegtohhrvghmvghmrdgtohhmqeenucggtffrrghtthgvrhhnpedutddvhe dvgfdvieejheffgfelgeduhfetvddtuddukeffjeejiefhledukeetudenucffohhmrghi nhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprghlvgigodhivghtfhestghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:Ic7SZKVg5y00GNAWyygWocN3hOyTEhaBo2m5qSiHYsiJ0mv_uw4hoQ> <xmx:Ic7SZGjQV9_AkuLPczbr82_WLEwk4VxIINv_Ji0f2TLelQ4Q057nNA> <xmx:Ic7SZKDwxInPaX989M64An_XZoXx374HLF144YflfG5nftcIv92JaA> <xmx:Ic7SZNOKIxjCIIY95nzbzIA0tzbWwOCxfFs9A2tjBid4BdIUPD3tww>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC3422A20085; Tue, 8 Aug 2023 19:22:09 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440
Mime-Version: 1.0
Message-Id: <2f0f3db9-00b2-4657-9f55-a4e88da38c24@app.fastmail.com>
In-Reply-To: <9C8D6E14-3CCA-4651-BD2E-39A1A6077A37@deployingradius.com>
References: <169049719437.3324.16812994471629733778@ietfa.amsl.com> <9C8D6E14-3CCA-4651-BD2E-39A1A6077A37@deployingradius.com>
Date: Wed, 09 Aug 2023 00:21:46 +0100
From: Alexander Clouter <alex+ietf@coremem.com>
To: radext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/30kFQlEgad7oeIPWIWr3lh0RK4o>
Subject: Re: [radext] Fwd: New Version Notification for draft-dekok-radext-reverse-coa-01.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2023 23:22:17 -0000

On Thu, 27 Jul 2023, at 23:33, Alan DeKok wrote:
>   Updated with minimal changes.
> 
>> Begin forwarded message:
>> 
>> A new version of I-D, draft-dekok-radext-reverse-coa-01.txt
>> has been successfully submitted by Alan DeKok and posted to the
>> IETF repository.
>> 
>> Name: draft-dekok-radext-reverse-coa
>> Revision: 01
>> Title: Reverse CoA in RADIUS
>> Document date: 2023-07-27
>> Group: Individual Submission
>> Pages: 10
>> URL:      https://www.ietf.org/archive/id/draft-dekok-radext-reverse-coa-01.txt
>> Status:   https://datatracker.ietf.org/doc/draft-dekok-radext-reverse-coa/
>> Html:     https://www.ietf.org/archive/id/draft-dekok-radext-reverse-coa-01.html
>> Htmlized: https://datatracker.ietf.org/doc/html/draft-dekok-radext-reverse-coa
>> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-dekok-radext-reverse-coa-01

Section 4:

Any reason why the server could not just send a CoA and record if it was accepted? This could be extended to pre-emptively send CoA's for sessions that cannot exist to capture if there is a response.

An observed ACK/NAK would be indicative that reverse CoA is supported whilst no response (the client would drop the packet, right?) is "no support".

This sort of is what happens for traditional forward proxying of CoA as you do not know if the visited site supports CoA.

I would not be too surprised if a number of embedded clients just processed the CoA on whatever socket it appeared on.

Of course NASs are strange things and I yield to your experience, but I figure if it is going to barf on a reverse CoA there is a chance it would barf on the Status-Server too...right?

As a bonus, for RADIUS/UDP, if done when there was recently a packet, the CoA may still make it through the door :)

Section 5:

I think this "It is not one-to-one, or 1-N, or M-1." is easier to read as " It is not one-to-one, or 1:N, or M:1. It is many-to-many." (ratio style).

I personally read '1-N' and 'M-1' as a calculation.

Misc:

s/addressible/addressable/g
s/identies/identities/g
s/usally/usually/g
s/practial/practical/g
s/acknowlegement/acknowledgement/g
s/sufficiant/sufficient/g
s/Eduroam/eduroam/g

Cheers