From nick.lowe@lugatech.com Sun Oct 4 10:25:12 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13F61B2AE9 for ; Sun, 4 Oct 2015 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1y8Ks-KgSj4b for ; Sun, 4 Oct 2015 10:25:10 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B46D1B2AE3 for ; Sun, 4 Oct 2015 10:25:10 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so90656419wic.1 for ; Sun, 04 Oct 2015 10:25:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=mz5jaFbXaKbck33WUb/oYPl4lo+J+l7hLXFEClD56Hs=; b=jlK5AUHbLg1MIMX0jfIalbWpfzZQR6+LmQPkyPYhvWrnuvDMG8vYmDvov3ABrJKiDz OYWn7+e5xYcHhX6U6aEQYBT69kcfFIwByJ4NMUKVCC53jKL0n9LjKcTmmWz5rygt2HU7 IrmJP9qeihEKasCzyTmmDffgYOKWCObBCOBRoS1pEykXhfjNwix13r5yImqU/ZEEsX2v XJOhO39gP8nv61Lrs8bH0e7WFla1wOu6z4XnzAUwNUEz8jXO7KC3ed4AsFsn4o8IvX52 K/7otiHaxuLWfieBfIGJYew6ujEjfvEk6iBYwLggQpFIwAjZSjwltaD5uVUyUGg2RGGP 6S+A== X-Gm-Message-State: ALoCoQlKmrz9kekrbjqvnaNQhlLm9mLFM7o4CkQ7vxm/jMECmBNGmkO6urnRQJQxJJCu12QYfmab MIME-Version: 1.0 X-Received: by 10.180.182.80 with SMTP id ec16mr6884286wic.47.1443979508543; Sun, 04 Oct 2015 10:25:08 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Sun, 4 Oct 2015 10:25:08 -0700 (PDT) X-Originating-IP: [77.96.75.177] Date: Sun, 4 Oct 2015 18:25:08 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 17:30:15 -0000 Dear all, Following on from the three errata that I opened against RFC 2866, I wished to expand on what Alan wrote at http://freeradius.org/rfc/acct_status_type_subsystem.html to, hopefully, get the ball rolling on an RFC that revises things. Carl Rigney helpfully clarified that the original intent of the Acct-Session-Id and Acct-Multi-Session-Id was that they were only intended to be unique in the context of a NAS during its uptime, not across reboots and certainly without requirements to be globally unique. The two errata that I raised that pertain to these attributes should be rejected as it would be a technical change. I did not realise this when I filed them. Therefore, a new RFC would be required to see change going forward. The errata that clarifies that Accounting-On and Accounting-Off apply on a per-NAS basis and not on a per-subsystem basis is, I believe, valid and should be accepted. This status quo can and should be improved. This original intent for the session ids, thankfully, does not prohibit improvements from being made as these are opaque tokens generated by a NAS. Please may I solicit your feedback on the following changes so that I may iterate the text as appropriate? Kind regards, Nick Lowe Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting for the NAS (for example, upon booting) by specifying Accounting-On and to mark the end of accounting for the NAS (for example, just before a scheduled reboot) by specifying Accounting-Off. Where Accounting-On or Accounting-Off is specified, a Called-Station-Id attribute SHOULD NOT be present. In the case that one is present, the value MUST be global to the NAS. It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Where Subsystem-On or Subsystem-Off is specified, a Called-Station-Id attribute MUST be present. The subsystem is indicated by the value of the Called-Station-Id attribute. It MUST uniquely identify the subsystem to the NAS. For IEEE 802.11, this attribute SHOULD be used to store the BSSID (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where the SSID is known, it SHOULD be appended to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". The Called-Station-Id SHOULD be UTF-8 encoded. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed ?? Subsystem-On ?? Subsystem-Off Acct-Session-Id Description This attribute is a globally unique Accounting ID to make it easy to match start and stop records in a log file. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. It is strongly recommended that the Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >= 3 String The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters. Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD contain UTF-8 encoded 10646 [7] characters. From nobody Sun Oct 4 10:43:49 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BF31B2BA7 for ; Sun, 4 Oct 2015 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrH0O9uxe-4a for ; Sun, 4 Oct 2015 10:43:47 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDF31B2BA3 for ; Sun, 4 Oct 2015 10:43:46 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so91476834wic.0 for ; Sun, 04 Oct 2015 10:43:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=JbFP2oODtLPo60pPI/EbcYmg+KjTFSSp7gMaFSHULPw=; b=YgRO/4sE9rmRL7WYnxzWoooi78RwLa1v+ReGA/zyezvodNmXoUnYsbCBL0vnIV+ohv a2LsnT8vWcSm7sD+1asmuB2LDy43ivRpW+gCA/RxotoBEYgFU7TyUvRpSXjkqQL8H4xQ PExFMnZQCT90JvxFgyv4N6Gdsvd/anGjEujzd8MbFQuPcm/Rls/F3u696TvDrD41d+ux a0dGoHNUFP0V/zSONCuOVmSwkzM+Og+ddZ0KtTYsTab1BtdNyYErNyk1cS+RE+67PUQc phCyMo1gDk9Z6BIt8kaJxafE5IQCHn3bVUpDigct7jUhmyp6rPlPM9CFvBKGxw3XouzH JxjA== X-Gm-Message-State: ALoCoQnVV4GzRoaH6UJ0Liwn3c5pvHgfOXV8y9epp3BTkjLJUsV4m3cXG29awcBjhuNSqsSC8DtD MIME-Version: 1.0 X-Received: by 10.180.206.52 with SMTP id ll20mr6860789wic.48.1443980625478; Sun, 04 Oct 2015 10:43:45 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Sun, 4 Oct 2015 10:43:45 -0700 (PDT) X-Originating-IP: [77.96.75.177] In-Reply-To: References: Date: Sun, 4 Oct 2015 18:43:45 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 17:43:48 -0000 Quick clarification that I missed, somehow: It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Should read: It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. From nobody Mon Oct 5 13:05:25 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC331B4F82 for ; Mon, 5 Oct 2015 13:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqQ3AjyMv4ht for ; Mon, 5 Oct 2015 13:05:22 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 471491B4F60 for ; Mon, 5 Oct 2015 13:05:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 58C6C22405B3; Mon, 5 Oct 2015 22:05:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDXrVVlkkwts; Mon, 5 Oct 2015 22:05:20 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 953462240451; Mon, 5 Oct 2015 22:05:20 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: Date: Mon, 5 Oct 2015 16:05:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> References: To: Nick Lowe X-Mailer: Apple Mail (2.3094) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 20:05:24 -0000 I've submitted an IANA request for allocation of Acct-Status-Type =3D = Subsystem-On and Subsystem-Off. It's been assigned to... someone for review. I think additional = discussion here would be useful. > On Oct 4, 2015, at 1:25 PM, Nick Lowe wrote: > Carl Rigney helpfully clarified that the original intent of the > Acct-Session-Id and Acct-Multi-Session-Id was that they were only > intended to be unique in the context of a NAS during its uptime, not > across reboots and certainly without requirements to be globally > unique. That's nice, but I think the design goals 20+ years ago shouldn't = restrict what we do today. > The errata that clarifies that Accounting-On and Accounting-Off apply > on a per-NAS basis and not on a per-subsystem basis is, I believe, > valid and should be accepted. I agree with that. > This original intent for the session ids, thankfully, does not > prohibit improvements from being made as these are opaque tokens > generated by a NAS. I agree. I *strongly* believe that implementations should try to make = these values globally and temporally unique. There is more than = sufficient CPU / memory available to even $30 routers to meet this = requirement. Alan DeKok. From nobody Tue Oct 6 05:25:15 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467031B2A60 for ; Tue, 6 Oct 2015 05:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb2jDiYqSziP for ; Tue, 6 Oct 2015 05:25:10 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EE91B3D0A for ; Tue, 6 Oct 2015 05:25:09 -0700 (PDT) Received: by wicge5 with SMTP id ge5so164335492wic.0 for ; Tue, 06 Oct 2015 05:25:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x/BRSngfjZfUs7YK7JLar5mdN0hyz+cUaYMy4pASB18=; b=hfJaY0zfT/MdIzWTZ/+NADAZEBECq75aj0hWxKxoRLDHDpCGqCCjAPDNMRkZcwUrwN wzOLQfhZA3dFMLqZNYH6aMgJhUogk+oPoppAhn5j81Gs0a69KXqeeiDp3XMH6KzlCwou bY3eSIe/7Eg5qCvMkfpc0ZAv8YF3YTWg6MwqDhASTa1k8xy3Ry4TMMhlxlrGBp4JT8JF KSCMZ/Kx1MllfECUTh5S3LCV1zilVgbdd9h2dYWmm1Puz2ltLPasOgYbwB4qYe+6SWrT ANNamD58f3S80qhjGX1cITMkshhJU294xj2ZInR3Y1UvnXlQ9OxwtcJP/WFyVtBATTwL BWKg== X-Gm-Message-State: ALoCoQknmSkhU9kM93yTwTZw0jgCtkLYCxhMu6B2zXC7Ni7/RklSHb8cFaZxTpdaEnUZyz2upkqg MIME-Version: 1.0 X-Received: by 10.180.88.168 with SMTP id bh8mr16033282wib.48.1444134308495; Tue, 06 Oct 2015 05:25:08 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Tue, 6 Oct 2015 05:25:08 -0700 (PDT) X-Originating-IP: [94.116.150.144] In-Reply-To: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Tue, 6 Oct 2015 13:25:08 +0100 Message-ID: From: Nick Lowe To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 12:25:13 -0000 Second revision. A discussion with Heikki Vatiainen (Radiator) underlined the importance of explaining that this is fully compatible with 802.11 wireless controllers and the need to fix/clarify RFC 3580 to explain the use of Acct-Multi-Session-Id in roaming or failover accounting scenarios. RFC 2865 ======== Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting for the NAS (for example, upon booting) by specifying Accounting-On and to mark the end of accounting for the NAS (for example, just before a scheduled reboot) by specifying Accounting-Off. Where Accounting-On or Accounting-Off is specified, a Called-Station-Id attribute SHOULD NOT be present. In the case that one is present, the value MUST be global to the NAS. It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Where Subsystem-On or Subsystem-Off is specified, a Called-Station-Id attribute MUST be present. The subsystem is indicated by the value of the Called-Station-Id attribute. It MUST uniquely identify the subsystem to the NAS. For IEEE 802.11, this attribute SHOULD be used to store the BSSID (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where the SSID is known, it SHOULD be appended to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". The Called-Station-Id SHOULD be UTF-8 encoded. For IEEE 802.11 in particular, the Called-Station-Id SHOULD be UTF-8 encoded as the SSID may be UTF-8 encoded. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed ?? Subsystem-On ?? Subsystem-Off Acct-Session-Id Description This attribute is a globally unique Accounting ID to make it easy to match start and stop records in a log file. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. It is strongly recommended that the Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >= 3 String The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters. Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD contain UTF-8 encoded 10646 [7] characters. RFC 3580 ======== 2.2. Acct-Multi-Session-Id The purpose of this attribute is to make it possible to link together multiple related sessions for IEEE 802.11. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Basic Service Sets or in failover accounting from one Controller to another to cause multiple RADIUS accounting packets to be sent by the same or different Access Points or Controllers. Where supported by the Access Points or the Controllers, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant or in failover accounting from one Controller to another. In such a situation, if the session context is transferred between Access Points or Controllers, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points or the Controllers as part of the Inter-Access Point Protocol (IAPP) or another handoff scheme. If the Acct-Multi-Session-Id were not globally unique between Access Points and Controllers, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point or Controller, and the Accounting Server would therefore be unable to distinguish a roaming or failover session from a multi-link session. In order to provide global uniqueness, it is suggested that the Acct-Multi-Session-Id be an UTF-8 encoded UUID that offers inherent global and temporal uniqueness. An alternative construction for the Acct-Multi-Session-Id may be of the form: BSSID | Supplicant MAC Address | NTP Timestamp Here "|" represents concatenation, the BSSID is the MAC address of the BSS under which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming or failover sessions, the Acct-Multi-Session-Id may be moved between Access Points or Controllers as part of IAPP or another handoff scheme. The use of an Acct-Multi-Session-Id of this form should guarantee uniqueness among all Basic Service Sets, Access Points, Supplicants, Controllers and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point or Controller could choose an Acct-Multi-Session-Id that could be confused with that of a previous session once time synchronisation has occurred. The downside of this construction is that it is dependent on time synchronisation having occurred. For this reason, a UUID is preferred. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an UTF-8 string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8" 3.20. Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge MAC address or IEEE 802.11 BSSID (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". For IEEE 802.11, where the SSID is known, it SHOULD be appended to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". The Called-Station-Id SHOULD be UTF-8 encoded. For IEEE 802.11, the Called-Station-Id MUST be UTF-8 encoded as the SSID may be UTF-8 encoded. From nobody Tue Oct 6 08:19:43 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF08B1B40EE for ; Tue, 6 Oct 2015 08:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-zet7g9DyTA for ; Tue, 6 Oct 2015 08:19:40 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788BC1B40E1 for ; Tue, 6 Oct 2015 08:19:40 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so164378101wic.1 for ; Tue, 06 Oct 2015 08:19:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=btrziNrErh2mxaebOchiXUYcZ3u54Zlk8O+UAF2qP8c=; b=awlVDKNBL1uNHaddKxWeBPrgI6BjoiySyDa9PoT5IDoTr1klWItBvPXJnpj3x95LC4 4fia0O8qUZBwQsJlafyLzh2OF4Qz35wlO4QPe0sG78OtYHHZo35bglCqpYV7rOWH/fHt CndYhe4b3ql1CcHETnNDREryw3JOMfGaNEDEXPmWVF1paTTDErXaDrfJb4oZad6m7+VV IiHF/TKPWG7ZeolGD3BZPdEgtg7WxbJkcw5FKKeXMOi0/sTPQBE8OAFlnOSyBeFWhmkL G7cgAXvTnUy1oQ+7GPOUD7H8i1jzsjeSh3C46CpkKBROYNw/l7kJ+BG1wSEkpgJh1Wup 3xpQ== X-Gm-Message-State: ALoCoQlSjj0Kq3IT13cjj9sblxWfyCr6UDtIEcO0UgOg74GD96VH1RL8F5uGhRxJVefXoQUnKgWd MIME-Version: 1.0 X-Received: by 10.194.171.3 with SMTP id aq3mr37148871wjc.54.1444144778831; Tue, 06 Oct 2015 08:19:38 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Tue, 6 Oct 2015 08:19:38 -0700 (PDT) X-Originating-IP: [94.116.150.144] Date: Tue, 6 Oct 2015 16:19:38 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 15:19:41 -0000 Dear list, Might it be possible for RFC 3580 to be transferred to be under the control of the RADIUS WG? Presently, as far as I can see, it is not, I believe it should be. I would certainly like to try to convince others that it is necessary in any case to clarify this RFC as it does not meet the needs of implementors today. There is a persistent technical error, being charitable... limitation, in RFC 3580 in that =E2=80=9CAccess Point=E2=80=9D is used instead of =E2= =80=9CBasic Service Set=E2=80=9D (BSS). This has lead to inconsistencies in RADIUS client behaviour, it is unnecessary and should, I believe, be corrected. The RFC was written prior to central controllers being common place and does not specify the expected behaviour where they are, particularly when it comes to roaming from one BSS to another BSS. In the Subsystem-on and Subsystem-off thread, I have drafted the type of change that I would like to see to the Called-Station-Id and Acct-Multi-Session-Id advise given. Access points may contain multiple radios and, for each radio, offer multiple Extended Service Sets (colloquially multiple SSIDs), which each use a discrete Basic Service Set (BSS). This ability is commonly known under the umbrella term Virtual Access Point (VAP). Stating an Access Point MAC address is at best meaningless as it is ambiguous, at worst it is harmful. A client can roam from one BSS to another BSS on the same AP, typically between 2.4 GHz and 5 GHz BSSes. I also wish to see a statement on the expected interaction of 802.1X re-authentication with Class attributes. 1) Should Class attributes being accounted with be replaced with subsequent values provided by a RADIUS server in the Access-Accept during 802.1X re-authentication? I think so. 2) What should happen if no Class attributes are provided during 802.1X re-authentication in the Access-Accept, yet the original authentication possessed one or more? I think the original Class attributes should continue to be accounted with. 3) Should the RADIUS server ensure that the Class attribute(s) provided in the Access-Accept when 802.1X re-authentication takes place matches those that were previously so that this becomes technically moot and not the concern of the NAS? Furthermore, should a Stop and Start should be observed when 802.1X re-authentication takes place? This is not specified anywhere. The expected behaviour should be specified. I believe that no Stop and a Start should be observed as the session continues. The construction recommended for the Acct-Multi-Session-Id is also suboptimal as it requires time synchronisation to have occurred. This is not always possible for an 802.11 NAS, a UUID is therefore preferable to guarantee global and temporal uniqueness. There is also a need to specify that because SSIDs can be UTF-8 encoded, a Called-Station-Id that contains BSSID:SSID SHOULD be UTF-8 encoded. This is missing from the RFC. The proposed Subsystem-on and Subsystem-off require something to use to define and scope to the subsystem. For 802.11, I believe that combination should be BSSID:SSID Ideally, the Called-Station-Id value used for a session SHOULD match the Called-Station-Id that is defines the subsystem. Clearly that should not be a MUST requirement though. Regards, Nick From nobody Tue Oct 6 08:30:54 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A341B4101 for ; Tue, 6 Oct 2015 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMtwasniSQxJ for ; Tue, 6 Oct 2015 08:30:52 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 06B541B40F3 for ; Tue, 6 Oct 2015 08:30:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 73EFD2240822; Tue, 6 Oct 2015 17:30:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh9RM4VndMR2; Tue, 6 Oct 2015 17:30:50 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 8BB8E224020D; Tue, 6 Oct 2015 17:30:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: Date: Tue, 6 Oct 2015 11:30:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> References: To: Nick Lowe X-Mailer: Apple Mail (2.3094) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 15:30:54 -0000 On Oct 6, 2015, at 11:19 AM, Nick Lowe wrote: > Might it be possible for RFC 3580 to be transferred to be under the > control of the RADIUS WG? Presently, as far as I can see, it is not, I > believe it should be. RFCs are under the control of the IETF / IESG. They can delegate = updates to any WG they desire. In this case, if there is consensus and charter updates, the RADEXT WG = could update 3580. > I would certainly like to try to convince others that it is necessary > in any case to clarify this RFC as it does not meet the needs of > implementors today. We'll put it on the list of documents to fix RADIUS. :( > There is a persistent technical error, being charitable... limitation, > in RFC 3580 in that =E2=80=9CAccess Point=E2=80=9D is used instead of = =E2=80=9CBasic Service > Set=E2=80=9D (BSS). This has lead to inconsistencies in RADIUS client > behaviour, it is unnecessary and should, I believe, be corrected. That's less an error than a limitation of the time it was written. > I also wish to see a statement on the expected interaction of 802.1X > re-authentication with Class attributes. My $0.02 is to write a document which updates RFC 3580 and others. I = can assist. If the document is simple and has no objections... it might take 3 = years to get published as an RFC. > 1) Should Class attributes being accounted with be replaced with > subsequent values provided by a RADIUS server in the Access-Accept > during 802.1X re-authentication? I think so.\ I would agree. > 2) What should happen if no Class attributes are provided during > 802.1X re-authentication in the Access-Accept, yet the original > authentication possessed one or more? I think the original Class > attributes should continue to be accounted with. I agree. > 3) Should the RADIUS server ensure that the Class attribute(s) > provided in the Access-Accept when 802.1X re-authentication takes > place matches those that were previously so that this becomes > technically moot and not the concern of the NAS? I'm not sure. I would *prefer* to push more behaviour off to the RADIUS server. = There are 100x as many NASes as RADIUS servers, and the RADIUS servers = get upgraded more often. So it's easier to fix things by upgrading the = RADIUS servers. > Furthermore, should a Stop and Start should be observed when 802.1X > re-authentication takes place? This is not specified anywhere. The > expected behaviour should be specified. I believe that no Stop and a > Start should be observed as the session continues. I agree. The difficulty here is the ambiguity / race condition. If Session-Timeout is 1000 seconds. Is the session *stopped* at 1000 = seconds? Or does the supplicant re-authenticate at 999 seconds, so that = the session can continue? If the re-authentication fails, does the NAS send Acct-Status-Type =3D = Stop? If the re-authentication succeeds, does the NAS send an = Acct-Status-Type =3D Start? The specs are *full* of ambiguities which cause problems in the real = world. > The construction recommended for the Acct-Multi-Session-Id is also > suboptimal as it requires time synchronisation to have occurred. This > is not always possible for an 802.11 NAS, a UUID is therefore > preferable to guarantee global and temporal uniqueness. I agree. > There is also a need to specify that because SSIDs can be UTF-8 > encoded, a Called-Station-Id that contains BSSID:SSID SHOULD be UTF-8 > encoded. This is missing from the RFC. I agree. > The proposed Subsystem-on and Subsystem-off require something to use > to define and scope to the subsystem. For 802.11, I believe that > combination should be BSSID:SSID That's a good idea, but it's difficult to define exactly what a = "session" is, or what a "scope" is. > Ideally, the Called-Station-Id value used for a session SHOULD match > the Called-Station-Id that is defines the subsystem. Clearly that > should not be a MUST requirement though. I agree. Alan DeKok. From nobody Tue Oct 6 09:14:53 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0EB1ACD7C for ; Tue, 6 Oct 2015 09:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ebaS9flcv6q for ; Tue, 6 Oct 2015 09:14:51 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2E51ACD9F for ; Tue, 6 Oct 2015 09:14:49 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so174322689wic.1 for ; Tue, 06 Oct 2015 09:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r+d1MNdlOMXnzbCb2MX8Yjr/fWi+baGlrca/nGEaQwQ=; b=OMZXKoB3Kfys+jnLi1ZrM3Xd/GN/fhgLgjgVxPdrEH5KNsn8Iff+HtKl7P9JfXliaB 4iwgUvJvf8lYs11gm2H+wplzXDpvbfXY6Z0t1kguKqT6PM0INkxlNZBvz1YLxTI+uPfn u8MgK2mWbHuOE/WYAGHknhMqy6+RjqE4FK301xS6+pLMXw8itmUr7D5+zbpKVaHyhAxt w0TPHBMytWiJYoNyS+RvfQXT6yqpSb6Vid2rdwzJ21zye7Z5H3FDybYHJer9It6PrMme ecbRNziXVOQdL2c/OaSvz6tbNbHOSlGxktaRy1xVdIOq2Lo/UWRd9CVSEobkOifzA3lj e4xw== MIME-Version: 1.0 X-Received: by 10.194.234.40 with SMTP id ub8mr36145950wjc.95.1444148087697; Tue, 06 Oct 2015 09:14:47 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Tue, 6 Oct 2015 09:14:47 -0700 (PDT) In-Reply-To: <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> References: <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> Date: Tue, 6 Oct 2015 12:14:47 -0400 Message-ID: From: Kathleen Moriarty To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Nick Lowe , "radext@ietf.org" Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 16:14:52 -0000 Hi, Just one quick question... On Tue, Oct 6, 2015 at 11:30 AM, Alan DeKok wro= te: > On Oct 6, 2015, at 11:19 AM, Nick Lowe wrote: >> Might it be possible for RFC 3580 to be transferred to be under the >> control of the RADIUS WG? Presently, as far as I can see, it is not, I >> believe it should be. > > RFCs are under the control of the IETF / IESG. They can delegate updat= es to any WG they desire. > > In this case, if there is consensus and charter updates, the RADEXT WG = could update 3580. > >> I would certainly like to try to convince others that it is necessary >> in any case to clarify this RFC as it does not meet the needs of >> implementors today. > > We'll put it on the list of documents to fix RADIUS. :( > >> There is a persistent technical error, being charitable... limitation, >> in RFC 3580 in that =E2=80=9CAccess Point=E2=80=9D is used instead of = =E2=80=9CBasic Service >> Set=E2=80=9D (BSS). This has lead to inconsistencies in RADIUS client >> behaviour, it is unnecessary and should, I believe, be corrected. > > That's less an error than a limitation of the time it was written. > >> I also wish to see a statement on the expected interaction of 802.1X >> re-authentication with Class attributes. > > My $0.02 is to write a document which updates RFC 3580 and others. I c= an assist. > > If the document is simple and has no objections... it might take 3 year= s to get published as an RFC. Is this a result of the workload of Radext, editors, or process problems? If it's process problems, let's fix that as I don' want to see drafts taking 3 years to publish. If it is workload and priorities for the WG, that is another matter (we can look at that as well). Thanks, Kathleen > >> 1) Should Class attributes being accounted with be replaced with >> subsequent values provided by a RADIUS server in the Access-Accept >> during 802.1X re-authentication? I think so.\ > > I would agree. > >> 2) What should happen if no Class attributes are provided during >> 802.1X re-authentication in the Access-Accept, yet the original >> authentication possessed one or more? I think the original Class >> attributes should continue to be accounted with. > > I agree. > >> 3) Should the RADIUS server ensure that the Class attribute(s) >> provided in the Access-Accept when 802.1X re-authentication takes >> place matches those that were previously so that this becomes >> technically moot and not the concern of the NAS? > > I'm not sure. > > I would *prefer* to push more behaviour off to the RADIUS server. Ther= e are 100x as many NASes as RADIUS servers, and the RADIUS servers get upgr= aded more often. So it's easier to fix things by upgrading the RADIUS serv= ers. > >> Furthermore, should a Stop and Start should be observed when 802.1X >> re-authentication takes place? This is not specified anywhere. The >> expected behaviour should be specified. I believe that no Stop and a >> Start should be observed as the session continues. > > I agree. The difficulty here is the ambiguity / race condition. > > If Session-Timeout is 1000 seconds. Is the session *stopped* at 1000 s= econds? Or does the supplicant re-authenticate at 999 seconds, so that the= session can continue? > > If the re-authentication fails, does the NAS send Acct-Status-Type =3D = Stop? > > If the re-authentication succeeds, does the NAS send an Acct-Status-Typ= e =3D Start? > > The specs are *full* of ambiguities which cause problems in the real wo= rld. > >> The construction recommended for the Acct-Multi-Session-Id is also >> suboptimal as it requires time synchronisation to have occurred. This >> is not always possible for an 802.11 NAS, a UUID is therefore >> preferable to guarantee global and temporal uniqueness. > > I agree. > >> There is also a need to specify that because SSIDs can be UTF-8 >> encoded, a Called-Station-Id that contains BSSID:SSID SHOULD be UTF-8 >> encoded. This is missing from the RFC. > > I agree. > >> The proposed Subsystem-on and Subsystem-off require something to use >> to define and scope to the subsystem. For 802.11, I believe that >> combination should be BSSID:SSID > > That's a good idea, but it's difficult to define exactly what a "sessio= n" is, or what a "scope" is. > >> Ideally, the Called-Station-Id value used for a session SHOULD match >> the Called-Station-Id that is defines the subsystem. Clearly that >> should not be a MUST requirement though. > > I agree. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Best regards, Kathleen From nobody Tue Oct 6 09:57:15 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6821ACED3 for ; Tue, 6 Oct 2015 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqxRW6m4jjR5 for ; Tue, 6 Oct 2015 09:57:11 -0700 (PDT) Received: from BLU004-OMC4S32.hotmail.com (blu004-omc4s32.hotmail.com [65.55.111.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB5C1ACEC8 for ; Tue, 6 Oct 2015 09:57:11 -0700 (PDT) Received: from BLU181-W34 ([65.55.111.137]) by BLU004-OMC4S32.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 6 Oct 2015 09:57:10 -0700 X-TMN: [fbhe51FPZKj5QwJerkMv3M9uF8e43cs9] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fd3c3705-ae56-43da-b59c-39ef2b8473c9_" From: Bernard Aboba To: Nick Lowe , Alan DeKok Date: Tue, 6 Oct 2015 09:57:09 -0700 Importance: Normal In-Reply-To: References: , <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 06 Oct 2015 16:57:10.0883 (UTC) FILETIME=[0ACDB330:01D10058] Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 16:57:13 -0000 --_fd3c3705-ae56-43da-b59c-39ef2b8473c9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments below.=20 >=20 > RFC 2865 > =3D=3D=3D=3D=3D=3D=3D=3D [BA] Not sure why you are referring to RFC 2865 here. This is a Draft Sta= ndard RFC that covers authentication/authorization. There is no material = in this document relating to accounting. =20 > Acct-Status-Type >=20 > Description >=20 > This attribute indicates whether this Accounting-Request marks > the beginning of the user service (Start) or the end (Stop). >=20 > It MAY be used by the client to mark the start of accounting for > the NAS (for example=2C upon booting) by specifying Accounting-On > and to mark the end of accounting for the NAS (for example=2C just > before a scheduled reboot) by specifying Accounting-Off. >=20 > Where Accounting-On or Accounting-Off is specified=2C a > Called-Station-Id attribute SHOULD NOT be present. In the case > that one is present=2C the value MUST be global to the NAS. [BA] What does "global to the NAS" mean? Are you referring to a globally u= nique MAC Address? =20 > For IEEE 802.11=2C this attribute SHOULD be used to store the > BSSID (upper case only)=2C=20 > The Called-Station-Id SHOULD be UTF-8 encoded. [BA] This seems to contradict the text before that which seems to imply th= at the BSSID is encoded in ASCII. Allowing UTF-8 encoding of the BSSID co= uld introduce interoperability issues so that is not a good idea.=20 > For IEEE 802.11 in particular=2C the Called-Station-Id SHOULD be > UTF-8 encoded as the SSID may be UTF-8 encoded. [BA] It would appear to me that only the SSID may be UTF-8 encoded. So why= don't we just say that? = --_fd3c3705-ae56-43da-b59c-39ef2b8473c9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Comments below. =3B
= >=3B
>=3B RFC 2865
>=3B =3D=3D=3D=3D=3D=3D=3D=3D
[BA]  =3BNot sure why you are referring to RFC 2865 here. &= nbsp=3BThis is a Draft Standard RFC that covers authentication/authorizatio= n.  =3B There is no material in this document relating to accounting. &= nbsp=3B =3B

>=3B Acct-Status-Type
>=3B =
>=3B Description
>=3B
>=3B This attribute indicat= es whether this Accounting-Request marks
>=3B the beginning of t= he user service (Start) or the end (Stop).
>=3B
>=3B It MA= Y be used by the client to mark the start of accounting for
>=3B = the NAS (for example=2C upon booting) by specifying Accounting-On
>= =3B and to mark the end of accounting for the NAS (for example=2C jus= t
>=3B before a scheduled reboot) by specifying Accounting-Off.<= br>>=3B
>=3B Where Accounting-On or Accounting-Off is specifi= ed=2C a
>=3B Called-Station-Id attribute SHOULD NOT be present. = In the case
>=3B that one is present=2C the value MUST be globa= l to the NAS.

[BA] What does "global to the NAS" m= ean?  =3BAre you referring to a globally unique MAC Address?  =3B

>=3B For IEEE 802.11=2C this attribute SHOU= LD be used to store the
>=3B BSSID (upper case only)=2C =3B<= /div>

>=3B The Called-Station-Id SHOULD be UTF-8= encoded.

[BA]  =3BThis seems to contradict th= e text before that which seems to imply that the BSSID is encoded in ASCII.=  =3B Allowing UTF-8 encoding of the BSSID could introduce interoperabi= lity issues so that is not a good idea. =3B

&g= t=3B For IEEE 802.11 in particular=2C the Called-Station-Id SHOULD be=
>=3B UTF-8 encoded as the SSID may be UTF-8 encoded.
=
[BA] It would appear to me that only the SSID may be UTF-8 e= ncoded.  =3BSo why don't we just say that?
= --_fd3c3705-ae56-43da-b59c-39ef2b8473c9_-- From nobody Tue Oct 6 12:05:43 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC0E1B2A0E for ; Tue, 6 Oct 2015 12:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEOOwOI1L_6u for ; Tue, 6 Oct 2015 12:05:35 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8841B2A2F for ; Tue, 6 Oct 2015 12:05:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7DAF722408A9; Tue, 6 Oct 2015 21:05:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPyu1AMcYEwF; Tue, 6 Oct 2015 21:05:33 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id B16982240490; Tue, 6 Oct 2015 21:05:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: Date: Tue, 6 Oct 2015 15:05:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <451E43F5-44DF-4651-8372-49BC90DFEC5A@deployingradius.com> References: <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3094) Archived-At: Cc: Nick Lowe , "radext@ietf.org" Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 19:05:41 -0000 On Oct 6, 2015, at 12:14 PM, Kathleen Moriarty = wrote: >> If the document is simple and has no objections... it might take 3 = years to get published as an RFC. >=20 > Is this a result of the workload of Radext, editors, or process > problems? If it's process problems, let's fix that as I don' want to > see drafts taking 3 years to publish. If it is workload and priorities > for the WG, that is another matter (we can look at that as well). It's been the process for as long as I've been involved in RADEXT. = Call it 10+ years? Alan DeKok. From nobody Tue Oct 6 13:12:33 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BFB1B32A1 for ; Tue, 6 Oct 2015 13:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1u2tEF5JiSH for ; Tue, 6 Oct 2015 13:12:23 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6176B1B32A8 for ; Tue, 6 Oct 2015 13:12:23 -0700 (PDT) Received: by wicge5 with SMTP id ge5so183406125wic.0 for ; Tue, 06 Oct 2015 13:12:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=+IewuMA2HJT/E45PHZ5hqEcSncyvj+kvWCyZRJYRNPk=; b=WbvMKj6Om4fOpeXCa2vPyQHQR/Si+NaPwhU9HPQC8UNDzSKKPJNesIrujGJBc2Hyic jBu6jHKO3lZd28EysgPksAkXGk5uhS98Gafn/y/cyhUfmn4huPOAYHj8iZusxCQTPDLe s+PprYlF1JuXj63BY02TD5zksS/YSpFpO7vtSY7pNSjG8tINzeOyDEV/UG4mwQSIvqcz 3H77voUQTeyDeIqyyi52wMb22RH+VOXly/Gi5TDQv+6XqE7Vkr1ee5gXNEPcC+5JNQ0A qVgZXo83RmomjRfTWXCGZCz0DXgT0pdRVhSMCoB65eXFEhJyTFXPjpi3eGFjk552mzuM 4VVQ== X-Gm-Message-State: ALoCoQmY3oiiK+Kbfen7prboYaHMVxdEAbovhlQNogdn+ybVtp4rwSu1K3Bpg4gbYiOnSOHINYq5 MIME-Version: 1.0 X-Received: by 10.180.210.162 with SMTP id mv2mr18448284wic.47.1444162341948; Tue, 06 Oct 2015 13:12:21 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Tue, 6 Oct 2015 13:12:21 -0700 (PDT) X-Originating-IP: [81.2.104.217] In-Reply-To: References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Tue, 6 Oct 2015 21:12:21 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [radext] Fwd: Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 20:12:31 -0000 On Tue, Oct 6, 2015 at 5:57 PM, Bernard Aboba wrote: > Comments below. >> >> RFC 2865 >> ======== > > [BA] Not sure why you are referring to RFC 2865 here. This is a Draft > Standard RFC that covers authentication/authorization. There is no > material in this document relating to accounting. Correct. I meant to say this was in the context of RFC 2866. I typed that autonomously and managed to miss that while proof reading. Sorry, it was a flat out mistake. >> Acct-Status-Type >> >> Description >> >> This attribute indicates whether this Accounting-Request marks >> the beginning of the user service (Start) or the end (Stop). >> >> It MAY be used by the client to mark the start of accounting for >> the NAS (for example, upon booting) by specifying Accounting-On >> and to mark the end of accounting for the NAS (for example, just >> before a scheduled reboot) by specifying Accounting-Off. >> >> Where Accounting-On or Accounting-Off is specified, a >> Called-Station-Id attribute SHOULD NOT be present. In the case >> that one is present, the value MUST be global to the NAS. > > [BA] What does "global to the NAS" mean? Are you referring to a globally > unique MAC Address? This is taken from Alan's wording: http://freeradius.org/rfc/acct_status_type_subsystem.html "with a value for Called-Station-Id that is global to the NAS" I wanted to mandate that the value must be something that applies to the whole NAS. It is not and cannot be a value that scopes to a subsystem and must therefore constant to all Accounting-On and Accounting-Off forms of Accounting-Request packets that a NAS sends. Perhaps it would be better to state the reverse, that any value must not scope to subsystem on the NAS. How would you word this? Omit this entirely? Any suggestions? I would prefer to prohibit a Called-Station-Id being present outright for Accounting-On and Accounting-Off. I cannot see that it serves a legitimate purpose but realise there may be too much of a compatibility implication pushing for this. The intent is for NASes that are currently sending Accounting-On and Accounting-Off that are scoped to a subsystem to stop doing so. >> For IEEE 802.11, this attribute SHOULD be used to store the >> BSSID (upper case only), > >> The Called-Station-Id SHOULD be UTF-8 encoded. > > [BA] This seems to contradict the text before that which seems to imply > that the BSSID is encoded in ASCII. Allowing UTF-8 encoding of the BSSID > could introduce interoperability issues so that is not a good idea. UTF-8 being a general superset of ASCII, my thoughts were that it would be easier to treat the whole thing as being UTF-8 encoded rather than thinking about it being ASCII encoded up and until the first : is encountered after which point UTF-8 is used. That was my reasoning behind writing it like that anyway. I felt it was unneeded complexity that could easily becomes too nuanced without giving a tangible benefit. I'll reword this if you think there could be significant interoperability issues. > >> For IEEE 802.11 in particular, the Called-Station-Id SHOULD be >> UTF-8 encoded as the SSID may be UTF-8 encoded. > > [BA] It would appear to me that only the SSID may be UTF-8 encoded. So why > don't we just say that? As above, I'll reword this if you feel there could be significant interoperability issues. From nobody Wed Oct 7 02:19:01 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7CF1B2C8F for ; Wed, 7 Oct 2015 02:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgsFtLp5NE50 for ; Wed, 7 Oct 2015 02:18:53 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14441A906E for ; Wed, 7 Oct 2015 02:18:52 -0700 (PDT) Received: by wicge5 with SMTP id ge5so203439593wic.0 for ; Wed, 07 Oct 2015 02:18:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=/pywqilEkxN6gqLyauHqqmV4DLdGMUzv6lWOv8Tfutk=; b=XZlQGkXn2WMk6v3vj8/8hoUmrTzMrqUHm9DMkuhvkqs+yG7m6Dy6WdqFnKgV/DtA0w sRRjsWRnhJZDqtssRwHCQ86a2CazuKnGN/1mJ49xlCJJwmko7nbHqsOKB1oA+Odxr3EL 2L7dFkRqjWhVM9AX4vuopftd9HyialEB6fsZkjglAd29pS75RE8py0gOG87chH2+Oh7i 7wpc1qohgvFMrqgJkoqPX+RBZMY9O7VvJ7QFsbBE3sSoGogFMZZuttLypUxSCc61WJzU 3rtuBCqNmVgBMmnEe48KKWv/lRR+ntrK+0M6okcQCZYv5pzAspk5ZjmHTnKlluK7R9Z8 1AUg== X-Gm-Message-State: ALoCoQmyJEfDLSBZ3h9PlZW5mBfRvHWJKLcVVa5y6ByYLiq2j8iYzxeWPsUenagUmMEr3mXRjymO MIME-Version: 1.0 X-Received: by 10.194.76.7 with SMTP id g7mr40698348wjw.44.1444209531044; Wed, 07 Oct 2015 02:18:51 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Wed, 7 Oct 2015 02:18:50 -0700 (PDT) X-Originating-IP: [94.116.196.121] In-Reply-To: References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Wed, 7 Oct 2015 10:18:50 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 09:19:00 -0000 Corrections made. Reference to RFC 2866 ===================== Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting for the NAS (for example, upon booting) by specifying Accounting-On and to mark the end of accounting for the NAS (for example, just before a scheduled reboot) by specifying Accounting-Off. Where Accounting-On or Accounting-Off is specified, a Called-Station-Id attribute SHOULD NOT be present. In the case that one is present, the value MUST apply to the whole NAS. It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Where Subsystem-On or Subsystem-Off is specified, a Called-Station-Id attribute MUST be present. The subsystem is indicated by the value of the Called-Station-Id attribute. It MUST uniquely identify the subsystem to the NAS. It is strongly recommended that the value of the Called-Station-Id attribute that is used for a session SHOULD match the value of the Called-Station-Id that identifies the subsystem. The value of any Called-Station-Id attributes that are used in accounting types that are session specific SHOULD match the value used when Subsystem-On and Subsystem-Off are specified where they come under the scope of that subsystem. For IEEE 802.11, this attribute SHOULD be used to store the BSSID (upper case only) in ASCII format, with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where the SSID is known, it SHOULD be appended to the BSSID in UTF-8 format, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". The SSID MUST be UTF-8 encoded as the SSID may be UTF-8 encoded. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed ?? Subsystem-On ?? Subsystem-Off Acct-Session-Id Description This attribute is a globally unique Accounting ID to make it easy to match start and stop records in a log file. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. It is strongly recommended that the Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >= 3 String The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters. Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD contain UTF-8 encoded 10646 [7] characters. Reference to RFC 3580 ===================== Acct-Multi-Session-Id The purpose of this attribute is to make it possible to link together multiple related sessions for IEEE 802.11. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Basic Service Sets or in failover accounting from one Controller to another to cause multiple RADIUS accounting packets to be sent by the same or different Access Points or Controllers. Where supported by the Access Points or the Controllers, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant or in failover accounting from one Controller to another. In such a situation, if the session context is transferred between Access Points or Controllers, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points or the Controllers as part of the Inter-Access Point Protocol (IAPP) or another handoff scheme. If the Acct-Multi-Session-Id were not globally unique between Access Points and Controllers, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point or Controller, and the Accounting Server would therefore be unable to distinguish a roaming or failover session from a multi-link session. In order to provide global uniqueness, it is suggested that the Acct-Multi-Session-Id be an UTF-8 encoded UUID that offers inherent global and temporal uniqueness. An alternative construction for the Acct-Multi-Session-Id may be of the form: BSSID | Supplicant MAC Address | NTP Timestamp Here "|" represents concatenation, the BSSID is the MAC address of the BSS under which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming or failover sessions, the Acct-Multi-Session-Id may be moved between Access Points or Controllers as part of IAPP or another handoff scheme. The use of an Acct-Multi-Session-Id of this form should guarantee uniqueness among all Basic Service Sets, Access Points, Supplicants, Controllers and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point or Controller could choose an Acct-Multi-Session-Id that could be confused with that of a previous session once time synchronisation has occurred. The downside of this construction is that it is dependent on time synchronisation having occurred. For this reason, a UUID is preferred. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an UTF-8 string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8" Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge MAC address or IEEE 802.11 BSSID in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". For IEEE 802.11, where the SSID is known, it SHOULD be appended in UTF-8 format to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". The SSID MUST be UTF-8 encoded as the SSID may be UTF-8 encoded. From nobody Wed Oct 7 02:38:36 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D791B2CC5 for ; Wed, 7 Oct 2015 02:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpZjxPK6jdml for ; Wed, 7 Oct 2015 02:38:33 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814061B2CB5 for ; Wed, 7 Oct 2015 02:38:33 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so19537714wic.0 for ; Wed, 07 Oct 2015 02:38:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=FovFvOy8aGbEXrotj0d6n0D6qpH7KHxAU3kWyIoYVCk=; b=Y/5epnXaS8ZBnInOklugjxinsw6+dVfNmnjwjcewbOVcx8B3LNaZ6lDcBEKwONWq43 nf02p0yc7+ggG7avHmgUmo8WkKj6mj/6jNO/hehTmhbJnekOpBqDSEXnPjjl2+7T0LHp oNw2WrM4HUSlefD5u+ewj3XGP1/u2ZRvcijiqbCGpoJrE79fQn3HpW5kHeWTfoxTB3Nl 4AdMrk+mKcPXjukDb2K4LxUy/KSKu8bR4TQNxF/LjFwyY0EdQ9QYYWepM1s5Xwa/bzkS PSJwLo3ZbVC3A5Dn//o3neFoWzjb/0eYANVCa0/NrIxuvM9c9Wn/qiosTeQlESxBCZdT oWVQ== X-Gm-Message-State: ALoCoQl0Upc5dQGyFUj5IMEs3xX9lfrFC5gHxN3Z2k+p+pu0osYgNwFVr1L2qHnZZGTRrC5TeG2z MIME-Version: 1.0 X-Received: by 10.180.206.52 with SMTP id ll20mr680629wic.48.1444210712008; Wed, 07 Oct 2015 02:38:32 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Wed, 7 Oct 2015 02:38:31 -0700 (PDT) X-Originating-IP: [94.116.196.121] In-Reply-To: References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Wed, 7 Oct 2015 10:38:31 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 09:38:34 -0000 Oops, this reads in a really odd way. Change: The SSID MUST be UTF-8 encoded as the SSID may be UTF-8 encoded. To: As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. From nobody Wed Oct 7 03:52:56 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AA61B2DD9 for ; Wed, 7 Oct 2015 03:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_WTHU6HXDbL for ; Wed, 7 Oct 2015 03:52:53 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70611B2DD4 for ; Wed, 7 Oct 2015 03:52:52 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so22261669wic.1 for ; Wed, 07 Oct 2015 03:52:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wlV+PxGZ9I3QmcYJ4dwqTNtJhyyXF4gY20r5AUYhimg=; b=LyDdqXSgXw+3R3A8EhQhizZf6+066XBf5OQDdYP+lcRdxKuE3/1Ll5pNrYK57m1ySP bc6SVrlEQl0+k3g6h9FKslWhf+spSs8aoW0bOo7eBin0P2PCu4dLx1jFca9ohWEgV44j vyVSOZPS4sfZVmDJ9ZTdR53kHWBGwj9j9irYcCBGcO76F+Db+jV6eIh0SPkVZ5Mz86cr xX1VvGSedMsd8Ohg2O3otxmuWffL2hp1OShS+BK/XHnv6bPgVaQNTAKS4OT2MAdpD/3Q RIVqJq9/rGk1cSkQhwxin+lCRAq8EXRk4/Qt4g/xbR8xXu8YhXGbFWiSYrguDxzlYL+i ckIw== X-Gm-Message-State: ALoCoQnc2wL92ErnfWhVRxiIkTklkfEzK1H8eOjtRGMQ/lNN3NQrdziNxmr81MtOkI8qiUPZQUnI MIME-Version: 1.0 X-Received: by 10.194.171.3 with SMTP id aq3mr443319wjc.54.1444215171358; Wed, 07 Oct 2015 03:52:51 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Wed, 7 Oct 2015 03:52:51 -0700 (PDT) X-Originating-IP: [94.117.140.196] In-Reply-To: References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Wed, 7 Oct 2015 11:52:51 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 10:52:55 -0000 Upon further reflection, I think that the term "log file" should be dropped and "easy to link" changed to "possible to link" for the Acct-Session-Id and Acct-Multi-Session-Id. If they're eventually going to be revised to offer global and temporal uniqueness, seems worth doing. Reference to RFC 2866 ===================== Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting for the NAS (for example, upon booting) by specifying Accounting-On and to mark the end of accounting for the NAS (for example, just before a scheduled reboot) by specifying Accounting-Off. Where Accounting-On or Accounting-Off is specified, a Called-Station-Id attribute SHOULD NOT be present. In the case that one is present, the value MUST apply to the whole NAS. It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Where Subsystem-On or Subsystem-Off is specified, a Called-Station-Id attribute MUST be present. The subsystem is indicated by the value of the Called-Station-Id attribute. It MUST uniquely identify the subsystem to the NAS. It is strongly recommended that the value of the Called-Station-Id attribute that is used for a session SHOULD match the value of the Called-Station-Id that identifies the subsystem. The value of any Called-Station-Id attributes that are used in accounting types that are session specific SHOULD match the value used when Subsystem-On and Subsystem-Off are specified where they come under the scope of that subsystem. For IEEE 802.11, this attribute SHOULD be used to store the BSSID (upper case only) in ASCII format, with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where the SSID is known, it SHOULD be appended to the BSSID in UTF-8 format, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed ?? Subsystem-On ?? Subsystem-Off Acct-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to match start and stop records. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. It is strongly recommended that the Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >= 3 String The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters. Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to link together multiple related sessions. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD contain UTF-8 encoded 10646 [7] characters. Reference to RFC 3580 ===================== Acct-Multi-Session-Id The purpose of this attribute is to make it possible to link together multiple related sessions for IEEE 802.11. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Basic Service Sets or in failover accounting from one Controller to another to cause multiple RADIUS accounting packets to be sent by the same or different Access Points or Controllers. Where supported by the Access Points or the Controllers, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant or in failover accounting from one Controller to another. In such a situation, if the session context is transferred between Access Points or Controllers, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points or the Controllers as part of the Inter-Access Point Protocol (IAPP) or another handoff scheme. If the Acct-Multi-Session-Id were not globally unique between Access Points and Controllers, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point or Controller, and the Accounting Server would therefore be unable to distinguish a roaming or failover session from a multi-link session. In order to provide global uniqueness, it is suggested that the Acct-Multi-Session-Id be a UUID that offers inherent global and temporal uniqueness. An alternative construction for the Acct-Multi-Session-Id may be of the form: BSSID | Supplicant MAC Address | NTP Timestamp Here "|" represents concatenation, the BSSID is the MAC address of the BSS under which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming or failover sessions, the Acct-Multi-Session-Id may be moved between Access Points or Controllers as part of IAPP or another handoff scheme. The use of an Acct-Multi-Session-Id of this form should guarantee uniqueness among all Basic Service Sets, Access Points, Supplicants, Controllers and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point or Controller could choose an Acct-Multi-Session-Id that could be confused with that of a previous session once time synchronisation has occurred. The downside of this construction is that it is dependent on time synchronisation having occurred. For this reason, a UUID is preferred. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an UTF-8 string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8" Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge MAC address or IEEE 802.11 BSSID in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". For IEEE 802.11, where the SSID is known, it SHOULD be appended in UTF-8 format to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. From nobody Wed Oct 7 04:30:37 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4B01B2E35 for ; Wed, 7 Oct 2015 04:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n568Fw-DBSnJ for ; Wed, 7 Oct 2015 04:30:34 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FB91B2E31 for ; Wed, 7 Oct 2015 04:30:34 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so208568851wic.0 for ; Wed, 07 Oct 2015 04:30:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ZT4NNpNu8zKuIQGrAoBKI3L5k3m8bCBuYa4xJn+V6/w=; b=TZzXhbJi3uC8p/gV1uZMs3aH5rn5tIeOivHEIhfkGbrdU99R57Z/EkJCFIeL/qUjgZ JLiObN5TuIKu3Nqfv/Pzz+Y3Eev6ID9pJEvYLN5JjXfjLyha2l7TmFfdHGMVtCJYlHQm kXqqZTLVLoC4dfRSjJkPA27bvejxAs7LGQ60v0/u5qPnPSiiIa671GCrXjIEfbGsHnXs iZaf74uWxSYO2DuLzmalxcCBL0g+ZOiDAbmRCZOdU9YV5tmKsDiXs95WKnBhuDdVD0EC wTyyQLjZ7t/InQ6rS2eib9kk0uYUiuXBLBS9KrT4gGVGJ/oO8t/nLhueuz59rzxlNUDi 4esw== X-Gm-Message-State: ALoCoQlTeOBlcqDfyjItlfeHDgCp1ahKr3LBR/SS4d/N+b4HVsUI3MEf1/X3OQa4vnurg4y0Oc4L MIME-Version: 1.0 X-Received: by 10.180.206.52 with SMTP id ll20mr1205081wic.48.1444217432624; Wed, 07 Oct 2015 04:30:32 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Wed, 7 Oct 2015 04:30:32 -0700 (PDT) X-Originating-IP: [81.109.161.68] In-Reply-To: References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Wed, 7 Oct 2015 12:30:32 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 11:30:36 -0000 Should we state: A session MUST only come under the scope of one subsystem. From nobody Wed Oct 7 04:36:21 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC811B2E3D for ; Wed, 7 Oct 2015 04:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I22glUBQaC3W for ; Wed, 7 Oct 2015 04:36:18 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1971C1B2E3C for ; Wed, 7 Oct 2015 04:36:18 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so23816674wic.0 for ; Wed, 07 Oct 2015 04:36:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=c7/kojf8Up4GSAUPlbI3Pp+gsJojHWb1Vyb7K63npyI=; b=Dvyj3B9dTdUNlBm58ZvFD8Bi0s0XHv6p9na7OkA97P5m7mob79H397+cF7M61NuOXj qGwbRMmPv3X97StZec10e3sPqKlzcrbLBmMLRxbaaJFf1spscCy8eZV73RUHZL4CHEdJ bVcVvV/R8jOgEBfDEhZhPquI4u7HA/Mr5skP+9g0+BLzyqwMNBF/z6KJrSx6XbzJe9kM QnV1YD4OGWsXIPrIfXqyIyY57igvaM4bM+useXSVr4VJ6q8QIbIJ8Hj9FDxcRYtOAFpE mLvo3fgHj12safAJr5LcmqPZz7s2dTfs8sOq6d4Ld65YVS5cat76reub6EWudkP4wm3R bP+Q== X-Gm-Message-State: ALoCoQkJoPvruWKjALi0X37/wzHp+zyP4eL5gR0ZKF48D0h/4PG2ZG4+Z2opUooBlSdmeQbC1UCv MIME-Version: 1.0 X-Received: by 10.180.210.162 with SMTP id mv2mr1202908wic.47.1444217776547; Wed, 07 Oct 2015 04:36:16 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Wed, 7 Oct 2015 04:36:16 -0700 (PDT) X-Originating-IP: [81.109.161.68] In-Reply-To: References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Wed, 7 Oct 2015 12:36:16 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 11:36:20 -0000 I definitely think that that needs to be stated which brings me to: Reference to RFC 2866 ===================== Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting for the NAS (for example, upon booting) by specifying Accounting-On and to mark the end of accounting for the NAS (for example, just before a scheduled reboot) by specifying Accounting-Off. Where Accounting-On or Accounting-Off is specified, a Called-Station-Id attribute SHOULD NOT be present. In the case that one is present, the value MUST apply to the whole NAS. It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Where Subsystem-On or Subsystem-Off is specified, a Called-Station-Id attribute MUST be present. The subsystem is indicated by the value of the Called-Station-Id attribute. It MUST uniquely identify the subsystem to the NAS. It is strongly recommended that the value of the Called-Station-Id attribute that is used for a session SHOULD match the value of the Called-Station-Id that identifies the subsystem. The value of any Called-Station-Id attributes that are used in accounting types that are session specific SHOULD match the value used when Subsystem-On and Subsystem-Off are specified where they come under the scope of that subsystem. A session MUST only come under the scope of one subsystem. For IEEE 802.11, this attribute SHOULD be used to store the BSSID (upper case only) in ASCII format, with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where the SSID is known, it SHOULD be appended to the BSSID in UTF-8 format, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed ?? Subsystem-On ?? Subsystem-Off Acct-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to match start and stop records. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. It is strongly recommended that the Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >= 3 String The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters. Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to link together multiple related sessions. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD contain UTF-8 encoded 10646 [7] characters. Reference to RFC 3580 ===================== Acct-Multi-Session-Id The purpose of this attribute is to make it possible to link together multiple related sessions for IEEE 802.11. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Basic Service Sets or in failover accounting from one Controller to another to cause multiple RADIUS accounting packets to be sent by the same or different Access Points or Controllers. Where supported by the Access Points or the Controllers, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant or in failover accounting from one Controller to another. In such a situation, if the session context is transferred between Access Points or Controllers, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points or the Controllers as part of the Inter-Access Point Protocol (IAPP) or another handoff scheme. If the Acct-Multi-Session-Id were not globally unique between Access Points and Controllers, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point or Controller, and the Accounting Server would therefore be unable to distinguish a roaming or failover session from a multi-link session. In order to provide global uniqueness, it is suggested that the Acct-Multi-Session-Id be a UUID that offers inherent global and temporal uniqueness. An alternative construction for the Acct-Multi-Session-Id may be of the form: BSSID | Supplicant MAC Address | NTP Timestamp Here "|" represents concatenation, the BSSID is the MAC address of the BSS under which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming or failover sessions, the Acct-Multi-Session-Id may be moved between Access Points or Controllers as part of IAPP or another handoff scheme. The use of an Acct-Multi-Session-Id of this form should guarantee uniqueness among all Basic Service Sets, Access Points, Supplicants, Controllers and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point or Controller could choose an Acct-Multi-Session-Id that could be confused with that of a previous session once time synchronisation has occurred. The downside of this construction is that it is dependent on time synchronisation having occurred. For this reason, a UUID is preferred. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an UTF-8 string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8" Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge MAC address or IEEE 802.11 BSSID in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". For IEEE 802.11, where the SSID is known, it SHOULD be appended in UTF-8 format to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. From nobody Wed Oct 7 05:58:14 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5D1A1A20 for ; Wed, 7 Oct 2015 05:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdSHpDYTolCS for ; Wed, 7 Oct 2015 05:57:54 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9159F1A1A1E for ; Wed, 7 Oct 2015 05:57:54 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so27064400wic.0 for ; Wed, 07 Oct 2015 05:57:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=0nA8MsTGdUnqj2wKzzdE5n0AEKftLm/Aq0vrANHwu4U=; b=iW//mpE1kluDvKvjHnSh+qDEk3ZcWV4zp6GfasBj0EgbZ4z4x0I5ZyBCJFzPFh48Ja NMTzX0gYbNPRksGVELZR1Bnqb321sviCqeSbMPAVrZ76MAAKKb6EqsX+rr3qwXHW8LuF zBeMhpZixEYr2aXAlHkO9hMh7ivrH41Mv+u4S+FC1gRk9p0tcBbsDJHqhP4yMvf5Nc9U UHdaUt7bdNxHVbE/r5IvHnZIaWiTKt5kth1s5oxWA+rlZF5mwkYxpu6MREzObxV48VAy ZMay6puZ5F1xqy7zXQ0YdaynMKEh91IaZ9Mw2/i7JHPykInf53hnb7KEeaWzzOS+XJdQ VwoA== X-Gm-Message-State: ALoCoQlyqmQb9QBXI4jODTqpXg4bX5ay8/D1z3wichc+w86zWLSDI6LIfPQpDNH4XVWsyH/ltUjh MIME-Version: 1.0 X-Received: by 10.194.184.20 with SMTP id eq20mr1106007wjc.22.1444222672786; Wed, 07 Oct 2015 05:57:52 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Wed, 7 Oct 2015 05:57:52 -0700 (PDT) X-Originating-IP: [81.109.161.68] In-Reply-To: References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Wed, 7 Oct 2015 13:57:52 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 12:57:57 -0000 I strongly feel that the opportunity should be seized to specify transition behaviour between subsystems. Subsystem-on and Subsystem-off would be a new Acct-Status-Types so there are no compatibility constraints. I have added more to the description for Acct-Status-Type. Thoughts please! Sorry about all the emails! Reference to RFC 2866 ===================== Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting for the NAS (for example, upon booting) by specifying Accounting-On and to mark the end of accounting for the NAS (for example, just before a scheduled reboot) by specifying Accounting-Off. Where Accounting-On or Accounting-Off is specified, a Called-Station-Id attribute SHOULD NOT be present. In the case that one is present, the value MUST apply to the whole NAS. It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Where Subsystem-On or Subsystem-Off is specified, a Called-Station-Id attribute MUST be present. The subsystem is indicated by the value of the Called-Station-Id attribute. It MUST uniquely identify the subsystem to the NAS. It is strongly recommended that the value of the Called-Station-Id attribute that is used for a session SHOULD match the value of the Called-Station-Id that identifies the subsystem. The value of any Called-Station-Id attributes that are used in accounting types that are session specific SHOULD match the value used when Subsystem-On and Subsystem-Off are specified where they come under the scope of that subsystem. A session MUST only come under the scope of one subsystem. For IEEE 802.11, this attribute SHOULD be used to store the BSSID (upper case only) in ASCII format, with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where the SSID is known, it SHOULD be appended to the BSSID in UTF-8 format, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. Where transition occurs for user service from one one NAS to another, the original session SHOULD end with a Stop and a new session SHOULD begin with a Start. This is strongly recommended. An Acct-Multi-Session-Id SHOULD be present with the same value to link together related sessions. This is strongly recommended. Where transition occurs for user service from one one subsystem to another, the original session MUST end with a Stop and a new session MUST begin with a Start. An Acct-Multi-Session-Id MUST be present with the same value to link together related sessions. The Acct-Session-Id MUST be different for new sessions started when transition occurs. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed ?? Subsystem-On ?? Subsystem-Off Acct-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to match start and stop records. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. It is strongly recommended that the Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >= 3 String The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters. Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to link together multiple related sessions. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD contain UTF-8 encoded 10646 [7] characters. Reference to RFC 3580 ===================== Acct-Multi-Session-Id The purpose of this attribute is to make it possible to link together multiple related sessions for IEEE 802.11. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Basic Service Sets or in failover accounting from one Controller to another to cause multiple RADIUS accounting packets to be sent by the same or different Access Points or Controllers. Where supported by the Access Points or the Controllers, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant or in failover accounting from one Controller to another. In such a situation, if the session context is transferred between Access Points or Controllers, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points or the Controllers as part of the Inter-Access Point Protocol (IAPP) or another handoff scheme. If the Acct-Multi-Session-Id were not globally unique between Access Points and Controllers, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point or Controller, and the Accounting Server would therefore be unable to distinguish a roaming or failover session from a multi-link session. In order to provide global uniqueness, it is suggested that the Acct-Multi-Session-Id be a UUID that offers inherent global and temporal uniqueness. An alternative construction for the Acct-Multi-Session-Id may be of the form: BSSID | Supplicant MAC Address | NTP Timestamp Here "|" represents concatenation, the BSSID is the MAC address of the BSS under which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming or failover sessions, the Acct-Multi-Session-Id may be moved between Access Points or Controllers as part of IAPP or another handoff scheme. The use of an Acct-Multi-Session-Id of this form should guarantee uniqueness among all Basic Service Sets, Access Points, Supplicants, Controllers and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point or Controller could choose an Acct-Multi-Session-Id that could be confused with that of a previous session once time synchronisation has occurred. The downside of this construction is that it is dependent on time synchronisation having occurred. For this reason, a UUID is preferred. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an UTF-8 string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8" Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge MAC address or IEEE 802.11 BSSID in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". For IEEE 802.11, where the SSID is known, it SHOULD be appended in UTF-8 format to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. From nobody Wed Oct 7 06:34:56 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E458B1A8A3B for ; Wed, 7 Oct 2015 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjiSUpOjrgIu for ; Wed, 7 Oct 2015 06:34:33 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2F21A89FA for ; Wed, 7 Oct 2015 06:34:32 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so211725358wic.1 for ; Wed, 07 Oct 2015 06:34:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=AZu57xtqqeHDxx8FCvYQOdhd4bKrrsJpj6vaRE4mumI=; b=LSXgpCx9DmhIGPwVExYo9eI/RG2CGo0SptYB/6USsKVPo8errsgX7qQ3V9JZ/6ECOn /jOavXQrdlJzmxODPKD8yK4QVcYGzSbC1a9JkHTn9xZfJqvFYaeusLvZFeXLGIGTAeBW ih49DgySb6/n04Z0BgR6pcnceynSpc1jU0IAgsq2aPyn0esWfVQNtpn/odr7cn1P0a/i 4Ifpoc7lZ7BJuWfvazu4Q/NZo1s7w/hHiSZB+cqgsfPaw86Ys5LV5H0rV2+Z1a11tVHK H+Rqw5A3FjwWqKQtDNdRx1OhbiOeLtLYjb/4e4kVz4UVwlA8k2/V/6jkKIr+kHny3ai+ tiqQ== X-Gm-Message-State: ALoCoQmcOpf9AHD34WIeCazyYWnqh9QZdYYqqaNG4Kv6Y+G0OHmwukv89v8sHVvReEVYoXgvjDDz MIME-Version: 1.0 X-Received: by 10.180.88.168 with SMTP id bh8mr21900667wib.48.1444224870910; Wed, 07 Oct 2015 06:34:30 -0700 (PDT) Received: by 10.28.49.11 with HTTP; Wed, 7 Oct 2015 06:34:30 -0700 (PDT) X-Originating-IP: [81.109.161.68] In-Reply-To: References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> Date: Wed, 7 Oct 2015 14:34:30 +0100 Message-ID: From: Nick Lowe To: radext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 13:34:36 -0000 Reference to RFC 2866 ===================== Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting for the NAS (for example, upon booting) by specifying Accounting-On and to mark the end of accounting for the NAS (for example, just before a scheduled reboot) by specifying Accounting-Off. Where Accounting-On or Accounting-Off is specified, a Called-Station-Id attribute SHOULD NOT be present. In the case that one is present, the value MUST apply to the whole NAS. It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Where Subsystem-On or Subsystem-Off is specified, a Called-Station-Id attribute MUST be present. The subsystem is indicated by the value of the Called-Station-Id attribute. It MUST uniquely identify the subsystem to the NAS. It is strongly recommended that the value of the Called-Station-Id attribute that is used for a session SHOULD match the value of the Called-Station-Id that identifies the subsystem. The value of any Called-Station-Id attributes that are used in accounting types that are session specific SHOULD match the value used when Subsystem-On and Subsystem-Off are specified where they come under the scope of that subsystem. A session MUST only come under the scope of one subsystem. For IEEE 802.11, this attribute SHOULD be used to store the BSSID (upper case only) in ASCII format, with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where the SSID is known, it SHOULD be appended to the BSSID in UTF-8 format, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. Where transition occurs for user service from one one NAS to another, the preceding session SHOULD end with a Stop and a new session SHOULD begin with a Start. This is strongly recommended. An Acct-Multi-Session-Id SHOULD be present with the same value to link together related sessions. This is strongly recommended. Where transition occurs for user service from one one subsystem to another, the preceding session MUST end with a Stop and a new session MUST begin with a Start. An Acct-Multi-Session-Id MUST be present with the same value to link together related sessions. The Acct-Session-Id MUST be different for new sessions started when transition occurs. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed ?? Subsystem-On ?? Subsystem-Off Acct-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to match start and stop records. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. It is strongly recommended that the Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >= 3 String The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters. Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to link together multiple related sessions. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD contain UTF-8 encoded 10646 [7] characters. Reference to RFC 3580 ===================== Acct-Multi-Session-Id The purpose of this attribute is to make it possible to link together multiple related sessions for IEEE 802.11. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Basic Service Sets or in failover accounting from one Controller to another to cause multiple RADIUS accounting packets to be sent by the same or different Access Points or Controllers. Where supported by the Access Points or the Controllers, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant or in failover accounting from one Controller to another. In such a situation, if the session context is transferred between Access Points or Controllers, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points or the Controllers as part of the Inter-Access Point Protocol (IAPP) or another handoff scheme. If the Acct-Multi-Session-Id were not globally unique between Access Points and Controllers, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point or Controller, and the Accounting Server would therefore be unable to distinguish a roaming or failover session from a multi-link session. In order to provide global uniqueness, it is suggested that the Acct-Multi-Session-Id be a UUID that offers inherent global and temporal uniqueness. An alternative construction for the Acct-Multi-Session-Id may be of the form: BSSID | Supplicant MAC Address | NTP Timestamp Here "|" represents concatenation, the BSSID is the MAC address of the BSS under which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming or failover sessions, the Acct-Multi-Session-Id may be moved between Access Points or Controllers as part of IAPP or another handoff scheme. The use of an Acct-Multi-Session-Id of this form should guarantee uniqueness among all Basic Service Sets, Access Points, Supplicants, Controllers and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point or Controller could choose an Acct-Multi-Session-Id that could be confused with that of a previous session once time synchronisation has occurred. The downside of this construction is that it is dependent on time synchronisation having occurred. For this reason, a UUID is preferred. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an UTF-8 string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8" Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge MAC address or IEEE 802.11 BSSID in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". For IEEE 802.11, where the SSID is known, it SHOULD be appended in UTF-8 format to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. From nobody Wed Oct 7 07:17:07 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37251A92B0 for ; Wed, 7 Oct 2015 07:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR02EPB-R5Vy for ; Wed, 7 Oct 2015 07:16:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A211A92AB for ; Wed, 7 Oct 2015 07:16:53 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 01AFB324310; Wed, 7 Oct 2015 16:16:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C08EF35C11F; Wed, 7 Oct 2015 16:16:51 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 16:16:51 +0200 From: To: Alan DeKok , Kathleen Moriarty Thread-Topic: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? Thread-Index: AQHRAEpvw2R6DEACeU2fOTTJWgq+K55eddcAgAAMSoCAAC+yAIABWvPg Date: Wed, 7 Oct 2015 14:16:50 +0000 Message-ID: <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> <451E43F5-44DF-4651-8372-49BC90DFEC5A@deployingradius.com> In-Reply-To: <451E43F5-44DF-4651-8372-49BC90DFEC5A@deployingradius.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.7.131518 Archived-At: Cc: Nick Lowe , "radext@ietf.org" Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 14:16:56 -0000 This document was published as Informational RFC through ISE process, so wi= thout WG consensus, even if key IETF participants were involved in this wor= k. Obviously, it does not prevent RADEXT to work on a new version of this docu= ment. However, before rushing for publishing a bis-version of this document= , it would be good to know what would be the purpose of this new document. The initial aim was to have non-normative text describing how to use RADIUS= with 802.1X, and this material was put in an information RFC as well as in= a non-normative appendix in IEEE specification.=20 I know that some cleanup/updates/clarifications are required for this docum= ent. But to be really useful, it could be interesting to know whether IEEE= would be happy to endorse/reference the new version of the RFC, especially= if some proposed changes have impacts on existing RADIUS implementation. J= ust to ensure that the proposed modifications/clarifications put in a bis-v= ersion will be followed by IEEE community. And also, what should be the status of this document: Standard track/Inform= ational? Now, if the work is agreed, the proposed changes straightforward and there = is no contentious discussions, I don't see why a 3-year period would be req= uired to publish a new version. It will depend on the amount and type of ch= ange. Regards, Lionel -----Message d'origine----- De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Alan DeKok Envoy=E9=A0: mardi 6 octobre 2015 21:06 =C0=A0: Kathleen Moriarty Cc=A0: Nick Lowe; radext@ietf.org Objet=A0: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? On Oct 6, 2015, at 12:14 PM, Kathleen Moriarty wrote: >> If the document is simple and has no objections... it might take 3 year= s to get published as an RFC. >=20 > Is this a result of the workload of Radext, editors, or process=20 > problems? If it's process problems, let's fix that as I don' want to=20 > see drafts taking 3 years to publish. If it is workload and priorities=20 > for the WG, that is another matter (we can look at that as well). It's been the process for as long as I've been involved in RADEXT. Call = it 10+ years? Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 7 07:51:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755321A90DA for ; Wed, 7 Oct 2015 07:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgunou1rJ7QW for ; Wed, 7 Oct 2015 07:50:57 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53C911A9150 for ; Wed, 7 Oct 2015 07:50:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 4249022406F2; Wed, 7 Oct 2015 16:50:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sntBIAtXDXNK; Wed, 7 Oct 2015 16:50:25 +0200 (CEST) Received: from [192.168.20.14] (65-110-217-180.cpe.pppoe.ca [65.110.217.180]) by power.freeradius.org (Postfix) with ESMTPSA id 64D392240451; Wed, 7 Oct 2015 16:50:25 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Wed, 7 Oct 2015 10:50:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <050EA58C-6BF9-4DC0-AFFC-FAC9285B039A@deployingradius.com> References: <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> <451E43F5-44DF-4651-8372-49BC90DFEC5A@deployingradius.com> <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3094) Archived-At: Cc: Nick Lowe , "radext@ietf.org" , Kathleen Moriarty Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 14:50:59 -0000 On Oct 7, 2015, at 10:16 AM, = wrote: > Obviously, it does not prevent RADEXT to work on a new version of this = document. However, before rushing for publishing a bis-version of this = document, it would be good to know what would be the purpose of this new = document. To bring the standards up to date with current requirements, and with = current use-cases. To address ambiguities in the current = specifications. To clarify best practices. =20 > The initial aim was to have non-normative text describing how to use = RADIUS with 802.1X, and this material was put in an information RFC as = well as in a non-normative appendix in IEEE specification.=20 >=20 > I know that some cleanup/updates/clarifications are required for this = document. But to be really useful, it could be interesting to know = whether IEEE would be happy to endorse/reference the new version of the = RFC, especially if some proposed changes have impacts on existing RADIUS = implementation. Just to ensure that the proposed = modifications/clarifications put in a bis-version will be followed by = IEEE community. I agree. > And also, what should be the status of this document: Standard = track/Informational? Probably the same as RFC 3580, informational. > Now, if the work is agreed, the proposed changes straightforward and = there is no contentious discussions, I don't see why a 3-year period = would be required to publish a new version. It will depend on the amount = and type of change. I agree. I'll work with Nick to come up with an I-D. I won't be in = Yokohama, but I can do a remote presentation. Alan DeKok. From nobody Wed Oct 7 08:51:47 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9991AC444 for ; Wed, 7 Oct 2015 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3ZIb2XBmYWP for ; Wed, 7 Oct 2015 08:51:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AE31AC82C for ; Wed, 7 Oct 2015 08:51:24 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 55CCEC0C49; Wed, 7 Oct 2015 17:51:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.10]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 353E9180099; Wed, 7 Oct 2015 17:51:23 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 17:51:22 +0200 From: To: Nick Lowe , "radext@ietf.org" Thread-Topic: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off Thread-Index: AQHRAQT2hZ5yERvIgU6k6HFR0fbft55gKVpw Date: Wed, 7 Oct 2015 15:51:22 +0000 Message-ID: <7190_1444233083_56153F7B_7190_15631_1_6B7134B31289DC4FAF731D844122B36E01D3D95B@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.7.141516 Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 15:51:28 -0000 Hi Nick, To make the life easier for people not involved in previous (offline) discu= ssions and receive feedback from RADEXT members, it would be better to: - have a separate email thread per proposed change, one for each attribute - provide a short summary of the issue triggering the proposed change - highlight the proposed changes (e.g. OLD/NEW) Moreover, I have 2 short general comments: - The proposed changes introduce the concept of " subsystem of NAS" that is= not defined, nor in RFC2865/2865, nor in the proposed changes. It should b= e introduced somewhere. It would be then easier to understand the relations= hip between Called-Station-Id and NAS/subsystem as well as the proposed new= values for Acct-Status-Type. - For sake of clarity, it would be maybe easier to make the distinction bet= ween the definition of the attribute and how this attribute should be used = depending on the context (with/without another attribute, etc.) - It should be considered if everything related to session management could= be captured in a separate section. Regards, Lionel -----Message d'origine----- De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Nick Lowe Envoy=E9=A0: mercredi 7 octobre 2015 15:35 =C0=A0: radext@ietf.org Objet=A0: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Sess= ion-Id, Accounting-On/Off and Subsystem-On/Off Reference to RFC 2866 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting for the NAS (for example, upon booting) by specifying Accounting-On and to mark the end of accounting for the NAS (for example, just before a scheduled reboot) by specifying Accounting-Off. Where Accounting-On or Accounting-Off is specified, a Called-Station-Id attribute SHOULD NOT be present. In the case that one is present, the value MUST apply to the whole NAS. It MAY be used by the client to mark the start of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS becomes available) by specifying Subsystem-On and to mark the end of accounting for a subsystem of the NAS (for example, when an IEEE 802.11 BSS is no longer available) by specifying Subsystem-Off. Where Subsystem-On or Subsystem-Off is specified, a Called-Station-Id attribute MUST be present. The subsystem is indicated by the value of the Called-Station-Id attribute. It MUST uniquely identify the subsystem to the NAS. It is strongly recommended that the value of the Called-Station-Id attribute that is used for a session SHOULD match the value of the Called-Station-Id that identifies the subsystem. The value of any Called-Station-Id attributes that are used in accounting types that are session specific SHOULD match the value used when Subsystem-On and Subsystem-Off are specified where they come under the scope of that subsystem. A session MUST only come under the scope of one subsystem. For IEEE 802.11, this attribute SHOULD be used to store the BSSID (upper case only) in ASCII format, with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where the SSID is known, it SHOULD be appended to the BSSID in UTF-8 format, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. Where transition occurs for user service from one one NAS to another, the preceding session SHOULD end with a Stop and a new session SHOULD begin with a Start. This is strongly recommended. An Acct-Multi-Session-Id SHOULD be present with the same value to link together related sessions. This is strongly recommended. Where transition occurs for user service from one one subsystem to another, the preceding session MUST end with a Stop and a new session MUST begin with a Start. An Acct-Multi-Session-Id MUST be present with the same value to link together related sessions. The Acct-Session-Id MUST be different for new sessions started when transition occurs. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed ?? Subsystem-On ?? Subsystem-Off Acct-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to match start and stop records. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. It is strongly recommended that the Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >=3D 3 String The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters. Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it possible to link together multiple related sessions. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. It MUST exhibit global and temporal uniqueness. For example, an implementation may use a string with a UUID. Other encodings are possible. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >=3D 3 String The String field SHOULD contain UTF-8 encoded 10646 [7] characters. Reference to RFC 3580 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Acct-Multi-Session-Id The purpose of this attribute is to make it possible to link together multiple related sessions for IEEE 802.11. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Basic Service Sets or in failover accounting from one Controller to another to cause multiple RADIUS accounting packets to be sent by the same or different Access Points or Controllers. Where supported by the Access Points or the Controllers, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant or in failover accounting from one Controller to another. In such a situation, if the session context is transferred between Access Points or Controllers, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points or the Controllers as part of the Inter-Access Point Protocol (IAPP) or another handoff scheme. If the Acct-Multi-Session-Id were not globally unique between Access Points and Controllers, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point or Controller, and the Accounting Server would therefore be unable to distinguish a roaming or failover session from a multi-link session. In order to provide global uniqueness, it is suggested that the Acct-Multi-Session-Id be a UUID that offers inherent global and temporal uniqueness. An alternative construction for the Acct-Multi-Session-Id may be of the form: BSSID | Supplicant MAC Address | NTP Timestamp Here "|" represents concatenation, the BSSID is the MAC address of the BSS under which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming or failover sessions, the Acct-Multi-Session-Id may be moved between Access Points or Controllers as part of IAPP or another handoff scheme. The use of an Acct-Multi-Session-Id of this form should guarantee uniqueness among all Basic Service Sets, Access Points, Supplicants, Controllers and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point or Controller could choose an Acct-Multi-Session-Id that could be confused with that of a previous session once time synchronisation has occurred. The downside of this construction is that it is dependent on time synchronisation having occurred. For this reason, a UUID is preferred. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an UTF-8 string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8" Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge MAC address or IEEE 802.11 BSSID in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". For IEEE 802.11, where the SSID is known, it SHOULD be appended in UTF-8 format to the BSSID, separated from the BSSID with a ":". Example "00-10-A4-23-19-C0:AP1". As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST be UTF-8 encoded. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 8 06:05:27 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E771B3380 for ; Thu, 8 Oct 2015 06:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6h3Be2RDvhuO for ; Thu, 8 Oct 2015 06:05:22 -0700 (PDT) Received: from BLU004-OMC1S33.hotmail.com (blu004-omc1s33.hotmail.com [65.55.116.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AAA1B3379 for ; Thu, 8 Oct 2015 06:05:21 -0700 (PDT) Received: from BLU181-W75 ([65.55.116.8]) by BLU004-OMC1S33.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 8 Oct 2015 06:05:21 -0700 X-TMN: [omguUIrmVyqIUz0Q7FDQwamb0ddqb5gL] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_0c7cdac1-ea52-4fb9-bb13-c9a4abd6561c_" From: Bernard Aboba To: "lionel.morand@orange.com" , Alan DeKok , Kathleen Moriarty Date: Thu, 8 Oct 2015 06:05:20 -0700 Importance: Normal In-Reply-To: <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: , <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com>, , <451E43F5-44DF-4651-8372-49BC90DFEC5A@deployingradius.com>, <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Oct 2015 13:05:21.0708 (UTC) FILETIME=[FD1D86C0:01D101C9] Archived-At: Cc: Nick Lowe , "radext@ietf.org" Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 13:05:25 -0000 --_0c7cdac1-ea52-4fb9-bb13-c9a4abd6561c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So far=2C the issues discussed relate to accounting=2C which is a relativel= y minor aspect of RFC 3580. =20 Furthermore=2C the accounting issues relate largely to IEEE 802.11=2C rathe= r than to IEEE 802.1X=2C which was the focus of RFC 3580.=20 As a result=2C it is not at all clear to me why it is necessary to transfer= control of this document from IEEE 802 to the IETF=2C let alone why it is = necessary to revise it at all.=20 If there is a desire to deal with accounting issues relating to IEEE 802.11= =2C why not create a new document focused on that topic=2C with review by I= EEE 802.11? If necessary=2C it can update RFC 3580.=20 = --_0c7cdac1-ea52-4fb9-bb13-c9a4abd6561c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So far=2C the issues discussed r= elate to accounting=2C which is a relatively minor aspect of RFC 3580. &nbs= p=3B

Furthermore=2C the accounting issues relate largely= to IEEE 802.11=2C rather than to IEEE 802.1X=2C which was the focus of RFC= 3580. =3B

As a result=2C it is not at all cle= ar to me why it is necessary to transfer control of this document from IEEE= 802 to the IETF=2C let alone why it is necessary to revise it at all. = =3B

If there is a desire to deal with accounting i= ssues relating to IEEE 802.11=2C why not create a new document focused on t= hat topic=2C with review by IEEE 802.11?  =3BIf necessary=2C it can upd= ate RFC 3580. =3B






= --_0c7cdac1-ea52-4fb9-bb13-c9a4abd6561c_-- From nobody Thu Oct 8 06:17:28 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7111B33A0 for ; Thu, 8 Oct 2015 06:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZebzoOCmJ3rX for ; Thu, 8 Oct 2015 06:17:22 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6701B3386 for ; Thu, 8 Oct 2015 06:17:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id AB15B2240490; Thu, 8 Oct 2015 15:17:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbl1bHEq_lPX; Thu, 8 Oct 2015 15:17:21 +0200 (CEST) Received: from [192.168.120.41] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by power.freeradius.org (Postfix) with ESMTPSA id AAAF422403A5; Thu, 8 Oct 2015 15:17:20 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: Date: Thu, 8 Oct 2015 09:17:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <802DC895-A379-46C9-87F4-96AF6A99B3A0@deployingradius.com> References: <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> <451E43F5-44DF-4651-8372-49BC90DFEC5A@deployingradius.com> <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: Aboba Bernard X-Mailer: Apple Mail (2.3094) Archived-At: Cc: Nick Lowe , "radext@ietf.org" , Kathleen Moriarty , "lionel.morand@orange.com" Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 13:17:27 -0000 On Oct 8, 2015, at 9:05 AM, Bernard Aboba = wrote: >=20 > So far, the issues discussed relate to accounting, which is a = relatively minor aspect of RFC 3580. =20 Which is good. > Furthermore, the accounting issues relate largely to IEEE 802.11, = rather than to IEEE 802.1X, which was the focus of RFC 3580.=20 Which is also goo. > As a result, it is not at all clear to me why it is necessary to = transfer control of this document from IEEE 802 to the IETF, That's not the purpose of the discussion. > let alone why it is necessary to revise it at all.=20 The revisions were motivated from seeing inter-operability problems, = and implementation problems. The existing RFCs discuss user sessions, = but the concept is vague and ill defined. The guidelines for how a NAS = / server should handle user sessions are similarly vague. This vagueness causes real-world problems. I run into this pretty = much every week. > If there is a desire to deal with accounting issues relating to IEEE = 802.11, why not create a new document focused on that topic, with review = by IEEE 802.11? If necessary, it can update RFC 3580.=20 That is the best approach, I think. Alan DeKok. From nobody Thu Oct 8 07:36:03 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC6C1A1A20 for ; Thu, 8 Oct 2015 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id4pFmRptG2Z for ; Thu, 8 Oct 2015 07:36:00 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE5A1A1A1B for ; Thu, 8 Oct 2015 07:36:00 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so31430045wic.1 for ; Thu, 08 Oct 2015 07:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CnfHhgyiy6cNZmL+f1ZX/SWQnvVvn6g1CWqHjpOVqv4=; b=ttsF1RHbT+ZD/zfzIMeF0yk01rNYTeaLqxWn8THk3BGq/GKRivtkGg5KtsbJ+47KvX YmptBnfhOeirRWfBsKvxLxpdzOmpyfYYQcRdV5HPxtpPDSE5MlmIFfrwO8UsBP+daBYO bIZiJjAa9jFTFtlJNiWXJOtU37I9OekU/7d+HzI8cuwk+E7trw+khCyzYwJsHG+nB8M0 +ZVLjOTOeRDdAobPfXD9irCjnovw6xaV6llZaotldxUiDCDH5jyVqAwx+0jsSB7EZlSh ufXsidpUGRm8Zvx5DNxstIH3FsVCZYQqiiA8wHTHIuR2Dm0mYRXN4H6gofiqw5pU/Izy 3SJQ== MIME-Version: 1.0 X-Received: by 10.180.23.72 with SMTP id k8mr4309410wif.90.1444314958717; Thu, 08 Oct 2015 07:35:58 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Thu, 8 Oct 2015 07:35:58 -0700 (PDT) In-Reply-To: <802DC895-A379-46C9-87F4-96AF6A99B3A0@deployingradius.com> References: <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> <451E43F5-44DF-4651-8372-49BC90DFEC5A@deployingradius.com> <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup> <802DC895-A379-46C9-87F4-96AF6A99B3A0@deployingradius.com> Date: Thu, 8 Oct 2015 10:35:58 -0400 Message-ID: From: Kathleen Moriarty To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Aboba Bernard , Nick Lowe , "lionel.morand@orange.com" , "radext@ietf.org" Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 14:36:02 -0000 If the IETF does not have change control, which is the case with some documents, we can't just pick it up and change/update the document. Let's figure out if something is needed and then we'll figure out what we can do or what needs to be done in the IEEE. Thanks, Kathleen On Thu, Oct 8, 2015 at 9:17 AM, Alan DeKok wrot= e: > On Oct 8, 2015, at 9:05 AM, Bernard Aboba wro= te: >> >> So far, the issues discussed relate to accounting, which is a relatively= minor aspect of RFC 3580. > > Which is good. > >> Furthermore, the accounting issues relate largely to IEEE 802.11, rather= than to IEEE 802.1X, which was the focus of RFC 3580. > > Which is also goo. > >> As a result, it is not at all clear to me why it is necessary to transfe= r control of this document from IEEE 802 to the IETF, > > That's not the purpose of the discussion. > >> let alone why it is necessary to revise it at all. > > The revisions were motivated from seeing inter-operability problems, an= d implementation problems. The existing RFCs discuss user sessions, but th= e concept is vague and ill defined. The guidelines for how a NAS / server = should handle user sessions are similarly vague. > > This vagueness causes real-world problems. I run into this pretty much= every week. > >> If there is a desire to deal with accounting issues relating to IEEE 802= .11, why not create a new document focused on that topic, with review by IE= EE 802.11? If necessary, it can update RFC 3580. > > That is the best approach, I think. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Best regards, Kathleen From nobody Tue Oct 13 11:43:36 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1051A8754 for ; Tue, 13 Oct 2015 11:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woEypPe5TL3V for ; Tue, 13 Oct 2015 11:43:24 -0700 (PDT) Received: from BLU004-OMC1S30.hotmail.com (blu004-omc1s30.hotmail.com [65.55.116.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60681A6F05 for ; Tue, 13 Oct 2015 11:40:09 -0700 (PDT) Received: from BLU181-W43 ([65.55.116.8]) by BLU004-OMC1S30.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 13 Oct 2015 11:40:08 -0700 X-TMN: [KCn7MXC1KzVIqie1h3h0D4vrwaQR426r] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b15bf432-a63e-4ac0-a0c4-7f6c43719872_" From: Bernard Aboba To: "lionel.morand@orange.com" , Nick Lowe , "radext@ietf.org" Date: Tue, 13 Oct 2015 11:40:08 -0700 Importance: Normal In-Reply-To: <7190_1444233083_56153F7B_7190_15631_1_6B7134B31289DC4FAF731D844122B36E01D3D95B@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: , <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com>, , , , , , , , , , , , <7190_1444233083_56153F7B_7190_15631_1_6B7134B31289DC4FAF731D844122B36E01D3D95B@OPEXCLILM43.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2015 18:40:08.0854 (UTC) FILETIME=[960D8360:01D105E6] Archived-At: Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 18:43:32 -0000 --_b15bf432-a63e-4ac0-a0c4-7f6c43719872_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would also like to distinguish extensions to RFC 2866 (such as Accounting= -On/Off) from revisions to RFC 2866.=20 Assignment of new RADIUS op-codes requires Standards Action=2C so this cann= ot be done in an Informational RFC. =20 Also=2C since RADIUS accounting is 20+ years old=2C revisions need to be ba= ckward compatible.=20 > From: lionel.morand@orange.com > To: nick.lowe@lugatech.com=3B radext@ietf.org > Date: Wed=2C 7 Oct 2015 15:51:22 +0000 > Subject: Re: [radext] Feedback solicited: Acct-Session-Id=2C Acct-Multi-S= ession-Id=2C Accounting-On/Off and Subsystem-On/Off >=20 > Hi Nick=2C >=20 > To make the life easier for people not involved in previous (offline) dis= cussions and receive feedback from RADEXT members=2C it would be better to: > - have a separate email thread per proposed change=2C one for each attrib= ute > - provide a short summary of the issue triggering the proposed change > - highlight the proposed changes (e.g. OLD/NEW) >=20 > Moreover=2C I have 2 short general comments: >=20 > - The proposed changes introduce the concept of " subsystem of NAS" that = is not defined=2C nor in RFC2865/2865=2C nor in the proposed changes. It sh= ould be introduced somewhere. It would be then easier to understand the rel= ationship between Called-Station-Id and NAS/subsystem as well as the propos= ed new values for Acct-Status-Type. >=20 > - For sake of clarity=2C it would be maybe easier to make the distinction= between the definition of the attribute and how this attribute should be u= sed depending on the context (with/without another attribute=2C etc.) >=20 > - It should be considered if everything related to session management cou= ld be captured in a separate section. >=20 > Regards=2C >=20 > Lionel >=20 > -----Message d'origine----- > De : radext [mailto:radext-bounces@ietf.org] De la part de Nick Lowe > Envoy=E9 : mercredi 7 octobre 2015 15:35 > =C0 : radext@ietf.org > Objet : Re: [radext] Feedback solicited: Acct-Session-Id=2C Acct-Multi-Se= ssion-Id=2C Accounting-On/Off and Subsystem-On/Off >=20 > Reference to RFC 2866 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Acct-Status-Type >=20 > Description >=20 > This attribute indicates whether this Accounting-Request marks > the beginning of the user service (Start) or the end (Stop). >=20 > It MAY be used by the client to mark the start of accounting for > the NAS (for example=2C upon booting) by specifying Accounting-On > and to mark the end of accounting for the NAS (for example=2C just > before a scheduled reboot) by specifying Accounting-Off. >=20 > Where Accounting-On or Accounting-Off is specified=2C a > Called-Station-Id attribute SHOULD NOT be present. In the case > that one is present=2C the value MUST apply to the whole NAS. >=20 > It MAY be used by the client to mark the start of accounting for a > subsystem of the NAS (for example=2C when an IEEE 802.11 BSS become= s > available) by specifying Subsystem-On and to mark the end of > accounting for a subsystem of the NAS (for example=2C when an IEEE > 802.11 BSS is no longer available) by specifying Subsystem-Off. >=20 > Where Subsystem-On or Subsystem-Off is specified=2C a > Called-Station-Id attribute MUST be present. The subsystem is > indicated by the value of the Called-Station-Id attribute. It > MUST uniquely identify the subsystem to the NAS. >=20 > It is strongly recommended that the value of the Called-Station-Id > attribute that is used for a session SHOULD match the value of the > Called-Station-Id that identifies the subsystem. >=20 > The value of any Called-Station-Id attributes that are used in > accounting types that are session specific SHOULD match the value > used when Subsystem-On and Subsystem-Off are specified where they > come under the scope of that subsystem. >=20 > A session MUST only come under the scope of one subsystem. >=20 > For IEEE 802.11=2C this attribute SHOULD be used to store the > BSSID (upper case only) in ASCII format=2C with octet values > separated by a "-". > Example: "00-10-A4-23-19-C0". > Where the SSID is known=2C it SHOULD be appended to the BSSID in > UTF-8 format=2C separated from the BSSID with a ":". > Example "00-10-A4-23-19-C0:AP1". >=20 > As IEEE 802.11 allows that SSIDs may be UTF-8 encoded=2C the SSID > MUST be UTF-8 encoded. >=20 > Where transition occurs for user service from one one NAS to > another=2C the preceding session SHOULD end with a Stop and a new > session SHOULD begin with a Start. This is strongly recommended. > An Acct-Multi-Session-Id SHOULD be present with the same value to > link together related sessions. This is strongly recommended. >=20 > Where transition occurs for user service from one one subsystem to > another=2C the preceding session MUST end with a Stop and a new > session MUST begin with a Start. An Acct-Multi-Session-Id MUST be > present with the same value to link together related sessions. >=20 > The Acct-Session-Id MUST be different for new sessions started > when transition occurs. >=20 > A summary of the Acct-Status-Type attribute format is shown below. > The fields are transmitted from left to right. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Value > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Value (cont) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Type >=20 > 40 for Acct-Status-Type. >=20 > Length >=20 > 6 >=20 > Value >=20 > The Value field is four octets. >=20 > 1 Start > 2 Stop > 3 Interim-Update > 7 Accounting-On > 8 Accounting-Off > 9-14 Reserved for Tunnel Accounting > 15 Reserved for Failed > ?? Subsystem-On > ?? Subsystem-Off >=20 > Acct-Session-Id >=20 > Description >=20 > This attribute is a globally unique Accounting ID to make it > possible to match start and stop records. The start and stop > records for a given session MUST have the same Acct-Session-Id. > An Accounting-Request packet MUST have an Acct-Session-Id. > An Access-Request packet MAY have an Acct-Session-Id=3B if it does= =2C > then the NAS MUST use the same Acct-Session-Id in the > Accounting-Request packets for that session. >=20 > It is strongly recommended that the Acct-Session-Id SHOULD contain > UTF-8 encoded 10646 [7] characters. It MUST exhibit global and > temporal uniqueness. >=20 > For example=2C an implementation may use a string with a UUID. > Other encodings are possible. >=20 > A summary of the Acct-Session-Id attribute format is shown below. > The fields are transmitted from left to right. >=20 > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Text ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Type >=20 > 44 for Acct-Session-Id. >=20 > Length >=20 > >=3D 3 >=20 > String >=20 > The String field SHOULD be a string of UTF-8 encoded 10646 [7] > characters. >=20 > Acct-Multi-Session-Id >=20 > Description >=20 > This attribute is a globally unique Accounting ID to make it > possible to link together multiple related sessions. Each session > linked together would have a globally unique Acct-Session-Id but > the same Acct-Multi-Session-Id. >=20 > It is strongly recommended that the Acct-Multi-Session-Id SHOULD > contain UTF-8 encoded 10646 [7] characters. It MUST exhibit > global and temporal uniqueness. >=20 > For example=2C an implementation may use a string with a UUID. > Other encodings are possible. >=20 > A summary of the Acct-Session-Id attribute format is shown below. > The fields are transmitted from left to right. >=20 > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Type >=20 > 50 for Acct-Multi-Session-Id. > Length >=20 > >=3D 3 >=20 > String >=20 > The String field SHOULD contain UTF-8 encoded 10646 [7] characters. >=20 >=20 > Reference to RFC 3580 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Acct-Multi-Session-Id >=20 > The purpose of this attribute is to make it possible to link together > multiple related sessions for IEEE 802.11. While [IEEE8021X] does > not act on aggregated ports=2C it is possible for a Supplicant roaming > between Basic Service Sets or in failover accounting from one > Controller to another to cause multiple RADIUS accounting packets to > be sent by the same or different Access Points or Controllers. >=20 > Where supported by the Access Points or the Controllers=2C the > Acct-Multi-Session-Id attribute can be used to link together the > multiple related sessions of a roaming Supplicant or in failover > accounting from one Controller to another. In such a situation=2C if > the session context is transferred between Access Points or > Controllers=2C accounting packets MAY be sent without a corresponding > authentication and authorization exchange=2C provided that Association > has occurred. However=2C in such a situation it is assumed that the > Acct-Multi-Session-Id is transferred between the Access Points or the > Controllers as part of the Inter-Access Point Protocol (IAPP) or > another handoff scheme. >=20 > If the Acct-Multi-Session-Id were not globally unique between Access > Points and Controllers=2C then it is possible that the chosen > Acct-Multi-Session-Id will overlap with an existing value allocated > on that Access Point or Controller=2C and the Accounting Server would > therefore be unable to distinguish a roaming or failover session > from a multi-link session. >=20 > In order to provide global uniqueness=2C it is suggested that the > Acct-Multi-Session-Id be a UUID that offers inherent global and > temporal uniqueness. >=20 > An alternative construction for the Acct-Multi-Session-Id may be of > the form: >=20 > BSSID | Supplicant MAC Address | NTP Timestamp >=20 > Here "|" represents concatenation=2C the BSSID is the MAC address of > the BSS under which the session started=2C and the 64-bit NTP timestam= p > indicates the beginning of the original session. In order to provide > for consistency of the Acct-Multi-Session-Id between roaming or > failover sessions=2C the Acct-Multi-Session-Id may be moved between > Access Points or Controllers as part of IAPP or another handoff > scheme. >=20 > The use of an Acct-Multi-Session-Id of this form should guarantee > uniqueness among all Basic Service Sets=2C Access Points=2C Supplicant= s=2C > Controllers and sessions. Since the NTP timestamp does not wrap on > reboot=2C there is no possibility that a rebooted Access Point or > Controller could choose an Acct-Multi-Session-Id that could be > confused with that of a previous session once time synchronisation > has occurred. The downside of this construction is that it is > dependent on time synchronisation having occurred. For this reason=2C > a UUID is preferred. >=20 > Since the Acct-Multi-Session-Id is of type String as defined in > [RFC2866]=2C for use with IEEE 802.1X=2C it is encoded as an UTF-8 str= ing > of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- > 14-23-DE-AF-23-83-C0-76-B8-44-E8" >=20 > Called-Station-Id >=20 > For IEEE 802.1X Authenticators=2C this attribute is used to store the > bridge MAC address or IEEE 802.11 BSSID in ASCII format (upper case > only)=2C with octet values separated by a "-". > Example: "00-10-A4-23-19-C0". >=20 > For IEEE 802.11=2C where the SSID is known=2C it SHOULD be appended in > UTF-8 format to the BSSID=2C separated from the BSSID with a ":". > Example "00-10-A4-23-19-C0:AP1". >=20 > As IEEE 802.11 allows that SSIDs may be UTF-8 encoded=2C the SSID MUST > be UTF-8 encoded. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses=2C exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur=2C veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration=2C > Orange decline toute responsabilite si ce message a ete altere=2C deforme= ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law=3B > they should not be distributed=2C used or copied without authorisation. > If you have received this email in error=2C please notify the sender and = delete this message and its attachments. > As emails may be altered=2C Orange is not liable for messages that have b= een modified=2C changed or falsified. > Thank you. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_b15bf432-a63e-4ac0-a0c4-7f6c43719872_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would also like to distinguish= extensions to RFC 2866 (such as Accounting-On/Off) from revisions to RFC 2= 866. =3B

Assignment of new RADIUS op-codes requires = Standards Action=2C so this cannot be done in an Informational RFC.  = =3B

Also=2C since RADIUS accounting is 20+ years old= =2C revisions need to be backward compatible. =3B
<= div>
>=3B From: lionel.morand@orange.com
>=3B To: nick.lowe@= lugatech.com=3B radext@ietf.org
>=3B Date: Wed=2C 7 Oct 2015 15:51:22 = +0000
>=3B Subject: Re: [radext] Feedback solicited: Acct-Session-Id= =2C Acct-Multi-Session-Id=2C Accounting-On/Off and Subsystem-On/Off
>= =3B
>=3B Hi Nick=2C
>=3B
>=3B To make the life easier for = people not involved in previous (offline) discussions and receive feedback = from RADEXT members=2C it would be better to:
>=3B - have a separate e= mail thread per proposed change=2C one for each attribute
>=3B - provi= de a short summary of the issue triggering the proposed change
>=3B - = highlight the proposed changes (e.g. OLD/NEW)
>=3B
>=3B Moreover= =2C I have 2 short general comments:
>=3B
>=3B - The proposed ch= anges introduce the concept of " subsystem of NAS" that is not defined=2C n= or in RFC2865/2865=2C nor in the proposed changes. It should be introduced = somewhere. It would be then easier to understand the relationship between C= alled-Station-Id and NAS/subsystem as well as the proposed new values for A= cct-Status-Type.
>=3B
>=3B - For sake of clarity=2C it would be = maybe easier to make the distinction between the definition of the attribut= e and how this attribute should be used depending on the context (with/with= out another attribute=2C etc.)
>=3B
>=3B - It should be consider= ed if everything related to session management could be captured in a separ= ate section.
>=3B
>=3B Regards=2C
>=3B
>=3B Lionel>=3B
>=3B -----Message d'origine-----
>=3B De =3B: radext= [mailto:radext-bounces@ietf.org] De la part de Nick Lowe
>=3B Envoy= =E9 =3B: mercredi 7 octobre 2015 15:35
>=3B =C0 =3B: radext@ie= tf.org
>=3B Objet =3B: Re: [radext] Feedback solicited: Acct-Sessi= on-Id=2C Acct-Multi-Session-Id=2C Accounting-On/Off and Subsystem-On/Off>=3B
>=3B Reference to RFC 2866
>=3B =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=3B
>=3B Acct-Status-Ty= pe
>=3B
>=3B Description
>=3B
>=3B This attr= ibute indicates whether this Accounting-Request marks
>=3B the b= eginning of the user service (Start) or the end (Stop).
>=3B
>= =3B It MAY be used by the client to mark the start of accounting for<= br>>=3B the NAS (for example=2C upon booting) by specifying Account= ing-On
>=3B and to mark the end of accounting for the NAS (for e= xample=2C just
>=3B before a scheduled reboot) by specifying Acc= ounting-Off.
>=3B
>=3B Where Accounting-On or Accounting-O= ff is specified=2C a
>=3B Called-Station-Id attribute SHOULD NOT= be present. In the case
>=3B that one is present=2C the value = MUST apply to the whole NAS.
>=3B
>=3B It MAY be used by t= he client to mark the start of accounting for a
>=3B subsystem o= f the NAS (for example=2C when an IEEE 802.11 BSS becomes
>=3B a= vailable) by specifying Subsystem-On and to mark the end of
>=3B = accounting for a subsystem of the NAS (for example=2C when an IEEE
>= =3B 802.11 BSS is no longer available) by specifying Subsystem-Off.>=3B
>=3B Where Subsystem-On or Subsystem-Off is specified= =2C a
>=3B Called-Station-Id attribute MUST be present. The sub= system is
>=3B indicated by the value of the Called-Station-Id a= ttribute. It
>=3B MUST uniquely identify the subsystem to the N= AS.
>=3B
>=3B It is strongly recommended that the value of= the Called-Station-Id
>=3B attribute that is used for a session= SHOULD match the value of the
>=3B Called-Station-Id that ident= ifies the subsystem.
>=3B
>=3B The value of any Called-Sta= tion-Id attributes that are used in
>=3B accounting types that a= re session specific SHOULD match the value
>=3B used when Subsys= tem-On and Subsystem-Off are specified where they
>=3B come unde= r the scope of that subsystem.
>=3B
>=3B A session MUST on= ly come under the scope of one subsystem.
>=3B
>=3B For IE= EE 802.11=2C this attribute SHOULD be used to store the
>=3B BSS= ID (upper case only) in ASCII format=2C with octet values
>=3B s= eparated by a "-".
>=3B Example: "00-10-A4-23-19-C0".
>=3B = Where the SSID is known=2C it SHOULD be appended to the BSSID in
&= gt=3B UTF-8 format=2C separated from the BSSID with a ":".
>=3B = Example "00-10-A4-23-19-C0:AP1".
>=3B
>=3B As IEEE 8= 02.11 allows that SSIDs may be UTF-8 encoded=2C the SSID
>=3B MU= ST be UTF-8 encoded.
>=3B
>=3B Where transition occurs for= user service from one one NAS to
>=3B another=2C the preceding = session SHOULD end with a Stop and a new
>=3B session SHOULD beg= in with a Start. This is strongly recommended.
>=3B An Acct-Mul= ti-Session-Id SHOULD be present with the same value to
>=3B link= together related sessions. This is strongly recommended.
>=3B
&g= t=3B Where transition occurs for user service from one one subsystem = to
>=3B another=2C the preceding session MUST end with a Stop an= d a new
>=3B session MUST begin with a Start. An Acct-Multi-Ses= sion-Id MUST be
>=3B present with the same value to link togethe= r related sessions.
>=3B
>=3B The Acct-Session-Id MUST be = different for new sessions started
>=3B when transition occurs.<= br>>=3B
>=3B A summary of the Acct-Status-Type attribute format = is shown below.
>=3B The fields are transmitted from left to right.=
>=3B
>=3B 0 1 2 = 3
>=3B 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
>=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
>=3B | Type | Length | = Value
>=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
>=3B Value (cont) |
>=3B += -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=3B
>=3B Type
>=3B >=3B 40 for Acct-Status-Type.
>=3B
>=3B Length
&g= t=3B
>=3B 6
>=3B
>=3B Value
>=3B
>=3B = The Value field is four octets.
>=3B
>=3B 1 St= art
>=3B 2 Stop
>=3B 3 Interim-Update
= >=3B 7 Accounting-On
>=3B 8 Accounting-Off>=3B 9-14 Reserved for Tunnel Accounting
>=3B 15 = Reserved for Failed
>=3B ?? Subsystem-On
>=3B = ?? Subsystem-Off
>=3B
>=3B Acct-Session-Id
>=3B
&= gt=3B Description
>=3B
>=3B This attribute is a globall= y unique Accounting ID to make it
>=3B possible to match start a= nd stop records. The start and stop
>=3B records for a given se= ssion MUST have the same Acct-Session-Id.
>=3B An Accounting-Req= uest packet MUST have an Acct-Session-Id.
>=3B An Access-Request= packet MAY have an Acct-Session-Id=3B if it does=2C
>=3B then t= he NAS MUST use the same Acct-Session-Id in the
>=3B Accounting-= Request packets for that session.
>=3B
>=3B It is strongly= recommended that the Acct-Session-Id SHOULD contain
>=3B UTF-8 = encoded 10646 [7] characters. It MUST exhibit global and
>=3B t= emporal uniqueness.
>=3B
>=3B For example=2C an implementa= tion may use a string with a UUID.
>=3B Other encodings are poss= ible.
>=3B
>=3B A summary of the Acct-Session-Id attribute fo= rmat is shown below.
>=3B The fields are transmitted from left to r= ight.
>=3B
>=3B 0 1 2>=3B 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>=3B +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=3B | Type = | Length | Text ...
>=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
>=3B
>=3B Type
>=3B
>=3B 4= 4 for Acct-Session-Id.
>=3B
>=3B Length
>=3B
>=3B = >=3B=3D 3
>=3B
>=3B String
>=3B
>=3B = The String field SHOULD be a string of UTF-8 encoded 10646 [7]
>=3B = characters.
>=3B
>=3B Acct-Multi-Session-Id
>=3B
&= gt=3B Description
>=3B
>=3B This attribute is a globall= y unique Accounting ID to make it
>=3B possible to link together= multiple related sessions. Each session
>=3B linked together w= ould have a globally unique Acct-Session-Id but
>=3B the same Ac= ct-Multi-Session-Id.
>=3B
>=3B It is strongly recommended = that the Acct-Multi-Session-Id SHOULD
>=3B contain UTF-8 encoded= 10646 [7] characters. It MUST exhibit
>=3B global and temporal= uniqueness.
>=3B
>=3B For example=2C an implementation ma= y use a string with a UUID.
>=3B Other encodings are possible.>=3B
>=3B A summary of the Acct-Session-Id attribute format is= shown below.
>=3B The fields are transmitted from left to right.>=3B
>=3B 0 1 2
>=3B= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>=3B +-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=3B | Type | = Length | String ...
>=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+
>=3B
>=3B Type
>=3B
>=3B 50 for Ac= ct-Multi-Session-Id.
>=3B Length
>=3B
>=3B >=3B=3D = 3
>=3B
>=3B String
>=3B
>=3B The String field S= HOULD contain UTF-8 encoded 10646 [7] characters.
>=3B
>=3B
= >=3B Reference to RFC 3580
>=3B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
>=3B
>=3B Acct-Multi-Session-Id
&= gt=3B
>=3B The purpose of this attribute is to make it possible to= link together
>=3B multiple related sessions for IEEE 802.11. Whi= le [IEEE8021X] does
>=3B not act on aggregated ports=2C it is possi= ble for a Supplicant roaming
>=3B between Basic Service Sets or in = failover accounting from one
>=3B Controller to another to cause mu= ltiple RADIUS accounting packets to
>=3B be sent by the same or dif= ferent Access Points or Controllers.
>=3B
>=3B Where supporte= d by the Access Points or the Controllers=2C the
>=3B Acct-Multi-Se= ssion-Id attribute can be used to link together the
>=3B multiple r= elated sessions of a roaming Supplicant or in failover
>=3B account= ing from one Controller to another. In such a situation=2C if
>=3B = the session context is transferred between Access Points or
>=3B C= ontrollers=2C accounting packets MAY be sent without a corresponding
>= =3B authentication and authorization exchange=2C provided that Associati= on
>=3B has occurred. However=2C in such a situation it is assumed= that the
>=3B Acct-Multi-Session-Id is transferred between the Acc= ess Points or the
>=3B Controllers as part of the Inter-Access Poin= t Protocol (IAPP) or
>=3B another handoff scheme.
>=3B
>= =3B If the Acct-Multi-Session-Id were not globally unique between Access=
>=3B Points and Controllers=2C then it is possible that the chosen=
>=3B Acct-Multi-Session-Id will overlap with an existing value all= ocated
>=3B on that Access Point or Controller=2C and the Accountin= g Server would
>=3B therefore be unable to distinguish a roaming or= failover session
>=3B from a multi-link session.
>=3B
>= =3B In order to provide global uniqueness=2C it is suggested that the>=3B Acct-Multi-Session-Id be a UUID that offers inherent global and<= br>>=3B temporal uniqueness.
>=3B
>=3B An alternative co= nstruction for the Acct-Multi-Session-Id may be of
>=3B the form:>=3B
>=3B BSSID | Supplicant MAC Address | NTP Timestamp
&g= t=3B
>=3B Here "|" represents concatenation=2C the BSSID is the MA= C address of
>=3B the BSS under which the session started=2C and th= e 64-bit NTP timestamp
>=3B indicates the beginning of the original= session. In order to provide
>=3B for consistency of the Acct-Mul= ti-Session-Id between roaming or
>=3B failover sessions=2C the Acct= -Multi-Session-Id may be moved between
>=3B Access Points or Contro= llers as part of IAPP or another handoff
>=3B scheme.
>=3B >=3B The use of an Acct-Multi-Session-Id of this form should guarante= e
>=3B uniqueness among all Basic Service Sets=2C Access Points=2C = Supplicants=2C
>=3B Controllers and sessions. Since the NTP timest= amp does not wrap on
>=3B reboot=2C there is no possibility that a = rebooted Access Point or
>=3B Controller could choose an Acct-Multi= -Session-Id that could be
>=3B confused with that of a previous ses= sion once time synchronisation
>=3B has occurred. The downside of = this construction is that it is
>=3B dependent on time synchronisat= ion having occurred. For this reason=2C
>=3B a UUID is preferred.<= br>>=3B
>=3B Since the Acct-Multi-Session-Id is of type String a= s defined in
>=3B [RFC2866]=2C for use with IEEE 802.1X=2C it is en= coded as an UTF-8 string
>=3B of Hex digits. Example: "00-10-A4-2= 3-19-C0-00-12-B2-
>=3B 14-23-DE-AF-23-83-C0-76-B8-44-E8"
>=3B =
>=3B Called-Station-Id
>=3B
>=3B For IEEE 802.1X Authen= ticators=2C this attribute is used to store the
>=3B bridge MAC add= ress or IEEE 802.11 BSSID in ASCII format (upper case
>=3B only)=2C= with octet values separated by a "-".
>=3B Example: "00-10-A4-23-1= 9-C0".
>=3B
>=3B For IEEE 802.11=2C where the SSID is known= =2C it SHOULD be appended in
>=3B UTF-8 format to the BSSID=2C sepa= rated from the BSSID with a ":".
>=3B Example "00-10-A4-23-19-C0:AP= 1".
>=3B
>=3B As IEEE 802.11 allows that SSIDs may be UTF-8 e= ncoded=2C the SSID MUST
>=3B be UTF-8 encoded.
>=3B
>=3B= _______________________________________________
>=3B radext mailing l= ist
>=3B radext@ietf.org
>=3B https://www.ietf.org/mailman/listin= fo/radext
>=3B
>=3B ____________________________________________= ___________________________________________________________________________= __
>=3B
>=3B Ce message et ses pieces jointes peuvent contenir d= es informations confidentielles ou privilegiees et ne doivent donc
>= =3B pas etre diffuses=2C exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur=2C veuillez le signaler
>=3B a l'expedite= ur et le detruire ainsi que les pieces jointes. Les messages electroniques = etant susceptibles d'alteration=2C
>=3B Orange decline toute responsab= ilite si ce message a ete altere=2C deforme ou falsifie. Merci.
>=3B <= br>>=3B This message and its attachments may contain confidential or priv= ileged information that may be protected by law=3B
>=3B they should no= t be distributed=2C used or copied without authorisation.
>=3B If you = have received this email in error=2C please notify the sender and delete th= is message and its attachments.
>=3B As emails may be altered=2C Orang= e is not liable for messages that have been modified=2C changed or falsifie= d.
>=3B Thank you.
>=3B
>=3B ______________________________= _________________
>=3B radext mailing list
>=3B radext@ietf.org>=3B https://www.ietf.org/mailman/listinfo/radext
=
= --_b15bf432-a63e-4ac0-a0c4-7f6c43719872_-- From nobody Tue Oct 13 11:56:34 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF941A884B for ; Tue, 13 Oct 2015 11:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Leeem8a8gjGY for ; Tue, 13 Oct 2015 11:56:30 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50A1D1A8860 for ; Tue, 13 Oct 2015 11:54:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8D5262240857; Tue, 13 Oct 2015 20:53:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jkqR-zdoBa2; Tue, 13 Oct 2015 20:53:34 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 6D7C522405C9; Tue, 13 Oct 2015 20:53:33 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: Date: Tue, 13 Oct 2015 14:53:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <592B56FD-03CD-4005-A0BC-2E52DB636D1B@deployingradius.com> References: <5654BCDA-9F97-44A4-97F1-EF0FBA3C715B@deployingradius.com> <7190_1444233083_56153F7B_7190_15631_1_6B7134B31289DC4FAF731D844122B36E01D3D95B@OPEXCLILM43.corporate.adroot.infra.ftgroup > To: Aboba Bernard X-Mailer: Apple Mail (2.3094) Archived-At: Cc: Nick Lowe , "radext@ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 18:56:32 -0000 On Oct 13, 2015, at 2:40 PM, Bernard Aboba = wrote: >=20 > I would also like to distinguish extensions to RFC 2866 (such as = Accounting-On/Off) from revisions to RFC 2866.=20 Sure. > Assignment of new RADIUS op-codes requires Standards Action, so this = cannot be done in an Informational RFC. =20 That's not needed. What has been requested (by me via IANA) are new = values for Acct-Status-Type. These require expert review, and not = standards action. There is no suggestion to assign new packet codes or attributes. > Also, since RADIUS accounting is 20+ years old, revisions need to be = backward compatible.=20 That is of key importance. For Acct-Session-Id, we can make recommendations for how it's values = are created... with no inter-operability issues. All consumers of = Acct-Session-Id treat it as an opaque token. This behaviour is implied = by RFC 2866. Recommending *better* values fort Acct-Session-Id has no impact on = existing NASes, proxies, or servers. Alan DeKok. From nobody Tue Oct 13 12:42:09 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA4E1A8974 for ; Tue, 13 Oct 2015 12:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjOf5Af7OF3h for ; Tue, 13 Oct 2015 12:42:07 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26E011A8966 for ; Tue, 13 Oct 2015 12:42:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8C9D92240857 for ; Tue, 13 Oct 2015 21:41:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrJhUCDSqI1m for ; Tue, 13 Oct 2015 21:41:36 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id E656322405C9 for ; Tue, 13 Oct 2015 21:41:35 +0200 (CEST) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 13 Oct 2015 15:41:34 -0400 To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) Archived-At: Subject: [radext] Acct-Status-Type and subsystems X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 19:42:08 -0000 Lionel says: > - The proposed changes introduce the concept of " subsystem of NAS" = that is not defined, nor in RFC2865/2865, nor in the proposed changes. = It should be introduced somewhere. I have a longer write-up on the web at = http://freeradius.org/rfc/acct_status_type_subsystem.html The problem is that multiple vendors are using "Acct-Status-Type =3D = Accounting-On" and "Acct-Status-Type =3D Accounting-Off" for purposes = which do not match the criteria in RFC 2866. This is bad. The suggestion is to define two new Acct-Status-Type values, which = better suit the vendors needs. The *utility* of Subsystem-On / Subsystem-Off is to signal that masses = of users have been kicked off of the network. It means that the NAS = send one packet "subsystem off", instead of many "user session is = stopped" packets. I don't want to define what a "subsystem" is, because I think any = quantitative definition will be too limited. I would suggest leaving it = to the NAS implementors. As for Called-Station-Id, that's where more hand-waving comes in. The = values should be unique per subsystem. What are those values? That = depends on the subsystem... The intent here is to clarify issues, not to create perfect solutions. = If I wanted a perfect solution, I wouldn't be using RADIUS. :( Alan DeKok. From nobody Wed Oct 14 14:14:10 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2B1A894F; Wed, 14 Oct 2015 14:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG3lkUhy7fCk; Wed, 14 Oct 2015 14:14:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 35BF71A8941; Wed, 14 Oct 2015 14:14:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 31BBE180476; Wed, 14 Oct 2015 14:13:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151014211352.31BBE180476@rfc-editor.org> Date: Wed, 14 Oct 2015 14:13:52 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 7585 on Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 21:14:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7585 Title: Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) Author: S. Winter, M. McCauley Status: Experimental Stream: IETF Date: October 2015 Mailbox: stefan.winter@restena.lu, mikem@airspayce.com Pages: 32 Characters: 70699 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-dynamic-discovery-15.txt URL: https://www.rfc-editor.org/info/rfc7585 DOI: http://dx.doi.org/10.17487/RFC7585 This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS). This document is a product of the RADIUS EXTensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Oct 19 06:19:49 2015 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A91381A90B5; Mon, 19 Oct 2015 06:19:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019131947.24395.37157.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 06:19:47 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-bigger-packets-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 13:19:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Larger Packets for RADIUS over TCP Author : Sam Hartman Filename : draft-ietf-radext-bigger-packets-04.txt Pages : 9 Date : 2015-10-19 Abstract: The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-bigger-packets-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 08:40:20 2015 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 052F81ACDEF; Mon, 19 Oct 2015 08:40:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019154019.17044.86655.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 08:40:19 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:40:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-06.txt Pages : 36 Date : 2015-10-19 Abstract: This document defines three new RADIUS attributes. For devices that implementing IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as CGN (Carrier Grade NAT), NAT64, Provider WLAN Gateway, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 11:03:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26951A8A1A for ; Mon, 19 Oct 2015 11:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu-7PJAR74MA for ; Mon, 19 Oct 2015 11:03:32 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618261A9145 for ; Mon, 19 Oct 2015 11:03:28 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 81469C015E for ; Mon, 19 Oct 2015 20:03:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 49D401A0070 for ; Mon, 19 Oct 2015 20:03:26 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 20:03:26 +0200 From: To: "radext@ietf.org" Thread-Topic: Agenda slot at the IETF94 Thread-Index: AdEKllZY6wCE+tyZSUSpjPwXeizy9gAAC79g Date: Mon, 19 Oct 2015 18:03:25 +0000 Message-ID: <31147_1445277806_5625306E_31147_10083_1_6B7134B31289DC4FAF731D844122B36E01D47E9B@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [radext] Agenda slot at the IETF94 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:03:36 -0000 Folks, For this IETF meeting, DIME and RADEXT WGs will have exceptionally a joint = session on Tuesday afternoon, from 13:00-15:00. For RADEXT, we will have about one hour. We expect some discussions/progress on the following WG documents: *draft-ietf-radext-datatypes-01 Moreover, a specific discussion on the following points is expected: *Update/revision of RFC 3580 *Update/revision of RFC 2866 Don't forget that a remote participation (using Meetecho) is possible if yo= u are not in Yokohama. For any other point outside the current charter that you would like to addr= ess, please send a specific request for an additional slot. Regards, Lionel and Stefan ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. From nobody Tue Oct 20 04:25:27 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240A31B3310 for ; Tue, 20 Oct 2015 04:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Y7-p39H_lt for ; Tue, 20 Oct 2015 04:25:23 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFE41B330D for ; Tue, 20 Oct 2015 04:25:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9A9302086D; Tue, 20 Oct 2015 07:23:39 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kerhCb7snLlP; Tue, 20 Oct 2015 07:23:39 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 20 Oct 2015 07:23:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6FF2D8250D; Tue, 20 Oct 2015 07:25:20 -0400 (EDT) From: Sam Hartman To: References: <31147_1445277806_5625306E_31147_10083_1_6B7134B31289DC4FAF731D844122B36E01D47E9B@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Tue, 20 Oct 2015 07:25:20 -0400 In-Reply-To: <31147_1445277806_5625306E_31147_10083_1_6B7134B31289DC4FAF731D844122B36E01D47E9B@OPEXCLILM43.corporate.adroot.infra.ftgroup> (lionel morand's message of "Mon, 19 Oct 2015 18:03:25 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Agenda slot at the IETF94 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 11:25:25 -0000 I've addressed or pushed back on the points raised on draft-ietf-radext-bigger-packets. Some of the chairs raised some concerns that I pushed back on. my assumption is that these concerns were raised as individuals not as chairs. My claim is that we have not yet reached consensus to make a change. My preference would be to send the document forward. However I think we need to give folks who raised concerns a chance to request discussion. I'd prefer to see someone affirmatively request discussion before giving an agenda slot, but handling that is of course the chairs' option. --Sam From nobody Tue Oct 20 04:34:05 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CEB1B3326; Tue, 20 Oct 2015 04:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10WybJrnXuDd; Tue, 20 Oct 2015 04:34:03 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDC41B3323; Tue, 20 Oct 2015 04:34:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 7BEED2086E; Tue, 20 Oct 2015 07:32:19 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTHnhFhUlIWq; Tue, 20 Oct 2015 07:32:19 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 20 Oct 2015 07:32:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 85B3B8250D; Tue, 20 Oct 2015 07:33:58 -0400 (EDT) From: Sam Hartman To: internet-drafts@ietf.org References: <20151019131947.24395.37157.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 07:33:58 -0400 In-Reply-To: <20151019131947.24395.37157.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon, 19 Oct 2015 06:19:47 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org, i-d-announce@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-bigger-packets-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 11:34:04 -0000 I believe I have responded to or pushed back on all the issues raised during the chairs' review. I haven't seen responses to my responses. From nobody Thu Oct 22 02:14:56 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A261A0146 for ; Thu, 22 Oct 2015 02:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc0HdXg_VlO7 for ; Thu, 22 Oct 2015 02:14:51 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 05AE61A0113 for ; Thu, 22 Oct 2015 02:14:48 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id CE10843AB2 for ; Thu, 22 Oct 2015 11:14:45 +0200 (CEST) To: radext@ietf.org References: <20151019131947.24395.37157.idtracker@ietfa.amsl.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <5628A905.3060003@restena.lu> Date: Thu, 22 Oct 2015 11:14:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bmtW28Wudn5k70fIHWX9jlC8C1eCCcUPX" Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-bigger-packets-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 09:14:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bmtW28Wudn5k70fIHWX9jlC8C1eCCcUPX Content-Type: multipart/mixed; boundary="------------060209000700050701010502" This is a multi-part message in MIME format. --------------060209000700050701010502 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > I believe I have responded to or pushed back on all the issues raised > during the chairs' review. > I haven't seen responses to my responses. Thanks for the updated draft. I will not be able to look into before late next week though. Stay tuned! Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------060209000700050701010502 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------060209000700050701010502-- --bmtW28Wudn5k70fIHWX9jlC8C1eCCcUPX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWKKkFAAoJEMDeajWKOdxmpi8P/RNyTwXJ9x7OO5MjxSb7oqKW DF8nDSyAlDhWrYuwBjv0O3JPNu9vV6oADwC7Ch3CcbOux70CdM9xfuuHO8uGbwTS 53rR9NyE5evhk3v1mNsVBgt4xRcJ2eyKvxfhYCTYBzxCyvXtktAkeYFOnqVGQp9N 7IBxTV+iThwf1PuDupY2ZXUckemvPw+0EBrYiDO5KZ3IF4RsHmeSfPL8nD0RzOzQ +Vd/kMtZEB5YT8QYjxoDiNjfRDDFIrTH42VbhpvCWek1nGYSDODUR5DckNGTO4VR W2k6aprzpyz133iTd492d4TJ39ZxEMfoRS1979xVaLpB6c85MV+zjwUYemn9ffRl +bi9rl6mBIiF1TsQZ/v9PNToSrbORNWvChCJv9c5oKVsa6W0b4tk6dnQ6axQp6Jg m1px5DyYxW/JXjZmZiIEli6dCxvHeLw9Qyx3MC774lGaGpU+hzUwTuJjE28Duarv Elzk8nuw43+j/lh3uBB20IDL348uyUgs+UXafmnMuqxjn0ifODw8UNLohsQAeZwI MvdU0Eu6r11QGZlv7y3OTYyNObXFJEqvExmATpCxfa+Y91n8XEQGXX4EgTDi8GpT nQP6Mr0G8TgvMwxWMMQbvaALu1hVCaxhof0dOsquufKhuTm0tl+VuixXkJXlq8vd JKxuaGMAHR0ReMfEdzvz =/Yw8 -----END PGP SIGNATURE----- --bmtW28Wudn5k70fIHWX9jlC8C1eCCcUPX-- From nobody Mon Oct 26 08:08:33 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959721B4944 for ; Mon, 26 Oct 2015 08:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUXCp-YI5x3Z for ; Mon, 26 Oct 2015 08:08:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9931B493A for ; Mon, 26 Oct 2015 08:07:11 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 80ED23B4250 for ; Mon, 26 Oct 2015 16:07:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 66E5018004F for ; Mon, 26 Oct 2015 16:07:09 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0248.002; Mon, 26 Oct 2015 16:07:09 +0100 From: To: "radext@ietf.org" Thread-Topic: Draft Agenda for Radext session in IETF94 Thread-Index: AdEPmAch7i1aEf3RSKas16kA9dQ7Yw== Date: Mon, 26 Oct 2015 15:07:09 +0000 Message-ID: <17008_1445872029_562E419D_17008_16335_1_6B7134B31289DC4FAF731D844122B36E01D4E443@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.26.142716 Archived-At: Subject: [radext] Draft Agenda for Radext session in IETF94 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 15:08:30 -0000 Hi, The draft aganda for the next IETF meeting has just been uploaded. Regards, Lionel & Stefan -------------------------------------------------- Chairs: Lionel Morand Stefan Winter < stefan.winter@restena.lu>=20 TUESDAY, November 3, 2015 1400-1500 Afternoon Session I (60 mins) Meeting room: Room 413 Jabber room: radext at jabber.ietf.org (Please join)=20 14:00 - 14:05, Preliminaries (5 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Note Well=20 Note Takers=20 Jabber scribe Agenda bashing=20 14:05 - 14:10, WG Document Status (5 minutes) ------------------------------------------ * draft-ietf-radext-dynamic-discovery --> RFC 7585 * draft-ietf-radext-bigger-packets-04 --> Waiting for Write-Up (Experiment= al) * draft-ietf-radext-datatypes-01 --> In WG --> WGLC? * draft-ietf-radext-ip-port-radius-ext-06 --> Waiting for Write-Up (Standar= d) Working group draft discussions (20 minutes) ------------------------------------------- 14:10 - 14:20 RADIUS Data Types, Alan (10 minutes) https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ 14:20 - 14:30 Bigger Packets, Sam/Stefan (10 minutes) https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ Issues related to RFC3580 and RFC2866 ------------------------------------------- 14:30 - 14:50 RFC3580/RFC2866 Issues and proposed fixes, Alan (20 minutes) Wrap-up and Next (5 minutes) -------------------- 13:55 - 14:00 Next Steps: WG Chairs & ADs (5 minutes)=20 WG Goals/Milestones status, next steps ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 29 03:19:32 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89EE1B2CB5 for ; Thu, 29 Oct 2015 03:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrlPfKOAItl7 for ; Thu, 29 Oct 2015 03:19:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB921B2CB3 for ; Thu, 29 Oct 2015 03:19:29 -0700 (PDT) Received: from localhost ([::1]:43278 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZrkIn-0005oZ-GP; Thu, 29 Oct 2015 03:19:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 29 Oct 2015 10:19:25 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/195#comment:3 Message-ID: <080.30ed18f2d02a7aaf8ced8bf2e146646c@trac.tools.ietf.org> References: <065.7a65c858f80799ca336eb6e4d4dc9eb2@trac.tools.ietf.org> X-Trac-Ticket-ID: 195 In-Reply-To: <065.7a65c858f80799ca336eb6e4d4dc9eb2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20151029101929.5BB921B2CB3@ietfa.amsl.com> Resent-Date: Thu, 29 Oct 2015 03:19:29 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #195 (bigger-packets): minor nits X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 10:19:30 -0000 #195: minor nits Comment (by stefan.winter@restena.lu): Version -04 of the draft fixes most of these, with the exception of these three: 6) In Security Considerations, a reference to RFC6613 is not in the standard xref [] notation. 7) In the same section, an e is missing: "If these attacks ar accaptable..." (are) 8) There should be a space in "Dial In" in Introduction, line 1. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Oct 29 03:24:13 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4F41B2CD1 for ; Thu, 29 Oct 2015 03:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFtCsJ94ICs4 for ; Thu, 29 Oct 2015 03:24:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F48F1B2CD0 for ; Thu, 29 Oct 2015 03:24:10 -0700 (PDT) Received: from localhost ([::1]:43411 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZrkNM-0003w6-Ce; Thu, 29 Oct 2015 03:24:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 29 Oct 2015 10:24:08 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/193#comment:1 Message-ID: <080.1ec989aeae47b088b320d5802451460f@trac.tools.ietf.org> References: <065.5dfecdab2a3782e0ece43e585d9b8dfb@trac.tools.ietf.org> X-Trac-Ticket-ID: 193 In-Reply-To: <065.5dfecdab2a3782e0ece43e585d9b8dfb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20151029102410.7F48F1B2CD0@ietfa.amsl.com> Resent-Date: Thu, 29 Oct 2015 03:24:10 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #193 (bigger-packets): clarify "endpoint" for coexistence with RADIUS fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 10:24:12 -0000 #193: clarify "endpoint" for coexistence with RADIUS fragmentation Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: Endpoint was changed to next hop. Since using Response-Length is not usable as discovery mechanism in this context, the rest of comment does not make sense any more :-) -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Oct 29 03:33:21 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED671B2CE9; Thu, 29 Oct 2015 03:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdMzN6S71nmY; Thu, 29 Oct 2015 03:33:18 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 11FBB1B2CEB; Thu, 29 Oct 2015 03:33:15 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6727243AA0; Thu, 29 Oct 2015 11:33:13 +0100 (CET) To: Sam Hartman , Alan DeKok References: <55D57021.8060308@restena.lu> <183E3AC7-A5CB-43D4-ADCA-E0B7DD04B43C@deployingradius.com> <733DFAE3-4017-466D-8CA1-E028AC6ED4B8@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <5631F5E9.6060306@restena.lu> Date: Thu, 29 Oct 2015 11:33:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GlEb2PCKDeDeWa7D2QVv3E3QTNGrl6ffW" Archived-At: Cc: "radext@ietf.org" , draft-ietf-radext-bigger-packets.authors@ietf.org Subject: Re: [radext] Questions about draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 10:33:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GlEb2PCKDeDeWa7D2QVv3E3QTNGrl6ffW Content-Type: multipart/mixed; boundary="------------050601020706060202010803" This is a multi-part message in MIME format. --------------050601020706060202010803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > Alan> On Sep 21, 2015, at 11:20 AM, Sam Hartman > Alan> wrote: > >> I don't support a stronger recommendation for explicit signaling= > >> than is present in the draft. > >>=20 > >> My rationale is that explicit signaling is very heavy weight for= > >> client-side libraries. >=20 > Alan> I would support a SHOULD for explicit signalling, especiall= y > Alan> for proxies. Failing that, the client SHOULD do signalling a= t > Alan> least once, and then cache the results for some time. >=20 > I think there's already a SHOULD for explicit signaling. Reading this thread, I'm not sure if both of you agreed. Parts of Alan's previous message hinted toward at least adding the text about making RFC2865 home server compatibility part of the things to be evaluated in this experiment. So, to clarify: are you happy with the text as-is in rev -04, or are there pending text changes? If the latter, could either of you suggest updated text for a new rev? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------050601020706060202010803 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------050601020706060202010803-- --GlEb2PCKDeDeWa7D2QVv3E3QTNGrl6ffW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWMfXpAAoJEMDeajWKOdxmWiwP/RiYLT29orJBQaeqSM3QMAZ1 HBL2BV6RKTy5xJRc1fjVoLbJ3uydivAQytl12o32fq80kID/R1LiiPAJbmRKlxXh oQWjXDmbOt+QyIDmTLrOxpOaR3NYarO6cvX1KW9e8pX3eR7728e8+yWsAR6Nun3f nN4cuxFlznBqQ//KJ4RMpJUFoTNq3VKuw387RjigIbEvLeizWTFDEFXbrzXU55eT kxTW4tNzjTh5nLD7DY/diob5XbTuHE9WuQswH/+nIJpkeN3VBo8Y4LYKSEKCkM8v /fc3lrX1fX6EvYrBzyHNiv/bu7DQWBAkpLrFYPFaACOtkEs6EqRutHHTAL9ukrNk mnDxzPOKPl15jKJYBEmgpA6mWSzb7cLEDfNXAEwJXDVKD2+yRbauU5Bi04m9dhHG IzCynU7tnkWcEtzZsrckjPyQYd48o8hEfrV23GqWDsKtV0CUhxz796B2RNGyOWNn FfIMcYoEIm4FsUJoaJ6DjOuUqGr2qFWP/hk6lkdouSndmSTY1QzPfuJbU4URRzXC yKRNPbDQcHnF+RzaFk3L4WRc0Jbh2akvV9iFxertgUy0V/6oUq6NAT3+7CFg359d uLer5T93wPfUxHPbvUhMt5iP4DdQg+q4jFv9iHna89Ok6YuFXKAp2BbTzPaPQQut V8VoHDtxLvLugkXCrt4J =b5dh -----END PGP SIGNATURE----- --GlEb2PCKDeDeWa7D2QVv3E3QTNGrl6ffW-- From nobody Thu Oct 29 03:33:23 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD321B2CF4 for ; Thu, 29 Oct 2015 03:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkgUtuB6nBkw for ; Thu, 29 Oct 2015 03:33:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF781B2CEB for ; Thu, 29 Oct 2015 03:33:20 -0700 (PDT) Received: from localhost ([::1]:43618 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZrkWE-0002Mj-L5; Thu, 29 Oct 2015 03:33:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 29 Oct 2015 10:33:18 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/191#comment:1 Message-ID: <080.3821552988d2f808404d84957fb09a22@trac.tools.ietf.org> References: <065.6531aba1b0a79386444f20fdda1cfb0f@trac.tools.ietf.org> X-Trac-Ticket-ID: 191 In-Reply-To: <065.6531aba1b0a79386444f20fdda1cfb0f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20151029103320.BDF781B2CEB@ietfa.amsl.com> Resent-Date: Thu, 29 Oct 2015 03:33:20 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #191 (bigger-packets): Is evaluation of backwards compatibility part of the experiment's goals? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 10:33:21 -0000 #191: Is evaluation of backwards compatibility part of the experiment's goals? Comment (by stefan.winter@restena.lu): in progress: see discussion thread "Questions about ..." on radext -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Oct 29 04:36:53 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CD01B2D67 for ; Thu, 29 Oct 2015 04:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUveKlcZwSab for ; Thu, 29 Oct 2015 04:36:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A85F1B2D68 for ; Thu, 29 Oct 2015 04:36:47 -0700 (PDT) Received: from localhost ([::1]:45771 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZrlVf-0005ic-3x; Thu, 29 Oct 2015 04:36:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 29 Oct 2015 11:36:47 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/194#comment:1 Message-ID: <080.f87a78ee4322b3435c63a35ab358af46@trac.tools.ietf.org> References: <065.ef5bf9284d0e734516ceae66e2ae74f3@trac.tools.ietf.org> X-Trac-Ticket-ID: 194 In-Reply-To: <065.ef5bf9284d0e734516ceae66e2ae74f3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20151029113647.7A85F1B2D68@ietfa.amsl.com> Resent-Date: Thu, 29 Oct 2015 04:36:47 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #194 (bigger-packets): find and list implementations X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 11:36:52 -0000 #194: find and list implementations Comment (by stefan.winter@restena.lu): in progress; is being clarified on the radext list -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Oct 29 04:37:03 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8551B2D6E; Thu, 29 Oct 2015 04:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HXUv746SaJO; Thu, 29 Oct 2015 04:36:59 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 5E3731B2D6B; Thu, 29 Oct 2015 04:36:59 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 098C243AA0; Thu, 29 Oct 2015 12:36:58 +0100 (CET) To: Alan DeKok References: <55D57021.8060308@restena.lu> <183E3AC7-A5CB-43D4-ADCA-E0B7DD04B43C@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <563204D9.1010401@restena.lu> Date: Thu, 29 Oct 2015 12:36:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <183E3AC7-A5CB-43D4-ADCA-E0B7DD04B43C@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OQh1OvPpoGormtohgRbaScngxHPbK9KUo" Archived-At: Cc: "radext@ietf.org" , draft-ietf-radext-bigger-packets.authors@ietf.org Subject: Re: [radext] Questions about draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 11:37:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OQh1OvPpoGormtohgRbaScngxHPbK9KUo Content-Type: multipart/mixed; boundary="------------080206020502000309060803" This is a multi-part message in MIME format. --------------080206020502000309060803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, >> 5) For "Document quality", I would mention implementations which are >> known to implement the spec. Are there any? If so, you may want to add= >> an RFC6982 "Implementation Status" section. >=20 > Uh.... clickety click... I'll take a look at the implementation side = of things. :) But that requires IANA allocation of the packet code and a= ttributes. >=20 > On that note: Response-Length is a 2-octet unsigned integer of maxi= mum response length. >=20 > Can that be changed to be of data type "integer"? And maybe referen= ce data types? >=20 > I'll refresh the data types document today. Unfortunately, RFC7120 does not foresee early allocation of "IESG Consensus" type allocations. I wonder what is the document author's preference: publish the document without waiting for an implementation and the accompanying Implementation Status section? Or include such a section, stating that a FreeRADIUS implementation is WI= P? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------080206020502000309060803 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------080206020502000309060803-- --OQh1OvPpoGormtohgRbaScngxHPbK9KUo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWMgTZAAoJEMDeajWKOdxmBtkP/3bjbm1w3TcZDeH6ekG/rGPa UaVs2RQLZrh3ZC8026NLNCGUybOqUkPNE2wH0uwJu1yUuJviuov/98B5n/taz0Hi x7sSbAKTHSMt5ZvW/5pspW24/rBdLyi/mYisYV5bgcI+f6pNSLhmt2hEM4h+rVJQ BcF6l4E5E2JQI89V074O0RaV08R0Ncns5a6nhjF6bGQ9IXpqPo9tcWkykUVhimPV ZoUInGqef0bza1Ym+hmXwPjQI8YP84Vnhw6Rf9Xt0EWm24PdGYu2N1prR4AZWjMM nXXXcHmf34ctEk1RyL3O4NGBG871sGfAjEhzvqz26XOIw54rKa3e4WptLXZZK/7j UzuJWRXFNY5n36dn8h9iwsAxjkqlPXAL6YGy69SI42JdWt3hq+T65coY0q96MP3e 4HGsNz8SkB8Q5FlVYypQ93bdsG4JqaTAxUIh0wCjBXf19wAUvCdfrtb3zgmZt4PT OEcHBXBLw9QcNjV9fixEaPHKuFP4PRjChofUz0G4VOGjexLBLq8KQZJnf1/WmDK0 tv3xcCHKGd3qIiDbPAvdFpkDBf/JFiic8IQFRm4BSl7JHpvShYBhHYxIeNcjx/bQ 5j6hzDtjb8lcSzx1AlMFvh0ymsU3/aeC6vDBBC7+jztw8iF8jCxUCj6DvHNv9HpH UUaj6Me5pLZB+45gDjaN =T+Xu -----END PGP SIGNATURE----- --OQh1OvPpoGormtohgRbaScngxHPbK9KUo-- From nobody Thu Oct 29 04:39:28 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D7C1B2D76 for ; Thu, 29 Oct 2015 04:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWHMBl80kY_6 for ; Thu, 29 Oct 2015 04:39:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE5D1B2D73 for ; Thu, 29 Oct 2015 04:39:26 -0700 (PDT) Received: from localhost ([::1]:45819 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZrlYE-0003Sv-7R; Thu, 29 Oct 2015 04:39:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 29 Oct 2015 11:39:26 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/190#comment:2 Message-ID: <080.d741c5a8ad994506793bc7a5f0529041@trac.tools.ietf.org> References: <065.b540a7fe9686d3ebabdd62233b43113c@trac.tools.ietf.org> X-Trac-Ticket-ID: 190 In-Reply-To: <065.b540a7fe9686d3ebabdd62233b43113c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20151029113926.6EE5D1B2D73@ietfa.amsl.com> Resent-Date: Thu, 29 Oct 2015 04:39:26 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #190 (bigger-packets): Does the document require an "Updates" relationship to RFC2865? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 11:39:27 -0000 #190: Does the document require an "Updates" relationship to RFC2865? Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => wontfix Comment: The author's preference is to hold the Updates until the document goes to standards track. No dissent on the mailing list, so let's do that. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Oct 29 04:56:13 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333D51B2DC2 for ; Thu, 29 Oct 2015 04:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1iGZ7waHLJP for ; Thu, 29 Oct 2015 04:56:10 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 74E901B2DB0 for ; Thu, 29 Oct 2015 04:56:10 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D30CB43AA0; Thu, 29 Oct 2015 12:56:08 +0100 (CET) To: Sam Hartman References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> <55D6CC73.9020002@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <56320958.2000403@restena.lu> Date: Thu, 29 Oct 2015 12:56:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fNRMcVNMbK6dpQjSoc3BF5BJ5KtwxbJw9" Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 11:56:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fNRMcVNMbK6dpQjSoc3BF5BJ5KtwxbJw9 Content-Type: multipart/mixed; boundary="------------020908060100090400030303" This is a multi-part message in MIME format. --------------020908060100090400030303 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > I think the particular configuration you quote above might be a good fi= t > for a system that uses both Moonshot and eduroam. > Especially if you make it a bit finer grained by allowing each > consortuim/set of CAs/whatever you want to describe it as for DNS have > its own configuration. The "whatever you want" makes it difficult to prescribe how exactly a classification of servers should be done - and was the reason why I considered the wording unclear. > I think I need something like this as a minimum so I'd like to have a > related SHOULd in the spec. > I'd be happy to get input on what approaches would give me this but wor= k > for you. Okay... We both agree that this parameter needs to be configurable. None of us really knows how "categories" should be defined exactly (nor do we know what will be useful classification criteria in the field). I think this is something actual implementations - and their customer demand - can and will sort out themselves. The important bit is that it must be configurable in principle IMHO; and that more than one global default is something to consider for an implementation. So how about this as a text proposal: OLD: If dynamic discovery mechanisms are supported, configuration SHOULD be provided for the maximum size of clients and servers in each dynamic discovery category. NEW: If dynamic discovery mechanisms are supported, the default maximum packet sizes for sending packets SHOULD be configurable. Implementations MAY choose to allow configuration of different defaults in different parts of their dynamic discovery configuration. How about that? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------020908060100090400030303 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020908060100090400030303-- --fNRMcVNMbK6dpQjSoc3BF5BJ5KtwxbJw9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWMglYAAoJEMDeajWKOdxmEAAQALR54BAdhjTR5PLGBdLfWaN0 WIQVvwQLmfE2SgbJtc1k7cprGkMaxKKiLn/G+SmD7UaQektFHM75Y+kyJjejw1Sc /TPIEg+4vyJBVTRSAjpKMrUqsg5mFDrJL7dTSkXpN3CEJk8hQt06QVy1ngJ/SgJI ye5sl9aN5sUA3xaphXmANWtO0/TuTtiMVNT1IGi41fO6DbTg8o6bA239QguXPkfX 0O4k2iqlFd9FcSKWuorIdCy7l1BpOwqYHVjKFYkIxEdp1Kh4fNS040iCfXxN/olb wwtxJvXKZHM7GEU99Boa2O33KFWGEFRef5Jq6RuvjjCNDktZEWm+zWoj/O8Dvt+t 1KGihmzcuXgZW2WQ82N6OnuXZVbt4srBZ+Lxc8CaAiKEGT0PvH852P05wI7RRyck pEOxXUU0UXnLC7Ad6Qh5xparzmegIjKMYvE181PMaSpRPZRD2FLIQEc93KcyjSrg m5F63lqwxMo3ab9+OcCZYqJPGE1yZF3ieuLIkPeOZjfsVjURlFiYvydG5ybONPQV S6SVDhIk5Oaskc1f5lqmzZ/zvOa5A4Y2DiVKBjlJbGoV+q22VvWBdjWhNkMO7a1w N7jB8NHyqY3AuW35ozCmZbSQWqsfE5HopiC3r+QnoItzyxKP19BnOmE8d24Ks2lo ZR6VD3unlTUsqCg5zR8T =eZtO -----END PGP SIGNATURE----- --fNRMcVNMbK6dpQjSoc3BF5BJ5KtwxbJw9-- From nobody Thu Oct 29 04:56:26 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618591B2DC9 for ; Thu, 29 Oct 2015 04:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfZwGXgjh91P for ; Thu, 29 Oct 2015 04:56:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F481B2DC6 for ; Thu, 29 Oct 2015 04:56:24 -0700 (PDT) Received: from localhost ([::1]:46405 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zrloe-0008T2-0A; Thu, 29 Oct 2015 04:56:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 29 Oct 2015 11:56:23 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/192#comment:1 Message-ID: <080.bb461c0cbf10f7fe242aad8cac5079db@trac.tools.ietf.org> References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> X-Trac-Ticket-ID: 192 In-Reply-To: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20151029115624.60F481B2DC6@ietfa.amsl.com> Resent-Date: Thu, 29 Oct 2015 04:56:24 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 11:56:25 -0000 #192: unclear meaning of "configured categories" of dynamically discovered servers Comment (by stefan.winter@restena.lu): in progress; new text proposal on the list -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Oct 29 05:29:02 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6A61B2E67; Thu, 29 Oct 2015 05:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGmMIde1EwMi; Thu, 29 Oct 2015 05:28:58 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC3911B2E69; Thu, 29 Oct 2015 05:28:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CF3A62240B13; Thu, 29 Oct 2015 13:28:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCeSkBC7eoWX; Thu, 29 Oct 2015 13:28:26 +0100 (CET) Received: from [192.168.120.41] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by power.freeradius.org (Postfix) with ESMTPSA id CD15022407AB; Thu, 29 Oct 2015 13:28:25 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: <563204D9.1010401@restena.lu> Date: Thu, 29 Oct 2015 08:28:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <330BC5C5-D84D-4EEC-8656-47FEF6EE37D1@deployingradius.com> References: <55D57021.8060308@restena.lu> <183E3AC7-A5CB-43D4-ADCA-E0B7DD04B43C@deployingradius.com> <563204D9.1010401@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "radext@ietf.org" , draft-ietf-radext-bigger-packets.authors@ietf.org Subject: Re: [radext] Questions about draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 12:29:00 -0000 On Oct 29, 2015, at 7:36 AM, Stefan Winter = wrote: >> On that note: Response-Length is a 2-octet unsigned integer of = maximum response length. >>=20 >> Can that be changed to be of data type "integer"? And maybe = reference data types? >>=20 >> I'll refresh the data types document today. >=20 > Unfortunately, RFC7120 does not foresee early allocation of "IESG > Consensus" type allocations. I meant more that the draft should be updated to use "integer" instead = of a non-standard data type. > I wonder what is the document author's preference: publish the = document > without waiting for an implementation and the accompanying > Implementation Status section? >=20 > Or include such a section, stating that a FreeRADIUS implementation is = WIP? It's hard to have an implementation without an assigned packet code or = attribute. But I think I can put one together with reasonable values... = and make sure to *not* ship before the numbers are allocated through = IANA. Alan DeKok. From nobody Thu Oct 29 06:03:30 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBF21A1A7D; Thu, 29 Oct 2015 06:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WZ5MSmTNvdy; Thu, 29 Oct 2015 06:03:25 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1B61A1A55; Thu, 29 Oct 2015 06:03:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C69D62087A; Thu, 29 Oct 2015 09:01:18 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmX77gaTsRwe; Thu, 29 Oct 2015 09:01:17 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 29 Oct 2015 09:01:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E83F388EBA; Thu, 29 Oct 2015 09:03:19 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <55D57021.8060308@restena.lu> <183E3AC7-A5CB-43D4-ADCA-E0B7DD04B43C@deployingradius.com> <563204D9.1010401@restena.lu> <330BC5C5-D84D-4EEC-8656-47FEF6EE37D1@deployingradius.com> Date: Thu, 29 Oct 2015 09:03:19 -0400 In-Reply-To: <330BC5C5-D84D-4EEC-8656-47FEF6EE37D1@deployingradius.com> (Alan DeKok's message of "Thu, 29 Oct 2015 08:28:24 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Winter Stefan , draft-ietf-radext-bigger-packets.authors@ietf.org, "radext@ietf.org" Subject: Re: [radext] Questions about draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 13:03:30 -0000 I think it's fine to publish this without implementation status section. Alan, what text change do you want for data types? From nobody Thu Oct 29 07:23:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6621B2EF0 for ; Thu, 29 Oct 2015 07:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH2GRxjQAaa1 for ; Thu, 29 Oct 2015 07:23:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14721B2EF2 for ; Thu, 29 Oct 2015 07:23:37 -0700 (PDT) Received: from localhost ([::1]:51199 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zro77-0007uf-IE; Thu, 29 Oct 2015 07:23:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 29 Oct 2015 14:23:37 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/194#comment:2 Message-ID: <080.ab7434d7302ee80632c64b07d2cbaeec@trac.tools.ietf.org> References: <065.ef5bf9284d0e734516ceae66e2ae74f3@trac.tools.ietf.org> X-Trac-Ticket-ID: 194 In-Reply-To: <065.ef5bf9284d0e734516ceae66e2ae74f3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20151029142337.F14721B2EF2@ietfa.amsl.com> Resent-Date: Thu, 29 Oct 2015 07:23:37 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #194 (bigger-packets): find and list implementations X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 14:23:39 -0000 #194: find and list implementations Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => wontfix Comment: author prefers not to have an Implementation Status section -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Oct 29 07:25:31 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D767A1B2EF9 for ; Thu, 29 Oct 2015 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pibmdf0n_XPv for ; Thu, 29 Oct 2015 07:25:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978C61B2EB2 for ; Thu, 29 Oct 2015 07:25:28 -0700 (PDT) Received: from localhost ([::1]:51276 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zro8u-00041l-6L; Thu, 29 Oct 2015 07:25:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 29 Oct 2015 14:25:28 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/196 Message-ID: <065.bb01562e3d7d02fe40d44c004c1246ce@trac.tools.ietf.org> X-Trac-Ticket-ID: 196 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20151029142528.978C61B2EB2@ietfa.amsl.com> Resent-Date: Thu, 29 Oct 2015 07:25:28 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: [radext] #196 (bigger-packets): change data type of Resonse-Length X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 14:25:30 -0000 #196: change data type of Resonse-Length from 2-octet unsigned integer to "integer" as per data types document -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext