From ietf@meetecho.com Thu Aug 1 02:07:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4610121F9D01 for ; Thu, 1 Aug 2013 02:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kegFbwT8ThTS for ; Thu, 1 Aug 2013 02:07:43 -0700 (PDT) Received: from smtpdg5.aruba.it (smtpdg223.aruba.it [62.149.158.223]) by ietfa.amsl.com (Postfix) with ESMTP id F3B7521F9E80 for ; Thu, 1 Aug 2013 02:06:57 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6w1m01E0EaGCq01M6xc5; Thu, 01 Aug 2013 11:06:57 +0200 Date: Thu, 1 Aug 2013 11:06:55 +0200 (CEST) From: Meetecho Team To: radext@ietf.org Message-ID: <720680577.39.1375348015196.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_38_732438683.1375348015194" X-Mailman-Approved-At: Thu, 01 Aug 2013 04:25:28 -0700 Subject: [radext] RADEXT session recording available X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2013 09:07:51 -0000 ------=_Part_38_732438683.1375348015194 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the RADEXT WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#RADEXT For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_38_732438683.1375348015194-- From jouni.nospam@gmail.com Sat Aug 3 13:50:23 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAFE21E8096 for ; Sat, 3 Aug 2013 13:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dU8cnjaJ-GwK for ; Sat, 3 Aug 2013 13:50:21 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5DA11E80A2 for ; Sat, 3 Aug 2013 13:50:21 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id d49so911426eek.34 for ; Sat, 03 Aug 2013 13:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=wpIxY0ItClbsYvOeek2qnCh8hTlJq5D9uoIKpfu2bWQ=; b=cRKYZ/+TgkOls+Ra5Zqm4gW+kcjhNnp/pqEh69aQNnBnQ+QxF4lnPOIkP4ZtotCm3d q/3mT6LYLqf5ZQE6GsNI0+v68jtCSFxBzBMS+0920vu/QRNrVA51jMmsjosYCYkEhcza H0SSVRqYNKwQsdeGAtErkaKn6VlkxmBTApRFk0vjw/umEYgPa/5fIhYZyRJO/uyjX0yS 5p7tHsFUnRR7O2hqTWvy/KYH0qnDGib19+GIWATjZCuxJgd1305C9d/+YiO+ekF3iebC YxBLmL2foaY0qQl08i1pMbk8BFR5tW+vNZ/M+K/yqq1DP3841fNU/SwDEyV5cckGNWv8 HmVg== X-Received: by 10.15.43.11 with SMTP id w11mr10736644eev.27.1375563020341; Sat, 03 Aug 2013 13:50:20 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id x3sm6593449eew.4.2013.08.03.13.50.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Aug 2013 13:50:19 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 3 Aug 2013 23:50:18 +0300 Message-Id: <9542BA90-2FE6-44D0-AF5A-4679998CFF3B@gmail.com> To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "radext-chairs@tools.ietf.org" Subject: [radext] WGLC#3 for draft-ietf-radext-dtls-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 20:50:24 -0000 Folks, The two weeks WGLC#3 for draft-ietf-radext-dtls-06 starts 4-Aug-2013 and ends 18-Aug-2013. If you have comments, please mail them to the list and also create an issue tracker ticket for the comment. Silence on the list is interpreted as an acceptance that the I-D is OK. - Jouni & Mauricio From jouni.nospam@gmail.com Mon Aug 5 01:11:58 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8C421F9C17 for ; Mon, 5 Aug 2013 01:11:57 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR2mePJpbEf1 for ; Mon, 5 Aug 2013 01:11:56 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAF721F9C16 for ; Mon, 5 Aug 2013 01:11:55 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id eo20so1794512lab.6 for ; Mon, 05 Aug 2013 01:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=MkFmXycLdqjoi2qmr22cr6R50nkVNpK6t0cyUsNqps0=; b=Am3LJ3CBUDUUtnHIw2XvR+9yf3k3o4mIXvuPBRjNcIesehVPJXAF6+lsW1E8UDPZKS 3LcZCBpiBaGBC9FfirgLfuWhuB6XDSSzPzfI+14P72vjYFvK6nrBLRptupFW+jaBY4As KhuujC17AkeJ/Is4t6jEUA3uTSZBfkL+QL/8Xh3IRoI7BxJzqmS6aAMU35WivUGm2Bhz 5/VQNaH5rIxE97L38amG/aAZjaDxCq51wqOQC6o8S84z4vebfPf4nLea2vY5GHXMUbef rmbGJsgNRQLzAyIPH3Bslf4aq7QFGwC06rHt78bzBzVr9e79cJfo5trMykmujiYUPQFx xt8A== X-Received: by 10.112.200.37 with SMTP id jp5mr8260477lbc.61.1375690314331; Mon, 05 Aug 2013 01:11:54 -0700 (PDT) Received: from [192.168.250.207] ([194.100.71.98]) by mx.google.com with ESMTPSA id ua4sm8503815lbb.17.2013.08.05.01.11.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 01:11:53 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <77542F32-2978-45B0-92A2-981D6F5DE8DC@gmail.com> Date: Mon, 5 Aug 2013 11:11:52 +0300 To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [radext] Notification of draft-ietf-softwire-map-radius work in Softwire X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 08:11:58 -0000 Folks, Softwire is working on RADIUS attributes & procedures for yet another = IPv6 transition mechanism provisioning & configuration using AAA. I = encourage to follow up the progress of this work, specifically those who = has interest on IPv6. - JOuni (as a co-chair)= From aland@deployingradius.com Tue Aug 6 07:17:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242A621F9A38 for ; Tue, 6 Aug 2013 07:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1mlTwzy275m for ; Tue, 6 Aug 2013 07:17:34 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 335AA21F8D0D for ; Tue, 6 Aug 2013 07:17:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1B338224008D; Tue, 6 Aug 2013 16:16:39 +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 A4O26XffD1AK; Tue, 6 Aug 2013 16:16:36 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 50D5E2240074; Tue, 6 Aug 2013 16:16:36 +0200 (CEST) Message-ID: <52010546.2060103@deployingradius.com> Date: Tue, 06 Aug 2013 10:16:38 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <77542F32-2978-45B0-92A2-981D6F5DE8DC@gmail.com> In-Reply-To: <77542F32-2978-45B0-92A2-981D6F5DE8DC@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , draft-ietf-softwire-map-radius@ietf.org Subject: Re: [radext] Notification of draft-ietf-softwire-map-radius work in Softwire X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 14:17:40 -0000 Jouni Korhonen wrote: > Folks, > > Softwire is working on RADIUS attributes & procedures for yet another IPv6 transition mechanism provisioning & configuration using AAA. I encourage to follow up the progress of this work, specifically those who has interest on IPv6. A quick editorial review: ... the User-password attribute (2) SHOULD be filled by the shared MAP password that has been preconfigured on the DHCPv6 server I would recommend allowing for other forms of authentication. It's nice to suggest User-Password SHOULD be used. But other authentication methods exist, and could be allowed. In both above-mentioned scenarios, Message-authenticator (type 80) [RFC2869] SHOULD be used to protect both Access-Request and Access- Accept messages. The Access-Accept is already signed by the response authenticator. A Message-Authenticator attribute isn't strictly necessary here. ... 4.3.3. Encapsulation/Translation Flag Sub Option This is a boolean flag in 16 bits of space. As per 6158, it should be using a 32-bit integer. The same comment applies to the later sub-options. As an additional note, using pre-defined data types would simplify this draft. Most of the ASCII art could go away, and it would be MUCH clearer when people used "ad hoc" data types, instead of the standard ones. Alan DeKok. From jouni.nospam@gmail.com Fri Aug 9 05:02:37 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EF321F99ED for ; Fri, 9 Aug 2013 05:02:37 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACVhr1CaQ2w2 for ; Fri, 9 Aug 2013 05:02:36 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 647AA21F9A16 for ; Fri, 9 Aug 2013 05:02:30 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id my10so1063101bkb.29 for ; Fri, 09 Aug 2013 05:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=duMhR5h3KRuxeIivd93080V9pu/344R7DGy1qJY/UgE=; b=PKibk7aEhDehmfWHUnLHTZz5+LkaF2dvu2iLj3FxisDHi+wW5f/FXf6hoiS1UBPLft 2Vl45+imEZ1q5ePvhUWAa1jo7I6kdyxWxohcaBCOx9116HRGHDCNpUsFKom8MPm78JE4 rH6S9VAgkAs8RDBMWcs3pT97v1Cvesjxn9sCHUZytYSHvoGqjKFmnjwHli4gS+y5QTsf U4Xusv28okV9OYqX7weE4yEO4XM7eUjYIT+NxeBUUYtc4hY/aVsDcN5CEvAACGEkMRq1 VLb4zOZirAX+tH6nnkpNPOMNrpn8GlNRCkRMsfQGfUPxecMrMh1SKdX+rq8rsd/7aIKn iVwA== X-Received: by 10.205.15.72 with SMTP id pt8mr2149957bkb.17.1376049749909; Fri, 09 Aug 2013 05:02:29 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ct12sm3375310bkb.12.2013.08.09.05.02.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 05:02:29 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 9 Aug 2013 15:02:28 +0300 Message-Id: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "radext-chairs@tools.ietf.org" Subject: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 12:02:38 -0000 Folks, Based on the discussion in Berlin we are ready to start another adoption call for the solution for fragmentation of RADIUS packets. This email starts a two week consensus call on adopting: Filename: draft-perez-radext-radius-fragmentation Revision: 06 Title: Support of fragmentation of RADIUS packets Creation date: 2013-07-02 Express your concerns or support by 23rd August EOB on the mailing list. - Jouni & Mauricio From mauricio.sanchez@hp.com Mon Aug 12 09:08:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B095021E81FA for ; Mon, 12 Aug 2013 09:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.995 X-Spam-Level: X-Spam-Status: No, score=-107.995 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBF9FvLM9y87 for ; Mon, 12 Aug 2013 09:08:04 -0700 (PDT) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 564D811E8116 for ; Mon, 12 Aug 2013 08:29:01 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id CDE37C16D for ; Mon, 12 Aug 2013 15:28:53 +0000 (UTC) Received: from G6W3996.americas.hpqcorp.net (16.205.80.211) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 12 Aug 2013 15:27:56 +0000 Received: from G6W2486.americas.hpqcorp.net ([169.254.9.155]) by G6W3996.americas.hpqcorp.net ([16.205.80.211]) with mapi id 14.03.0123.003; Mon, 12 Aug 2013 15:27:57 +0000 From: "Sanchez, Mauricio" To: "radext@ietf.org" Thread-Topic: RADEXT: IETF87 meeting notes Thread-Index: AQHOl3CF5tTsuDfNRUGmzKHSH30/Hg== Date: Mon, 12 Aug 2013 15:27:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [15.193.49.26] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3459140875_30983269" MIME-Version: 1.0 Subject: [radext] RADEXT: IETF87 meeting notes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Aug 2013 16:08:15 -0000 --B_3459140875_30983269 Content-type: multipart/alternative; boundary="B_3459140874_31011714" --B_3459140874_31011714 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Meeting notes have been uploaded to IETF site. Also pasted below for your review. Any corrections/additions welcome. Thanks go out to Nancy for taking notes. -Jouni and Mauricio --------------- RADEXT IETF 87 Berlin, Germany Tuesday, July 30, 2013 Meeting started 5:01PM and adjourned 6:31PM Chairs: Jouni Korhonen Mauricio Sanchez AD: Benoit Claise 1.Preliminaries Nancy Cam-Winget volunteered to take notes. Mauricio reviews Note Well and agenda; no comments/feedback to agenda Radext status: - RFC6911 now published - RFC6929 now published - Nothing in editor's queue or WLC - Review of current work in progress to be discussed today (e.g. attributes draft has a couple comments that is targeted to address today, DTLS no new version but should be ready for WLC that could start this week, NAI-based discovery does have new version and 1 open issue, fragmentation charter discussion, Radius extended request based on deacon- draft, new work around data types and request go address key management) - Discussion of goals/milestones shows WG is behind by almost a year: focus needs to close these items before adding any new items and/or closing group **************************************************************************** ***** 2.DTLS (Alan deKok) Main diff between last IETF include: - removal of port overloading based on Joe's comments of TLS changing coming and presumptions may no longer apply - need to issue new draft now that freeze is over - no open issues remaining - Mauricio states that next step is WLC after IETF 87 **************************************************************************** ***** 3.NAI (4282 bis...Alan deKok) - new version -04 coming to address Bernard's comment - Sticking points: o Normalization done at edge or core? No one does this right now at edge, do we want to force lots of devices vs. less at the core. Question is whether Unicode string can be normalized without doing anything; while it may be feasible, there may be resistant to change though there may be some places where it is infeasible. Can suggest proxies can normalize, but there are cases in which they can not (if that's the case then use it as an opaque blob) o Feedback from il8n has been very little (they say "maybe") - Mauricio asks if it'd be useful to put it as a request from il8n to get more responses e.g. put more weight behind this? Alan believes "yes" would be good. It'd be useful to have this documented and agree on a standard, so officially asking for a proper response would be helpful. Mauricio and Jouni will work with Alan to elicit better response. - Stefan: situation of # devices at the edge is not as grim as thought. Most deployments would use ascii realm; this would be more for the future so just need to make sure new supplicants can support this. The deployed base should not prevent this from moving forward - Alan: People don't use internationalized domain names; if they are, likely doing it wrong. They take blob and take it to the AAA server and server needs to figure it out....which means upgrades are needed. - Bernard: its really about realm not user name. Needs to compare realm to realm table...basically a domainname and domainname comparison; so if you're able to lookup domainname, it's the same process. So not sure the problem is that complex - Alan: may not doing DNS lookup so you'd have to do domainname comparison themselves; can work with Benoit to get answer from idna (?) people....as they claim use of different formats and hope for the best in interpretation - Stefan: nobody does this because specs is a mess, so Eduroam recognized this and stated not to use it for domainnames. But don't see that this is a big issue, as soon as use internationalized doaminnames these have to be clarified. - Mauricio closes that follow thru is needed with the group. - Bernard: if someone converts, need to determine if it is in il8n form or not - Jim Schaad: believes that is the case - Alan: worries using Unicode version of realname which may be a bad thing to do **************************************************************************** ***** 4.Dynamic Discovery (Stefan Winter) - -07 now to integrate Jim Schaad comments hopefully resolving all of them - Issue based on Trac #168 - Discovery process via NAPTR->SRV do you have to follow all paths? Spec says you don't have to if highest priority is discovered target else have to follow dns flow...needs discussion - Security considerations per Alan's comments as there's a potential DoS and 2nd comment based on misconfigurations regarding negative connection attempts usurping compute power based on excessive retries. Have updated the text to keep memory for a configured time length - Still need to resolve MTI mechanism for server authZ: o Need cert property to express authoritative server for the NAI realm as using subjectaltname:dnsname is sloppy o Doesn't need to be in the same domain as the dns: suggest use UTF8. o Based on posh BoF, Radius is not the only one having this problem...not sure if posh can provide anything for this - Diego Lopez: why look at subjectAltName:nairealm as it may be more sloppy than using CommonName - Stefan: can put realmname in certificate and could buy argument for including it - Diego: could be dirty but quick - Jim: only thing needed in pkix to assign this field...should have no blocking gateway for including this - Stefan: other issue is to get OID assigned. If there's a way to address this, would be good to have a wildcard match (equivalent of accounting departments...but not sure it makes sense) - Joe: agrees that we should not do that as the radius accounting already define how to do the matching - Stefan: not sure the reasons apply, though we should continue to use the wildcard - Joe: this is a little different - Stefan: ok, will change to have wildcards on leftmost label then - Stefan discusses privacy implications per Jim's comments...nothing to be learned by the dns lookups being performed so not sure updates are needed. - Jim: getting more exact info of where user's going to (depending on whether there's a single server acting as a gateway)....learning where a particular server is going to vs. having traffic from radius client to a single radius proxy, now going to a particular radius proxy. Disclosing info on which domains are being traversed. - Stefan: question is who gets to know more or less....proxies would learn more - Jim: it's a question of who the trusted identities are - Stefan: so yes, anyone can observe the traffic, but believes its reasonable tradeoff - Jim: that's fine as long as tradeoff is documented - Stefan: naptr->srv->a/aaaa maintains more state which may be more complex but should be acceptable. But problem is based on misconfiguration: if you should know realm is different than what's on your table, if find it thru the discovery, what to do? That could be bad....if full result is provided then it can help....can do loop detection to address this as discovery can onlyl capture loops introduced due to discovery. As you don't want to spend that much time on discovery especially if accuracy is not required....agrees there's sense to that argument; but no draft/text to do this due to lack of interest....so do we address this as a separate I-D. - Could add a loop detection attribute, but it could be a couple 100's iterations before converging. If looking at recent alignment based on 4K radius boundaries, then limiting rate could help, but more work is needed - Mauricio checks consensus: o After completing our WG items, how many want to address loop detection: mostly consensus to address this - Stefan mentions there could be a draft ready before next IETF **************************************************************************** ***** 5.IEEE 802 attributes (Bernard Aboba) - Bernard asks if any IEEE on meetecho (Jim says Yes, Mick Seaman is on...) - Issues to discuss: o WLAN SSID: suggest to remove it as its redundant to Called-station-ID o Stefan: not catastrophe to remove it, but to address this the fix may not be as clean. Same thing may apply for the MPPE keys o Bernard: if you send this and not the other stuff, you'll break current implementations. This is an interoperability problem....this is same info as the called-station-ID attribute (namely SSID) o Sam: what's status of this document? Would be comfortable if copied text from called station ID into this document o Bernard: OK o Issue with Access-info: this TLV is included in EAPoL announcement and MACSec PDUs...what messages could this go in and what does the NAS do with this? Worked thru with Joe and Brian on the model. Determined that 0 or 1 Access-Info attribute can be present in all RADIUS messages. In the Access-Request it reflects what the use has sent in the Eapol announcement (could be in MACSec PDU or MKA PDU). o Sam: clarify, I'm sending CoA and ask to announce this to the world? o Bernard: if sent with a NID name, its unicast addr and doesn't apply to a port, case where it's a disconnect request o Sam: not necessarily part of the session o Bernard: but you'd be online and want to CoA o Joe: you would be part of it o Sam: but the CoA server could lie o Bernard: all CoA has to be linked to a session o Sam: trusting AAA server to get linking right o Bernard: you have to be specific enough to figure out the destination o Sam: why can't the NAS figure the dest o Bernard: it can. There's a 'specific' and 'generic' as several can be on a generic port o Sam: process problem. CoA is experimental and this normative text depends on CoA...don't understand how this is useful in standards track normative text o Bernard: still applies to Access Accept/Reject/Challenge o Sam: believe CoA description requires a normative down rev o Bernard: we have dozens of documents that mention CoA o Sam: may be but it's a process problem...would like to open an issue that describing CoA usage in standards doc requires down rev to the spec o Bernard: ok, but first need to understand how it works. Back to description: believes it goes in all radius messages...in Accounting Request reflects and EAPol announcement sent from NAS to user o An Eapol-announcement can be for a specific nid or not...need to determine type...if NID is not included then maps to the port...what other TLVs would be relevant? Brian mentioned MACsec cipher suites, key management tlv and organization or more? o Brian Weiss: will need more than one o Bernard: can make it match the 802...so take TLV info string and copy it to Radius. Issue may be whether it fits in a radius packet (vs. breaking each into a separate TLV)...more announcement TLVs may be needed, like organizational specific set or individual TLVs? o Mauricio: if it's a question to the group... o Brian: can't remember diff between set or single organizational tlv o Bernard: but question of do we look at others or do arbitrary assignments? o Mauricio: we're out of time, what next? o Bernard: will send proposal and will discuss in reflector **************************************************************************** ***** 6.Fragmentation (Diego Lopez) - 1st proposal is to add this only applies in authZ exchanges - now in version -06 - addressed comments against -05 version: o clarification of fragmentation mechanism o clarification of the se cases and alternatives in the intro o satisfy abfab requirements o new intro section to highlight scope (including new section for scope, filename and title change) - Discussion of details of authN and authZ o Decompose radius chat in 3 phases: pre-authZ, authZ and post-authZ o Include implementation goals: including open source code - Stefan: believes its work needed in abfab so would support this work, but realizes this is really a hack - Diego: agrees - Stefan: problem would go away if we had bigger packets. What happened to Sam's work in enlarging the packet? - Sam: I support adoption of this draft where there are scenarios that need to work with proxies. Preference is that for TLS we raise the packet size....but didn't get any positive feedback on the reflector for this so didn't move forward. - Stefan: suggests that Sam do generate a draft for this. Follow up is to ask why TCP is different than UDP? So if raise it for TCP/TLS, why not do it for UDP too? There's no inherent reason not to do it - Diego: it is a quick hack and can last for a while - Sam: reason you don't now is it doesn't help with existing proxies. Without a path into the mechanism it doesn't work...udp doesn't have such a path - Mauricio: lots of healthy discussion, not sure if we have convergence for adoption. With the focus change, what's different? Only the messages? - Diego: applies for authZ exchanges only, so scope changes. It originated within abfab and there was a previous misunderstanding - Mauricio: charter is more general so more discussion is needed - Diego: but this is a part of the solution - Mauricio: so implicitly, there'd be other drafts to cover the other or generality - Diego: yes, like Sam's proposal - Mauricio: asks who read draft...answer: a few. Believes this is on trajectory for adoption, so need to put to reflector and ask volunteer review **************************************************************************** ***** 7.Data Types (Alan) - Data types named in RFC 2865 was used but practice has not continued in other RFCs - 3162 "address" is IPv6 and other examples - suggest that data types be defined in a new document and create IANA registry to track data types. Change attribute registry to include data type column and description so that now XML registry can be pulled to create dictionaries and avoid ASCII art - do not see any downside as this is common practice - Mauricio: comments that downside is that its about 10yrs late; as its good to look at historical and put in place improvements for future. But at this time, can't take new work as we need to focus on current backlog items. Propose to keep this in the parking lot and once we reduce backlog, bring it back to the group to see if its adopted as another item to work thru - Alan: may make new standards easier to write, so before we adopt new attributes, this work should precede those. **************************************************************************** ***** 8.Radius extensions for Key Management in WLAN Network (Li Xue) - Lots of discussion on the reflector for why its needed. Review of the use cases... - Traditional operator example use case: service GW connects to AAA, SW and AC. The GW as the management service, then it needs the information as its also acting as the Authenticator. GW is more centralized than an AC. - Define radius packets for sharing key information. Defines 2 new attributes for providing key announcement and key material. - Security considerations will be addressed in future draft - Mauricio: is the intent to have informational or standards track? - Li: wants it to be standards track - Stefan: looking at the problem statement, usually the function is in the AC not SGW....now that you've taken it from AC to SGW things break. Proposing that we fix the break, going out of the way in fixing something that was intended to work one way to make it fit your model; so do not buy into this solution. Is it that your company line is wanting to do it this way? - Li: for the operators there are many reasons that the GW should be the authenticator. If AC is the authenticator and the EAP proxy too. - Stefan: AC is already getting Radius packets already to get the key, so its basically the same code. - Li: not right, because then AC has to be both - Stefan: AC then has to speak some EAP or the GW has to speak all of EAP. I don't think the problem is that complex to address. Don't see what you gain by this proposal - Li: operators want to find a more single solution, want to simplify AC. - Stefan: we can go on, but I still don't see the point. You don't have to do this at the IETF now, you can just try it on your devices first and if you can prove that this is better than what the standards have, then we can contemplate it. You don't need to have standards approval - Mauricio: agrees with Stefan. At this point, can't expand the charter to adopt this as a WG item, but encourage you to keep moving forward in your solution set. Will keep it in the parking lot. Meeting adjourns --B_3459140874_31011714 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Meeting notes have= been uploaded to IETF site. Also pasted below for your review.  Any co= rrections/additions welcome.  Thanks go out to Nancy for taking notes.&= nbsp;

-Jouni and Mauricio
---= ------------


RADEXT
IETF 87
Berlin, Germany

Tuesday, July 30, 2013
Meeting started 5:01PM and adjourned 6:31PM

Chairs:

Jouni Korhonen <jouni.korhonen at renesasmobile.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>



AD:

Benoit Claise <bclaise at cisco.com> 

1.Preliminaries

Nancy Cam-Winget volunteered to take notes. 

Mauricio reviews Note Well and agenda; no comments/feedback to agenda

Radext status:

- RFC6911 now published
- RFC6929 now published
- Nothing in editor's queue or WLC
- Review of current work in progress to be discussed today (e.g. attributes=
 draft has a couple comments that is targeted to address today, DTLS no new =
version but should be ready for WLC that could start this week, NAI-based di=
scovery does have new version and 1 open issue, fragmentation charter discus=
sion, Radius extended request based on deacon- draft, new work around data t=
ypes and request go address key management)
- Discussion of goals/milestones shows WG is behind by almost a year: focus=
 needs to close these items before adding any new items and/or closing group=


***************************************************************************=
******
2.DTLS (Alan deKok)

Main diff between last IETF include:

- removal of port overloading based on Joe's comments of TLS changing comin=
g and presumptions may no longer apply
- need to issue new draft now that freeze is over
- no open issues remaining
- Mauricio states that next step is WLC after IETF 87

***************************************************************************=
******
3.NAI (4282 bis...Alan deKok)

- new version -04 coming to address Bernard's comment
- Sticking points:
o Normalization done at edge or core?  No one does this right now at edge, =
do we want to force lots of devices vs. less at the core.  Question is wheth=
er Unicode string can be normalized without doing anything; while it may be =
feasible, there may be resistant to change though there may be some places w=
here it is infeasible.  Can suggest proxies can normalize, but there are cas=
es in which they can not (if that's the case then use it as an opaque blob)
o Feedback from il8n has been very little (they say "maybe")
- Mauricio asks if it'd be useful to put it as a request from il8n to get m=
ore responses e.g. put more weight behind this?  Alan believes "yes" would b=
e good. It'd be useful to have this documented and agree on a standard, so o=
fficially asking for a proper response would be helpful.  Mauricio and Jouni=
 will work with Alan to elicit better response.
- Stefan: situation of # devices at the edge is not as grim as thought.  Mo=
st deployments would use ascii realm; this would be more for the future so j=
ust need to make sure new supplicants can support this.  The deployed base s=
hould not prevent this from moving forward
- Alan: People don't use internationalized domain names; if they are, likel=
y doing it wrong.  They take blob and take it to the AAA server and server n=
eeds to figure it out....which means upgrades are needed.
- Bernard: its really about realm not user name.  Needs to compare realm to=
 realm table...basically a domainname and domainname comparison; so if you'r=
e able to lookup domainname, it's the same process.  So not sure the problem=
 is that complex
- Alan: may not doing DNS lookup so you'd have to do domainname comparison =
themselves; can work with Benoit to get answer from idna (?) people....as th=
ey claim use of different formats and hope for the best in interpretation
- Stefan: nobody does this because specs is a mess, so Eduroam recognized t=
his and stated not to use it for domainnames.  But don't see that this is a =
big issue, as soon as use internationalized doaminnames these have to be cla=
rified.
- Mauricio closes that follow thru is needed with the group.
- Bernard: if someone converts, need to determine if it is in il8n form or =
not
- Jim Schaad: believes that is the case
- Alan: worries using Unicode version of realname which may be a bad thing =
to do

***************************************************************************=
******
4.Dynamic Discovery (Stefan Winter)

- -07 now to integrate Jim Schaad comments hopefully resolving all of them
- Issue based on Trac #168
- Discovery process via NAPTR->SRV do you have to follow all paths?  Spe=
c says you don't have to if highest priority is discovered target else have =
to follow dns flow...needs discussion
- Security considerations per Alan's comments as there's a potential DoS an=
d 2nd comment based on misconfigurations regarding negative connection attem=
pts usurping compute power based on excessive retries.  Have updated the tex=
t to keep memory for a configured time length
- Still need to resolve MTI mechanism for server authZ:
o   Need cert property to express authoritative server for the NAI realm as=
 using subjectaltname:dnsname is sloppy
o   Doesn't need to be in the same domain as the dns: suggest use UTF8.
o   Based on posh BoF, Radius is not the only one having this problem...not=
 sure if posh can provide anything for this
- Diego Lopez: why look at subjectAltName:nairealm as it may be more sloppy=
 than using CommonName
- Stefan: can put realmname in certificate and could buy argument for inclu=
ding it
- Diego: could be dirty but quick
- Jim: only thing needed in pkix to assign this field...should have no bloc=
king gateway for including this
- Stefan: other issue is to get OID assigned.  If there's a way to address =
this, would be good to have a wildcard match (equivalent of accounting depar=
tments...but not sure it makes sense)
- Joe: agrees that we should not do that as the radius accounting already d=
efine how to do the matching
- Stefan: not sure the reasons apply, though we should continue to use the =
wildcard
- Joe: this is a little different
- Stefan: ok, will change to have wildcards on leftmost label then
- Stefan discusses privacy implications per Jim's comments...nothing to be =
learned by the dns lookups being performed so not sure updates are needed.
- Jim: getting more exact info of where user's going to (depending on wheth=
er there's a single server acting as a gateway)....learning where a particul=
ar server is going to vs. having traffic from radius client to a single radi=
us proxy, now going to a particular radius proxy.  Disclosing info on which =
domains are being traversed.
- Stefan: question is who gets to know more or less....proxies would learn =
more
- Jim: it's a question of who the trusted identities are
- Stefan: so yes, anyone can observe the traffic, but believes its reasonab=
le tradeoff
- Jim: that's fine as long as tradeoff is documented
- Stefan: naptr->srv->a/aaaa maintains more state which may be more c=
omplex but should be acceptable.  But problem is based on misconfiguration: =
if you should know realm is different than what's on your table, if find it =
thru the discovery, what to do?  That could be bad....if full result is prov=
ided then it can help....can do loop detection to address this as discovery =
can onlyl capture loops introduced due to discovery.  As you don't want to s=
pend that much time on discovery especially if accuracy is not required....a=
grees there's sense to that argument; but no draft/text to do this due to la=
ck of interest....so do we address this as a separate I-D.
-  Could add a loop detection attribute, but it could be a couple 100's ite=
rations before converging.  If looking at recent alignment based on 4K radiu=
s boundaries, then limiting rate could help, but more work is needed
-  Mauricio checks consensus:
o   After completing our WG items, how many want to address loop detection:=
  mostly consensus to address this
- Stefan mentions there could be  a draft ready before next IETF

***************************************************************************=
******
5.IEEE 802 attributes (Bernard Aboba)

- Bernard asks if any IEEE on meetecho (Jim says Yes, Mick Seaman is on...)=

- Issues to discuss:
o   WLAN SSID: suggest to remove it as its redundant to Called-station-ID
o   Stefan: not catastrophe to remove it, but to address this the fix may n=
ot be as clean.  Same thing may apply for the MPPE keys
o   Bernard: if you send this and not the other stuff, you'll break current=
 implementations.  This is an interoperability problem....this is same info =
as the called-station-ID attribute (namely SSID)
o   Sam: what's status of this document?  Would be comfortable if copied te=
xt from called station ID into this document
o   Bernard: OK
o   Issue with Access-info:  this TLV is included in EAPoL announcement and=
 MACSec PDUs...what messages could this go in and what does the NAS do with =
this?  Worked thru with Joe and Brian on the model.  Determined that 0 or 1 =
Access-Info attribute can be present in all RADIUS messages.  In the Access-=
Request it reflects what the use has sent in the Eapol announcement (could b=
e in MACSec PDU or MKA PDU). 
o   Sam: clarify, I'm sending CoA and ask to announce this to the world?
o   Bernard: if sent with a NID name, its unicast addr and doesn't apply to=
 a port, case where it's a disconnect request
o   Sam: not necessarily part of the session
o   Bernard: but you'd be online and want to CoA
o   Joe: you would be part of it
o   Sam: but the CoA server could lie
o   Bernard: all CoA has to be linked to a session
o   Sam: trusting AAA server to get linking right
o   Bernard: you have to be specific enough to figure out the destination
o   Sam: why can't the NAS figure the dest
o   Bernard: it can.  There's a 'specific' and 'generic' as several can be =
on a generic port
o   Sam: process problem.  CoA is experimental and this normative text depe=
nds on CoA...don't understand how this is useful in standards track normativ=
e text
o   Bernard: still applies to Access Accept/Reject/Challenge
o   Sam: believe CoA description requires a normative down rev
o   Bernard: we have dozens of documents that mention CoA
o   Sam: may be but it's a process problem...would like to open an issue th=
at describing CoA usage in standards doc requires down rev to the spec
o   Bernard: ok, but first need to understand how it works.  Back to descri=
ption: believes it goes in all radius messages...in Accounting Request refle=
cts and EAPol announcement sent from NAS to user
o   An Eapol-announcement can be for a specific nid or not...need to determ=
ine type...if NID is not included then maps to the port...what other TLVs wo=
uld be relevant?  Brian mentioned MACsec cipher suites, key management tlv a=
nd organization or more?
o   Brian Weiss: will need more than one
o   Bernard: can make it match the 802...so take TLV info string and copy i=
t to Radius.  Issue may be whether it fits in a radius packet (vs. breaking =
each into a separate TLV)...more announcement TLVs may be needed, like organ=
izational specific set or individual TLVs?
o   Mauricio: if it's a question to the group...
o   Brian: can't remember diff between set or single organizational tlv
o   Bernard: but question of do we look at others or do arbitrary assignmen=
ts?
o   Mauricio: we're out of time, what next?
o   Bernard: will send proposal and will discuss in reflector

***************************************************************************=
******
6.Fragmentation (Diego Lopez)

- 1st proposal is to add this only applies in authZ exchanges
- now in version -06
- addressed comments against -05 version:
o   clarification of fragmentation mechanism
o   clarification of the se cases and alternatives in the intro
o   satisfy abfab requirements
o   new intro section to highlight scope (including new section for scope, =
filename and title change)
- Discussion of details of authN and authZ
o   Decompose radius chat in 3 phases: pre-authZ, authZ and post-authZ
o   Include implementation goals: including open source code
- Stefan: believes its work needed in abfab so would support this work, but=
 realizes this is really a hack
- Diego: agrees       
- Stefan: problem would go away if we had bigger packets.  What happened to=
 Sam's work in enlarging the packet?
- Sam: I support adoption of this draft where there are scenarios that need=
 to work with proxies.  Preference is that for TLS we raise the packet size.=
...but didn't get any positive feedback on the reflector for this so didn't =
move forward.
- Stefan: suggests that Sam do generate a draft for this.  Follow up is to =
ask why TCP is different than UDP? So if raise it for TCP/TLS, why not do it=
 for UDP too? There's no inherent reason not to do it
- Diego: it is a quick hack and can last for a while
- Sam: reason you don't now is it doesn't help with existing proxies. Witho=
ut a path into the mechanism it doesn't work...udp doesn't have such a path
- Mauricio: lots of healthy discussion, not sure if we have convergence for=
 adoption.  With the focus change, what's different? Only the messages?
- Diego: applies for authZ exchanges only, so scope changes.  It originated=
 within abfab and there was a previous misunderstanding
- Mauricio: charter is more general so more discussion is needed
- Diego: but this is a part of the solution
- Mauricio: so implicitly, there'd be other drafts to cover the other or ge=
nerality
- Diego: yes, like Sam's proposal
- Mauricio: asks who read draft...answer: a few.  Believes this is on traje=
ctory for adoption, so need to put to reflector and ask volunteer review

***************************************************************************=
******
7.Data Types (Alan)

- Data types named in RFC 2865 was used but practice has not continued in o=
ther RFCs
- 3162 "address" is IPv6 and other examples
- suggest that data types be defined in a new document and create IANA regi=
stry to track data types.  Change attribute registry to include data type co=
lumn and description so that now XML registry can be pulled to create dictio=
naries and avoid ASCII art
- do not see any downside as this is common practice
- Mauricio: comments that downside is that its about 10yrs late; as its goo=
d to look at historical and put in place improvements for future.  But at th=
is time, can't take new work as we need to focus on current backlog items.  =
Propose to keep this in the parking lot and once we reduce backlog, bring it=
 back to the group to see if its adopted as another item to work thru
- Alan: may make new standards easier to write, so before we adopt new attr=
ibutes, this work should precede those.

***************************************************************************=
******
8.Radius extensions for Key Management in WLAN Network (Li Xue)

- Lots of discussion on the reflector for why its needed.  Review of the us=
e cases...
- Traditional operator example use case: service GW connects to AAA, SW and=
 AC.  The GW as the management service, then it needs the information as its=
 also acting as the Authenticator.  GW is more centralized than an AC.
- Define radius packets for sharing key information.  Defines 2 new attribu=
tes for providing key announcement and key material.
- Security considerations will be addressed in future draft
- Mauricio: is the intent to have informational or standards track?
- Li: wants it to be standards track
- Stefan: looking at the problem statement, usually the function is in the =
AC not SGW....now that you've taken it from AC to SGW things break.  Proposi=
ng that we fix the break, going out of the way in fixing something that was =
intended to work one way to make it fit your model; so do not buy into this =
solution.  Is it that your company line is wanting to do it this way?
- Li: for the operators there are many reasons that the GW should be the au=
thenticator.  If AC is the authenticator and the EAP proxy too.
- Stefan: AC is already getting Radius packets already to get the key, so i=
ts basically the same code.
- Li: not right, because then AC has to be both
- Stefan: AC then has to speak some EAP or the GW has to speak all of EAP. =
 I don't think the problem is that complex to address.  Don't see what you g=
ain by this proposal
- Li: operators want to find a more single solution, want to simplify AC. 
- Stefan: we can go on, but I still don't see the point.  You don't have to=
 do this at the IETF now, you can just try it on your devices first and if y=
ou can prove that this is better than what the standards have, then we can c=
ontemplate it. You don't need to have standards approval
- Mauricio: agrees with Stefan.  At this point, can't expand the charter to=
 adopt this as a WG item, but encourage you to keep moving forward in your s=
olution set.  Will keep it in the parking lot.

Meeting adjourns
--B_3459140874_31011714-- --B_3459140875_30983269 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgZSCTPCdvdGeVhNWxxjiB+EbI ZZ67egCUro4FDd4r73YwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwODEyMTUyNzU0WjANBgkqhkiG9w0BAQEFAASCAQB3FO4VfERFlDocvzq8rAEXEL4z 8St6AE7aX94OK7jaxR8ScQAKVrpvwnB6SJJFTQZLCJJoUsD1OVBV6DJ2e6RXw57wQIORGr7H QrwEpVCo06VikAHbKUTS6gNpyW9abGxG22pU0qEv4ZKgGtZfBFiLI1KXXY/TgUUsNouUEYS8 FYDFIzG/vM29W0NBdBCp1Otf9fihQ6TFepvaZutxERriwG3bHNz/6xOdXFCcfjWpkop4W8S6 q1zR4OR35Famk1/lTKX2A9ZIkCdzqgBnBniWdVNEhWy5KxzMagzVmELk5zxOr1Acm2zIbmyO 2lWS1I8iMstrIVQIRhi8gcnsedJ7 --B_3459140875_30983269-- From jouni.nospam@gmail.com Mon Aug 19 00:11:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3759D21F9263 for ; Mon, 19 Aug 2013 00:11:22 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBSwP3qaAWvP for ; Mon, 19 Aug 2013 00:11:21 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B828621F9A64 for ; Mon, 19 Aug 2013 00:11:20 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so3047676lab.16 for ; Mon, 19 Aug 2013 00:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LN/in6wrQlBVhgu1KhDo+vIGUuES2ybUDXqXGDJhE3c=; b=vxi6ybzL/5LpgCQRf3MNauR1/bPx511V2mGdZOIq49SmUOBlSVie/wNoGKdaOPP5F3 xz46wxsquxQv1bXm1T66Srd25eFQDO+uE4L7t2OtGDbpGWcbQgM8qXHY9jMlZWr7ppyL VNd6T1MB80rHqUO9lBhbr9ET0P7+2fdyYVJ9mwFKKd0t6a2j2lJajdYazw5J3RQ3YaBj WkuAl4BK8bmjAl6eXWMo2iCtylekvyP4/LS4IjTTIDPGDtSEhO37UzKf2RRLZ0jDPaT6 aHgMI6nWw8BCoVE2d8+LIZsVhaLzQbJoiWiuyYzA0gcleanGJJOA9CJqd87C1XeM2KuM YFvw== X-Received: by 10.112.24.2 with SMTP id q2mr601323lbf.34.1376896279616; Mon, 19 Aug 2013 00:11:19 -0700 (PDT) Received: from [192.168.250.187] ([194.100.71.98]) by mx.google.com with ESMTPSA id pw4sm4051272lbb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 00:11:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> Date: Mon, 19 Aug 2013 10:11:19 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: "radext-chairs@tools.ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 07:11:22 -0000 A friendly reminder ! On Aug 9, 2013, at 3:02 PM, Jouni Korhonen wrote: > Folks, > > Based on the discussion in Berlin we are ready to start another > adoption call for the solution for fragmentation of RADIUS packets. > > This email starts a two week consensus call on adopting: > > Filename: draft-perez-radext-radius-fragmentation > Revision: 06 > Title: Support of fragmentation of RADIUS packets > Creation date: 2013-07-02 > > Express your concerns or support by 23rd August EOB on the mailing list. > > - Jouni & Mauricio From stefan.winter@restena.lu Wed Aug 21 00:37:47 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EC711E8195 for ; Wed, 21 Aug 2013 00:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z8McnYYcZua for ; Wed, 21 Aug 2013 00:37:31 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 971C921F9AD8 for ; Wed, 21 Aug 2013 00:37:27 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 606D710589 for ; Wed, 21 Aug 2013 09:37:26 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 511581057F for ; Wed, 21 Aug 2013 09:37:26 +0200 (CEST) Message-ID: <52146E31.1030701@restena.lu> Date: Wed, 21 Aug 2013 09:37:21 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: radext@ietf.org References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> In-Reply-To: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bfRRCUk8mSEn72iXtsrd9aMO3xk9lpxEC" X-Virus-Scanned: ClamAV Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 07:37:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bfRRCUk8mSEn72iXtsrd9aMO3xk9lpxEC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I support adoption of this document as an immediate solution to a real-world problem. As stated on the mic in Berlin, a more long-term solution would be to modify the RADIUS protocol to allow more than 4096 bytes, and to transmit over a transport which does not need to resort to UDP fragmentation, i.e. over TCP (with or without TLS). I understand that work to that end is ongoing, but not submitted as an I-D yet. When that work has happened, it may be that the the work done in this draft will eventually become obsolete; but that's not a reason not to adopt it at this point. I've reviewed -06 and have a few nits. 1. Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D You state: "As noted in that document [RFC6158], the practical limit on RADIUS packet sizes is governed by the Path MTU (PMTU), which may be significantly smaller than 4096 octets." I wouldn't phrase it in such a harsh way. A packet with PMTU < packet size <=3D 4096 will lead to UDP fragmentation, sure. But that's not the end of the world. The consequence of it is that you have to make sure you are using sane network equipment which can handle that condition. When that is the case, the practical limit remains the 4096 boundary. In eduroam, we firs thought that we'll have to limit ourselves to the PMTU in an attempt of duck-and-cover, but in the long run, the only sane thing to do was to document that UDP frag support is required, and to shout loudly at operators if we found their equipment not to do it proper= ly. In that light, I see your draft as useful (only) in cases where the data to be transmitted is actually >4096 bytes; for anything below my answer would be "fix your equipment!". In the second bullet, you state that the approach "is not usable". As you explain later in the paragraph, it *is*. It is only very clumsy; some deployments might put enough effort into their setup to get it to work that way. So for this item, I'd rather like to see you state that it is not very practical for most deployments, as opposed to unusable. Your draft is from 2 July, when RADIUS Extensions was already RFC6929; you still mention its draft. Please update the reference. 2. Scope =3D=3D=3D=3D=3D=3D=3D=3D I have trouble parsing the third and fourth para here. First you state that CoA does not need to be fragmented. Then in the next para there seems to be a mechanism that is about: if it is needed anyway, then here's an alternative to do it; the alternative involves sending an Access-Request. I don't understand how this goes together. If it's not needed, it's not needed - and no alternative needs to be specified. I guess the core of my confusion is the sentence "Implementations supporting this specification may not be able to change authorization data for a particular session." Why (they do support fragmentation, but not for this particular session)? And if they can't, why is that a fragmentation problem? I also don't get how the roles are here. A CoA client is often the RADIUS server; the CoA Server is the NAS. In that paragraph, "implementations" seems to be a CoA Server/NAS - because you require such an implementation to send a CoA NAK. If that's true, I wonder why fragmentation would occur; the bulk of the authorization change payload data is sent from the CoA client (RADIUS server) to the CoA Server (NAS). The return is either an ACK or a NAK, but according to RFC5176's Table of Attributes, their content is extremely limited in size. 3. Overview =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As stated above, IMHO your definition of "size limit" should really be exactly 4096 bytes; not the min(PMTU,4096). I also continue my long-standing comment about hazardous unknowns again: You state "The number of attributes encoded in a particular chunk depends on the size limit, the size of each attribute, the number of proxies between client and server, and the overhead for fragmentation signalling attributes." The size limit, size of attributes, and size of fragmentation overhead signalling are known and can be calculated. The "number of proxies between client and server" is UNknown and CANNOT be considered in the chunk size calculation. Even if Proxy-State-Len is able to figure out how many Proxy-State space is needed, it will still be a whacky assumption because those proxies could decide they need to add *more* bytes than just a Proxy-State attribute; they could add or delete more VSAs or arbitrary other attributes. There is no way for an implementation of your draft to know that. I know that sections 5 and 7 speak about this. I just want to reiterate that this is a rather dangerous/necessarily-clumsy area of the spec. E.g. Proxy-State-Len might fail its discovery if the packet size is not monotonically increasing from proxy to proxy. It might be worthwhile to consider if stacking of fragmentation is possible with your draft; i.e. if a proxy receives a chunk, can it use the fragmentation draft to split that incoming packet into chunks on its own again? Can the receiver make sense of that double-fragging? I didn't wrap my head around your draft enough to be able to answer that question myself at this point :-) In the paragraph about the "Extended Type" attributes you introduce a new flag to support chunking. I'm not convinced this is necessary. Sure, RFC6929 requires that all fragments of Long-Extended need to be consecutive, in the same packet, and be in-order. But that is not necessarily something you need to consider; your draft requires to re-assemble the chunks before treating the combined result as packet "as usual". So long as the Long-Extended checks are performed after the re-assembly has been done, all is fine on that layer. 4.1 Pre-authz =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For the last exchange, you incorrectly state "It generates the appropriate response, which can be either Access-Accept or Access-Reject." It may also be an Access-Challenge; imagine a big fragmented packet, out of which one attribute is EAP-Message which starts an EAP conversation. 6. Allowed size =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It might be worthwhile to calculate how much actual fragmented data will be transmittable with 20 such roundtrips, and the maximum possible overhe= ad. I think it would be (4096-517)*19+(4096-517+253) in the worst case (one round-trip's User-Name is actually part of the payload, and not a repetition. 9.1 Legacy proxies =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There is an implicit assumption in the draft that proxies make their routing decisions based on User-Name; that's the reason why User-Name always gets repeated in every chunk. The whole fragmentation along unmodified proxies will break if the proxy uses other attributes for its forwarding decisions, say the SSID part of Called-Station-Id. I don't know how common that is; but your draft should at least explicitly state that User-Name is the (only) attribute that proxies can use to make their forwarding decisions. You may also want to discuss replacing or augmenting the attribute repetition for other attributes as needed; but that increases the complexity of your draft significantly. Actually, now that I think of it, I have heard of (few) eduroam SP RADIUS proxies which decide based on the SSID whether the incoming request is for eduroam (proxy to their national eduroam server) or for something else (proxy elsewhere). So that use case is not completely theoretical. Greetings, Stefan Winter On 09.08.2013 14:02, Jouni Korhonen wrote: > Folks, >=20 > Based on the discussion in Berlin we are ready to start another > adoption call for the solution for fragmentation of RADIUS packets. >=20 > This email starts a two week consensus call on adopting: >=20 > Filename: draft-perez-radext-radius-fragmentation > Revision: 06 > Title: Support of fragmentation of RADIUS packets > Creation date: 2013-07-02 >=20 > Express your concerns or support by 23rd August EOB on the mailing list= =2E >=20 > - Jouni & Mauricio > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=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 --bfRRCUk8mSEn72iXtsrd9aMO3xk9lpxEC 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.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIUbjYACgkQ+jm90f8eFWafOACggFc84T7IUoItZWu6dq8cNdcP ec4An0YS4Amdbs/9K3UXWPkO/2jQuD3T =HJ2t -----END PGP SIGNATURE----- --bfRRCUk8mSEn72iXtsrd9aMO3xk9lpxEC-- From aland@deployingradius.com Wed Aug 21 05:11:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3FC11E8203 for ; Wed, 21 Aug 2013 05:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgLYKDaCP3Tu for ; Wed, 21 Aug 2013 05:11:35 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCA4D11E8209 for ; Wed, 21 Aug 2013 05:11:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1FA0C22400ED; Wed, 21 Aug 2013 14:10:39 +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 z2v+4Kg1GDIa; Wed, 21 Aug 2013 14:10:37 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id EA7282240071; Wed, 21 Aug 2013 14:10:36 +0200 (CEST) Message-ID: <5214AE3C.4010909@deployingradius.com> Date: Wed, 21 Aug 2013 08:10:36 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> In-Reply-To: <52146E31.1030701@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 12:11:40 -0000 Some short responses. The PMTU / 4096 octet problem is one which I think should be supported by the draft. Telling operators to "fix their equipment" works in some cases. In others, it's useful to be able to fragment at sizes which are *known* to work. Fragmentation in this draft is only for authorization (Access-Request / Access-Accept). CoA can be done via sending a CoA with "Service-Type = Additional-Authorization". The client should then do fragmentation as per the draft. It's just too much to add fragmentation in multiple places in the protocol. Additional fragmentation in proxies can be done. But it likely involves re-assembly and subsequent re-sending / re-fragmentation of the entire data. Doing "on the fly" additional fragmentation is just too hard (IMHO). We need a new flag for extended-type attributes. Each Access-Request / Access-Accept packet MUST be a perfect RADIUS packet in and of itself. Some proxies MAY support RFC 6929, and will toss the packet if it isn't formatted correctly. i.e. if the attribute fragments "fall off" the end of a packet. Fragmentation doesn't work with Access-Challenge. There was a lot of discussion between the draft authors about this. The fragmentation is *only* for authorization. And it carries *only* authorization data, not authentication data. Think of it as pausing an existing RADIUS conversation, and inserting a "fragmented data" exchange. We're assuming that proxy decisions are made via User-Name. If it's done via anything else... well... sorry, but it won't work. There are trade-offs which have to be made. And eduroam proxying via SSID is just weird. Isn't the SSID for eduroam just "EDUROAM"? Alan DeKok. From hartmans@painless-security.com Wed Aug 21 05:37:12 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3A21F84B8 for ; Wed, 21 Aug 2013 05:37:12 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ+G9qiAQjgN for ; Wed, 21 Aug 2013 05:37:03 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D4BB411E820F for ; Wed, 21 Aug 2013 05:36:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0AB40202C0; Wed, 21 Aug 2013 08:35:09 -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 YvcmrpssUW-6; Wed, 21 Aug 2013 08:35:08 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 21 Aug 2013 08:35:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B3A4581233; Wed, 21 Aug 2013 08:36:33 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> Date: Wed, 21 Aug 2013 08:36:33 -0400 In-Reply-To: <52146E31.1030701@restena.lu> (Stefan Winter's message of "Wed, 21 Aug 2013 09:37:21 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 12:37:12 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Hello, I support adoption of this document as an immediate Stefan> solution to a real-world problem. Stefan> As stated on the mic in Berlin, a more long-term solution Stefan> would be to modify the RADIUS protocol to allow more than Stefan> 4096 bytes, and to transmit over a transport which does not Stefan> need to resort to UDP fragmentation, i.e. over TCP (with or Stefan> without TLS). I understand that work to that end is ongoing, Stefan> but not submitted as an I-D yet. When that work has Stefan> happened, it may be that the the work done in this draft Stefan> will eventually become obsolete; but that's not a reason not Stefan> to adopt it at this point. I will be submitting such a draft by the next IETF. I actually think this work is an important part of the long-term picture because I think there cre cases where RADIUS UDP is important and probably cases where proxy transparency is critical in the long-term. There are definitely cases where proxy-transparency is critical in the short-term. So, I support adoption, but I also support permitting longer packets over TLS and to the extent practical TCP. (TLS has the nice property of being experimental at this point and while interoperability with the existing implementations for 4k packets is a requirement, I think we have more flexibility than we do for UDP). From peterd@iea-software.com Wed Aug 21 06:32:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4990711E839D for ; Wed, 21 Aug 2013 06:32:52 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kQTn9k9s38i for ; Wed, 21 Aug 2013 06:32:47 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 484C011E8394 for ; Wed, 21 Aug 2013 06:32:42 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 21 Aug 2013 06:32:41 -0700 Date: Wed, 21 Aug 2013 06:32:38 -0700 (Pacific Daylight Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <52146E31.1030701@restena.lu> Message-ID: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 13:32:52 -0000 On Wed, 21 Aug 2013, Stefan Winter wrote: > Hello, > I support adoption of this document as an immediate solution to a > real-world problem. > As stated on the mic in Berlin, a more long-term solution would be to > modify the RADIUS protocol to allow more than 4096 bytes, and to > transmit over a transport which does not need to resort to UDP > fragmentation, i.e. over TCP (with or without TLS). I understand that > work to that end is ongoing, but not submitted as an I-D yet. When that This is supported by my existing I-D. draft-deacon-radext-extended-request-01 regards, Peter From stefan.winter@restena.lu Wed Aug 21 06:45:03 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2011E83C9 for ; Wed, 21 Aug 2013 06:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72AyE722pT52 for ; Wed, 21 Aug 2013 06:45:02 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1B94711E83AD for ; Wed, 21 Aug 2013 06:45:00 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 05F4810589; Wed, 21 Aug 2013 15:45:00 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id E401410581; Wed, 21 Aug 2013 15:44:59 +0200 (CEST) Message-ID: <5214C457.70204@restena.lu> Date: Wed, 21 Aug 2013 15:44:55 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: radext@ietf.org References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> <5214AE3C.4010909@deployingradius.com> In-Reply-To: <5214AE3C.4010909@deployingradius.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VeBegtwmS3JNAQ7u9loQ15uCx4gSu9577" X-Virus-Scanned: ClamAV Cc: Alan DeKok Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 13:45:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VeBegtwmS3JNAQ7u9loQ15uCx4gSu9577 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > The PMTU / 4096 octet problem is one which I think should be supporte= d > by the draft. Telling operators to "fix their equipment" works in some= > cases. In others, it's useful to be able to fragment at sizes which ar= e > *known* to work. I don't have particularly hard feelings about this; so if there's use for it, the text can also stay as it is. > Fragmentation in this draft is only for authorization (Access-Request= > / Access-Accept). CoA can be done via sending a CoA with "Service-Type= > =3D Additional-Authorization". The client should then do fragmentation= as > per the draft. It's just too much to add fragmentation in multiple > places in the protocol. That's how I understood the first two paras in the document. The third one seemed to deal with the CoA-ACK/NAK replies, but there I got lost why these would need to be fragmented. > Additional fragmentation in proxies can be done. But it likely > involves re-assembly and subsequent re-sending / re-fragmentation of th= e > entire data. Doing "on the fly" additional fragmentation is just too > hard (IMHO). So it would suffice to state that chunks are not supposed to be fragmented as-is; they need to be re-assembled into the long packet, and then that needs to be chunked again. > We need a new flag for extended-type attributes. Each Access-Request= > / Access-Accept packet MUST be a perfect RADIUS packet in and of > itself. Some proxies MAY support RFC 6929, and will toss the packet if= > it isn't formatted correctly. i.e. if the attribute fragments "fall > off" the end of a packet. That doesn't seem right. If a proxy supports RFC6929, but not the fragmentation draft, it will not know that the T flag exists and can't react accordingly. It will see an M flag and some gibberish in the Reserved field (which RFC6929 says should simply be ignored). It will observe that the M flag requirements are violated and has every right to drop the packet. > Fragmentation doesn't work with Access-Challenge. There was a lot of= > discussion between the draft authors about this. The fragmentation is > *only* for authorization. And it carries *only* authorization data, no= t > authentication data. Think of it as pausing an existing RADIUS > conversation, and inserting a "fragmented data" exchange. That's understood; I didn't want Access-Challenge packets to be fragmented. My concern was that an initial (long) Access-Request needs to be fragmented, but that upon completing its reassembly, the server side finds that it is in the middle of an exchange which requires Access-Challenge as a subsequent packet. It must be possible to finalise the fragmented packet reassambly not just with an Accept or Reject; it may need to be a Challenge to complete the subsequent authentication that is done after the pre-authz. > We're assuming that proxy decisions are made via User-Name. If it's > done via anything else... well... sorry, but it won't work. There are > trade-offs which have to be made. >=20 > And eduroam proxying via SSID is just weird. Isn't the SSID for > eduroam just "EDUROAM"? Sure it is. But you may be participating in more than one consortium with your hotspot. Imagine a single access point which is part of "eduroam" and "S-Mobile"; and emits both SSIDs. Both consortia use RADIUS auth; the access point is dumb and only knows "its" authentication server. At that point, the RADIUS server which gets the AP's packet needs to realise: if a user tried to log into the eduroam SSID, I'll proxy the packet to eduroam infrastructure; if the user tried S-Mobile, I'll proxy to their infrastructure. That's real life (but not on very many sites, as far as I can see). "Sorry" may well be the appropriate answer. But that answer should be written explicitly into the draft. 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 --VeBegtwmS3JNAQ7u9loQ15uCx4gSu9577 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.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIUxFsACgkQ+jm90f8eFWYCoACfTZmgjVN+zkTwHYUVVSvROWCY InkAnROQFw1hzaQ3SYMtaF7kcCyIkhMJ =NDY5 -----END PGP SIGNATURE----- --VeBegtwmS3JNAQ7u9loQ15uCx4gSu9577-- From peterd@iea-software.com Wed Aug 21 11:05:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79AB11E83E3 for ; Wed, 21 Aug 2013 11:05:25 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-ULET4uWYf4 for ; Wed, 21 Aug 2013 11:05:20 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6F42F11E822C for ; Wed, 21 Aug 2013 11:05:20 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id for ; Wed, 21 Aug 2013 11:05:19 -0700 Date: Wed, 21 Aug 2013 11:05:16 -0700 (Pacific Daylight Time) From: Peter Deacon To: "radext@ietf.org" In-Reply-To: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> Message-ID: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 18:05:26 -0000 On Fri, 9 Aug 2013, Jouni Korhonen wrote: > Based on the discussion in Berlin we are ready to start another > adoption call for the solution for fragmentation of RADIUS packets. I would support this draft with narrower scope as interim solution addressing a specific use. Have some concerns with draft as a general solution: Section 2. RFC5176 dynamic auth clients are not necessarily always RADIUS servers. We have production systems where CoA client and RADIUS server are separate with separate roles. Seeing value in maintaining separation I do not favor Additional-Authorization. Accounting proposal is not atomic and depends on assumptions about type of content. (e.g long attribute not able to fit within 4096 byte limit cannot be transmitted) Proposed 'T' bit in extended long attributes means existing systems supporting extended attributes may require enhancement to pass needed data. Despite 'SHOULD' language from RFC6929 I do not believe it reasonable expectation proxy systems able to understand an attribute known to be broke would elect to forward such an attribute anyway. General. Attribute proxy not possible without proxy server modification to support draft. Existing proxy servers not supporting draft may lose ability to understand/enforce policy when attribute fragmentation is used. Section 5. A policy of limiting large RADIUS UDP packets to MTU would about triple number of round trips needed to convey same information. Section 10. Message-Authenticator does not offer replay protection. Recommend text "This signature prevents forging to the limits of the existing security." regards, Peter From alex@um.es Thu Aug 22 00:24:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8339A21F9D52 for ; Thu, 22 Aug 2013 00:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkpxyhrYEimp for ; Thu, 22 Aug 2013 00:24:19 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 052CA21F9D53 for ; Thu, 22 Aug 2013 00:24:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id E69384BD2F for ; Thu, 22 Aug 2013 09:24:15 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2dfgrPBeSEK4 for ; Thu, 22 Aug 2013 09:24:14 +0200 (CEST) Received: from [192.168.10.2] (84.124.135.236.dyn.user.ono.com [84.124.135.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 010BA4BD2E for ; Thu, 22 Aug 2013 09:24:12 +0200 (CEST) Message-ID: <5215BC9B.2070107@um.es> Date: Thu, 22 Aug 2013 09:24:11 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: radext@ietf.org References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> In-Reply-To: <52146E31.1030701@restena.lu> Content-Type: multipart/alternative; boundary="------------080306030903050805020700" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 07:24:24 -0000 This is a multi-part message in MIME format. --------------080306030903050805020700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stefan, thanks for the thorough review. Let me try to complete Alan's answers. > Hello, > > I support adoption of this document as an immediate solution to a > real-world problem. > > As stated on the mic in Berlin, a more long-term solution would be to > modify the RADIUS protocol to allow more than 4096 bytes, and to > transmit over a transport which does not need to resort to UDP > fragmentation, i.e. over TCP (with or without TLS). I understand that > work to that end is ongoing, but not submitted as an I-D yet. When that > work has happened, it may be that the the work done in this draft will > eventually become obsolete; but that's not a reason not to adopt it at > this point. > > I've reviewed -06 and have a few nits. > > 1. Introduction > =============== > You state: "As noted in that document [RFC6158], the practical > limit on RADIUS packet sizes is governed by the Path MTU (PMTU), > which may be significantly smaller than 4096 octets." > > I wouldn't phrase it in such a harsh way. A packet with > PMTU < packet size <= 4096 > will lead to UDP fragmentation, sure. But that's not the end of the > world. The consequence of it is that you have to make sure you are using > sane network equipment which can handle that condition. When that is the > case, the practical limit remains the 4096 boundary. > > In eduroam, we firs thought that we'll have to limit ourselves to the > PMTU in an attempt of duck-and-cover, but in the long run, the only sane > thing to do was to document that UDP frag support is required, and to > shout loudly at operators if we found their equipment not to do it properly. > > In that light, I see your draft as useful (only) in cases where the data > to be transmitted is actually >4096 bytes; for anything below my answer > would be "fix your equipment!". > > In the second bullet, you state that the approach "is not usable". As > you explain later in the paragraph, it *is*. It is only very clumsy; > some deployments might put enough effort into their setup to get it to > work that way. So for this item, I'd rather like to see you state that > it is not very practical for most deployments, as opposed to unusable. > > Your draft is from 2 July, when RADIUS Extensions was already RFC6929; > you still mention its draft. Please update the reference. > > 2. Scope > ======== > I have trouble parsing the third and fourth para here. First you state > that CoA does not need to be fragmented. Then in the next para there > seems to be a mechanism that is about: if it is needed anyway, then > here's an alternative to do it; the alternative involves sending an > Access-Request. > > I don't understand how this goes together. If it's not needed, it's not > needed - and no alternative needs to be specified. > > I guess the core of my confusion is the sentence "Implementations > supporting this specification may not be able to change authorization > data for a particular session." Why (they do support fragmentation, but > not for this particular session)? And if they can't, why is that a > fragmentation problem? > > I also don't get how the roles are here. A CoA client is often the > RADIUS server; the CoA Server is the NAS. > > In that paragraph, "implementations" seems to be a CoA Server/NAS - > because you require such an implementation to send a CoA NAK. > If that's true, I wonder why fragmentation would occur; the bulk of the > authorization change payload data is sent from the CoA client (RADIUS > server) to the CoA Server (NAS). The return is either an ACK or a NAK, > but according to RFC5176's Table of Attributes, their content is > extremely limited in size. > > 3. Overview > =========== > As stated above, IMHO your definition of "size limit" should really be > exactly 4096 bytes; not the min(PMTU,4096). > > I also continue my long-standing comment about hazardous unknowns again: > You state > > "The number of > attributes encoded in a particular chunk depends on the size limit, > the size of each attribute, the number of proxies between client and > server, and the overhead for fragmentation signalling attributes." > > The size limit, size of attributes, and size of fragmentation overhead > signalling are known and can be calculated. > > The "number of proxies between client and server" is UNknown and CANNOT > be considered in the chunk size calculation. Actually, they are known by the Server, but unknown by the Client. When the server is the one fragmenting information, that information is accurate. > Even if Proxy-State-Len is > able to figure out how many Proxy-State space is needed, it will still > be a whacky assumption because those proxies could decide they need to > add *more* bytes than just a Proxy-State attribute; they could add or > delete more VSAs or arbitrary other attributes. There is no way for an > implementation of your draft to know that. That's right. Proxy-State-Len provides an approximation to that value. A Client will probably adjust chunk size as if Proxy-State-Len would be higher. I agree that being conservative is the best. This calculation mechanisms does not solve all the problems, but IMHO offers more information that using plain RADIUS, where the Client cannot even guess. > I know that sections 5 and 7 > speak about this. I just want to reiterate that this is a rather > dangerous/necessarily-clumsy area of the spec. E.g. Proxy-State-Len > might fail its discovery if the packet size is not monotonically > increasing from proxy to proxy. I agree. This attribute tries to help deciding. A Client may keep sending 1KB chunks no matter what the Proxy-State-Len says. In the worse case, you have plain RADIUS (i.e. chunk size fixed on configuration files). > > It might be worthwhile to consider if stacking of fragmentation is > possible with your draft; i.e. if a proxy receives a chunk, can it use > the fragmentation draft to split that incoming packet into chunks on its > own again? Can the receiver make sense of that double-fragging? I didn't > wrap my head around your draft enough to be able to answer that question > myself at this point :-) No, please :). > > In the paragraph about the "Extended Type" attributes you introduce a > new flag to support chunking. I'm not convinced this is necessary. Sure, > RFC6929 requires that all fragments of Long-Extended need to be > consecutive, in the same packet, and be in-order. But that is not > necessarily something you need to consider; your draft requires to > re-assemble the chunks before treating the combined result as packet "as > usual". So long as the Long-Extended checks are performed after the > re-assembly has been done, all is fine on that layer. > > 4.1 Pre-authz > ============= > For the last exchange, you incorrectly state > "It generates the appropriate response, which can be either > Access-Accept or Access-Reject." > > It may also be an Access-Challenge; imagine a big fragmented packet, out > of which one attribute is EAP-Message which starts an EAP conversation. It will not be an Access-Challenge, as the Access-Request of a pre-authz exchange does not contain any authentication attribute (e.g. EAP-Messsage). It only contains authorization related information, thus suitable responses are Access-Accept (i.e. I correctly received and understood your data), or Access-Reject (i.e. data not understood or not valid). In previous versions of the draft it was possible to do what you said, but we decided to simplify to avoid a lot of troubles if mixing with authentication exchanges. > > 6. Allowed size > =============== > It might be worthwhile to calculate how much actual fragmented data will > be transmittable with 20 such roundtrips, and the maximum possible overhead. > > I think it would be (4096-517)*19+(4096-517+253) in the worst case (one > round-trip's User-Name is actually part of the payload, and not a > repetition. Well, the draft also states to set the limit in a few tens of kilooctets 20. That is, whatever is reached first. Nonetheless, this are recommendations, but it will be a configuration decision, not sure if it is really important to state in the draft. Best regards, Alejandro > 1 Legacy proxies > ================== > There is an implicit assumption in the draft that proxies make their > routing decisions based on User-Name; that's the reason why User-Name > always gets repeated in every chunk. > > The whole fragmentation along unmodified proxies will break if the proxy > uses other attributes for its forwarding decisions, say the SSID part of > Called-Station-Id. > > I don't know how common that is; but your draft should at least > explicitly state that User-Name is the (only) attribute that proxies can > use to make their forwarding decisions. You may also want to discuss > replacing or augmenting the attribute repetition for other attributes as > needed; but that increases the complexity of your draft significantly. > > Actually, now that I think of it, I have heard of (few) eduroam SP > RADIUS proxies which decide based on the SSID whether the incoming > request is for eduroam (proxy to their national eduroam server) or for > something else (proxy elsewhere). So that use case is not completely > theoretical. > > Greetings, > > Stefan Winter > > On 09.08.2013 14:02, Jouni Korhonen wrote: >> Folks, >> >> Based on the discussion in Berlin we are ready to start another >> adoption call for the solution for fragmentation of RADIUS packets. >> >> This email starts a two week consensus call on adopting: >> >> Filename: draft-perez-radext-radius-fragmentation >> Revision: 06 >> Title: Support of fragmentation of RADIUS packets >> Creation date: 2013-07-02 >> >> Express your concerns or support by 23rd August EOB on the mailing list. >> >> - Jouni & Mauricio >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------080306030903050805020700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stefan,

thanks for the thorough review. Let me try to complete Alan's answers.

Hello,

I support adoption of this document as an immediate solution to a
real-world problem.

As stated on the mic in Berlin, a more long-term solution would be to
modify the RADIUS protocol to allow more than 4096 bytes, and to
transmit over a transport which does not need to resort to UDP
fragmentation, i.e. over TCP (with or without TLS). I understand that
work to that end is ongoing, but not submitted as an I-D yet. When that
work has happened, it may be that the the work done in this draft will
eventually become obsolete; but that's not a reason not to adopt it at
this point.

I've reviewed -06 and have a few nits.

1. Introduction
===============
You state: "As noted in that document [RFC6158], the practical
   limit on RADIUS packet sizes is governed by the Path MTU (PMTU),
   which may be significantly smaller than 4096 octets."

I wouldn't phrase it in such a harsh way. A packet with
PMTU < packet size <= 4096
will lead to UDP fragmentation, sure. But that's not the end of the
world. The consequence of it is that you have to make sure you are using
sane network equipment which can handle that condition. When that is the
case, the practical limit remains the 4096 boundary.

In eduroam, we firs thought that we'll have to limit ourselves to the
PMTU in an attempt of duck-and-cover, but in the long run, the only sane
thing to do was to document that UDP frag support is required, and to
shout loudly at operators if we found their equipment not to do it properly.

In that light, I see your draft as useful (only) in cases where the data
to be transmitted is actually >4096 bytes; for anything below my answer
would be "fix your equipment!".

In the second bullet, you state that the approach "is not usable". As
you explain later in the paragraph, it *is*. It is only very clumsy;
some deployments might put enough effort into their setup to get it to
work that way. So for this item, I'd rather like to see you state that
it is not very practical for most deployments, as opposed to unusable.

Your draft is from 2 July, when RADIUS Extensions was already RFC6929;
you still mention its draft. Please update the reference.

2. Scope
========
I have trouble parsing the third and fourth para here. First you state
that CoA does not need to be fragmented. Then in the next para there
seems to be a mechanism that is about: if it is needed anyway, then
here's an alternative to do it; the alternative involves sending an
Access-Request.

I don't understand how this goes together. If it's not needed, it's not
needed - and no alternative needs to be specified.

I guess the core of my confusion is the sentence "Implementations
supporting this specification may not be able to change authorization
data for a particular session." Why (they do support fragmentation, but
not for this particular session)? And if they can't, why is that a
fragmentation problem?

I also don't get how the roles are here. A CoA client is often the
RADIUS server; the CoA Server is the NAS.

In that paragraph, "implementations" seems to be a CoA Server/NAS -
because you require such an implementation to send a CoA NAK.
If that's true, I wonder why fragmentation would occur; the bulk of the
authorization change payload data is sent from the CoA client (RADIUS
server) to the CoA Server (NAS). The return is either an ACK or a NAK,
but according to RFC5176's Table of Attributes, their content is
extremely limited in size.

3. Overview
===========
As stated above, IMHO your definition of "size limit" should really be
exactly 4096 bytes; not the min(PMTU,4096).

I also continue my long-standing comment about hazardous unknowns again:
You state

  "The number of
   attributes encoded in a particular chunk depends on the size limit,
   the size of each attribute, the number of proxies between client and
   server, and the overhead for fragmentation signalling attributes."

The size limit, size of attributes, and size of fragmentation overhead
signalling are known and can be calculated.

The "number of proxies between client and server" is UNknown and CANNOT
be considered in the chunk size calculation.

Actually, they are known by the Server, but unknown by the Client. When the server is the one fragmenting information, that information is accurate.

Even if Proxy-State-Len is
able to figure out how many Proxy-State space is needed, it will still
be a whacky assumption because those proxies could decide they need to
add *more* bytes than just a Proxy-State attribute; they could add or
delete more VSAs or arbitrary other attributes. There is no way for an
implementation of your draft to know that.

That's right. Proxy-State-Len provides an approximation to that value. A Client will probably adjust chunk size as if Proxy-State-Len would be higher. I agree that being conservative is the best.
This calculation mechanisms does not solve all the problems, but IMHO offers more information that using plain RADIUS, where the Client cannot even guess.

I know that sections 5 and 7
speak about this. I just want to reiterate that this is a rather
dangerous/necessarily-clumsy area of the spec. E.g. Proxy-State-Len
might fail its discovery if the packet size is not monotonically
increasing from proxy to proxy.

I agree. This attribute tries to help deciding. A Client may keep sending 1KB chunks no matter what the Proxy-State-Len says. In the worse case, you have plain RADIUS (i.e. chunk size fixed on configuration files).



It might be worthwhile to consider if stacking of fragmentation is
possible with your draft; i.e. if a proxy receives a chunk, can it use
the fragmentation draft to split that incoming packet into chunks on its
own again? Can the receiver make sense of that double-fragging? I didn't
wrap my head around your draft enough to be able to answer that question
myself at this point :-)

No, please :).


In the paragraph about the "Extended Type" attributes you introduce a
new flag to support chunking. I'm not convinced this is necessary. Sure,
RFC6929 requires that all fragments of Long-Extended need to be
consecutive, in the same packet, and be in-order. But that is not
necessarily something you need to consider; your draft requires to
re-assemble the chunks before treating the combined result as packet "as
usual". So long as the Long-Extended checks are performed after the
re-assembly has been done, all is fine on that layer.

4.1 Pre-authz
=============
For the last exchange, you incorrectly state
"It generates the appropriate response, which can be either
Access-Accept or Access-Reject."

It may also be an Access-Challenge; imagine a big fragmented packet, out
of which one attribute is EAP-Message which starts an EAP conversation.

It will not be an Access-Challenge, as the Access-Request of a pre-authz exchange does not contain any authentication attribute (e.g. EAP-Messsage). It only contains authorization related information, thus suitable responses are Access-Accept (i.e. I correctly received and understood your data), or Access-Reject (i.e. data not understood or not valid).

In previous versions of the draft it was possible to do what you said, but we decided to simplify to avoid a lot of troubles if mixing with authentication exchanges.


6. Allowed size
===============
It might be worthwhile to calculate how much actual fragmented data will
be transmittable with 20 such roundtrips, and the maximum possible overhead.

I think it would be (4096-517)*19+(4096-517+253) in the worst case (one
round-trip's User-Name is actually part of the payload, and not a
repetition.

Well, the draft also states to set the limit in a few tens of kilooctets 20. That is, whatever is reached first. Nonetheless, this are recommendations, but it will be a configuration decision, not sure if it is really important to state in the draft.

Best regards,
Alejandro
1 Legacy proxies
==================
There is an implicit assumption in the draft that proxies make their
routing decisions based on User-Name; that's the reason why User-Name
always gets repeated in every chunk.

The whole fragmentation along unmodified proxies will break if the proxy
uses other attributes for its forwarding decisions, say the SSID part of
Called-Station-Id.

I don't know how common that is; but your draft should at least
explicitly state that User-Name is the (only) attribute that proxies can
use to make their forwarding decisions. You may also want to discuss
replacing or augmenting the attribute repetition for other attributes as
needed; but that increases the complexity of your draft significantly.

Actually, now that I think of it, I have heard of (few) eduroam SP
RADIUS proxies which decide based on the SSID whether the incoming
request is for eduroam (proxy to their national eduroam server) or for
something else (proxy elsewhere). So that use case is not completely
theoretical.

Greetings,

Stefan Winter

On 09.08.2013 14:02, Jouni Korhonen wrote:

Folks,

Based on the discussion in Berlin we are ready to start another
adoption call for the solution for fragmentation of RADIUS packets.

This email starts a two week consensus call on adopting:

 Filename:         draft-perez-radext-radius-fragmentation
 Revision:         06
 Title:            Support of fragmentation of RADIUS packets
 Creation date:    2013-07-02

Express your concerns or support by 23rd August EOB on the mailing list.

- Jouni & Mauricio
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext






_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------080306030903050805020700-- From stefan.winter@restena.lu Thu Aug 22 00:53:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B55B21F9F40 for ; Thu, 22 Aug 2013 00:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUOyi2fzJkbk for ; Thu, 22 Aug 2013 00:53:14 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C3B4421F9F3D for ; Thu, 22 Aug 2013 00:53:13 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7178C10589 for ; Thu, 22 Aug 2013 09:53:12 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 655E610581 for ; Thu, 22 Aug 2013 09:53:12 +0200 (CEST) Message-ID: <5215C364.6080502@restena.lu> Date: Thu, 22 Aug 2013 09:53:08 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: radext@ietf.org References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> <5215BC9B.2070107@um.es> In-Reply-To: <5215BC9B.2070107@um.es> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wUKfKb5S84LKpXI2NKfAoPG45FcGKXgG2" X-Virus-Scanned: ClamAV Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 07:53:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wUKfKb5S84LKpXI2NKfAoPG45FcGKXgG2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Actually, they are known by the Server, but unknown by the Client. When= > the server is the one fragmenting information, that information is accu= rate. It doesn't know; it's an estimation which is hopefully rather accurate these days because many sane implementations of forwarding server do add Proxy-State; but they are not at all obliged to. RFC2865, 2.3 "Proxy" states: The forwarding server MAY add one Proxy-State attribute to the packet. (It MUST NOT add more than one.) So your server in the end may see less Proxy-State than there were proxies. This is mostly irrelevant to your draft, because if that proxy didn't add Proxy-State, then is also doesn't consume space in the packet.= OTOH, if that proxy decided that it wants to add other attributes besides Proxy-State, then that proxy *will* have an impact. For extra fun, consider that a proxy may not feel the urge to add an attribute in the request, but does so in the reply. That makes for an asynchronous MTU= ! This begs the question: if a fragmentation-draft-unaware proxy receives a chunk close to 4096, and decides it wants to add an arbitrary attribute on its own, and cannot -> bad luck, discard? I also just found another gem regarding Proxy-State that I wasn't aware of until now: a forwarding server may truncate the Proxy-State values it found from earlier proxies, and only send its new one further on. It merely needs to remember the content of the earlier ones, to add them back in the reply. I'm speaking of this text in the same section: " The forwarding server MAY include the Proxy-State attributes in the access-request when it forwards the request, or MAY omit them in the forwarded request. If the forwarding server omits the Proxy-State attributes in the forwarded access-request, it MUST attach them to the response before sending it to the client." This would totally break your proxy detection. I am not aware of anyone implementing this though. > That's right. Proxy-State-Len provides an approximation to that value. = A > Client will probably adjust chunk size as if Proxy-State-Len would be > higher. I agree that being conservative is the best. > This calculation mechanisms does not solve all the problems, but IMHO > offers more information that using plain RADIUS, where the Client canno= t > even guess. Your 7.1 point 3 does not explicitly mention that the client should leave some leeway. You might want to add a sentence to that effect. >> It might be worthwhile to consider if stacking of fragmentation is >> possible with your draft; i.e. if a proxy receives a chunk, can it use= >> the fragmentation draft to split that incoming packet into chunks on i= ts >> own again? Can the receiver make sense of that double-fragging? I didn= 't >> wrap my head around your draft enough to be able to answer that questi= on >> myself at this point :-) >=20 > No, please :). Okay :-) Alan's response kind of gave a hint already: reassemble the whole packet, add your attributes, chunk it. The question of frag-unaware proxies remains; their only choice is to discard if they can't fit in their attributes. > It will not be an Access-Challenge, as the Access-Request of a pre-auth= z > exchange does not contain any authentication attribute (e.g. > EAP-Messsage). It only contains authorization related information, thus= > suitable responses are Access-Accept (i.e. I correctly received and > understood your data), or Access-Reject (i.e. data not understood or no= t > valid). >=20 > In previous versions of the draft it was possible to do what you said, > but we decided to simplify to avoid a lot of troubles if mixing with > authentication exchanges. That's not what your example does: The packet in 4.1 contains a "User-Password" attribute. Maybe that's a leftover from an earlier rev? >> 6. Allowed size >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> It might be worthwhile to calculate how much actual fragmented data wi= ll >> be transmittable with 20 such roundtrips, and the maximum possible ove= rhead. >> >> I think it would be (4096-517)*19+(4096-517+253) in the worst case (on= e >> round-trip's User-Name is actually part of the payload, and not a >> repetition. >=20 > Well, the draft also states to set the limit in a few tens of kilooctet= s > 20. That is, whatever is reached first. Nonetheless, this are > recommendations, but it will be a configuration decision, not sure if i= t > is really important to state in the draft. My point is that you could give implementers or even deployers some hints regarding "what they get" for specific values. Just stating: when using the default 20 roundtrips maximum ceiling, the amount of data that can be transferred is between x Bytes (lowest overhead) and y Bytes (highest overhead). It makes life easier for people who want or need to judge whether the default value is good enough for their implementation or deployment. It's just a suggestion for readability / comprehensability of the draft anyway. Greetings, Stefan >=20 > Best regards, > Alejandro >> 1 Legacy proxies >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> There is an implicit assumption in the draft that proxies make their >> routing decisions based on User-Name; that's the reason why User-Name >> always gets repeated in every chunk. >> >> The whole fragmentation along unmodified proxies will break if the pro= xy >> uses other attributes for its forwarding decisions, say the SSID part = of >> Called-Station-Id. >> >> I don't know how common that is; but your draft should at least >> explicitly state that User-Name is the (only) attribute that proxies c= an >> use to make their forwarding decisions. You may also want to discuss >> replacing or augmenting the attribute repetition for other attributes = as >> needed; but that increases the complexity of your draft significantly.= >> >> Actually, now that I think of it, I have heard of (few) eduroam SP >> RADIUS proxies which decide based on the SSID whether the incoming >> request is for eduroam (proxy to their national eduroam server) or for= >> something else (proxy elsewhere). So that use case is not completely >> theoretical. >> >> Greetings, >> >> Stefan Winter >> >> On 09.08.2013 14:02, Jouni Korhonen wrote: >>> Folks, >>> >>> Based on the discussion in Berlin we are ready to start another >>> adoption call for the solution for fragmentation of RADIUS packets. >>> >>> This email starts a two week consensus call on adopting: >>> >>> Filename: draft-perez-radext-radius-fragmentation >>> Revision: 06 >>> Title: Support of fragmentation of RADIUS packets >>> Creation date: 2013-07-02 >>> >>> Express your concerns or support by 23rd August EOB on the mailing li= st. >>> >>> - Jouni & Mauricio >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >>> >> >> >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=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 --wUKfKb5S84LKpXI2NKfAoPG45FcGKXgG2 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.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIVw2gACgkQ+jm90f8eFWabOgCfS63Gtf1i1P3ukMqQ6f9+vO97 K0AAn03EpB8wwIICJrdOg9j93bkzVI2M =P0Iz -----END PGP SIGNATURE----- --wUKfKb5S84LKpXI2NKfAoPG45FcGKXgG2-- From alex@um.es Thu Aug 22 00:56:31 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF7911E80F9 for ; Thu, 22 Aug 2013 00:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIzQaiRVM3gG for ; Thu, 22 Aug 2013 00:56:27 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id B68EC11E815C for ; Thu, 22 Aug 2013 00:56:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id E49F04BD88 for ; Thu, 22 Aug 2013 09:56:25 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yYKlrxG0tMFi for ; Thu, 22 Aug 2013 09:56:25 +0200 (CEST) Received: from [192.168.10.2] (84.124.135.236.dyn.user.ono.com [84.124.135.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 0EDF64BD20 for ; Thu, 22 Aug 2013 09:56:23 +0200 (CEST) Message-ID: <5215C426.2040603@um.es> Date: Thu, 22 Aug 2013 09:56:22 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: radext@ietf.org References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> <5214AE3C.4010909@deployingradius.com> <5214C457.70204@restena.lu> In-Reply-To: <5214C457.70204@restena.lu> Content-Type: multipart/alternative; boundary="------------000007060503090902040306" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 07:56:32 -0000 This is a multi-part message in MIME format. --------------000007060503090902040306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 21/08/13 15:44, Stefan Winter escribió: > Hi, > >> The PMTU / 4096 octet problem is one which I think should be supported >> by the draft. Telling operators to "fix their equipment" works in some >> cases. In others, it's useful to be able to fragment at sizes which are >> *known* to work. > I don't have particularly hard feelings about this; so if there's use > for it, the text can also stay as it is. > >> Fragmentation in this draft is only for authorization (Access-Request >> / Access-Accept). CoA can be done via sending a CoA with "Service-Type >> = Additional-Authorization". The client should then do fragmentation as >> per the draft. It's just too much to add fragmentation in multiple >> places in the protocol. > That's how I understood the first two paras in the document. The third > one seemed to deal with the CoA-ACK/NAK replies, but there I got lost > why these would need to be fragmented. We will improve that paragraph, to make it clearer. > >> Additional fragmentation in proxies can be done. But it likely >> involves re-assembly and subsequent re-sending / re-fragmentation of the >> entire data. Doing "on the fly" additional fragmentation is just too >> hard (IMHO). > So it would suffice to state that chunks are not supposed to be > fragmented as-is; they need to be re-assembled into the long packet, and > then that needs to be chunked again. We could add that sentence if it serves to clarify further that aspect. > >> We need a new flag for extended-type attributes. Each Access-Request >> / Access-Accept packet MUST be a perfect RADIUS packet in and of >> itself. Some proxies MAY support RFC 6929, and will toss the packet if >> it isn't formatted correctly. i.e. if the attribute fragments "fall >> off" the end of a packet. > That doesn't seem right. If a proxy supports RFC6929, but not the > fragmentation draft, it will not know that the T flag exists and can't > react accordingly. It will see an M flag and some gibberish in the > Reserved field (which RFC6929 says should simply be ignored). It will > observe that the M flag requirements are violated and has every right to > drop the packet. Probably you are right. Indeed we have repeatedly discuss about that flag's utility, but we decided that having it will not harm anyone. However, it makes specification slightly complexer, and if it is not really useful, I agree it should be just removed. > >> Fragmentation doesn't work with Access-Challenge. There was a lot of >> discussion between the draft authors about this. The fragmentation is >> *only* for authorization. And it carries *only* authorization data, not >> authentication data. Think of it as pausing an existing RADIUS >> conversation, and inserting a "fragmented data" exchange. > That's understood; I didn't want Access-Challenge packets to be > fragmented. My concern was that an initial (long) Access-Request needs > to be fragmented, but that upon completing its reassembly, the server > side finds that it is in the middle of an exchange which requires > Access-Challenge as a subsequent packet. It must be possible to finalise > the fragmented packet reassambly not just with an Accept or Reject; it > may need to be a Challenge to complete the subsequent authentication > that is done after the pre-authz. Nope, the first Access-Request packet of an Authentication conversation is supposed to not need to be fragmented, as authentication mechanisms (e.g. RADIUS-EAP) already deal with packet size. If a Client generates a large Access-Request packet with EAP-Message, would be most probably to the inclusion of additional authorization attributes, and then, a pre-authz exchange is the way to go. > >> We're assuming that proxy decisions are made via User-Name. If it's >> done via anything else... well... sorry, but it won't work. There are >> trade-offs which have to be made. >> >> And eduroam proxying via SSID is just weird. Isn't the SSID for >> eduroam just "EDUROAM"? > Sure it is. But you may be participating in more than one consortium > with your hotspot. > > Imagine a single access point which is part of "eduroam" and "S-Mobile"; > and emits both SSIDs. Both consortia use RADIUS auth; the access point > is dumb and only knows "its" authentication server. > > At that point, the RADIUS server which gets the AP's packet needs to > realise: if a user tried to log into the eduroam SSID, I'll proxy the > packet to eduroam infrastructure; if the user tried S-Mobile, I'll proxy > to their infrastructure. > > That's real life (but not on very many sites, as far as I can see). > > "Sorry" may well be the appropriate answer. But that answer should be > written explicitly into the draft. We need to clearly state that, so far, proxying is only supported by means of User-Name attribute. Although I guess that's allowing a different attribute could be something configurable. Best regards, Alejandro > > Greetings, > > Stefan Winter > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------000007060503090902040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
El 21/08/13 15:44, Stefan Winter escribió:
Hi,


  The PMTU / 4096 octet problem is one which I think should be supported
by the draft.  Telling operators to "fix their equipment" works in some
cases.  In others, it's useful to be able to fragment at sizes which are
*known* to work.

I don't have particularly hard feelings about this; so if there's use
for it, the text can also stay as it is.


  Fragmentation in this draft is only for authorization (Access-Request
/ Access-Accept).  CoA can be done via sending a CoA with "Service-Type
= Additional-Authorization".  The client should then do fragmentation as
per the draft.  It's just too much to add fragmentation in multiple
places in the protocol.

That's how I understood the first two paras in the document. The third
one seemed to deal with the CoA-ACK/NAK replies, but there I got lost
why these would need to be fragmented.

We will improve that paragraph, to make it clearer.



  Additional fragmentation in proxies can be done.  But it likely
involves re-assembly and subsequent re-sending / re-fragmentation of the
entire data.  Doing "on the fly" additional fragmentation is just too
hard (IMHO).

So it would suffice to state that chunks are not supposed to be
fragmented as-is; they need to be re-assembled into the long packet, and
then that needs to be chunked again.

We could add that sentence if it serves to clarify further that aspect. 



  We need a new flag for extended-type attributes.  Each Access-Request
 / Access-Accept packet MUST be a perfect RADIUS packet in and of
itself.  Some proxies MAY support RFC 6929, and will toss the packet if
it isn't formatted correctly.  i.e. if the attribute fragments "fall
off" the end of a packet.

That doesn't seem right. If a proxy supports RFC6929, but not the
fragmentation draft, it will not know that the T flag exists and can't
react accordingly. It will see an M flag and some gibberish in the
Reserved field (which RFC6929 says should simply be ignored). It will
observe that the M flag requirements are violated and has every right to
drop the packet.

Probably you are right. Indeed we have repeatedly discuss about that flag's utility, but we decided that having it will not harm anyone. However, it makes specification slightly complexer, and if it is not really useful, I agree it should be just removed. 



  Fragmentation doesn't work with Access-Challenge.  There was a lot of
discussion between the draft authors about this.  The fragmentation is
*only* for authorization.  And it carries *only* authorization data, not
authentication data.  Think of it as pausing an existing RADIUS
conversation, and inserting a "fragmented data" exchange.

That's understood; I didn't want Access-Challenge packets to be
fragmented. My concern was that an initial (long) Access-Request needs
to be fragmented, but that upon completing its reassembly, the server
side finds that it is in the middle of an exchange which requires
Access-Challenge as a subsequent packet. It must be possible to finalise
the fragmented packet reassambly not just with an Accept or Reject; it
may need to be a Challenge to complete the subsequent authentication
that is done after the pre-authz.

Nope, the first Access-Request packet of an Authentication conversation is supposed to not need to be fragmented, as authentication mechanisms (e.g. RADIUS-EAP) already deal with packet size. If a Client generates a large Access-Request packet with EAP-Message, would be most probably to the inclusion of additional authorization attributes, and then, a pre-authz exchange is the way to go.



  We're assuming that proxy decisions are made via User-Name.  If it's
done via anything else... well... sorry, but it won't work.  There are
trade-offs which have to be made.

  And eduroam proxying via SSID is just weird.  Isn't the SSID for
eduroam just "EDUROAM"?

Sure it is. But you may be participating in more than one consortium
with your hotspot.

Imagine a single access point which is part of "eduroam" and "S-Mobile";
and emits both SSIDs. Both consortia use RADIUS auth; the access point
is dumb and only knows "its" authentication server.

At that point, the RADIUS server which gets the AP's packet needs to
realise: if a user tried to log into the eduroam SSID, I'll proxy the
packet to eduroam infrastructure; if the user tried S-Mobile, I'll proxy
to their infrastructure.

That's real life (but not on very many sites, as far as I can see).

"Sorry" may well be the appropriate answer. But that answer should be
written explicitly into the draft.

We need to clearly state that, so far, proxying is only supported by means of User-Name attribute. Although I guess that's allowing a different attribute could be something configurable.

Best regards,
Alejandro

Greetings,

Stefan Winter




_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------000007060503090902040306-- From alex@um.es Thu Aug 22 01:11:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6511E8168 for ; Thu, 22 Aug 2013 01:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwIIvLo9O5da for ; Thu, 22 Aug 2013 01:11:03 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id A249D11E810D for ; Thu, 22 Aug 2013 01:10:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id DF27C4BD88 for ; Thu, 22 Aug 2013 10:10:55 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GFXx1D2C5lap for ; Thu, 22 Aug 2013 10:10:55 +0200 (CEST) Received: from [192.168.10.2] (84.124.135.236.dyn.user.ono.com [84.124.135.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id BAD474BD8C for ; Thu, 22 Aug 2013 10:10:54 +0200 (CEST) Message-ID: <5215C78D.4050501@um.es> Date: Thu, 22 Aug 2013 10:10:53 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: radext@ietf.org References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> <5215BC9B.2070107@um.es> <5215C364.6080502@restena.lu> In-Reply-To: <5215C364.6080502@restena.lu> Content-Type: multipart/alternative; boundary="------------020300040108090407030800" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 08:11:10 -0000 This is a multi-part message in MIME format. --------------020300040108090407030800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 22/08/13 09:53, Stefan Winter escribió: > Hi, > >> Actually, they are known by the Server, but unknown by the Client. When >> the server is the one fragmenting information, that information is accurate. > It doesn't know; it's an estimation which is hopefully rather accurate > these days because many sane implementations of forwarding server do add > Proxy-State; but they are not at all obliged to. I meant, when the server is sending chunks, it will know exactly how much space it needs to leave for sending back the received Proxy-State attributes, isn't it. (I will say otherwise below, after knowing more about proxy state behaviour :D) > > RFC2865, 2.3 "Proxy" states: > > The forwarding server MAY add one Proxy-State attribute to the > packet. (It MUST NOT add more than one.) > > So your server in the end may see less Proxy-State than there were > proxies. This is mostly irrelevant to your draft, because if that proxy > didn't add Proxy-State, then is also doesn't consume space in the packet. > > OTOH, if that proxy decided that it wants to add other attributes > besides Proxy-State, then that proxy *will* have an impact. For extra > fun, consider that a proxy may not feel the urge to add an attribute in > the request, but does so in the reply. That makes for an asynchronous MTU! > > This begs the question: if a fragmentation-draft-unaware proxy receives > a chunk close to 4096, and decides it wants to add an arbitrary > attribute on its own, and cannot -> bad luck, discard? Exactly, just like it happens today with RADIUS. > > I also just found another gem regarding Proxy-State that I wasn't aware > of until now: a forwarding server may truncate the Proxy-State values it > found from earlier proxies, and only send its new one further on. It > merely needs to remember the content of the earlier ones, to add them > back in the reply. I'm speaking of this text in the same section: > > " The forwarding server MAY > include the Proxy-State attributes in the access-request when it > forwards the request, or MAY omit them in the forwarded request. If > the forwarding server omits the Proxy-State attributes in the > forwarded access-request, it MUST attach them to the response before > sending it to the client." > > This would totally break your proxy detection. I am not aware of anyone > implementing this though. Oh, I did not know either. This would complicate things, as the packet may grow arbitrarily between the Client and the Server, without any of them knowing that. That makes even more important to leave a "safety" margin. > >> That's right. Proxy-State-Len provides an approximation to that value. A >> Client will probably adjust chunk size as if Proxy-State-Len would be >> higher. I agree that being conservative is the best. >> This calculation mechanisms does not solve all the problems, but IMHO >> offers more information that using plain RADIUS, where the Client cannot >> even guess. > Your 7.1 point 3 does not explicitly mention that the client should > leave some leeway. You might want to add a sentence to that effect. Sure. It should be stated. > >>> It might be worthwhile to consider if stacking of fragmentation is >>> possible with your draft; i.e. if a proxy receives a chunk, can it use >>> the fragmentation draft to split that incoming packet into chunks on its >>> own again? Can the receiver make sense of that double-fragging? I didn't >>> wrap my head around your draft enough to be able to answer that question >>> myself at this point :-) >> No, please :). > Okay :-) Alan's response kind of gave a hint already: reassemble the > whole packet, add your attributes, chunk it. > > The question of frag-unaware proxies remains; their only choice is to > discard if they can't fit in their attributes. Well, that's right. > >> It will not be an Access-Challenge, as the Access-Request of a pre-authz >> exchange does not contain any authentication attribute (e.g. >> EAP-Messsage). It only contains authorization related information, thus >> suitable responses are Access-Accept (i.e. I correctly received and >> understood your data), or Access-Reject (i.e. data not understood or not >> valid). >> >> In previous versions of the draft it was possible to do what you said, >> but we decided to simplify to avoid a lot of troubles if mixing with >> authentication exchanges. > That's not what your example does: The packet in 4.1 contains a > "User-Password" attribute. > > Maybe that's a leftover from an earlier rev? Sure, it should be removed. Thanks! > >>> 6. Allowed size >>> =============== >>> It might be worthwhile to calculate how much actual fragmented data will >>> be transmittable with 20 such roundtrips, and the maximum possible overhead. >>> >>> I think it would be (4096-517)*19+(4096-517+253) in the worst case (one >>> round-trip's User-Name is actually part of the payload, and not a >>> repetition. >> Well, the draft also states to set the limit in a few tens of kilooctets >> 20. That is, whatever is reached first. Nonetheless, this are >> recommendations, but it will be a configuration decision, not sure if it >> is really important to state in the draft. > My point is that you could give implementers or even deployers some > hints regarding "what they get" for specific values. Just stating: when > using the default 20 roundtrips maximum ceiling, the amount of data that > can be transferred is between x Bytes (lowest overhead) and y Bytes > (highest overhead). > > It makes life easier for people who want or need to judge whether the > default value is good enough for their implementation or deployment. > It's just a suggestion for readability / comprehensability of the draft > anyway. You are right, but in this particular portion of the text, 20 roundtrips means exactly that, 20 roundtrips. We also added a byte-based limit: "a few tens of kilooctets". Probably that limit should be more specific, like 15 kilooctets, or 32. Anyway, if you think it would increase readability, it won't harm :). Best regards, Alejandro > > Greetings, > > Stefan > >> Best regards, >> Alejandro >>> 1 Legacy proxies >>> ================== >>> There is an implicit assumption in the draft that proxies make their >>> routing decisions based on User-Name; that's the reason why User-Name >>> always gets repeated in every chunk. >>> >>> The whole fragmentation along unmodified proxies will break if the proxy >>> uses other attributes for its forwarding decisions, say the SSID part of >>> Called-Station-Id. >>> >>> I don't know how common that is; but your draft should at least >>> explicitly state that User-Name is the (only) attribute that proxies can >>> use to make their forwarding decisions. You may also want to discuss >>> replacing or augmenting the attribute repetition for other attributes as >>> needed; but that increases the complexity of your draft significantly. >>> >>> Actually, now that I think of it, I have heard of (few) eduroam SP >>> RADIUS proxies which decide based on the SSID whether the incoming >>> request is for eduroam (proxy to their national eduroam server) or for >>> something else (proxy elsewhere). So that use case is not completely >>> theoretical. >>> >>> Greetings, >>> >>> Stefan Winter >>> >>> On 09.08.2013 14:02, Jouni Korhonen wrote: >>>> Folks, >>>> >>>> Based on the discussion in Berlin we are ready to start another >>>> adoption call for the solution for fragmentation of RADIUS packets. >>>> >>>> This email starts a two week consensus call on adopting: >>>> >>>> Filename: draft-perez-radext-radius-fragmentation >>>> Revision: 06 >>>> Title: Support of fragmentation of RADIUS packets >>>> Creation date: 2013-07-02 >>>> >>>> Express your concerns or support by 23rd August EOB on the mailing list. >>>> >>>> - Jouni & Mauricio >>>> _______________________________________________ >>>> radext mailing list >>>> radext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/radext >>>> >>> >>> >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >> >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------020300040108090407030800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
El 22/08/13 09:53, Stefan Winter escribió:
Hi,


Actually, they are known by the Server, but unknown by the Client. When
the server is the one fragmenting information, that information is accurate.

It doesn't know; it's an estimation which is hopefully rather accurate
these days because many sane implementations of forwarding server do add
Proxy-State; but they are not at all obliged to.

I meant, when the server is sending chunks, it will know exactly how much space it needs to leave for sending back the received Proxy-State attributes, isn't it. (I will say otherwise below, after knowing more about proxy state behaviour :D)


RFC2865, 2.3 "Proxy" states:

The forwarding server MAY add one Proxy-State attribute to the
      packet.  (It MUST NOT add more than one.)

So your server in the end may see less Proxy-State than there were
proxies. This is mostly irrelevant to your draft, because if that proxy
didn't add Proxy-State, then is also doesn't consume space in the packet.

OTOH, if that proxy decided that it wants to add other attributes
besides Proxy-State, then that proxy *will* have an impact. For extra
fun, consider that a proxy may not feel the urge to add an attribute in
the request, but does so in the reply. That makes for an asynchronous MTU!

This begs the question: if a fragmentation-draft-unaware proxy receives
a chunk close to 4096, and decides it wants to add an arbitrary
attribute on its own, and cannot -> bad luck, discard?
Exactly, just like it happens today with RADIUS.


I also just found another gem regarding Proxy-State that I wasn't aware
of until now: a forwarding server may truncate the Proxy-State values it
found from earlier proxies, and only send its new one further on. It
merely needs to remember the content of the earlier ones, to add them
back in the reply. I'm speaking of this text in the same section:

"  The forwarding server MAY
   include the Proxy-State attributes in the access-request when it
   forwards the request, or MAY omit them in the forwarded request.  If
   the forwarding server omits the Proxy-State attributes in the
   forwarded access-request, it MUST attach them to the response before
   sending it to the client."

This would totally break your proxy detection. I am not aware of anyone
implementing this though.

Oh, I did not know either. This would complicate things, as the packet may grow arbitrarily between the Client and the Server, without any of them knowing that. That makes even more important to leave a "safety" margin.



That's right. Proxy-State-Len provides an approximation to that value. A
Client will probably adjust chunk size as if Proxy-State-Len would be
higher. I agree that being conservative is the best.
This calculation mechanisms does not solve all the problems, but IMHO
offers more information that using plain RADIUS, where the Client cannot
even guess.

Your 7.1 point 3 does not explicitly mention that the client should
leave some leeway. You might want to add a sentence to that effect.

Sure. It should be stated.



It might be worthwhile to consider if stacking of fragmentation is
possible with your draft; i.e. if a proxy receives a chunk, can it use
the fragmentation draft to split that incoming packet into chunks on its
own again? Can the receiver make sense of that double-fragging? I didn't
wrap my head around your draft enough to be able to answer that question
myself at this point :-)

No, please :).

Okay :-) Alan's response kind of gave a hint already: reassemble the
whole packet, add your attributes, chunk it.

The question of frag-unaware proxies remains; their only choice is to
discard if they can't fit in their attributes.

Well, that's right.



It will not be an Access-Challenge, as the Access-Request of a pre-authz
exchange does not contain any authentication attribute (e.g.
EAP-Messsage). It only contains authorization related information, thus
suitable responses are Access-Accept (i.e. I correctly received and
understood your data), or Access-Reject (i.e. data not understood or not
valid).

In previous versions of the draft it was possible to do what you said,
but we decided to simplify to avoid a lot of troubles if mixing with
authentication exchanges.

That's not what your example does: The packet in 4.1 contains a
"User-Password" attribute.

Maybe that's a leftover from an earlier rev?

Sure, it should be removed. Thanks!



6. Allowed size
===============
It might be worthwhile to calculate how much actual fragmented data will
be transmittable with 20 such roundtrips, and the maximum possible overhead.

I think it would be (4096-517)*19+(4096-517+253) in the worst case (one
round-trip's User-Name is actually part of the payload, and not a
repetition.

Well, the draft also states to set the limit in a few tens of kilooctets
20. That is, whatever is reached first. Nonetheless, this are
recommendations, but it will be a configuration decision, not sure if it
is really important to state in the draft.

My point is that you could give implementers or even deployers some
hints regarding "what they get" for specific values. Just stating: when
using the default 20 roundtrips maximum ceiling, the amount of data that
can be transferred is between x Bytes (lowest overhead) and y Bytes
(highest overhead).

It makes life easier for people who want or need to judge whether the
default value is good enough for their implementation or deployment.
It's just a suggestion for readability / comprehensability of the draft
anyway.

You are right, but in this particular portion of the text, 20 roundtrips means exactly that, 20 roundtrips. We also added a byte-based limit: "a few tens of kilooctets".
Probably that limit should be more specific, like 15 kilooctets, or 32. Anyway, if you think it would increase readability, it won't harm :).

Best regards,
Alejandro 


Greetings,

Stefan


Best regards,
Alejandro

1 Legacy proxies
==================
There is an implicit assumption in the draft that proxies make their
routing decisions based on User-Name; that's the reason why User-Name
always gets repeated in every chunk.

The whole fragmentation along unmodified proxies will break if the proxy
uses other attributes for its forwarding decisions, say the SSID part of
Called-Station-Id.

I don't know how common that is; but your draft should at least
explicitly state that User-Name is the (only) attribute that proxies can
use to make their forwarding decisions. You may also want to discuss
replacing or augmenting the attribute repetition for other attributes as
needed; but that increases the complexity of your draft significantly.

Actually, now that I think of it, I have heard of (few) eduroam SP
RADIUS proxies which decide based on the SSID whether the incoming
request is for eduroam (proxy to their national eduroam server) or for
something else (proxy elsewhere). So that use case is not completely
theoretical.

Greetings,

Stefan Winter

On 09.08.2013 14:02, Jouni Korhonen wrote:

Folks,

Based on the discussion in Berlin we are ready to start another
adoption call for the solution for fragmentation of RADIUS packets.

This email starts a two week consensus call on adopting:

 Filename:         draft-perez-radext-radius-fragmentation
 Revision:         06
 Title:            Support of fragmentation of RADIUS packets
 Creation date:    2013-07-02

Express your concerns or support by 23rd August EOB on the mailing list.

- Jouni & Mauricio
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext




_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext



_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext






_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------020300040108090407030800-- From alex@um.es Thu Aug 22 01:20:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7DC11E810D for ; Thu, 22 Aug 2013 01:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=-1.399, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R-OYsCDdRRG for ; Thu, 22 Aug 2013 01:20:07 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 86D8E11E8180 for ; Thu, 22 Aug 2013 01:20:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 7D4065D5B4 for ; Thu, 22 Aug 2013 10:19:59 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TSQfKXmKdEHh for ; Thu, 22 Aug 2013 10:19:58 +0200 (CEST) Received: from [192.168.10.2] (84.124.135.236.dyn.user.ono.com [84.124.135.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id D24B25D575 for ; Thu, 22 Aug 2013 10:19:58 +0200 (CEST) Message-ID: <5215C9AD.1060805@um.es> Date: Thu, 22 Aug 2013 10:19:57 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: radext@ietf.org References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 08:20:15 -0000 Hello Peter, thanks for the comments. See some responses below. El 21/08/13 20:05, Peter Deacon escribió: > On Fri, 9 Aug 2013, Jouni Korhonen wrote: > >> Based on the discussion in Berlin we are ready to start another >> adoption call for the solution for fragmentation of RADIUS packets. > > I would support this draft with narrower scope as interim solution > addressing a specific use. > > Have some concerns with draft as a general solution: > > Section 2. > > RFC5176 dynamic auth clients are not necessarily always RADIUS > servers. We have production systems where CoA client and RADIUS server > are separate with separate roles. Seeing value in maintaining > separation I do not favor Additional-Authorization. > > Accounting proposal is not atomic and depends on assumptions about > type of content. (e.g long attribute not able to fit within 4096 byte > limit cannot be transmitted) I probably misunderstood your comment. We do not deal with CoA or Accounting exchanges. They are left the way they are. > > Proposed 'T' bit in extended long attributes means existing systems > supporting extended attributes may require enhancement to pass needed > data. Despite 'SHOULD' language from RFC6929 I do not believe it > reasonable expectation proxy systems able to understand an attribute > known to be broke would elect to forward such an attribute anyway. umm, you are probably right. Let's see what Alan says about this. > > General. > > Attribute proxy not possible without proxy server modification to > support draft. > > Existing proxy servers not supporting draft may lose ability to > understand/enforce policy when attribute fragmentation is used. According to your previous comment, that would be partially true, but only when the proxy supports RFC6929. > > Section 5. > > A policy of limiting large RADIUS UDP packets to MTU would about > triple number of round trips needed to convey same information. That's probably right. You are able to send the data, but you have to pay a price. Compromise is the key here. > > Section 10. > > Message-Authenticator does not offer replay protection. Recommend > text "This signature prevents forging to the limits of the existing > security." Thanks, we will update the text accordingly. Regards, Alejandro > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Aug 22 06:14:37 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AAE11E81B8 for ; Thu, 22 Aug 2013 06:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9QDFP-E3f+0 for ; Thu, 22 Aug 2013 06:14:31 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD711E81C1 for ; Thu, 22 Aug 2013 06:14:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 90D572240144; Thu, 22 Aug 2013 15:14:27 +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 x-LP0bxw1zif; Thu, 22 Aug 2013 15:14:27 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id EDB9F224013E; Thu, 22 Aug 2013 15:14:26 +0200 (CEST) Message-ID: <52160EB3.9070603@deployingradius.com> Date: Thu, 22 Aug 2013 09:14:27 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 13:14:37 -0000 Peter Deacon wrote: > RFC5176 dynamic auth clients are not necessarily always RADIUS servers. > We have production systems where CoA client and RADIUS server are > separate with separate roles. Seeing value in maintaining separation I > do not favor Additional-Authorization. There is a network connecting the machines. The RADIUS server can proxy Access-Requests to the maching hosting the CoA information. > Accounting proposal is not atomic and depends on assumptions about type > of content. (e.g long attribute not able to fit within 4096 byte limit > cannot be transmitted) There has been no demonstrated need for large accounting packets. > Proposed 'T' bit in extended long attributes means existing systems > supporting extended attributes may require enhancement to pass needed > data. Despite 'SHOULD' language from RFC6929 I do not believe it > reasonable expectation proxy systems able to understand an attribute > known to be broke would elect to forward such an attribute anyway. There are no deployed proxies which implement 6929. The implementations could support the "T" bit before this document is finalized. Nothing prevents implementations from adding new, non-standardized functionality. > General. > > Attribute proxy not possible without proxy server modification to > support draft. The only issue is the T bit. No other proxy modifications are required. > Existing proxy servers not supporting draft may lose ability to > understand/enforce policy when attribute fragmentation is used. Tough. Existing proxy servers which don't implement RFC 6929 won't understand / enforce policies when RFC 6929 attributes are used. This argument is, IMHO, ridiculous. If we are to believe it at face value, it means we cannot implement ANY new feature in RADIUS. Because existing proxies won't be able to enforce policies for those new features. If you want to shut down all progress in RADEXT, just say so. There's no need to repeatedly bring up specious arguments. > A policy of limiting large RADIUS UDP packets to MTU would about triple > number of round trips needed to convey same information. Some systems don't support UDP fragmentation, and drop all fragmented UDP packets. So one alternative is to have *no* RADIUS traffic go through the network. You may think that's better. I don't. Alan DeKok. From aland@deployingradius.com Thu Aug 22 06:19:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6756611E81C4 for ; Thu, 22 Aug 2013 06:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNAfJTrtv5ZQ for ; Thu, 22 Aug 2013 06:19:11 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 869BD11E81B8 for ; Thu, 22 Aug 2013 06:19:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2AEE72240144; Thu, 22 Aug 2013 15:18:42 +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 91miLdv2OpL0; Thu, 22 Aug 2013 15:18:40 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 27675224013E; Thu, 22 Aug 2013 15:18:40 +0200 (CEST) Message-ID: <52160FB0.30208@deployingradius.com> Date: Thu, 22 Aug 2013 09:18:40 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> <5214AE3C.4010909@deployingradius.com> <5214C457.70204@restena.lu> In-Reply-To: <5214C457.70204@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 13:19:17 -0000 Stefan Winter wrote: > That doesn't seem right. If a proxy supports RFC6929, but not the > fragmentation draft, it will not know that the T flag exists and can't > react accordingly. It will see an M flag and some gibberish in the > Reserved field (which RFC6929 says should simply be ignored). It will > observe that the M flag requirements are violated and has every right to > drop the packet. Yes. That presumes (a) everyone implements RFC 6929, and (b) those implementations get deployed to proxies. I don't think either will happen for a while. That limits the problems with this approach. > Imagine a single access point which is part of "eduroam" and "S-Mobile"; > and emits both SSIDs. Both consortia use RADIUS auth; the access point > is dumb and only knows "its" authentication server. > > At that point, the RADIUS server which gets the AP's packet needs to > realise: if a user tried to log into the eduroam SSID, I'll proxy the > packet to eduroam infrastructure; if the user tried S-Mobile, I'll proxy > to their infrastructure. I think initially the idea is to have fragmentation from server to server. i.e. few (if any) APs will be implementing it. So the issue becomes less relevant. A server local to the AP can track a users session, including SSID. And then make proxy decisions based on that. The proxies in the wider network will *not* know about the site's SSID, and will *not* be basing proxy decisions on it. Alan DeKok. From peterd@iea-software.com Thu Aug 22 09:48:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B297611E80FC for ; Thu, 22 Aug 2013 09:48:16 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuBzXerCPjlc for ; Thu, 22 Aug 2013 09:48:11 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5B34911E80E3 for ; Thu, 22 Aug 2013 09:48:11 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 22 Aug 2013 09:48:10 -0700 Date: Thu, 22 Aug 2013 09:48:08 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <52160EB3.9070603@deployingradius.com> Message-ID: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52160EB3.9070603@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 16:48:16 -0000 On Thu, 22 Aug 2013, Alan DeKok wrote: >> RFC5176 dynamic auth clients are not necessarily always RADIUS servers. >> We have production systems where CoA client and RADIUS server are >> separate with separate roles. Seeing value in maintaining separation I >> do not favor Additional-Authorization. > There is a network connecting the machines. The RADIUS server can > proxy Access-Requests to the maching hosting the CoA information. Speaking for myself this is problematic. Dynamic auth clients are just clients with no capability to act as RADIUS server. They only manage a subset of possible authorization parameters not capable of full response. The argument is not whether it is possible to coordinate rather value in maintaining separation. If transport limits are lifted rather than supporting adoption of this draft none of these "workarounds" are necessary. >> Accounting proposal is not atomic and depends on assumptions about type >> of content. (e.g long attribute not able to fit within 4096 byte limit >> cannot be transmitted) > There has been no demonstrated need for large accounting packets. If authors see no value recommend removing associated references from draft. >> Proposed 'T' bit in extended long attributes means existing systems >> supporting extended attributes may require enhancement to pass needed >> data. Despite 'SHOULD' language from RFC6929 I do not believe it >> reasonable expectation proxy systems able to understand an attribute >> known to be broke would elect to forward such an attribute anyway. > There are no deployed proxies which implement 6929. The Incorrect > implementations could support the "T" bit before this document is > finalized. Nothing prevents implementations from adding new, > non-standardized functionality. If modification is necessary I see no value in supporting this draft vs solutions addressing underlying transport limit. The whole point was that it work with existing systems unmodified. >> General. >> Attribute proxy not possible without proxy server modification to >> support draft. > The only issue is the T bit. No other proxy modifications are required. I apologize for any confusion. By attribute proxy I mean forwarding requests based on attributes other than User-Name. >> Existing proxy servers not supporting draft may lose ability to >> understand/enforce policy when attribute fragmentation is used. > Tough. Existing proxy servers which don't implement RFC 6929 won't > understand / enforce policies when RFC 6929 attributes are used. > This argument is, IMHO, ridiculous. If we are to believe it at face > value, it means we cannot implement ANY new feature in RADIUS. Because > existing proxies won't be able to enforce policies for those new > features. My understanding is both existing and new attributes may be conveyed using the fragmentation mechanism. Existing attributes may end up being transmitted in separate requests where previously they would have to occur in the same request. >> A policy of limiting large RADIUS UDP packets to MTU would about triple >> number of round trips needed to convey same information. > Some systems don't support UDP fragmentation, and drop all fragmented > UDP packets. So one alternative is to have *no* RADIUS traffic go > through the network. > You may think that's better. I don't. This is an edge problem within most operators administrative control to effect. regards, Peter From aland@deployingradius.com Thu Aug 22 16:17:39 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6586221F9D09 for ; Thu, 22 Aug 2013 16:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNKKZkpkdUqG for ; Thu, 22 Aug 2013 16:17:33 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78E5D11E826D for ; Thu, 22 Aug 2013 16:17:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8324F2240144; Fri, 23 Aug 2013 01:17:18 +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 rXteLcQEHKhK; Fri, 23 Aug 2013 01:17:16 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 1B76C224013E; Fri, 23 Aug 2013 01:17:16 +0200 (CEST) Message-ID: <52169BFE.7020404@deployingradius.com> Date: Thu, 22 Aug 2013 19:17:18 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52160EB3.9070603@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 23:17:39 -0000 Peter Deacon wrote: > Speaking for myself this is problematic. Dynamic auth clients are just > clients with no capability to act as RADIUS server. They only manage a > subset of possible authorization parameters not capable of full response. Would it be possible to change them? After all, implementing any draft requires changes to existing systems. As with anything RADIUS, no proposal will be perfect. There may be some situations where the proposal doesn't match existing practices. e.g. multiple clients behind a NAT. The solution isn't to give on the proposal and walk away. The solution may be to say that certain situations are simply not supported. > The argument is not whether it is possible to coordinate rather value in > maintaining separation. If transport limits are lifted rather than > supporting adoption of this draft none of these "workarounds" are > necessary. Write a draft proposing to lift the transport limits for UDP. Make it handle all of the existing situations. e.g. "my upstream equipment doesn't deal with fragmented UDP packets, therefore I absolutely oppose raising the transport limits". When you replace one imperfect proposal with another imperfect proposal because the first one is imperfect... I just find it unproductive. > I apologize for any confusion. By attribute proxy I mean forwarding > requests based on attributes other than User-Name. See my response to Stefan. Are there roaming federations which proxy based on anything *other* than User-Name? If so, I'm unaware of them. What you do in your own network is your issue. However, the draft could be clearer, and state that private networks need to do something so that the fragmentation proxy works. > My understanding is both existing and new attributes may be conveyed > using the fragmentation mechanism. Existing attributes may end up being > transmitted in separate requests where previously they would have to > occur in the same request. Yes. This does not address my counter-argument. > [ re: UDP fragmentation] > > This is an edge problem within most operators administrative control to > effect. Maybe. Do a search for "SIP UDP fragmentation", and you'll see many complaints. The summary is that fragmented UDP packets are not generally supported across the Internet. An operator may be able to fix their own equipment. They do *not* have the capability to fix someone else's equipment. Alan DeKok. From peterd@iea-software.com Thu Aug 22 17:12:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049C121F9D0D for ; Thu, 22 Aug 2013 17:12:53 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PY94nLG03Bc for ; Thu, 22 Aug 2013 17:12:48 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id D0A3E21F9D1E for ; Thu, 22 Aug 2013 17:12:47 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 22 Aug 2013 17:12:46 -0700 Date: Thu, 22 Aug 2013 17:12:45 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <5215C9AD.1060805@um.es> Message-ID: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5215C9AD.1060805@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 00:12:53 -0000 On Thu, 22 Aug 2013, Alejandro Perez Mendez wrote: > Hello Peter, > thanks for the comments. See some responses below. >>> Based on the discussion in Berlin we are ready to start another >>> adoption call for the solution for fragmentation of RADIUS packets. >> I would support this draft with narrower scope as interim solution >> addressing a specific use. >> Have some concerns with draft as a general solution: >> Section 2. >> RFC5176 dynamic auth clients are not necessarily always RADIUS servers. >> We have production systems where CoA client and RADIUS server are >> separate with separate roles. Seeing value in maintaining separation I >> do not favor Additional-Authorization. >> Accounting proposal is not atomic and depends on assumptions about type >> of content. (e.g long attribute not able to fit within 4096 byte limit >> cannot be transmitted) > I probably misunderstood your comment. We do not deal with CoA or > Accounting exchanges. They are left the way they are. Hi Alejandro, >From section 2 "scope of this document". Perhaps it might be best to simply address what is supported and remove extraneous references to what is not changed (CoA and Accounting). Specifically: " Instead, the CoA client MUST send a CoA-Request packet containing session identification attributes, along with Service-Type = Additional- Authorization, and a State attribute. Implementations not supporting fragmentation will respond with a CoA-NAK, and an Error-Cause of Unsupported-Service. Implementations supporting this specification may not be able to change authorization data for a particular session. In that case, they MUST respond with a CoA-NAK, as above. Otherwise, the implementation MUST start fragmentation via Access-Request, using the methods defined here." >> Proposed 'T' bit in extended long attributes means existing systems >> supporting extended attributes may require enhancement to pass needed >> data. Despite 'SHOULD' language from RFC6929 I do not believe it >> reasonable expectation proxy systems able to understand an attribute >> known to be broke would elect to forward such an attribute anyway. >> Attribute proxy not possible without proxy server modification to >> support draft. >> Existing proxy servers not supporting draft may lose ability to >> understand/enforce policy when attribute fragmentation is used. > According to your previous comment, that would be partially true, but > only when the proxy supports RFC6929. Thinking about a case where there is a fragmented "Pre-authorization" request. Attributes normally sent with Access-Request could be scattered about in different Access-Requests requests? I'm a little confused with "authentication" terminology normally during Access-Request there are attributes which provide context to authentication and then attributes which perform authentication. Attributes normally in Access-Request that are not passwords or EAPs is essentially "Pre-authorization" or is there another separation? >From section 2 " Specifically, its scope is limited to the exchange of authorization data, as other exchanges do not require of such a mechanism. In particular, authentication exchanges have already been defined to overcome this limitation" Is this still true in -06? For example am I allowed to send NAS-Id in first request and a NAS-Port-Type attribute in subsequent message where they are later combined by RADIUS server? If so just as an example what happens if an old proxy server is doing something that depends on both of these items being present? If just one is present there could be behavior it misses? regards, Peter From alex@um.es Fri Aug 23 04:27:21 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A30B21F9D82 for ; Fri, 23 Aug 2013 04:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELOgsC3ONEM1 for ; Fri, 23 Aug 2013 04:27:15 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id F18D721F9A81 for ; Fri, 23 Aug 2013 04:27:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 45BB05D499; Fri, 23 Aug 2013 13:27:13 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pXMcbEnkdvzg; Fri, 23 Aug 2013 13:27:12 +0200 (CEST) Received: from [192.168.10.2] (84.124.135.236.dyn.user.ono.com [84.124.135.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPSA id 56E805D490; Fri, 23 Aug 2013 13:27:10 +0200 (CEST) Message-ID: <5217470D.3090606@um.es> Date: Fri, 23 Aug 2013 13:27:09 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Deacon References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5215C9AD.1060805@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 11:27:22 -0000 El 23/08/13 02:12, Peter Deacon escribió: > On Thu, 22 Aug 2013, Alejandro Perez Mendez wrote: > >> Hello Peter, >> thanks for the comments. See some responses below. > >>>> Based on the discussion in Berlin we are ready to start another >>>> adoption call for the solution for fragmentation of RADIUS packets. > >>> I would support this draft with narrower scope as interim solution >>> addressing a specific use. > >>> Have some concerns with draft as a general solution: > >>> Section 2. >>> RFC5176 dynamic auth clients are not necessarily always RADIUS >>> servers. We have production systems where CoA client and RADIUS >>> server are separate with separate roles. Seeing value in >>> maintaining separation I do not favor Additional-Authorization. > >>> Accounting proposal is not atomic and depends on assumptions about >>> type of content. (e.g long attribute not able to fit within 4096 >>> byte limit cannot be transmitted) > >> I probably misunderstood your comment. We do not deal with CoA or >> Accounting exchanges. They are left the way they are. > > Hi Alejandro, > > From section 2 "scope of this document". Perhaps it might be best to > simply address what is supported and remove extraneous references to > what is not changed (CoA and Accounting). Specifically: > > " Instead, the > CoA client MUST send a CoA-Request packet containing session > identification attributes, along with Service-Type = Additional- > Authorization, and a State attribute. Implementations not supporting > fragmentation will respond with a CoA-NAK, and an Error-Cause of > Unsupported-Service. > > Implementations supporting this specification may not be able to > change authorization data for a particular session. In that case, > they MUST respond with a CoA-NAK, as above. Otherwise, the > implementation MUST start fragmentation via Access-Request, using the > methods defined here." > The purpose of that text is to explain why we do not deal with CoA or Accounting, that is, why they do not need of a fragmentation solution. Removing them would provoke other people to ask why we do not support them. >>> Proposed 'T' bit in extended long attributes means existing systems >>> supporting extended attributes may require enhancement to pass >>> needed data. Despite 'SHOULD' language from RFC6929 I do not believe >>> it reasonable expectation proxy systems able to understand an >>> attribute known to be broke would elect to forward such an attribute >>> anyway. > >>> Attribute proxy not possible without proxy server modification to >>> support draft. > >>> Existing proxy servers not supporting draft may lose ability to >>> understand/enforce policy when attribute fragmentation is used. > >> According to your previous comment, that would be partially true, but >> only when the proxy supports RFC6929. > > Thinking about a case where there is a fragmented "Pre-authorization" > request. Attributes normally sent with Access-Request could be > scattered about in different Access-Requests requests? > > I'm a little confused with "authentication" terminology normally > during Access-Request there are attributes which provide context to > authentication and then attributes which perform authentication. > > Attributes normally in Access-Request that are not passwords or EAPs > is essentially "Pre-authorization" or is there another separation? They are completely different exchanges, composed by different packets. Let me picture it. Let's imagine the following exchange where, in addition to the usual authentication exchange (that is, RADIUS-EAP), the NAS wants to send a SAML request to the AS, that will be replied after the User has been authenticated. SAML messages could exceed the 4096 limit. User ----- EAP-Identity ---> NAS (triggers a RADIUS conversation) Pre-authorization exchange: NAS needs to send authz data to AS prior authentication. This is actually carried out by a series of Access-Request/Access-Accept exchanges. NAS ----- SAML request ---> AS Authentication exchange: typical RADIUS-EAP exchange. No changes at all. NAS ----- EAP-Identity ---> AS NAS <---- EAP ---> AS NAS <---- Access-Accept---- AS Post authorization exchange: AS needs to send authz data to NAS after authentication. This is actually carried out by a series of Access-Accept/Access-Request exchanges. NAS <---- SAML Response---- AS All these exchanges are tied together by the use of the State attribute. I hope this clarifies the concepts > > From section 2 > > " Specifically, its scope is limited to the exchange of authorization > data, as other exchanges do not require of such a mechanism. In > particular, authentication exchanges have already been defined to > overcome this limitation" > > Is this still true in -06? That paragraph just states that current existing authentication exchanges (e.g. RADIUS-EAP) already deal with fragmentation issues. That's why we do not interfere. > > For example am I allowed to send NAS-Id in first request and a > NAS-Port-Type attribute in subsequent message where they are later > combined by RADIUS server? If so just as an example what happens if > an old proxy server is doing something that depends on both of these > items being present? If just one is present there could be behavior > it misses? Alan provided an answer to this in relation to Stefan's comments: We're assuming that proxy decisions are made via User-Name. Regards, Alejandro > > regards, > Peter From stefan.winter@restena.lu Fri Aug 23 05:01:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77F011E80FF for ; Fri, 23 Aug 2013 05:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JygRz0huy1WB for ; Fri, 23 Aug 2013 05:01:27 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D46F411E81B1 for ; Fri, 23 Aug 2013 05:01:24 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 3BCD510589 for ; Fri, 23 Aug 2013 14:01:22 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2E33610581 for ; Fri, 23 Aug 2013 14:01:22 +0200 (CEST) Message-ID: <52174F0D.4040103@restena.lu> Date: Fri, 23 Aug 2013 14:01:17 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: radext@ietf.org References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> <5214AE3C.4010909@deployingradius.com> <5214C457.70204@restena.lu> <52160FB0.30208@deployingradius.com> In-Reply-To: <52160FB0.30208@deployingradius.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FrniBkPmoDMjwXhBievuUSI29HlVtmKCA" X-Virus-Scanned: ClamAV Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:01:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FrniBkPmoDMjwXhBievuUSI29HlVtmKCA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> That doesn't seem right. If a proxy supports RFC6929, but not the >> fragmentation draft, it will not know that the T flag exists and can't= >> react accordingly. It will see an M flag and some gibberish in the >> Reserved field (which RFC6929 says should simply be ignored). It will >> observe that the M flag requirements are violated and has every right = to >> drop the packet. >=20 > Yes. That presumes (a) everyone implements RFC 6929, and (b) those > implementations get deployed to proxies. Most RADIUS servers are versaitle enough to act as server and proxy; Radiator has hinted towards 6929 support soon, and I believe your FreeRADIUS is a reference implementation of it since a long time. Both can proxy, and both are in wide-spread use. I think the issue is not artificial; it may well bite a deployment in its backside. That's not the end of the world though; simply adding a sentence in the draft such a case exists and that deployments need to take care that their deployed implementation(s) don't stumble over this. > I think initially the idea is to have fragmentation from server to > server. i.e. few (if any) APs will be implementing it. So the issue > becomes less relevant. Aha! I had the impression that authz exchanges in the ABFAB world go all the way from/to the RADIUS client that does the whole GSS EAP magic. And that this is the equivalent of an "AP" in the non-network-access use case= =2E > A server local to the AP can track a users session, including SSID. > And then make proxy decisions based on that. The proxies in the wider > network will *not* know about the site's SSID, and will *not* be basing= > proxy decisions on it. That's something I can live with. Again, documenting in the draft that User-Name is the only proxying criterion would be enough for me then. Maybe a second one explaining that client to first-server is not in scope/has complexities that can make the use of this draft hard/unsuitabl= e. Greetings, Stefan >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=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 --FrniBkPmoDMjwXhBievuUSI29HlVtmKCA 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.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIXTxEACgkQ+jm90f8eFWbFSQCdHYI43EXJtomoC4aTgwL3GQE3 2n8An2LL+LTFKjs93PXEg0qE1Du2Mm/f =HI3F -----END PGP SIGNATURE----- --FrniBkPmoDMjwXhBievuUSI29HlVtmKCA-- From hartmans@painless-security.com Fri Aug 23 05:29:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4939311E80FF for ; Fri, 23 Aug 2013 05:29:24 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNEUwbSXYgZ6 for ; Fri, 23 Aug 2013 05:29:18 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5113011E80F4 for ; Fri, 23 Aug 2013 05:29:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 2541A202C9; Fri, 23 Aug 2013 08:27:45 -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 qPX2S16_2pP5; Fri, 23 Aug 2013 08:27:44 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Fri, 23 Aug 2013 08:27:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B18FD8803B; Fri, 23 Aug 2013 08:29:14 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5215C9AD.1060805@um.es> <5217470D.3090606@um.es> Date: Fri, 23 Aug 2013 08:29:14 -0400 In-Reply-To: <5217470D.3090606@um.es> (Alejandro Perez Mendez's message of "Fri, 23 Aug 2013 13:27:09 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: radext@ietf.org, Peter Deacon Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:29:24 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: Alejandro> El 23/08/13 02:12, Peter Deacon escribió: >> On Thu, 22 Aug 2013, Alejandro Perez Mendez wrote: >> >>> Hello Peter, thanks for the comments. See some responses below. >> >>>>> Based on the discussion in Berlin we are ready to start >>>>> another adoption call for the solution for fragmentation of >>>>> RADIUS packets. >> >>>> I would support this draft with narrower scope as interim >>>> solution addressing a specific use. >> >>>> Have some concerns with draft as a general solution: >> >>>> Section 2. RFC5176 dynamic auth clients are not necessarily >>>> always RADIUS servers. We have production systems where CoA >>>> client and RADIUS server are separate with separate roles. >>>> Seeing value in maintaining separation I do not favor >>>> Additional-Authorization. >> >>>> Accounting proposal is not atomic and depends on assumptions >>>> about type of content. (e.g long attribute not able to fit >>>> within 4096 byte limit cannot be transmitted) >> >>> I probably misunderstood your comment. We do not deal with CoA >>> or Accounting exchanges. They are left the way they are. >> >> Hi Alejandro, >> >> From section 2 "scope of this document". Perhaps it might be >> best to simply address what is supported and remove extraneous >> references to what is not changed (CoA and >> Accounting). Specifically: >> >> " Instead, the CoA client MUST send a CoA-Request packet >> containing session identification attributes, along with >> Service-Type = Additional- Authorization, and a State attribute. >> Implementations not supporting fragmentation will respond with a >> CoA-NAK, and an Error-Cause of Unsupported-Service. >> >> Implementations supporting this specification may not be able to >> change authorization data for a particular session. In that >> case, they MUST respond with a CoA-NAK, as above. Otherwise, the >> implementation MUST start fragmentation via Access-Request, using >> the methods defined here." >> Alejandro> The purpose of that text is to explain why we do not deal Alejandro> with CoA or Accounting, that is, why they do not need of Alejandro> a fragmentation solution. Removing them would provoke Alejandro> other people to ask why we do not support them. I support retaining the section 2 text. From aland@deployingradius.com Fri Aug 23 05:42:03 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47CF11E8111 for ; Fri, 23 Aug 2013 05:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRks-+sUsrDL for ; Fri, 23 Aug 2013 05:41:52 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05FCF11E80F4 for ; Fri, 23 Aug 2013 05:41:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 024DE2240136; Fri, 23 Aug 2013 14:41:03 +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 iL6vzVVPEeoQ; Fri, 23 Aug 2013 14:41:01 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id E061C22400FD; Fri, 23 Aug 2013 14:41:00 +0200 (CEST) Message-ID: <5217585D.4080902@deployingradius.com> Date: Fri, 23 Aug 2013 08:41:01 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> <5214AE3C.4010909@deployingradius.com> <5214C457.70204@restena.lu> <52160FB0.30208@deployingradius.com> <52174F0D.4040103@restena.lu> In-Reply-To: <52174F0D.4040103@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:42:03 -0000 Stefan Winter wrote: > That's not the end of the world though; simply adding a sentence in the > draft such a case exists and that deployments need to take care that > their deployed implementation(s) don't stumble over this. Yes. Even if there are deployed proxies which implement 6929, there are no attributes which use the 6929 format. So there's a bit of time to upgrade the systems. > Aha! I had the impression that authz exchanges in the ABFAB world go all > the way from/to the RADIUS client that does the whole GSS EAP magic. And > that this is the equivalent of an "AP" in the non-network-access use case. In the abfab world, they may go to the client, which can be a commodity system with user logins, web browser, etc. i.e. a capable system. I don't recall seeing a demand for APs or switches to implement the fragmentation draft. > That's something I can live with. Again, documenting in the draft that > User-Name is the only proxying criterion would be enough for me then. > Maybe a second one explaining that client to first-server is not in > scope/has complexities that can make the use of this draft hard/unsuitable. Yes. We'll do that. Alan DeKok. From aland@deployingradius.com Sat Aug 24 07:07:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3557B11E80FD for ; Sat, 24 Aug 2013 07:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPOhmlbDTHda for ; Sat, 24 Aug 2013 07:06:59 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7711E80F4 for ; Sat, 24 Aug 2013 07:06:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6844E22400FD; Sat, 24 Aug 2013 16:06:45 +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 hNzUgcD-5eVc; Sat, 24 Aug 2013 16:06:44 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 6835722400B1; Sat, 24 Aug 2013 16:06:44 +0200 (CEST) Message-ID: <5218BDF7.2080801@deployingradius.com> Date: Sat, 24 Aug 2013 10:06:47 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <52146E31.1030701@restena.lu> <5215BC9B.2070107@um.es> <5215C364.6080502@restena.lu> In-Reply-To: <5215C364.6080502@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 14:07:07 -0000 Stefan Winter wrote: > It doesn't know; it's an estimation which is hopefully rather accurate > these days because many sane implementations of forwarding server do add > Proxy-State; but they are not at all obliged to. From what I've seen, Proxy-State has little or no value. FreeRADIUS adds it because there's a suggestion to do so. But it doesn't do anything with Proxy-State. > This begs the question: if a fragmentation-draft-unaware proxy receives > a chunk close to 4096, and decides it wants to add an arbitrary > attribute on its own, and cannot -> bad luck, discard? Pretty much. Or, to *not* add the attribute. > I also just found another gem regarding Proxy-State that I wasn't aware > of until now: a forwarding server may truncate the Proxy-State values it > found from earlier proxies, and only send its new one further on. It > merely needs to remember the content of the earlier ones, to add them > back in the reply. I'm speaking of this text in the same section: Yes. I'm not aware of anyone who does that, though. > The question of frag-unaware proxies remains; their only choice is to > discard if they can't fit in their attributes. Yes. That's a reason to either not re-write packets in a proxy, or to keep the maximum packet size "small", to leave room for proxy re-writing. Alan DeKok. From jouni.nospam@gmail.com Mon Aug 26 00:36:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C796621F9FC8 for ; Mon, 26 Aug 2013 00:36:01 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F91rW2YHHz8O for ; Mon, 26 Aug 2013 00:36:00 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id E885421F9E67 for ; Mon, 26 Aug 2013 00:35:59 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id p5so1119368lbi.8 for ; Mon, 26 Aug 2013 00:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fb2fsiDH+GrPcoSZcdK9Lcj5RHiBMagOsrsxH+TJlZg=; b=ggDaeLjitE87Hx00ihgDlrZyxBm1J+H/fsTTXG3j9jaGIvufBfh8ErExGp0aq6E9uD rk55XZ1s7S0uK4AzfJOACobvjh3EXG2/I8Jphqr6zh+AKPU3DxfNDKT2x6ShUsPJTZ1I XbPoZo4n/lsVZ5zhfs1AJierShXmP0AHqhEP25oVKSJAEUKW9u1vXqfRDQRmx+PEC+GI uL31tzuJaR8D3In02zwB9ozVrL8sE9hDcnTO1hMAjKW3E0Au9+x0AO8eacwo8jd2bjga /bO1MIM9hXmvSk6EF5jsLMhcxEXkeE8572TdRdE/Q3xGOTLremUcyGxLXApQkAKQAU2T fuqA== X-Received: by 10.152.115.242 with SMTP id jr18mr123478lab.40.1377502558631; Mon, 26 Aug 2013 00:35:58 -0700 (PDT) Received: from [192.168.250.158] ([194.100.71.98]) by mx.google.com with ESMTPSA id ua4sm4603955lbb.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 00:35:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> Date: Mon, 26 Aug 2013 10:35:56 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: Jouni Korhonen , radext-chairs@tools.ietf.org, "draft-perez-radext-radius-fragmentation@tools.ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 07:36:02 -0000 Folks, We got some support and none going against the adoption. There were already some very detailed discussion on aspects people want to see changed in the document, which is a really good start. We will take draft-perez-radext-radius-fragmentation-06 as the _basis_ for the WG solution. Now the WG needs to come up with text that everybody agrees with. whether we need further documents on fragmentation, e.g. as a generic long term solution is to be seen and discussed. - Jouni & Mauricio On Aug 9, 2013, at 3:02 PM, Jouni Korhonen wrote: > Folks, > > Based on the discussion in Berlin we are ready to start another > adoption call for the solution for fragmentation of RADIUS packets. > > This email starts a two week consensus call on adopting: > > Filename: draft-perez-radext-radius-fragmentation > Revision: 06 > Title: Support of fragmentation of RADIUS packets > Creation date: 2013-07-02 > > Express your concerns or support by 23rd August EOB on the mailing list. > > - Jouni & Mauricio From internet-drafts@ietf.org Tue Aug 27 13:36:31 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1666E21F9B57; Tue, 27 Aug 2013 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTeDUQUIvINc; Tue, 27 Aug 2013 13:36:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5BC21F9425; Tue, 27 Aug 2013 13:36:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130827203630.24261.94179.idtracker@ietfa.amsl.com> Date: Tue, 27 Aug 2013 13:36:30 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2013 20:36:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : Support of fragmentation of RADIUS packets Author(s) : Alejandro Perez-Mendez Rafa Marin-Lopez Fernando Pereniguez-Garcia Gabriel Lopez-Millan Diego R. Lopez Alan DeKok Filename : draft-ietf-radext-radius-fragmentation-00.txt Pages : 25 Date : 2013-08-27 Abstract: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy clients and servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-00 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/