From jouni.nospam@gmail.com Sun Oct 6 22:45: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 ECDFD21E814B for ; Sun, 6 Oct 2013 22:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 x4zHvysbFMYM for ; Sun, 6 Oct 2013 22:45:30 -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 9FCA721E8160 for ; Sun, 6 Oct 2013 22:45:18 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so5226245lab.30 for ; Sun, 06 Oct 2013 22:45:17 -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=390cpZBqv2O8aSBIRcH8SHubFFMlpnh4BAznaN4/EnY=; b=Mojbr7aw5VU2MFzLZ2dgk9iKtiBb1nEDCq/FL5qxGzt88RDhj6/eSI/l6J+T6Zfh1H IWdA9/azmBop34VCdF/cyIfYebY5BaiAHmVneNVFMZLPiI5kwF//cgYiC9paVdTUC09a yr4hUFXFQXw/jqvZke9VS2uYnOWCKNrz2FHb8uGs9KAHCgp5P3ae/7HvxlR138gbUlIT up9qJ1iSIrmjrZpVGHLUqb2ySowmijlD/hteO8n8Nz1MqV1XrryyKPOGP1FQ/E+HtRKY t3ub26VNsAlFdkLS0nHDhnAL7gp9ivJ0zYHRKnoNiZZu1HJ3xPzsanE+X37U7lOmYX/C WvHw== X-Received: by 10.152.2.233 with SMTP id 9mr118671lax.38.1381124717394; Sun, 06 Oct 2013 22:45:17 -0700 (PDT) Received: from [192.168.250.211] ([194.100.71.98]) by mx.google.com with ESMTPSA id zc3sm17797383lbb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 22:45:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 7 Oct 2013 08:45:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <030EFC3D-A9C8-4B68-AD7F-F98414781B77@gmail.com> References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> To: Sam Hartman X-Mailer: Apple Mail (2.1510) Cc: Jouni Korhonen , "draft-perez-radext-radius-fragmentation@tools.ietf.org" , radext-chairs@tools.ietf.org, "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: Mon, 07 Oct 2013 05:45:31 -0000 Sam, Sorry for the delay. Inline.. On Sep 4, 2013, at 1:48 AM, Sam Hartman = wrote: >>>>>> "Jouni" =3D=3D Jouni Korhonen writes: >=20 > Jouni> Folks, >=20 > Jouni> We will take draft-perez-radext-radius-fragmentation-06 as > Jouni> the _basis_ for the WG solution >=20 > Hi. > I'd be happy if you reword that sentence as "_a_ _basis_ for _a_ WG > solution." Pardon my non-native English.. 'a' is fine. >=20 > I think there was significant support for the idea that this draft = alone > is insufficient and that we want to revisit the RADIUS message size = over > TCP. > I do not believe the discussion supports the idea that this draft will > be a singular solution. > So, I'd ask the chairs to clarify. In the mail you quoted I also said: "agrees with. whether we need further documents on fragmentation, e.g. = as a generic long term solution is to be seen and discussed." which should be clear answer for what you ask above. We can revisit the fragmentation topic if the current WG I-D does not fit in all use cases and there can be further documents. Whether we would need to recharter for more documents on fragmentation or whether just new milestones are sufficient, I have not thought about yet. - Jouni >=20 > --Sam From jouni.nospam@gmail.com Mon Oct 7 06:03:44 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 C150C21E81A8 for ; Mon, 7 Oct 2013 06:03:44 -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 vCPo5Ss4EXBo for ; Mon, 7 Oct 2013 06:03:44 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 691F721E81D1 for ; Mon, 7 Oct 2013 06:03:37 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id eh20so5429832lab.5 for ; Mon, 07 Oct 2013 06:03:36 -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:references :to:message-id:mime-version; bh=JM894Cz9Xc4xxvfH6+BGRY/NTNXdpFM6u5FQpjti6QU=; b=V1c291O9YxuACjbi/nkiuFUjYb8RTmI0AuncobjRvAC/JEwlPodZZQyPdLulZKyZC4 z/Y53UNVxndZj68ybqCt+RqB+Jn29gHwBX+lTcW8/gqcSF6ANLLd+vt2kyOtco9JZJwU 3HfwW5cSyeixEEOfm8Tj+xrmSXJYpilTnHL0GbCaricVAwIA3yA76LEqbx52Q7e0rxkZ afci7Iby6qT7lD6DEEF+H1bbBzDh/BkAdnJd88jjd16exIwYMi8ZpRs/Mn6rAT4M9fpz ARU8T8oiAn7zQZiR1BQyADhT8ifmRQ/0p1X1kCeodGpa6D2E6fJ7tDtRqJsqPTMLtsK8 oCSw== X-Received: by 10.112.29.147 with SMTP id k19mr25709674lbh.9.1381151016223; Mon, 07 Oct 2013 06:03:36 -0700 (PDT) Received: from [192.168.250.211] ([194.100.71.98]) by mx.google.com with ESMTPSA id o1sm25311705lah.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 06:03:35 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Oct 2013 16:03:34 +0300 References: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> To: "radext@ietf.org" Message-Id: <7B7EC3B3-C46C-4FB2-92E6-1B546A7048C1@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [radext] Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left 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, 07 Oct 2013 13:03:44 -0000 FYI Begin forwarded message: > From: NomCom Chair 2013 > Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left > Date: October 4, 2013 8:31:49 PM GMT+03:00 > To: IETF Announcement List > Cc: IETF Discuss List > Reply-To: ietf@ietf.org, Nomcom@ietfa.amsl.com, Chair@ietfa.amsl.com, = "2013 =20 > Nominations for the IESG, IAB, and IAOC are due to the Nomcom by = Friday, 18 October, 2013. >=20 > Is there someone you work with at IETF who has leadership potential = and a growing track record? Please read the Nomcom call for nominations = and consider nominating her or him. Or several folks! Deadline for = nominations is October 18. Nominate soon to give your nominee(s) plenty = time to fill in the questionnaire. Information about the desired = expertise for positions is here:=20 > https://datatracker.ietf.org/nomcom/2013/expertise >=20 > Lots more, including which positions are open, how to make a = nomination, and how to=20 > send us your feedback on the desired expertise, follows. >=20 > IETFers, let's hear from you! Make nominations, accept nominations! >=20 > If you have any questions about the process, feel free to get in touch = with me. >=20 > Best regards, >=20 > Allison for the Nomcom >=20 > Allison Mankin=20 > Nomcom Chair 2013-14 >=20 > ----- The Info You Need for Nominating ----- >=20 > The 2013-14 Nominating Committee (Nomcom) is seeking nominations > from now until October 18, 2013. The open positions being considered > by this year's Nomcom can be found later in this section, and also on > this year's Nomcom website:=20 >=20 > https://datatracker.ietf.org/nomcom/2013/ >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2013 home page, or by visiting the following URL:=20 >=20 > https://datatracker.ietf.org/nomcom/2013/nominate/ >=20 > Note that nominations made using the web tool require an ietf.org=20 > datatracker account. You can create a datatracker ietf.org account=20 > if you don't have one already by visiting the following URL: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 > Nominations may also be made by email to nomcom13 at ietf.org. > If you nominate by email, please include the word "Nominate" in the = Subject > and indicate in the email who is being nominated, their email address = (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you use email, please use a separate = email for > each person you nominate, and for each position (if you are nominating = one > person for multiple positions). >=20 > Self-nomination is welcome! No need to be shy. >=20 > Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current Nomcom cycle is not confidential". Willing nominees for each > position will be listed in a publicly accessible way - anyone with a > datatracker account may access the lists. In all other ways, the=20 > confidentiality requirements of RFC 3777/BCP10 remain in effect. All > feedback and all Nomcom deliberations will remain confidential and = will > not be disclosed. =20 >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the=20 > Nomcom on or before October 18, 2013. Please submit your nominations =20= > as early as possible for the sake of your nominees, as we've set the=20= > questionnaire submission deadline for October 25, 2013. >=20 > The list of people and posts whose terms end with the March 2014 IETF = meeting,=20 > and thus the positions for which we are accepting nominations: =20 >=20 > IAOC > Chris Griffiths >=20 > IAB > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig >=20 > IESG > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF. Also, please give serious consideration to accepting = nominations > you receive. =20 >=20 > The summaries of the desired expertise for the positions, developed by = the=20 > respective bodies, are found at: >=20 > https://datatracker.ietf.org/nomcom/2013/expertise/ >=20 > In addition to nominations, the Nomcom seeks community input on=20 > the positions themselves. We need and welcome the community's=20 > views and input on the jobs within each organization. If you=20 > have ideas on the positions' responsibilities (more, less,=20 > different), please let us know. You can send us email about this to > nomcom13 at ietf.org, and we will use this feedback actively. >=20 > Thank you for your help in nominating a great pool of strong and = interesting > nominees! >=20 >=20 >=20 From internet-drafts@ietf.org Wed Oct 9 11:17: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 0D4BB21E811C; Wed, 9 Oct 2013 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 m9OCF9Xs+xBN; Wed, 9 Oct 2013 11:17:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09611E80EC; Wed, 9 Oct 2013 11:17:45 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009181743.15919.21877.idtracker@ietfa.amsl.com> Date: Wed, 09 Oct 2013 11:17:43 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-07.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 18:17:52 -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 : DTLS as a Transport Layer for RADIUS Author(s) : Alan DeKok Filename : draft-ietf-radext-dtls-07.txt Pages : 23 Date : 2013-10-09 Abstract: The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "obfuscated" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dtls-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dtls-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aland@deployingradius.com Wed Oct 9 11:22:56 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 5746911E80E2 for ; Wed, 9 Oct 2013 11:22:56 -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 E3pEpsIcO0nP for ; Wed, 9 Oct 2013 11:22:51 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B85321F96ED for ; Wed, 9 Oct 2013 11:22:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 22278224017D for ; Wed, 9 Oct 2013 20:21:48 +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 JSS+vci3cvpI for ; Wed, 9 Oct 2013 20:21:47 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176121002.dsl.bell.ca [70.26.46.170]) by power.freeradius.org (Postfix) with ESMTPSA id 5D2372240080 for ; Wed, 9 Oct 2013 20:21:47 +0200 (CEST) Message-ID: <52559ECC.7060801@deployingradius.com> Date: Wed, 09 Oct 2013 14:22:04 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: radext@ietf.org References: <20131009181743.15919.21877.idtracker@ietfa.amsl.com> In-Reply-To: <20131009181743.15919.21877.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] I-D Action: draft-ietf-radext-dtls-07.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: Wed, 09 Oct 2013 18:22:56 -0000 The changes from -06 to -07 are the result of the secdir and opsdir review. I believe at this point the document is finished. internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : DTLS as a Transport Layer for RADIUS > Author(s) : Alan DeKok > Filename : draft-ietf-radext-dtls-07.txt > Pages : 23 > Date : 2013-10-09 > > Abstract: > The RADIUS protocol [RFC2865] has limited support for authentication > and encryption of RADIUS packets. The protocol transports data "in > the clear", although some parts of the packets can have "obfuscated" > content. Packets may be replayed verbatim by an attacker, and > client-server authentication is based on fixed shared secrets. This > document specifies how the Datagram Transport Layer Security (DTLS) > protocol may be used as a fix for these problems. It also describes > how implementations of this proposal can co-exist with current RADIUS > systems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dtls > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dtls-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-07 > > > 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/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From melinda.shore@gmail.com Wed Oct 9 11:38: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 00CB911E80F7 for ; Wed, 9 Oct 2013 11:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 5lvMTP5ugNwG for ; Wed, 9 Oct 2013 11:38:22 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id D45EB21E816C for ; Wed, 9 Oct 2013 11:38:20 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id ld10so1463253pab.8 for ; Wed, 09 Oct 2013 11:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aC2IbawtjrAS8eGTdMto/u+ixKe++QcGDAe82GT2lgo=; b=PmdMxiPJrjl9LR+Bbscb6M2Tix38pdV5MOPj4mqGcB03z09PDtT6HDNqv3/Q7/MCcT aBDEMGqPyOQgmb9FX8rSxNRkrrR3tCurHk0TDt3l0yDbJ/JGwOLZyOzMmw1Rj3Qd/kTl Z7F7y2FiCMJOSyePrq7ZcAGjqUvwnl0fs5n1zFZ0JZg1+AkRDP0xk+HGcfKAeC5+1tVR rEz3sz4jhvygJI0F0i6ZmuROtRkbzdR9NQNrzDtkaVGfJWUt+JvFn4NnC+GTOQOsEK4y B6+ucMevbhnS7tL/PCAr3C+KT8BfTn5LrJfvh+GLT8XmGzAFMbvke/wVr80qtqt7acB3 NYZg== X-Received: by 10.68.88.161 with SMTP id bh1mr9434808pbb.49.1381343900513; Wed, 09 Oct 2013 11:38:20 -0700 (PDT) Received: from spandex.local (216-67-113-166.dynamic.dsl.acsalaska.net. [216.67.113.166]) by mx.google.com with ESMTPSA id ja5sm48138365pbc.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 11:38:19 -0700 (PDT) Message-ID: <5255A299.40204@gmail.com> Date: Wed, 09 Oct 2013 10:38:17 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alan DeKok References: <20131009181743.15919.21877.idtracker@ietfa.amsl.com> <52559ECC.7060801@deployingradius.com> In-Reply-To: <52559ECC.7060801@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-dtls-07.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: Wed, 09 Oct 2013 18:38:23 -0000 On 10/9/13 10:22 AM, Alan DeKok wrote: > The changes from -06 to -07 are the result of the secdir and opsdir > review. I believe at this point the document is finished. I'll try to give it a read before the end of the day today. Melinda From mauricio.sanchez@hp.com Tue Oct 15 23:03:50 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 8C82211E80FA for ; Tue, 15 Oct 2013 23:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, 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 0MTVzYfzalUN for ; Tue, 15 Oct 2013 23:03:45 -0700 (PDT) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by ietfa.amsl.com (Postfix) with ESMTP id D54CB11E8267 for ; Tue, 15 Oct 2013 23:03:43 -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 g6t0185.atlanta.hp.com (Postfix) with ESMTPS id 316322401D; Wed, 16 Oct 2013 06:03:42 +0000 (UTC) Received: from G5W5498.americas.hpqcorp.net (16.201.144.178) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 16 Oct 2013 06:01:59 +0000 Received: from G5W2722.americas.hpqcorp.net ([169.254.1.74]) by G5W5498.americas.hpqcorp.net ([16.201.144.178]) with mapi id 14.03.0123.003; Wed, 16 Oct 2013 06:01:59 +0000 From: "Sanchez, Mauricio" To: Jouni Korhonen , "radext@ietf.org" Thread-Topic: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 Thread-Index: AQHOyjU5AEeYZ7GkykObtRgsdg0ayg== Date: Wed, 16 Oct 2013 06:01:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [15.193.49.21] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3464722915_8675054" MIME-Version: 1.0 Cc: "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: Wed, 16 Oct 2013 06:03:50 -0000 --B_3464722915_8675054 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Now that the the Perez, et.al. draft has made it into WG draft status we see that discussion turned to what the scope of solution should be. Can the authors of the draft summarize their current understanding of the situation and what their suggested/planned next steps are? I expect that one or more of the authors will be at IETF 88 to add this draft to the agenda, so please confirm availability. As a reminder, we are on the 1st day (Monday) at 1300. -Mauricio & Jouni On 8/26/13 12:35 AM, "Jouni Korhonen" wrote: > >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 > >_______________________________________________ >radext mailing list >radext@ietf.org >https://www.ietf.org/mailman/listinfo/radext --B_3464722915_8675054 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 DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgHiyYPfJ8zh7+53KTko243k+4 DFv9wnEXavfIRvsxr84wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMxMDE2MDYwMTU1WjANBgkqhkiG9w0BAQEFAASCAQBcRbUEzLKqCz4Of6VZspvakzyD Gg6BUBMda4myKT19i1IzsoqHGW2kPlCkVAR4w9mLNzbkV6gJ+S6Z5JOKqWk7RV+yQJx6ov5I LwrE1Pj/tiu72IUzxU4iyLPCUmphsxJ8uBaog65rCat0N1GM/PfAsTpy+UB4q4ZD6DAj0nZS 66D1w1UkrdvBoVFFrvo/+af4o5nc3jYU/mHJ04FFbeT3Z85pfcIPhYunPhB1zhF1w5CHw8cR f1sf470CE3GVKGzawcbx5e/pcKCxzMSeLhs5CksRz/M+oFsv5xexPbxL59dGrPI00XwL3CEE 70x8ll6PtqzgaZYJMi0XepsFu3ur --B_3464722915_8675054-- From alex@um.es Wed Oct 16 00:01: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 3D8AD11E815C for ; Wed, 16 Oct 2013 00:01:02 -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_22=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 pnZvzCW5CUcn for ; Wed, 16 Oct 2013 00:00:57 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 800ED21F9D44 for ; Wed, 16 Oct 2013 00:00:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id DD990537C7 for ; Wed, 16 Oct 2013 09:00:53 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C-Fni2Qvh9nY for ; Wed, 16 Oct 2013 09:00:53 +0200 (CEST) Received: from [155.54.205.8] (inf-205-8.inf.um.es [155.54.205.8]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 52F035376D for ; Wed, 16 Oct 2013 09:00:52 +0200 (CEST) Message-ID: <525E39A4.7030201@um.es> Date: Wed, 16 Oct 2013 09:00:52 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030000060108060908050007" 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, 16 Oct 2013 07:01:02 -0000 This is a multi-part message in MIME format. --------------030000060108060908050007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 16/10/13 08:01, Sanchez, Mauricio escribió: > Now that the the Perez, et.al. draft has made it into WG draft status we > see that discussion turned to what the scope of solution should be. Can > the authors of the draft summarize their current understanding of the > situation and what their suggested/planned next steps are? I expect that > one or more of the authors will be at IETF 88 to add this draft to the > agenda, so please confirm availability. > > As a reminder, we are on the 1st day (Monday) at 1300. > > -Mauricio & Jouni Dear Mauricio & Jouni, the scope of this draft is to provide a means for the transmission of large amounts of authorization data between two RADIUS endpoints. The reasons why it is focused only on authorization data are described in the "Scope of this document" section on the draft, and can be summarized on the following sentence: "Other exchanges (i.e. authentication and accounting) do not require of such a mechanism". This is justified on the following premises: 1) Authentication exchanges already deal with fragmentation (e.g. RADIUS-EAP). Moreover, as they represent the most critical part of a RADIUS conversation, it is preferable to not introduce any modification to their operation that may affect existing equipment. 2) There not documented need for fragmentation of accounting data so far. Additionally, other of the cornerstone points of this mechanism is to work through unmodified proxies, thus: * It should be based on UDP * It should not require of any change to the RADIUS specification * It should conform with current RADIUS attribute & packet formats Those are the basis of our draft, and the requirements that have guided the definition of the current fragmentation mechanism. However, it does not provide a perfect solution. In particular, it requires proxying to be done based on the User-Name attribute (although the most typical case, specific scenarios may have a different configuration), it requires proxies to not drop unrecognised attributes (who does not?), it requires proxies to not try to modify the contents of a packet (apart of inserting Proxy-State attributes), and the receptor do not know how much data will arrive until it actually receives it. Taking into account aforementioned restrictions it seems that, for new deployments where keeping the infrastructure unmodified is not a MUST, a different approach of using RADIUS TCP, *and* changing RADIUS specification to increase the maximum packet length from 4 KiB to 64 KiB may provide a simpler solution. From my perspective, both solutions could coexists. While the TCP-based solution may provide a simpler solution, in scenarios where existing infrastructure cannot be easily upgraded, an UDP-based solution is still needed. We are currently finishing a new version which clarifies some points that were raised on the mailing list, mainly related to the mentioned limitations. It is our intention to have it ready before the IETF meeting. I will not personally attend the meeting, but I will be available via Jabber. Regards, Alejandro > > > > > > On 8/26/13 12:35 AM, "Jouni Korhonen" wrote: > >> 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 >> _______________________________________________ >> 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 --------------030000060108060908050007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
El 16/10/13 08:01, Sanchez, Mauricio escribió:
Now that the the Perez, et.al. draft has made it into WG draft status we
see that discussion turned to what the scope of solution should be.  Can
the authors of the draft summarize their current understanding of the
situation and what their suggested/planned next steps are?  I expect that
one or more of the authors will be at IETF 88 to add this draft to the
agenda, so please confirm availability.

As a reminder, we are on the 1st day (Monday) at 1300.

-Mauricio & Jouni

Dear Mauricio & Jouni,

the scope of this draft is to provide a means for the transmission of large amounts of authorization data between two RADIUS endpoints. The reasons why it is focused only on authorization data are described in the "Scope of this document" section on the draft, and can be summarized on the following sentence: "Other exchanges (i.e. authentication and accounting) do not require of such a mechanism". This is justified on the following premises:

1) Authentication exchanges already deal with fragmentation (e.g. RADIUS-EAP). Moreover, as they represent the most critical part of a RADIUS conversation, it is preferable to not introduce any modification to their operation that may affect existing equipment.
2) There not documented need for fragmentation of accounting data so far.

Additionally, other of the cornerstone points of this mechanism is to work through unmodified proxies, thus:
* It should be based on UDP
* It should not require of any change to the RADIUS specification
* It should conform with current RADIUS attribute & packet formats

Those are the basis of our draft, and the requirements that have guided the definition of the current fragmentation mechanism.

However, it does not provide a perfect solution. In particular, it requires proxying to be done based on the User-Name attribute (although the most typical case, specific scenarios may have a different configuration), it requires proxies to not drop unrecognised attributes (who does not?), it requires proxies to not try to modify the contents of a packet (apart of inserting Proxy-State attributes), and the receptor do not know how much data will arrive until it  actually receives it.

Taking into account aforementioned restrictions it seems that, for new deployments where keeping the infrastructure unmodified is not a MUST, a different approach of using RADIUS TCP, *and* changing RADIUS specification to increase the maximum packet length from 4 KiB to 64 KiB may provide a simpler solution.

From my perspective, both solutions could coexists. While the TCP-based solution may provide a simpler solution, in scenarios where existing infrastructure cannot be easily upgraded, an UDP-based solution is still needed.

We are currently finishing a new version which clarifies some points that were raised on the mailing list, mainly related to the mentioned limitations. It is our intention to have it ready before the IETF meeting.

I will not personally attend the meeting, but I will be available via Jabber.

Regards,
Alejandro







On 8/26/13 12:35 AM, "Jouni Korhonen" <jouni.nospam@gmail.com> wrote:


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 <jouni.nospam@gmail.com> 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

--------------030000060108060908050007-- From trac+radext@trac.tools.ietf.org Wed Oct 16 06:26: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 BF7AD21F9C90 for ; Wed, 16 Oct 2013 06:26:15 -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 hgrLhwfVlgEB for ; Wed, 16 Oct 2013 06:26:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 88B6C11E82A4 for ; Wed, 16 Oct 2013 06:26:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:47526 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VWR73-0002TK-5m; Wed, 16 Oct 2013 15:26:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 16 Oct 2013 13:26:09 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/168#comment:1 Message-ID: <080.4628d0c5fd4d61f22af4a78bbe1a37d3@trac.tools.ietf.org> References: <065.8e3b593ce94ff54b06f468a19aa3f87e@trac.tools.ietf.org> X-Trac-Ticket-ID: 168 In-Reply-To: <065.8e3b593ce94ff54b06f468a19aa3f87e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mikem@open.com.au, stefan.winter@restena.lu Resent-Message-Id: <20131016132612.88B6C11E82A4@ietfa.amsl.com> Resent-Date: Wed, 16 Oct 2013 06:26:11 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #168: Remaining issues for dynamic-discovery draft X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:26:16 -0000 #168: Remaining issues for dynamic-discovery draft Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: Re 1.1: allocation is still pending; added IANA Considerations note to keep track of the allocation. This needs not be tracked in this TRAC ticket. Re 1.2: -08 makes this UTF8Realm as per discussion in IETF87. Re 1.3: changed to allow * only on the leftmost label in -08. Re 2: Added new section "Privacy Considerations" with tradeoff discussion as discussed in IETF87. Re 3: Added an explicit reference to the entirety of section 2.2 of S-NAPTR RFC which explains all the various terminal and non-terminal lookups in more detail. The soon-to-be-submitted -08 thus closes all issues in this ticket. Please re-open if the added text in the draft is not satisfactory. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | dynamic-discovery@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: dynamic-discovery | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From internet-drafts@ietf.org Wed Oct 16 06:27:36 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 5BE4011E82AA; Wed, 16 Oct 2013 06:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 9WzuqNUf+qie; Wed, 16 Oct 2013 06:27:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D55A121F935A; Wed, 16 Oct 2013 06:27:35 -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.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016132735.32139.2011.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 06:27:35 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:27:36 -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 : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADI= US/DTLS Author(s) : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-08.txt Pages : 25 Date : 2013-10-16 Abstract: This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan.winter@restena.lu Wed Oct 16 06:30:54 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 5F35421F9CE8 for ; Wed, 16 Oct 2013 06:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WEIRD_PORT=0.001] 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 47JznDp760Y0 for ; Wed, 16 Oct 2013 06:30:53 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2833221F9BB5 for ; Wed, 16 Oct 2013 06:30:53 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 15A9810580 for ; Wed, 16 Oct 2013 15:30:52 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 0768B1057F for ; Wed, 16 Oct 2013 15:30:51 +0200 (CEST) Message-ID: <525E950A.9030704@restena.lu> Date: Wed, 16 Oct 2013 15:30:50 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: radext@ietf.org References: <20131016132735.32139.2011.idtracker@ietfa.amsl.com> In-Reply-To: <20131016132735.32139.2011.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kA9nObPQdvDkVkoefEiWWdFNOcACd8cFS" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-08.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: Wed, 16 Oct 2013 13:30:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kA9nObPQdvDkVkoefEiWWdFNOcACd8cFS Content-Type: multipart/mixed; boundary="------------020402040507050508080500" This is a multi-part message in MIME format. --------------020402040507050508080500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, this new draft closes the issues in TRAC #168 and also all the other pending items which were discussed in IETF87 and on the ML. I believe the draft is now ready for another WGLC if one is needed before further advancement of the draft. Greetings, Stefan Winter > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. >=20 > Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and = RADIUS/DTLS > Author(s) : Stefan Winter > Mike McCauley > Filename : draft-ietf-radext-dynamic-discovery-08.txt > Pages : 25 > Date : 2013-10-16 >=20 > Abstract: > This document specifies a means to find authoritative RADIUS servers= > for a given realm. It is used in conjunction with either RADIUS/TLS= > and RADIUS/DTLS. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-= 08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------020402040507050508080500 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020402040507050508080500-- --kA9nObPQdvDkVkoefEiWWdFNOcACd8cFS 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/ iQIcBAEBCgAGBQJSXpUKAAoJEMDeajWKOdxmpFUP/2U73pYTWUBWchG3zwNXXFXN m9e9encLJWhPbX/llstnkmLOFb/gf0Gaz1eSI7R1pjFgOb+gjtirCUyqbZJv5uSm luwyJJxoxRAqBwM/pqB5p/b+3A9Ie+Ww/POs/qDm2+culfSmAfrdZayeK1j30oli 6Lp9PBaYhGR33jnzMnvwDNmdowWiyRiDYwQF2pJ7wvESq2TRqpuAvFNIuRbfJ0o7 BDcbMiBMNdEuXPUMM6x9BBM6MPc7vC9104OAJ3zrmse2rHaxN9MXAlYPiWRsjt2u hQXMAz9XnR6zGrm3GojjyCFpnefmp4il6KN1ivWgKovIPujy/6yEKDvwlIFBdR87 4OAZjUr1mP13+bsnx2nctktYFDdlWKxd6Iq7/77QTutiI7edqLiaOtrcAuK4Osoo GnzK8lVoSF4LrTIRPpWEZhRDfN0uPrdipayRAPRDnjkw17FHECQ+4OJPge0D40zj b0s/ehx2QON+j/VCymcTzQ68F/29GcOlNFRqf6vAq0PwAPsTYQR1vmekyC3GLvQA BzBc/WLDcyhnh0kgaWfTuF8ebjJAk0MVi+eaVBr/1js0Kn35oWd3UZuV6XFAJcCY GrYR1XctOZsBOi3m/nnabZf4PIJJVbstxDlcNe6q18qYPKaBkDDcfDgQkqqGnNR3 W3MmAnOsbjfo5h6n6tqA =F3fQ -----END PGP SIGNATURE----- --kA9nObPQdvDkVkoefEiWWdFNOcACd8cFS-- From trac+radext@trac.tools.ietf.org Wed Oct 16 17:02: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 20E1D11E811B for ; Wed, 16 Oct 2013 17:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 4UxW4Gi8gEtf for ; Wed, 16 Oct 2013 17:02:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 14FC411E8153 for ; Wed, 16 Oct 2013 17:01:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:45983 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VWb2E-0002K6-UR; Thu, 17 Oct 2013 02:01:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 17 Oct 2013 00:01:50 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/145#comment:2 Message-ID: <081.89f46d027823e720a83c81730b0f4389@trac.tools.ietf.org> References: <066.dedf4d09031fe61f6c86516c36146705@trac.tools.ietf.org> X-Trac-Ticket-ID: 145 In-Reply-To: <066.dedf4d09031fe61f6c86516c36146705@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #145: Allowable code points X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 00:02:03 -0000 #145: Allowable code points Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: Suggested text, after the requirement that : * Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS. ... One caveat on the above recommendation is the issues noted in [CODEPOINTS]. That document notes that there are additional restrictions around DNS registration which forbid some code points from being valid in a DNS U-label. These restrictions cannot be expressed algorithmically. For this specification, that caveat means the following. Realms not matching the above ABNF are not valid NAIs. However, some realms which do match the ABNF are still invalid NAIs. That is, matching the ABNF is a necessary, but not sufficient, requirement for an NAI. -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | aland@deployingradius.com Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: nai | Version: 1.0 Severity: Candidate WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Oct 16 17:09:20 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 C522C21F9A72 for ; Wed, 16 Oct 2013 17:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.874 X-Spam-Level: X-Spam-Status: No, score=-100.874 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 s985oVcWaKUd for ; Wed, 16 Oct 2013 17:09:20 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD011E8153 for ; Wed, 16 Oct 2013 17:09:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:46690 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VWb9I-0007Uz-O6; Thu, 17 Oct 2013 02:09:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Thu, 17 Oct 2013 00:09:08 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/162#comment:1 Message-ID: <081.43eeef839b36be21c73a616b67aacfc1@trac.tools.ietf.org> References: <066.aea3cacc2610a00b8086f12c64529e3a@trac.tools.ietf.org> X-Trac-Ticket-ID: 162 In-Reply-To: <066.aea3cacc2610a00b8086f12c64529e3a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Resent-Message-Id: <20131017000913.1BBD011E8153@ietfa.amsl.com> Resent-Date: Wed, 16 Oct 2013 17:09:12 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #162: Section 2.6 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 00:09:20 -0000 #162: Section 2.6 Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: My approach would be to discuss the preferred design, and then explain why it's difficult to achieve. I would suggest splitting the section into two pieces. The first would discuss the ideal process. The second would discuss what we can do in reality. We're also waiting for input from i18n people on what's possible. Their answer will have a large impact on the text in this section. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | nai@tools.ietf.org Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: nai | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Oct 16 17:13:08 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 C08C911E819B for ; Wed, 16 Oct 2013 17:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.682 X-Spam-Level: X-Spam-Status: No, score=-100.682 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 PHojrmAaaK0v for ; Wed, 16 Oct 2013 17:13:08 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CA0FB11E8153 for ; Wed, 16 Oct 2013 17:13:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:47008 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VWbD4-0005vZ-Sg; Thu, 17 Oct 2013 02:13:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 17 Oct 2013 00:13:02 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/146#comment:2 Message-ID: <081.5f9e1b3cafd15a1e03ba10b80f9a75fa@trac.tools.ietf.org> References: <066.d7856f6a412e6225fc72caaacf5fd2b6@trac.tools.ietf.org> X-Trac-Ticket-ID: 146 In-Reply-To: <066.d7856f6a412e6225fc72caaacf5fd2b6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #146: Terminology and RFC 6365 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 00:13:08 -0000 #146: Terminology and RFC 6365 Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: OK. I'll add a reference && terminology updates -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | aland@deployingradius.com Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: nai | Version: 1.0 Severity: Candidate WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Oct 16 17:15:11 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 D6AF911E80E4 for ; Wed, 16 Oct 2013 17:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.587 X-Spam-Level: X-Spam-Status: No, score=-100.587 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 8FmAaYnWBjvL for ; Wed, 16 Oct 2013 17:15:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1394E11E8113 for ; Wed, 16 Oct 2013 17:15:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:47212 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VWbEz-00054M-Fy; Thu, 17 Oct 2013 02:15:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Thu, 17 Oct 2013 00:15:01 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/164#comment:1 Message-ID: <081.5953db5f171861bf8b679219a23454b6@trac.tools.ietf.org> References: <066.3290278ee287b1ad855248036bd73d4e@trac.tools.ietf.org> X-Trac-Ticket-ID: 164 In-Reply-To: <066.3290278ee287b1ad855248036bd73d4e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Resent-Message-Id: <20131017001510.1394E11E8113@ietfa.amsl.com> Resent-Date: Wed, 16 Oct 2013 17:15:09 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #164: Section 2.8 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 00:15:11 -0000 #164: Section 2.8 Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: The text was already updated in the last version of the document. The "byte-for-byte" sentence is gone, and a longer discussion fo the issues has been added. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | nai@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: nai | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Oct 16 17:19:00 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 2D18E21F94FF for ; Wed, 16 Oct 2013 17:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.529 X-Spam-Level: X-Spam-Status: No, score=-100.529 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 1IM8T-NfrwvU for ; Wed, 16 Oct 2013 17:18:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 916E321F943C for ; Wed, 16 Oct 2013 17:18:50 -0700 (PDT) Received: from localhost ([127.0.0.1]:47646 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VWbIe-0008Hr-Ov; Thu, 17 Oct 2013 02:18:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Thu, 17 Oct 2013 00:18:48 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/167#comment:1 Message-ID: <081.3e81a31e3550b94592b9f30d8ab318e5@trac.tools.ietf.org> References: <066.aacf7e7a81af59d50c7b525ec16b4429@trac.tools.ietf.org> X-Trac-Ticket-ID: 167 In-Reply-To: <066.aacf7e7a81af59d50c7b525ec16b4429@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Resent-Message-Id: <20131017001850.916E321F943C@ietfa.amsl.com> Resent-Date: Wed, 16 Oct 2013 17:18:50 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #167: Section 2.12 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 00:19:00 -0000 #167: Section 2.12 Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: I've added an example of a greek domain name, taken from http://www.iana.org/domains/reserved ... bob@δοκιμή.com -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | nai@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: nai | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From hartmans@painless-security.com Wed Oct 16 21:58: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 3F29821F9D7B for ; Wed, 16 Oct 2013 21:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3] 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 Wo0xR9zEXput for ; Wed, 16 Oct 2013 21:58:34 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 04E9F21F9D7E for ; Wed, 16 Oct 2013 21:58:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 16D63204F8; Thu, 17 Oct 2013 00:56:48 -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 pEJwy9mBLfjK; Thu, 17 Oct 2013 00:56:46 -0400 (EDT) Received: from [172.31.44.221] (unknown [137.205.238.40]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: hartmans@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA; Thu, 17 Oct 2013 00:56:45 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <081.5f9e1b3cafd15a1e03ba10b80f9a75fa@trac.tools.ietf.org> References: <066.d7856f6a412e6225fc72caaacf5fd2b6@trac.tools.ietf.org> <081.5f9e1b3cafd15a1e03ba10b80f9a75fa@trac.tools.ietf.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----54Z4C08WRZO0QVN9HAECFCT3I53F2K" From: Sam Hartman Date: Thu, 17 Oct 2013 05:58:22 +0100 To: radext@ietf.org, radext issue tracker , aland@deployingradius.com, bernard_aboba@hotmail.com Message-ID: Subject: Re: [radext] #146: Terminology and RFC 6365 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, 17 Oct 2013 04:58:39 -0000 ------54Z4C08WRZO0QVN9HAECFCT3I53F2K Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It does not make sense to close an issue if you are still waiting for input radext issue tracker wrote: >#146: Terminology and RFC 6365 > >Changes (by aland@deployingradius.com): > > * status: new => closed > * resolution: => fixed > > >Comment: > > OK. I'll add a reference && terminology updates > >-- >-------------------------------------+------------------------------------- > Reporter: | Owner: > bernard_aboba@hotmail.com | aland@deployingradius.com > Type: defect | Status: closed > Priority: major | Milestone: milestone1 >Component: nai | Version: 1.0 > Severity: Candidate WG Document | Resolution: fixed > Keywords: | >-------------------------------------+------------------------------------- > >Ticket URL: >radext > >_______________________________________________ >radext mailing list >radext@ietf.org >https://www.ietf.org/mailman/listinfo/radext -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------54Z4C08WRZO0QVN9HAECFCT3I53F2K Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit It does not make sense to close an issue if you are still waiting for input

radext issue tracker <trac+radext@trac.tools.ietf.org> wrote:
#146: Terminology and RFC 6365

Changes (by aland@deployingradius.com):

* status:  new => closed
* resolution:   => fixed


Comment:

OK.  I'll add a reference && terminology updates

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------54Z4C08WRZO0QVN9HAECFCT3I53F2K-- From aland@deployingradius.com Thu Oct 17 05:18:05 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 B23D111E81B9 for ; Thu, 17 Oct 2013 05:18: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 laWebthKwrao for ; Thu, 17 Oct 2013 05:17:59 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A14511E81B5 for ; Thu, 17 Oct 2013 05:17:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 0CCE02240130; Thu, 17 Oct 2013 14:17:06 +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 Ko-DXKIgkNda; Thu, 17 Oct 2013 14:17:05 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176121002.dsl.bell.ca [70.26.46.170]) by power.freeradius.org (Postfix) with ESMTPSA id 5698322400E2; Thu, 17 Oct 2013 14:17:05 +0200 (CEST) Message-ID: <525FD54A.1080202@deployingradius.com> Date: Thu, 17 Oct 2013 08:17:14 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <066.d7856f6a412e6225fc72caaacf5fd2b6@trac.tools.ietf.org> <081.5f9e1b3cafd15a1e03ba10b80f9a75fa@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: bernard_aboba@hotmail.com, radext@ietf.org, radext issue tracker Subject: Re: [radext] #146: Terminology and RFC 6365 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, 17 Oct 2013 12:18:05 -0000 Sam Hartman wrote: > It does not make sense to close an issue if you are still waiting for input I think this comment was about the normalization issue. The text in the current draft addresses Bernards comments directly. It's the best we can do given our current knowledge. So IMHO, the issue should be closed. We could track a separate issue to "get feedback from i18n people". But that's already on my short list for Vancouver. As soon as I get an answer, I'll report it to the list, and do a final update of the document. Alan DeKok. From diego@tid.es Thu Oct 17 09:49: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 3C3E611E82A0 for ; Thu, 17 Oct 2013 09:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.776 X-Spam-Level: X-Spam-Status: No, score=-5.776 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 5SPrANdoBFT1 for ; Thu, 17 Oct 2013 09:49:35 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 005AF11E82A2 for ; Thu, 17 Oct 2013 09:49:30 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MUT00BMCO2AP3@tid.hi.inet> for radext@ietf.org; Thu, 17 Oct 2013 18:49:28 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 31.83.28420.81510625; Thu, 17 Oct 2013 18:49:28 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MUT00BMPO2GP3@tid.hi.inet> for radext@ietf.org; Thu, 17 Oct 2013 18:49:28 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Thu, 17 Oct 2013 18:49:28 +0200 Date: Thu, 17 Oct 2013 16:49:27 +0000 From: "Diego R. Lopez" In-reply-to: <525E39A4.7030201@um.es> X-Originating-IP: [10.95.64.115] To: Alejandro Perez Mendez Message-id: <48380D05-BEAC-4DB6-AC90-A31C97542257@tid.es> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9tA1u3VphA4gjazsvUi0aA)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 Thread-index: AQHOyj2RuxEiKTAai0ac6i/zvYm/+Zn45WEA X-AuditID: 0a5f4e69-b7fe58e000006f04-24-5260151859af X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsXCFe9nqCshmhBkcGqlpkXLq5lsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6Lw0gaVgXVHF0rk7mRoYn8R3MXJySAiYSJydfJQdwhaTuHBv PVsXIxeHkMB2RomJRxqgnF+MEm+OvoZyZjJKPF/1B8jh4GARUJV42JkP0s0GZD5q/g02SVgg ROJ932RGEJsTKH5o7XZGiA0KEn/OPWYBsUUE1CW23vvEBGIzC2hKLH/TD9bLK2ApsW7uajYI W1Dix+R7LBA10RJLTx6FqheXaG69CRZnFJCVeDd/PivEzFCJpu9zmCFsI4mtX2eyQuwVkFiy 5zwzhC0q8fLxP7C4kICvxPIdv1gmMIrNQrJuFpJ1s5Csg7D1JG5MncIGYWtLLFv4mhnC1pWY 8e8QVI2ZxOyn31iR1Sxg5FjFKFacVJSZnlGSm5iZk25gpJeRqZeZl1qyiRESj5k7GJfvVDnE KMDBqMTDe/BbfJAQa2JZcWXuIUYJDmYlEd5W4YQgId6UxMqq1KL8+KLSnNTiQ4xMHJxSDYyd /Dc/fbf++/ze/mmnO8PSk5OyPxYd3/Hxoer9SQ9/7Wo4/mFJ8oa0FRb5x//xaexl9zX8/Ja/ 7aWh1bnvKTy3pN6U5PZfmmYp7jfn75KiGWceWVqLCceeDAq1YLmy6dVE/Rk/1mzQivAukvsq +elqQNT6Ji+T/r7zrs/qM1T0OzL28c+auf2REktxRqKhFnNRcSIA1xpuPKUCAAA= References: <525E39A4.7030201@um.es> Cc: "" 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, 17 Oct 2013 16:49:39 -0000 --Boundary_(ID_9tA1u3VphA4gjazsvUi0aA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, I plan to attend the meeting, and I am rather sure that at least another co= -author will be there, so please do add the item to the agenda. Be goode, On 16 Oct 2013, at 09:00 , Alejandro Perez Mendez wrote: El 16/10/13 08:01, Sanchez, Mauricio escribi=F3: Now that the the Perez, et.al. draft has made it into WG draft status we see that discussion turned to what the scope of solution should be. Can the authors of the draft summarize their current understanding of the situation and what their suggested/planned next steps are? I expect that one or more of the authors will be at IETF 88 to add this draft to the agenda, so please confirm availability. As a reminder, we are on the 1st day (Monday) at 1300. -Mauricio & Jouni Dear Mauricio & Jouni, the scope of this draft is to provide a means for the transmission of large= amounts of authorization data between two RADIUS endpoints. The reasons wh= y it is focused only on authorization data are described in the "Scope of t= his document" section on the draft, and can be summarized on the following = sentence: "Other exchanges (i.e. authentication and accounting) do not requ= ire of such a mechanism". This is justified on the following premises: 1) Authentication exchanges already deal with fragmentation (e.g. RADIUS-EA= P). Moreover, as they represent the most critical part of a RADIUS conversa= tion, it is preferable to not introduce any modification to their operation= that may affect existing equipment. 2) There not documented need for fragmentation of accounting data so far. Additionally, other of the cornerstone points of this mechanism is to work = through unmodified proxies, thus: * It should be based on UDP * It should not require of any change to the RADIUS specification * It should conform with current RADIUS attribute & packet formats Those are the basis of our draft, and the requirements that have guided the= definition of the current fragmentation mechanism. However, it does not provide a perfect solution. In particular, it requires= proxying to be done based on the User-Name attribute (although the most ty= pical case, specific scenarios may have a different configuration), it requ= ires proxies to not drop unrecognised attributes (who does not?), it requir= es proxies to not try to modify the contents of a packet (apart of insertin= g Proxy-State attributes), and the receptor do not know how much data will = arrive until it actually receives it. Taking into account aforementioned restrictions it seems that, for new depl= oyments where keeping the infrastructure unmodified is not a MUST, a differ= ent approach of using RADIUS TCP, *and* changing RADIUS specification to in= crease the maximum packet length from 4 KiB to 64 KiB may provide a simpler= solution. >From my perspective, both solutions could coexists. While the TCP-based sol= ution may provide a simpler solution, in scenarios where existing infrastru= cture cannot be easily upgraded, an UDP-based solution is still needed. We are currently finishing a new version which clarifies some points that w= ere raised on the mailing list, mainly related to the mentioned limitations= . It is our intention to have it ready before the IETF meeting. I will not personally attend the meeting, but I will be available via Jabbe= r. Regards, Alejandro On 8/26/13 12:35 AM, "Jouni Korhonen" wrote: 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 _______________________________________________ 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 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_9tA1u3VphA4gjazsvUi0aA) Content-id: Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi,

I plan to attend the meeting, and I am rather sure that at least anoth= er co-author will be there, so please do add the item to the agenda.

Be goode,

On 16 Oct 2013, at 09:00 , Alejandro Perez Mendez wrote:


El 16/10/13 08:01, Sanchez, Mauricio escribi= =F3:
Now that the the Perez, et.al. draft has made it into WG draft status =
we
see that discussion turned to what the scope of solution should be.  Can
the authors of the draft summarize their current understanding of the
situation and what their suggested/planned next steps are?  I expect that
one or more of the authors will be at IETF 88 to add this draft to the
agenda, so please confirm availability.

As a reminder, we are on the 1st day (Monday) at 1300.

-Mauricio & Jouni

Dear Mauricio & Jouni,

the scope of this draft is to provide a means for the transmission of large= amounts of authorization data between two RADIUS endpoints. The reasons wh= y it is focused only on authorization data are described in the "Scope= of this document" section on the draft, and can be summarized on the following sentence: "Other exchanges (i.= e. authentication and accounting) do not require of such a mechanism".= This is justified on the following premises:

1) Authentication exchanges already deal with fragmentation (e.g. RADIUS-EA= P). Moreover, as they represent the most critical part of a RADIUS conversa= tion, it is preferable to not introduce any modification to their operation= that may affect existing equipment.
2) There not documented need for fragmentation of accounting data so far.
Additionally, other of the cornerstone points of this mechanism is to work = through unmodified proxies, thus:
* It should be based on UDP
* It should not require of any change to the RADIUS specification
* It should conform with current RADIUS attribute & packet formats

Those are the basis of our draft, and the requirements that have guided the= definition of the current fragmentation mechanism.

However, it does not provide a perfect solution. In particular, it requires= proxying to be done based on the User-Name attribute (although the most ty= pical case, specific scenarios may have a different configuration), it requ= ires proxies to not drop unrecognised attributes (who does not?), it requires proxies to not try to modify the c= ontents of a packet (apart of inserting Proxy-State attributes), and the re= ceptor do not know how much data will arrive until it  actually receiv= es it.

Taking into account aforementioned restrictions it seems that, for new depl= oyments where keeping the infrastructure unmodified is not a MUST, a differ= ent approach of using RADIUS TCP, *and* changing RADIUS specification to in= crease the maximum packet length from 4 KiB to 64 KiB may provide a simpler solution.

>From my perspective, both solutions could coexists. While the TCP-based sol= ution may provide a simpler solution, in scenarios where existing infrastru= cture cannot be easily upgraded, an UDP-based solution is still needed.

We are currently finishing a new version which clarifies some points that w= ere raised on the mailing list, mainly related to the mentioned limitations= . It is our intention to have it ready before the IETF meeting.

I will not personally attend the meeting, but I will be available via Jabbe= r.

Regards,
Alejandro






On 8/26/13 12:35 AM, "Jouni Korhonen" <jouni.nospam@gmail.com&g=
t; wrote:


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 <jouni.nospam@gmail.com> 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
radex=
t@ietf.org
https://www.ietf.org/mailman/listinfo/radext



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

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


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_9tA1u3VphA4gjazsvUi0aA)-- From internet-drafts@ietf.org Thu Oct 17 10:52: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 41F2311E8295; Thu, 17 Oct 2013 10:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, 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 g8KW+YHp0RfX; Thu, 17 Oct 2013 10:52:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DABE11E8146; Thu, 17 Oct 2013 10:52:36 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131017175236.32568.32666.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 10:52:36 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:52:37 -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 : The Network Access Identifier Author(s) : Alan DeKok Filename : draft-ietf-radext-nai-04.txt Pages : 24 Date : 2013-10-17 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each others users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282 [RFC4282], which addresses issues with international character sets, as well as a number of other corrections to the previous document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-nai There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-nai-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@painless-security.com Fri Oct 18 08:01: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 6662111E82CB for ; Fri, 18 Oct 2013 08:01:17 -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 ge7hh3ZoywGi for ; Fri, 18 Oct 2013 08:01:12 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE4A21F8F9A for ; Fri, 18 Oct 2013 08:01:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6C193204F9; Fri, 18 Oct 2013 10:59:22 -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 uTlHZyemaliA; Fri, 18 Oct 2013 10:59:20 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.108]) (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, 18 Oct 2013 10:59:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2594F83781; Fri, 18 Oct 2013 11:01:05 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <066.d7856f6a412e6225fc72caaacf5fd2b6@trac.tools.ietf.org> <081.5f9e1b3cafd15a1e03ba10b80f9a75fa@trac.tools.ietf.org> <525FD54A.1080202@deployingradius.com> Date: Fri, 18 Oct 2013 11:01:05 -0400 In-Reply-To: <525FD54A.1080202@deployingradius.com> (Alan DeKok's message of "Thu, 17 Oct 2013 08:17:14 -0400") 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: bernard_aboba@hotmail.com, radext@ietf.org, radext issue tracker Subject: Re: [radext] #146: Terminology and RFC 6365 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, 18 Oct 2013 15:01:17 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> It does not make sense to close an issue if you are still waiting >> for input Alan> I think this comment was about the normalization issue. Alan> The text in the current draft addresses Bernards comments Alan> directly. It's the best we can do given our current Alan> knowledge. So IMHO, the issue should be closed. Alan> We could track a separate issue to "get feedback from i18n Alan> people". But that's already on my short list for Vancouver. Alan> As soon as I get an answer, I'll report it to the list, and do Alan> a final update of the document. I think I'd be fine with a new issue opened to track i18n review. I agree additional review is required and don't believe we're done until we get that review. From trac+radext@trac.tools.ietf.org Sun Oct 20 13:14:50 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 D72D411E8264 for ; Sun, 20 Oct 2013 13:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.641 X-Spam-Level: X-Spam-Status: No, score=-101.641 tagged_above=-999 required=5 tests=[AWL=0.958, 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 MdOo4onSx5hE for ; Sun, 20 Oct 2013 13:14:50 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BED8311E842B for ; Sun, 20 Oct 2013 13:14:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:56849 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VXzOa-00010Y-0b; Sun, 20 Oct 2013 22:14:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 20 Oct 2013 20:14:39 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/169#comment:1 Message-ID: <081.f57f02d52653a58d559e4e57003b9484@trac.tools.ietf.org> References: <066.c432cc21d21b9ea3a853702eea13f968@trac.tools.ietf.org> X-Trac-Ticket-ID: 169 In-Reply-To: <066.c432cc21d21b9ea3a853702eea13f968@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131020201449.BED8311E842B@ietfa.amsl.com> Resent-Date: Sun, 20 Oct 2013 13:14:49 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #169: WLAN-SSID Attribute redundant X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 20:14:51 -0000 #169: WLAN-SSID Attribute redundant Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Oct 20 13:57:54 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 0C05F11E8278 for ; Sun, 20 Oct 2013 13:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.778 X-Spam-Level: X-Spam-Status: No, score=-101.778 tagged_above=-999 required=5 tests=[AWL=0.821, 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 OxjTu8V-mpNs for ; Sun, 20 Oct 2013 13:57:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7011E8281 for ; Sun, 20 Oct 2013 13:57:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:60518 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY04F-0001EG-UE; Sun, 20 Oct 2013 22:57:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 20 Oct 2013 20:57:43 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/170 Message-ID: <066.8c6dadfe7b14348ea276155a3c7ba51e@trac.tools.ietf.org> X-Trac-Ticket-ID: 170 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131020205753.17A7011E8281@ietfa.amsl.com> Resent-Date: Sun, 20 Oct 2013 13:57:52 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #170: Allowed-Called-Station-Id usage scenarios X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 20:57:54 -0000 #170: Allowed-Called-Station-Id usage scenarios Section 2.1 currently lists three potential usage scenarios for the Allowed-Called-Station-Id attribute. However, of the three scenarios, the most compelling ones relate to wireless. Narrowing the focus to a single usage scenario would improve the clarity of the section. The following text is proposed for Section 2.1: 2.1. Allowed-Called-Station-Id Description The Allowed-Called-Station-Id Attribute allows the RADIUS server to specify the authenticator MAC addresses and/or networks to which the user is allowed to connect. One or more Allowed-Called- Station-Id attributes MAY be included in an Access-Accept or CoA- Request packet. The Allowed-Called-Station-Id Attribute can be useful in situations where pre-authentication is supported (e.g. IEEE 802.11 pre-authentication). In these scenarios, the network name typically will not be included in a Called-Station-Id Attribute within the Access-Request and the RADIUS server will not know the network that the user is attempting to access. The Allowed- Called-Station-Id enables the RADIUS server to restrict the networks and attachment points to which the user can subsequently connect. A summary of the Allowed-Called-Station-Id Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code TBD1 Length >=3 String The String field is one or more octets, specifying a Called- Station-Id that the user may utilize as a point of attachment. If the user attempts to connect to the Network Authentication Server (NAS) from a Called-Station-Id that does not match one of the Allowed-Called-Station-Id attributes, then the NAS MUST NOT permit the user to access the network. In the case of IEEE 802, the Allowed-Called-Station-Id Attribute is used to store the Medium Access Control (MAC) address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where restrictions on both the network and authenticator MAC address usage are intended, the network name MUST be appended to the authenticator MAC address, separated from the MAC address with a ":". Example: "00-10-A4-23-19-C0:AP1". Where no MAC address restriction is intended, the MAC address field MUST be omitted, but ":" and the network name field MUST be included. Example: ":AP1". Within IEEE 802.11 [IEEE-802.11], the SSID constitutes the network name; within IEEE 802.1X [IEEE-802.1X], the Network-Id Name (NID- Name) constitutes the network name. Since a NID-Name can be up to 253 octets in length, when used with [IEEE-802.1X], there may not be sufficient room within the Allowed-Called-Station-Id Attribute to include both a MAC address and a Network Name. However, since the Allowed-Called-Station-Id Attribute is expected to be used largely in wireless access scenarios, this restriction is not considered serious. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Oct 20 14:32:54 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 5A75411E8292 for ; Sun, 20 Oct 2013 14:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.88 X-Spam-Level: X-Spam-Status: No, score=-101.88 tagged_above=-999 required=5 tests=[AWL=0.719, 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 MCaStqZknC20 for ; Sun, 20 Oct 2013 14:32:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3E56111E8444 for ; Sun, 20 Oct 2013 14:32:50 -0700 (PDT) Received: from localhost ([127.0.0.1]:34707 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY0c6-0005R5-1u; Sun, 20 Oct 2013 23:32:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 20 Oct 2013 21:32:41 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/170#comment:1 Message-ID: <081.c12eaf68c72597f1e514f0f325d42d6d@trac.tools.ietf.org> References: <066.8c6dadfe7b14348ea276155a3c7ba51e@trac.tools.ietf.org> X-Trac-Ticket-ID: 170 In-Reply-To: <066.8c6dadfe7b14348ea276155a3c7ba51e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131020213251.3E56111E8444@ietfa.amsl.com> Resent-Date: Sun, 20 Oct 2013 14:32:50 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #170: Allowed-Called-Station-Id usage scenarios X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 21:32:54 -0000 #170: Allowed-Called-Station-Id usage scenarios Comment (by bernard_aboba@hotmail.com): Some clean up of the proposed text for Section 2.1: 2.1. Allowed-Called-Station-Id Description The Allowed-Called-Station-Id Attribute allows the RADIUS server to specify the authenticator MAC addresses and/or networks to which the user is allowed to connect. One or more Allowed-Called- Station-Id attributes MAY be included in an Access-Accept, CoA- Request or Accounting-Request packet. The Allowed-Called-Station-Id Attribute can be useful in situations where pre-authentication is supported (e.g. IEEE 802.11 pre-authentication). In these scenarios, a Called-Station- Id Attribute typically will not be included within the Access- Request so that the RADIUS server will not know the network that the user is attempting to access. The Allowed-Called-Station-Id enables the RADIUS server to restrict the networks and attachment points to which the user can subsequently connect. A summary of the Allowed-Called-Station-Id Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code TBD1 Length >=3 String The String field is one or more octets, specifying a Called- Station-Id that the user MAY connect to; if the Called-Station-Id that the user connects to does not match one of the Allowed- Called-Station-Id Attributes, the Network Authentication Server (NAS) MUST NOT permit the user to access the network. In the case of IEEE 802, the Allowed-Called-Station-Id Attribute is used to store the Medium Access Control (MAC) address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". Where restrictions on both the network and authenticator MAC address usage are intended, the network name MUST be appended to the authenticator MAC address, separated from the MAC address with a ":". Example: "00-10-A4-23-19-C0:AP1". Where no MAC address restriction is intended, the MAC address field MUST be omitted, but ":" and the network name field MUST be included. Example: ":AP1". Within IEEE 802.11 [IEEE-802.11], the SSID constitutes the network name; within IEEE 802.1X [IEEE-802.1X], the Network-Id Name (NID- Name) constitutes the network name. Since a NID-Name can be up to 253 octets in length, when used with [IEEE-802.1X], there may not be sufficient room within the Allowed-Called-Station-Id Attribute to include both a MAC address and a Network Name. However, since the Allowed-Called-Station-Id Attribute is expected to be used largely in wireless access scenarios, this restriction is not considered serious. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Oct 20 14:34:44 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 DB32111E828C for ; Sun, 20 Oct 2013 14:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.96 X-Spam-Level: X-Spam-Status: No, score=-101.96 tagged_above=-999 required=5 tests=[AWL=0.639, 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 awJx9uy2SBzx for ; Sun, 20 Oct 2013 14:34:44 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 555CF11E8290 for ; Sun, 20 Oct 2013 14:34:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:35062 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY0dy-0006HJ-VR; Sun, 20 Oct 2013 23:34:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 20 Oct 2013 21:34:38 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/171 Message-ID: <066.c317995d834641dbb305f75b27c8f880@trac.tools.ietf.org> X-Trac-Ticket-ID: 171 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131020213444.555CF11E8290@ietfa.amsl.com> Resent-Date: Sun, 20 Oct 2013 14:34:44 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #171: Updates: 3580 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 21:34:45 -0000 #171: Updates: 3580 Since the document indicates that the NID-Name is not to be include in the Called-Station-Id attribute, it updates RFC 3580. The proposed resolution is to indicate this in the document meta-data (in the Updates: field in the header). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Oct 20 16:22:01 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 2056D11E82C5 for ; Sun, 20 Oct 2013 16:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 4ZfDreHkuaGj for ; Sun, 20 Oct 2013 16:22:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7C311E80DE for ; Sun, 20 Oct 2013 16:22:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:44229 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY2Jk-0000X4-J4; Mon, 21 Oct 2013 01:21:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com X-Trac-Project: radext Date: Sun, 20 Oct 2013 23:21:52 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:6 Message-ID: <081.d5a0d836d7f002ae4119f480f96e27b8@trac.tools.ietf.org> References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131020232200.5B7C311E80DE@ietfa.amsl.com> Resent-Date: Sun, 20 Oct 2013 16:22:00 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 23:22:01 -0000 #153: Section 2.8 Access-Info Comment (by bernard_aboba@hotmail.com): As discussed at IETF 87, it may be necessary to transport multiple EAPoL- Announcement TLVs, not just the Access Information TLV. As a result a more generic solution is needed. The proposed resolution is to define an EAPoL-Announcement Attribute in Section 2.8. Here is the proposed text: 2.8. EAPoL-Announcement Description The EAPoL-Announcement Attribute contains EAPoL-Announcement Type Length Value Tuples (TLVs) defined within Table 11-8 of IEEE-802.1X [IEEE-802.1X]. Zero or more EAPoL-Announcement Attributes are permitted within an Access-Request, Access-Accept, Access-Challenge, Access-Reject, Accounting-Request, CoA-Request or Disconnect-Request packet. When included within an Access-Request packet, EAPoL- Announcement Attributes contain TLVs that the user sent in an EAPoL-Announcement. When included within an Access-Accept, Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request packet, EAPoL-Announcement Attributes contain EAPoL- Announcement TLVs that the NAS is to send to the user in a unicast EAPoL-Announcement. When sent within an Accounting-Request packet, EAPoL-Announcment attributes contain EAPoL- Announcement TLVs that the NAS has most recently sent to the user in a unicast EAPoL-Announcement. A summary of the EAPoL-Announcement Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code TBD7 Length >=3 String The String field is one or more octets, containing EAPoL- Announcement TLVs in the format defined in Figure 11-8 of Section 11.12 of [IEEE-802.1X]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length | TLV Information String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If multiple EAPoL-Announcement attributes are present in a packet, their String fields should be concatenated before being parsed for EAPoL-Announcement TLVs; this allows TLVs longer than 253 octets to be transported by RADIUS. TLV Type Any EAPoL-Announcement TLV Type MAY be included within an EAPoL- Announcement Attribute, including Organizationally Specific TLVs. TLV Length <=511 TLV Information String The TLV Information String field contains information specific to the TLV Type. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: reopened Priority: critical | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Oct 20 16:50: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 7494721F9FAC for ; Sun, 20 Oct 2013 16:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[AWL=0.523, 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 IVCj7SXht7Ml for ; Sun, 20 Oct 2013 16:50:20 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A856F21F9FA4 for ; Sun, 20 Oct 2013 16:50:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:46906 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY2lC-00014z-9z; Mon, 21 Oct 2013 01:50:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com X-Trac-Project: radext Date: Sun, 20 Oct 2013 23:50:14 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:7 Message-ID: <081.5af36284efbab97c92cf7df8fa0dde3f@trac.tools.ietf.org> References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131020235020.A856F21F9FA4@ietfa.amsl.com> Resent-Date: Sun, 20 Oct 2013 16:50:20 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 23:50:21 -0000 #153: Section 2.8 Access-Info Comment (by bernard_aboba@hotmail.com): Updated text: 2.8. EAPoL-Announcement Description The EAPoL-Announcement Attribute contains EAPoL-Announcement Type Length Value Tuples (TLVs) defined within Table 11-8 of IEEE-802.1X [IEEE-802.1X]. Zero or more EAPoL-Announcement attributes are permitted within an Access-Request, Access-Accept, Access-Challenge, Access-Reject, Accounting-Request, CoA-Request or Disconnect-Request packet. When included within an Access-Request packet, EAPoL-Announcement attributes contain EAPoL-Announcement TLVs that the user sent in an EAPoL-Announcement. When included within an Access-Accept, Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request packet, EAPoL-Announcement attributes contain EAPoL-Announcement TLVs that the NAS is to send to the user in a unicast EAPoL- Announcement. When sent within an Accounting-Request packet, EAPoL-Announcment attributes contain EAPoL-Announcement TLVs that the NAS has most recently sent to the user in a unicast EAPoL- Announcement. A summary of the EAPoL-Announcement Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code TBD7 Length >=3 String The String field is one or more octets, containing EAPoL- Announcement TLVs in the format defined in Figure 11-8 of Section 11.12 of [IEEE-802.1X]. Any EAPoL-Announcement TLV Type MAY be included within an EAPoL-Announcement Attribute, including Organizationally Specific TLVs. If multiple EAPoL-Announcement attributes are present in a packet, their String fields MUST be concatenated before being parsed for EAPoL-Announcement TLVs; this allows EAPoL-Announcement TLVs longer than 253 octets to be transported by RADIUS. Similarly, EAPoL-Announcement TLVs larger than 253 octets MUST be fragmented between multiple EAPoL- Announcement attributes. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: reopened Priority: critical | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From internet-drafts@ietf.org Sun Oct 20 16:53:30 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 D663D11E82E2; Sun, 20 Oct 2013 16:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 PnGrlB6hvcRv; Sun, 20 Oct 2013 16:53:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E8111E82DC; Sun, 20 Oct 2013 16:53: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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131020235330.22714.11678.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 16:53:30 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ieee802ext-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 23:53: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 : RADIUS Attributes for IEEE 802 Networks Author(s) : Bernard Aboba Jouni Malinen Paul Congdon Joseph Salowey Mark Jones Filename : draft-ietf-radext-ieee802ext-09.txt Pages : 28 Date : 2013-10-20 Abstract: RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as clarifying the usage of the EAP-Key- Name attribute (updating RFC 4072) and the Called-Station-Id attribute (updating RFC 3580). The attributes defined in this document are usable both within RADIUS and Diameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ieee802ext-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ieee802ext-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 12:04:36 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 DBB8011E86E7; Mon, 21 Oct 2013 12:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 gYJOuw7hqlPd; Mon, 21 Oct 2013 12:04:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B91011E86CE; Mon, 21 Oct 2013 12:01:01 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021190101.32548.6269.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 12:01:01 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:04:39 -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-01.txt Pages : 27 Date : 2013-10-21 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-fragmentation-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@mit.edu Mon Oct 21 13:00:08 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 0593E11E826A for ; Mon, 21 Oct 2013 13:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 IB6pDLkvtZvx for ; Mon, 21 Oct 2013 13:00: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 D6E8111E870E for ; Mon, 21 Oct 2013 12:58:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 53ECF20503 for ; Mon, 21 Oct 2013 15:56:07 -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 DneK-FDZLZyJ for ; Mon, 21 Oct 2013 15:56:07 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (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 for ; Mon, 21 Oct 2013 15:56:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 205F682A4F; Mon, 21 Oct 2013 15:57:57 -0400 (EDT) From: Sam Hartman To: radext@ietf.org Date: Mon, 21 Oct 2013 15:57:57 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [radext] [internet-drafts@ietf.org] New Version Notification for draft-hartman-radext-bigger-packets-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: Mon, 21 Oct 2013 20:00:08 -0000 --=-=-= I've written a draft that proposes expanding the maximum packet size for RFC 6613-based transports including RFC 6614. This draft is intentionally designed to be minimal: no capability negotiation as an example. A few details such as the registration of code points are left out, but I believe the draft is complete enough to evaluate the technical approach. My draft is intentionally simpler than Peter's approach (or the part of it that deals with this) I don't think the complexity of his approach is needed for solving the part of the problem I would like to see solved. I believe this draft compliments draft-ietf-radext-radius-fragmentation and would like to see my draft and that draft go forward. Comments welocme. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mail.painless-security.com ([unix socket]) by mail.suchdamage.org (Cyrus v2.4.16-Debian-2.4.16-4) with LMTPA; Mon, 21 Oct 2013 15:50:48 -0400 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A2C6520503 for ; Mon, 21 Oct 2013 15:50:47 -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 3CXJLjd6Q14x for ; Mon, 21 Oct 2013 15:50:47 -0400 (EDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mail.painless-security.com (Postfix) with ESMTP for ; Mon, 21 Oct 2013 15:50:47 -0400 (EDT) Received: from mailhub-dmz-1.mit.edu ( [18.9.21.41]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 58.12.02612.70685625; Mon, 21 Oct 2013 15:52:39 -0400 (EDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id r9LJnsUB011926 for ; Mon, 21 Oct 2013 15:52:38 -0400 X-AuditID: 12074422-b7f5a8e000000a34-56-526586072497 Authentication-Results: symauth.service.identifier Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id E0.44.02502.60685625; Mon, 21 Oct 2013 15:52:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A1C11E867D for ; Mon, 21 Oct 2013 12:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 gPn+ULu52gIb for ; Mon, 21 Oct 2013 12:52:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0B221F9FC8; Mon, 21 Oct 2013 12:50:06 -0700 (PDT) From: internet-drafts@ietf.org To: Sam Hartman , "Sam D. Hartman" Subject: New Version Notification for draft-hartman-radext-bigger-packets-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021195006.32455.95710.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 12:50:06 -0700 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixCmqqcvelhpkcPyMsMXXtgdsDoweK6ee Zg9gjOKySUnNySxLLdK3S+DKuDPzEHNBB1fFzEOvWBoYz7N3MXJySAiYSPT8/skGYYtJXLi3 Hsjm4hAS2MsosXTpYmYI5z6jxLStN9hgOiZ3zmIFsRkFjCR2n3vFClF0mFHiRHcXI4SzjlFi X+t0VogODYkZKy9AJa4wSmyYtZgFJCEkMI1R4vNaNxCbV0BQ4uTMJ0BxDg5mAU2J9bv0QcLM AtoSyxa+Zgax2QTkJFa/msYIYosIRElMu/YPbL6wQJDEidmHmSF2iUi8u/oQypaUOLJyHxvE pXISP449ZgKxBQQEJP5NusACsdZR4u+3FWA2i4CqREfjfLCXJQS+sks0zVjNNoFRYhaS82Yh nDcLyXkLGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrq5WaW6KWmlG5iBEUWu4vSDsafB5UO MQpwMCrx8GZYpQYJsSaWFVfmHmKU5GBSEuU92wwU4kvKT6nMSCzOiC8qzUktPsQowcGsJMIr kAyU401JrKxKLcqHSclwcChJ8Bq0AqUEi1LTUyvSMnOA6QMmzcTBCdLOA9TuBVLDW1yQmFuc mQ6RP8WoKCXOOxlkpwBIIqM0D64XlrxeMYoDHSvMqwjSzgNMfHDdr4AGMwENdmYEG1ySiJCS amDsOGmm7+gn0/pmtXjM1J9KbTf+vla68NfkQvTzlsgtO+J3hqr4qAVnMDw0+tQ/2dEvsPDk o5Af6cyx99Pvi/2V7hV4Ot+5rCT09Mm+fQufdYvpPPtX67L6xvuOLbbM9w+KvuHes/YGyzNv vg7z6V8LCzWjTmhxd0eE/tQWn/nCyku+me3UrqtKLMUZiYZazEXFiQBgjCWROQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRWlGSWpSXmKPExsXCI2Ylp8vWlhpk8KBDy2LO19VsDoweTWeO MgcwRnHZpKTmZJalFunbJXBl3Jl5iLmgg6ti5qFXLA2M59m7GDk5JARMJCZ3zmIFsRkFjCR2 n3vFChEXk7hwbz1bFyMXh5DAYUaJE91djBDOOkaJfa3Toao0JGasvACVuMIosWHWYhaQhJDA NEaJz2vdQGxeAUGJkzOfAMU5OJgFNCXW79IHCTMLaEssW/iaGcRmE5CTWP1qGiOILSLgL9H6 /QDYdcICQRInZh9mhtglIvHu6kMoW1LiyMp9bBBXy0n8OPaYCcQWEBCQ+DfpAgvEWkeJv99W gNksAqoSHY3zmScwisxCctEshItmIbloASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0TvdzM Er3UlNJNjMCQF+KU5N/B+O2g0iFGAQ5GJR7eDKvUICHWxLLiytxDjJIcTEqivGebgUJ8Sfkp lRmJxRnxRaU5qcWHGCU4mJVEeAWSgXK8KYmVValF+TApaQ4WJXHemxz2QUIC6YklqdmpqQWp RTBZJg72Q4wyHBxKErxFrUDdgkWp6akVaZk5JchqOEEEF8gaHqA1bSCFvMUFibnFmekQRacY FaXEeSeD3CYAksgozYMbAEtTlxhlpYR5GRkYGIR4gC4AehxV/hWjONDTwrxxION5MvNK4Ka/ AlrMBLTYmRFscUkiQkqqgZGhb56P15cDs/3lCj54TX8f1h9juuQty6xn/Gsr1lt/D5aq3vHn /3L/NZzHKh8rPd9lYXpV+cPr5jDpI2/KBTMnelvt/PeP2epU5dx0hb5V9yatblLwWMu5iVe/ 8TKzgeIfkR9p99gkJDT9OFhjzMR3577UFn19LqPsbPTsLezpD2zZ/Dsnv1ZiKc5INNRiLipO BAChqrwwTgMAAA== MIME-Version: 1.0 A new version of I-D, draft-hartman-radext-bigger-packets-00.txt has been successfully submitted by Sam Hartman and posted to the IETF repository. Filename: draft-hartman-radext-bigger-packets Revision: 00 Title: Larger Packets for Remote RADIUS over TCP Creation date: 2013-10-21 Group: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-hartman-radext-bigger-packets-00.txt Status: http://datatracker.ietf.org/doc/draft-hartman-radext-bigger-packets Htmlized: http://tools.ietf.org/html/draft-hartman-radext-bigger-packets-00 Abstract: The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. 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. The IETF Secretariat --=-=-=-- From aland@deployingradius.com Mon Oct 21 13:56: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 BAAC311E83F4 for ; Mon, 21 Oct 2013 13:56:21 -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 atlaPfyA83pZ for ; Mon, 21 Oct 2013 13:56:15 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4C511E81C8 for ; Mon, 21 Oct 2013 13:56:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 28295224013F; Mon, 21 Oct 2013 22:55:13 +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 vgdCfGHlET1f; Mon, 21 Oct 2013 22:55:11 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176121002.dsl.bell.ca [70.26.46.170]) by power.freeradius.org (Postfix) with ESMTPSA id D0CE82240098; Mon, 21 Oct 2013 22:55:10 +0200 (CEST) Message-ID: <526594C5.7040406@deployingradius.com> Date: Mon, 21 Oct 2013 16:55:33 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] [internet-drafts@ietf.org] New Version Notification for draft-hartman-radext-bigger-packets-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: Mon, 21 Oct 2013 20:56:21 -0000 Sam Hartman wrote: > I believe this draft compliments draft-ietf-radext-radius-fragmentation > and would like to see my draft and that draft go forward. I think it's a good start. I'd prefer capability negotiation, as it's more robust. But it also opens another can of worms which is better left closed. Alan DeKok. From peterd@iea-software.com Mon Oct 21 17:30:06 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 3785011E875F for ; Mon, 21 Oct 2013 17:30:06 -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 9x35b27SrD3D for ; Mon, 21 Oct 2013 17:30:01 -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 587C711E82CE for ; Mon, 21 Oct 2013 17:29:58 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 21 Oct 2013 17:29:57 -0700 Date: Mon, 21 Oct 2013 17:29:35 -0700 (Pacific Daylight Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: 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] [internet-drafts@ietf.org] New Version Notification for draft-hartman-radext-bigger-packets-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, 22 Oct 2013 00:30:06 -0000 On Mon, 21 Oct 2013, Sam Hartman wrote: > I've written a draft that proposes expanding the maximum packet size for > RFC 6613-based transports including RFC 6614. This draft is > intentionally designed to be minimal: no capability negotiation as an > example. > A few details such as the registration of code points are left out, but > I believe the draft is complete enough to evaluate the technical > approach. > My draft is intentionally simpler than Peter's approach (or the part of > it that deals with this) The way my draft is structured one can simply provide a non-default administrative option at each peer enabling large packets. No new command codes or attributes required. > I don't think the complexity of his approach is needed for solving the > part of the problem I would like to see solved. Don't know how much the following matters for your uses - some things to think about. Section 3. With TCP any number of RADIUS requests could be in-flight before RADIUS server even sees a request to react. When a connection is dropped client can't always even be sure what request if any closure was in response let alone why. In response to closure specifically and the "too big" code in general how long should client think bigger-packets is not supported by server? next connection? forever? RFC6613 allows implementation to close TCP connection in response to unknown code. This "MAY" cause a client not supporting bigger-packets to disconnect on receipt of the "too big" code. This unfortunately is a good example why I don't support this language in RFC6613. 2. "Clients MAY silently discard a packet greater than some configured size" How does this work? For example I'm authenticating someone and Access-Accept is too big. Do I assume access-reject? Keep waiting for the response that is not too big? regards, Peter From alex@um.es Tue Oct 22 00:57:06 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 CE64911E814C for ; Tue, 22 Oct 2013 00:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 0Oie9UML-XWE for ; Tue, 22 Oct 2013 00:57:02 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 2892C11E817C for ; Tue, 22 Oct 2013 00:56:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 8A88E5D511 for ; Tue, 22 Oct 2013 09:56:33 +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 gGL38rr4POdR for ; Tue, 22 Oct 2013 09:56:33 +0200 (CEST) Received: from [192.168.10.2] (84.124.131.72.dyn.user.ono.com [84.124.131.72]) (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 0FD775D4F8 for ; Tue, 22 Oct 2013 09:56:31 +0200 (CEST) Message-ID: <52662FAE.3040900@um.es> Date: Tue, 22 Oct 2013 09:56:30 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050005080509090207020903" Subject: Re: [radext] [internet-drafts@ietf.org] New Version Notification for draft-hartman-radext-bigger-packets-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, 22 Oct 2013 07:57:06 -0000 This is a multi-part message in MIME format. --------------050005080509090207020903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > I've written a draft that proposes expanding the maximum packet size for > RFC 6613-based transports including RFC 6614. > This draft is intentionally designed to be minimal: no capability > negotiation as an example. > A few details such as the registration of code points are left out, but > I believe the draft is complete enough to evaluate the technical > approach. > > My draft is intentionally simpler than Peter's approach (or the part of > it that deals with this) > I don't think the complexity of his approach is needed for solving the > part of the problem I would like to see solved. > > I believe this draft compliments draft-ietf-radext-radius-fragmentation > and would like to see my draft and that draft go forward. > > Comments welocme. > Sam, thank you for this contribution, I think it is a better choice for situations where keeping the infrastructure untouched is not a MUST. I have one comment. In the text, you state that: Clients will not typically be able to adjust and resend requests when this error is received. Having that expectation in mind, and wondering what the actual impact of just dropping the entire session is, wouldn't it be more simple to just send an Access-Reject code with the new attribute indicating the reason (eg. packet over 3500 octets), instead of defining a new code? The client would be able to re-start the session using smaller packets, RADIUS fragmentation or just desisting from it. Of course, this would require to start over with the current session. But since you don't really expect clients to dynamically re-adjust packet size, that there might be a negotiation capability, and that there would probably exists a federation agreement... what is the real impact of just dropping the session? Regards, Alejandro > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------050005080509090207020903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
I've written a draft that proposes expanding the maximum packet size for
RFC 6613-based transports including RFC 6614.
This draft is intentionally designed to be minimal: no capability
negotiation as an example.
A few details such as the registration of code points are left out, but
I believe the draft is complete enough to evaluate the technical
approach.

My draft is intentionally simpler than Peter's approach (or the part of
it that deals with this)
I don't think the complexity of his approach is needed for solving the
part of the problem I would like to see solved.

I believe this draft compliments draft-ietf-radext-radius-fragmentation
and would like to see my draft and that draft go forward.

Comments welocme.

Sam,

thank you for this contribution, I think it is a better choice for situations where keeping the infrastructure untouched is not a MUST.

I have one comment. In the text, you state that:
Clients will not typically be able to adjust and resend requests when
   this error is received.
Having that expectation in mind, and wondering what the actual impact of just dropping the entire session is, wouldn't it be more simple to just send an Access-Reject code with the new attribute indicating the reason (eg. packet over 3500 octets), instead of defining a new code? The client would be able to re-start the session using smaller packets, RADIUS fragmentation or just desisting from it.

Of course, this would require to start over with the current session. But since you don't really expect clients to dynamically re-adjust packet size, that there might be a negotiation capability, and that there would probably exists a federation agreement... what is the real impact of just dropping the session?

Regards,
Alejandro


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

--------------050005080509090207020903-- From sdanda@cisco.com Sun Oct 27 22:58: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 2511111E832E for ; Sun, 27 Oct 2013 22:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vwXlZo4odu1E for ; Sun, 27 Oct 2013 22:58:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5F11E8337 for ; Sun, 27 Oct 2013 22:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=947; q=dns/txt; s=iport; t=1382939892; x=1384149492; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YTm6dwzLBWQpNX2zCePgmLqlYb6m6j6U8iOS16KXOd8=; b=bCDF+jCbECT/jrQq9ro4pKe5pI0is9SPRrJCRA7NigIW+p9hmyVeg2/Y N00sAJXgtm57K3weptojxd88jszEViO4DEq0Sk5xzX3fZe7jBT1JPdo0N YfZMyaG5wwUEeqFLoI6A0s+a80+Q3iE231tQzqprnRtr0jGIkxvlGN7l3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAIT8bVKtJXG8/2dsb2JhbABZgwc4VL4TS4EdFnSCJQEBAQQBAQE3NAkCDAQCAQgRBAEBAQoUBQQHJwsUCQgCBAENBQiHfw24FgSPJDEHBoMZgQ0DqhGBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,584,1378857600"; d="scan'208";a="277351658" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 28 Oct 2013 05:58:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9S5wAbw015518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 05:58:10 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 00:58:09 -0500 From: "Satyanarayana Danda (sdanda)" To: Alan DeKok , Sam Hartman Thread-Topic: [radext] [internet-drafts@ietf.org] New Version Notification for draft-hartman-radext-bigger-packets-00.txt Thread-Index: AQHOzpg1+ZPVT556lkS/x9ruILH87pn/9mWAgAmxSOA= Date: Mon, 28 Oct 2013 05:58:08 +0000 Message-ID: References: <526594C5.7040406@deployingradius.com> In-Reply-To: <526594C5.7040406@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.105.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] [internet-drafts@ietf.org] New Version Notification for draft-hartman-radext-bigger-packets-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: Mon, 28 Oct 2013 05:58:22 -0000 I would like to second Alan to look at capability negotiation framework for= these kind of extensions to be wel negotiated. Thanks Satya -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= Alan DeKok Sent: Tuesday, October 22, 2013 2:26 AM To: Sam Hartman Cc: radext@ietf.org Subject: Re: [radext] [internet-drafts@ietf.org] New Version Notification f= or draft-hartman-radext-bigger-packets-00.txt Sam Hartman wrote: > I believe this draft compliments=20 > draft-ietf-radext-radius-fragmentation > and would like to see my draft and that draft go forward. I think it's a good start. I'd prefer capability negotiation, as it's mo= re robust. But it also opens another can of worms which is better left clo= sed. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Tue Oct 29 07:01:46 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 A33B111E825C for ; Tue, 29 Oct 2013 07:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.6 X-Spam-Level: X-Spam-Status: No, score=-107.6 tagged_above=-999 required=5 tests=[AWL=1.602, BAYES_00=-2.599, 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 3EtnEmiZh1Zr for ; Tue, 29 Oct 2013 07:01:40 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53611E815F for ; Tue, 29 Oct 2013 07:01:39 -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 g6t0186.atlanta.hp.com (Postfix) with ESMTPS id D796D2C00A for ; Tue, 29 Oct 2013 14:01:33 +0000 (UTC) Received: from G6W3999.americas.hpqcorp.net (16.205.80.214) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Oct 2013 13:59:11 +0000 Received: from G6W2505.americas.hpqcorp.net ([169.254.12.30]) by G6W3999.americas.hpqcorp.net ([16.205.80.214]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 13:59:11 +0000 From: "Sanchez, Mauricio" To: "radext@ietf.org" Thread-Topic: IETF 88: Preliminary Agenda Thread-Index: AQHO1K8KVe4WmyigtUuqImVIefAQEA== Date: Tue, 29 Oct 2013 13:59:10 +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.8.130913 x-originating-ip: [15.193.49.17] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3465874748_11305528" MIME-Version: 1.0 Subject: [radext] IETF 88: Preliminary Agenda 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, 29 Oct 2013 14:01:46 -0000 --B_3465874748_11305528 Content-type: multipart/alternative; boundary="B_3465874747_11263064" --B_3465874747_11263064 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable At IETF 87 RADEXT has 90 minutes allocated (Monday 11/4 1:00PM-2:30PM). Below is the draft agenda consisting of items the chairs would believe would be useful to discuss. Please respond with any suggested changes or comments. -Jouni & Mauricio =8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B RADEXT WG IETF 88 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, Nov 4, 2013 1:00 - 2:30PM Plaza A 1:00 - 1:10 PM, Preliminaries (10 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Working group draft discussion (45 minutes) ------------------------------------------- 1:10 - 1:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 minutes) http://tools.ietf.org/id/draft-ietf-radext-dtls 1:20 - 1:25PM The Network Access Identifier, Alan DeKok (5 minutes) http://tools.ietf.org/html/draft-ietf-radext-nai 1:25 - 1:30PM RADIUS dynamic discovery, Stefan Winter (5 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 1:30 - 1:40PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-ieee802ext 1:40 - 1:55PM Support of fragmentation of RADIUS packets, Diego Lopez (15 minutes) http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation Chartered individual draft discussion (15 minutes) -------------------------------------------------- 1:55 - 2:10PM Larger Packets for Remote RADIUS over TCP, Sam Hartman (15 minutes) http://tools.ietf.org/html/draft-hartman-radext-bigger-packets Wrap-up (10 minutes) -------------------- 2:10 - 2:20 PM Next Steps: WG Chairs & ADs (5 minutes) WG Goals/Milestones status, next steps --B_3465874747_11263064 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
At IETF 87 RADEXT has 90 minutes allocat= ed (Monday 11/4 1:00PM-2:30PM).
Below is the draft agenda consisting of items the chairs wou= ld believe
would= be useful to discuss.  Please respond with any suggested changes = or
comments.

-Jouni & Mauricio


————= ———————————= ;—
RA= DEXT WG IETF 88 Agenda  

Chairs:
Jou= ni Korhonen <jouni.korhonen at renesasmobile.com>
Mauricio S= anchez <mauricio.sanchez at hp.com>

Jabber ro= om: radext at jabber.ietf.org (Please join)
Monday, Nov 4, 2013
1:00 - 2:30PM
Plaza A

1:00 - 1:10= PM, Preliminaries (10 minutes)
----------------------------------= --------
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda ba= sh
Document Status

Working group draft di= scussion (45 minutes)
-------------------------------------------<= /div>
1:10 - 1:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10= minutes)
http://tools.ietf.org/id/draft-ietf-radext-dtls

1:20 - 1:25PM The Network Access Identifier, Alan DeKok (5 = minutes)
http://tools.ietf.org/html/draft-ietf-radext-nai

1:25 - 1:30PM RADIUS dynamic discovery, Stefan Winter (5 mi= nutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discov= ery

1:30 - 1:40PM RADIUS Attributes for IEEE 802 Ne= tworks, Bernard Aboba (10 minutes)
http://tools.ietf.org/html/draf= t-ietf-radext-ieee802ext

1:40 - 1:55PM Support of f= ragmentation of RADIUS packets, Diego Lopez (15 minutes)
http://to= ols.ietf.org/html/draft-perez-radext-radius-fragmentation

Chartered individual draft discussion (15 minutes)
--------= ------------------------------------------
1:55 - 2:10PM Larger Pa= ckets for Remote RADIUS over TCP, Sam  Hartman (15 minutes)
h= ttp://tools.ietf.org/html/draft-hartman-radext-bigger-packets

=
Wrap-up (10 minutes)
--------------------
2:1= 0 -  2:20 PM Next Steps: WG Chairs & ADs (5 minutes) 
WG Goals/Milestones status, next steps 

--B_3465874747_11263064-- --B_3465874748_11305528 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 DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgps/teUNGI+B03R2QWk0nrd+5 uY227yIe8tFoIa/A9UAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMxMDI5MTM1OTA3WjANBgkqhkiG9w0BAQEFAASCAQB6sQwXrx86qJ3HsC5CuKAEROr/ oCtScvqa7KdlalDN7YBzKQTe0/N1aJ4stlrrh9k7TQRpEJgYW0KvG1vjT9z3EKoGEoSL/tWT fHZB54Od1IuBhT+9gyimbehg662mGOorPwnYXg0wZAdZF0HPJzLWrhTnxQjVAHI/BGytwMje f6YvJ4JruPGllc/8rSPHMBzMY0qp4pzmq5GELPDMjrhT9330T+B21NhcYENizeBYUK4kIZtF FnBZkIw2z6g4l906CMKPSZQQKuacsq1Ahk5/GoLYdjx6XMF5YOo6pcP0WG0d546svLnyhWuN YosmXciAFIAYMUL7Sfm1noQpI1SZ --B_3465874748_11305528-- From alex@um.es Tue Oct 29 08:00: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 1F42C11E8283 for ; Tue, 29 Oct 2013 08:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, 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 Le7wMm4b1bUF for ; Tue, 29 Oct 2013 08:00:18 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id AC4E011E82CA for ; Tue, 29 Oct 2013 08:00:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id F00265D5D4 for ; Tue, 29 Oct 2013 16:00:13 +0100 (CET) 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 SzmE475WiBXq for ; Tue, 29 Oct 2013 16:00:09 +0100 (CET) Received: from [192.168.103.210] (124.Red-88-26-248.staticIP.rima-tde.net [88.26.248.124]) (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 28DB85D553 for ; Tue, 29 Oct 2013 16:00:08 +0100 (CET) Message-ID: <526FCD77.10207@um.es> Date: Tue, 29 Oct 2013 16:00:07 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010908040300000405020707" Subject: Re: [radext] IETF 88: Preliminary Agenda 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, 29 Oct 2013 15:00:24 -0000 This is a multi-part message in MIME format. --------------010908040300000405020707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hello Mauricio, just a minor comment. The link to the RADIUS fragmentation draft is outdated. Since it become a WG document, its new URL is: http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation Best regards, Alejandro El 29/10/13 14:59, Sanchez, Mauricio escribió: > At IETF 87 RADEXT has 90 minutes allocated (Monday 11/4 1:00PM-2:30PM). > Below is the draft agenda consisting of items the chairs would believe > would be useful to discuss. Please respond with any suggested changes or > comments. > > -Jouni & Mauricio > > > ------------------------------------------------ > RADEXT WG IETF 88 Agenda > > Chairs: > Jouni Korhonen > Mauricio Sanchez > > Jabber room: radext at jabber.ietf.org (Please join) > Monday, Nov 4, 2013 > 1:00 - 2:30PM > Plaza A > > 1:00 - 1:10 PM, Preliminaries (10 minutes) > ------------------------------------------ > Audio/Video & Remote Presentation Debugging > Note Well > Note Takers > Jabber scribe > Agenda bash > Document Status > > Working group draft discussion (45 minutes) > ------------------------------------------- > 1:10 - 1:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 > minutes) > http://tools.ietf.org/id/draft-ietf-radext-dtls > > 1:20 - 1:25PM The Network Access Identifier, Alan DeKok (5 minutes) > http://tools.ietf.org/html/draft-ietf-radext-nai > > 1:25 - 1:30PM RADIUS dynamic discovery, Stefan Winter (5 minutes) > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery > > 1:30 - 1:40PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba > (10 minutes) > http://tools.ietf.org/html/draft-ietf-radext-ieee802ext > > 1:40 - 1:55PM Support of fragmentation of RADIUS packets, Diego Lopez > (15 minutes) > http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation > > Chartered individual draft discussion (15 minutes) > -------------------------------------------------- > 1:55 - 2:10PM Larger Packets for Remote RADIUS over TCP, Sam Hartman > (15 minutes) > http://tools.ietf.org/html/draft-hartman-radext-bigger-packets > > Wrap-up (10 minutes) > -------------------- > 2:10 - 2:20 PM Next Steps: WG Chairs & ADs (5 minutes) > WG Goals/Milestones status, next steps > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------010908040300000405020707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Mauricio,

just a minor comment. The link to the RADIUS fragmentation draft is outdated. Since it become a WG document, its new URL is:
http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation

Best regards,
Alejandro

El 29/10/13 14:59, Sanchez, Mauricio escribió:
At IETF 87 RADEXT has 90 minutes allocated (Monday 11/4 1:00PM-2:30PM).
Below is the draft agenda consisting of items the chairs would believe
would be useful to discuss.  Please respond with any suggested changes or
comments.

-Jouni & Mauricio


————————————————
RADEXT WG IETF 88 Agenda  

Chairs:
Jouni Korhonen <jouni.korhonen at renesasmobile.com>
Mauricio Sanchez <mauricio.sanchez at hp.com>

Jabber room: radext at jabber.ietf.org (Please join)
Monday, Nov 4, 2013
1:00 - 2:30PM
Plaza A

1:00 - 1:10 PM, Preliminaries (10 minutes)
------------------------------------------
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

Working group draft discussion (45 minutes)
-------------------------------------------
1:10 - 1:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 minutes)

1:20 - 1:25PM The Network Access Identifier, Alan DeKok (5 minutes)

1:25 - 1:30PM RADIUS dynamic discovery, Stefan Winter (5 minutes)

1:30 - 1:40PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes)

1:40 - 1:55PM Support of fragmentation of RADIUS packets, Diego Lopez (15 minutes)

Chartered individual draft discussion (15 minutes)
--------------------------------------------------
1:55 - 2:10PM Larger Packets for Remote RADIUS over TCP, Sam  Hartman (15 minutes)

Wrap-up (10 minutes)
--------------------
2:10 -  2:20 PM Next Steps: WG Chairs & ADs (5 minutes) 
WG Goals/Milestones status, next steps 



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

--------------010908040300000405020707-- From jouni.nospam@gmail.com Thu Oct 31 01:59:14 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 CBD6721F9D05 for ; Thu, 31 Oct 2013 01:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 3323UDm3rSkg for ; Thu, 31 Oct 2013 01:59:14 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F12CC21F9F2B for ; Thu, 31 Oct 2013 01:59:10 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so2117673lbj.17 for ; Thu, 31 Oct 2013 01:59:10 -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=vmHvr2sb0FVv8spRZBFS03yAjYW5/HcybtyDuY/mUsM=; b=UwzePyFXo3nLw6byo2KGF2yWAlH0uXVddnmfnKGM8ekRGvas9ZLHqD+f399nkoVSx1 aXyMaibluBKaJdzz/z9lKdtP/g0DyT4Sv6za8E1VwcsOC9xsaXlAy8BHJzaUBBWeUpdH RbWbQOMXmpFmSqArOjeelGHrpo+hFsUDKh+Ulo3FujRvSYe0dR4ZW41ohoHR3thqc9z0 g705XkgxBRxe+0RBGNhfyJrfLet+z7lSCcT1b2x9x4SgnJxfjJ+lCOT/Kp2YzRbdSbNz rF7JhNyhrI5vnN6fov0V/pliywiig+0kwcVWvniymTJAGOpwdZ4f4Sa2+f8BXN8swJAO E6mw== X-Received: by 10.112.200.100 with SMTP id jr4mr1630982lbc.36.1383209949948; Thu, 31 Oct 2013 01:59:09 -0700 (PDT) Received: from [192.168.250.208] ([194.100.71.98]) by mx.google.com with ESMTPSA id vk8sm1992627lbb.0.2013.10.31.01.59.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 01:59:09 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 31 Oct 2013 10:59:07 +0200 Message-Id: <9DB80303-8DC2-475F-BC3C-1916039C4938@gmail.com> To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: Sam Hartman , "radext-chairs@tools.ietf.org" , Bernard Aboba , Stefan Winter , Alan DeKok , "Diego R. Lopez" Subject: [radext] Meeting presentation materials 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, 31 Oct 2013 08:59:14 -0000 Folks, Since RADEXT meeting is already on Monday (instead of the traditional last Friday slot), send your presentation materials to the chairs latest by Sunday and before the welcome reception. Jouni & Mauricio