From nobody Wed Jul 2 10:32:56 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A221B2918; Wed, 2 Jul 2014 10:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPFr-ioiRWTm; Wed, 2 Jul 2014 10:32:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9594E1B29B5; Wed, 2 Jul 2014 10:32:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702173249.16770.42550.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 10:32:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/3RLtIbiiK84GxVwqGbVguIxCkaU Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-bigger-packets-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:32:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Larger Packets for RADIUS over TCP Author : Sam Hartman Filename : draft-ietf-radext-bigger-packets-01.txt Pages : 8 Date : 2014-07-02 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. This document registers a new RADIUS code, an action which requires IESG approval. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-bigger-packets-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-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 nobody Wed Jul 2 10:34:17 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE191B2833 for ; Wed, 2 Jul 2014 10:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM2tq2e8EIVU for ; Wed, 2 Jul 2014 10:34:11 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945E91B29D1 for ; Wed, 2 Jul 2014 10:34:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8075620740 for ; Wed, 2 Jul 2014 13:30:32 -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 2tGThfqxHry3 for ; Wed, 2 Jul 2014 13:30:31 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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 ; Wed, 2 Jul 2014 13:30:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4073081B69; Wed, 2 Jul 2014 13:34:09 -0400 (EDT) From: Sam Hartman To: radext@ietf.org References: <20140702173249.16770.42550.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 13:34:09 -0400 In-Reply-To: <20140702173249.16770.42550.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed, 02 Jul 2014 10:32:49 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/radext/HTIKreUkqKBNsezfjG5PGGo3jjg Subject: Re: [radext] I-D Action: draft-ietf-radext-bigger-packets-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:34:15 -0000 I've posted a new version of the bigger packets draft. This includes the IANA actions, and I believe there are no open issues with the draft. --Sam From nobody Thu Jul 3 15:21:04 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178161B289F for ; Thu, 3 Jul 2014 15:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc-UdPvzX58K for ; Thu, 3 Jul 2014 15:20:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3BC1A032E for ; Thu, 3 Jul 2014 15:20:58 -0700 (PDT) Received: from localhost ([::1]:56797 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X2pMy-0001px-47; Thu, 03 Jul 2014 15:20:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, aland@deployingradius.com X-Trac-Project: radext Date: Thu, 03 Jul 2014 22:20:43 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/180#comment:2 Message-ID: <080.25e23b47cc48edd61eef609a5f57decb@trac.tools.ietf.org> References: <065.fe6830fb6d900ff63bd95d61218553db@trac.tools.ietf.org> X-Trac-Ticket-ID: 180 In-Reply-To: <065.fe6830fb6d900ff63bd95d61218553db@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es, rafa@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/ftdAFdYaa5Yz4vz6RU7h0gsUPlw Cc: radext@ietf.org Subject: Re: [radext] #180 (radius-fragmentation): draft-ietf-radext-radius-fragmentation-06: mop-up of small comments X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:21:01 -0000 #180: draft-ietf-radext-radius-fragmentation-06: mop-up of small comments Comment (by aland@deployingradius.com): > the section deals with CoA and co-location with a RADIUS server. It was impossible for me to follow the prose text - an ASCII-art flow picture is badly needed here! I've written some clarifying text and added some diagrams. We should also note that using proxies with CoA is currently *impossible* in RADIUS. There is no specification for how to proxy CoA packets across multiple hops. It would seem that this document depends on the document which fixes CoA proxying. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Jul 3 15:28:17 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6291A0AC6; Thu, 3 Jul 2014 15:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCTw2G_nxSTr; Thu, 3 Jul 2014 15:28:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAE11A03EB; Thu, 3 Jul 2014 15:28:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703222810.23453.63939.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 15:28:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/r477cdD_rnv8l0q6oX_JkPuNBIg Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-13.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:28:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : DTLS as a Transport Layer for RADIUS Author : Alan DeKok Filename : draft-ietf-radext-dtls-13.txt Pages : 27 Date : 2014-07-03 Abstract: The RADIUS protocol defined in RFC 2865 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 04:17:37 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70971B2D22; Fri, 4 Jul 2014 04:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu5EVd9l5mvf; Fri, 4 Jul 2014 04:17:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FFF1B2D07; Fri, 4 Jul 2014 04:17:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704111733.14015.5770.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 04:17:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/POpYtJ-rksgwqjBtWp3i_fJP-ho Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-07.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:17:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Support of fragmentation of RADIUS packets Authors : Alejandro Perez-Mendez Rafa Marin-Lopez Fernando Pereniguez-Garcia Gabriel Lopez-Millan Diego R. Lopez Alan DeKok Filename : draft-ietf-radext-radius-fragmentation-07.txt Pages : 33 Date : 2014-07-04 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-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 nobody Fri Jul 4 04:19:49 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2322A1B2D2D for ; Fri, 4 Jul 2014 04:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvzZho2JoNK7 for ; Fri, 4 Jul 2014 04:19:47 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 00D561B2837 for ; Fri, 4 Jul 2014 04:19:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 482CB1188 for ; Fri, 4 Jul 2014 13:19:44 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zEdGLD0WgSwJ for ; Fri, 4 Jul 2014 13:19:44 +0200 (CEST) Received: from [192.168.1.16] (82.159.60.135.dyn.user.ono.com [82.159.60.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 1DEC4F38 for ; Fri, 4 Jul 2014 13:19:43 +0200 (CEST) Message-ID: <53B68DCE.7030305@um.es> Date: Fri, 04 Jul 2014 13:19:42 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: radext@ietf.org References: <20140704111733.14015.5770.idtracker@ietfa.amsl.com> In-Reply-To: <20140704111733.14015.5770.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/s0k30La_3dWLnUuQb05N7rzRcbg Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-07.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:19:48 -0000 We've posted a new version of the fragmentation draft, addressing the open issues raised in the trac. Regards, Alejandro El 04/07/14 13:17, internet-drafts@ietf.org escribió: > 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 : Support of fragmentation of RADIUS packets > Authors : Alejandro Perez-Mendez > Rafa Marin-Lopez > Fernando Pereniguez-Garcia > Gabriel Lopez-Millan > Diego R. Lopez > Alan DeKok > Filename : draft-ietf-radext-radius-fragmentation-07.txt > Pages : 33 > Date : 2014-07-04 > > 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-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-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 nobody Mon Jul 7 06:06:10 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3649B1A001B; Mon, 7 Jul 2014 06:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yock5QC0DB0; Mon, 7 Jul 2014 06:06:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A44B1A0409; Mon, 7 Jul 2014 06:06:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140707130604.25709.51995.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 06:06:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/jJI4qH6vLAuHmOoFSm0Cp2DgXmY Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Document Action: 'DTLS as a Transport Layer for RADIUS' to Experimental RFC (draft-ietf-radext-dtls-13.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:06:08 -0000 The IESG has approved the following document: - 'DTLS as a Transport Layer for RADIUS' (draft-ietf-radext-dtls-13.txt) as Experimental RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-dtls/ Technical Summary This document specifies how the DTLS protocol may be used as a fix for security issues RADIUS has, namely authentication and encryption of RADIUS packets. The document also describes how implementations of the solution proposal can co-exist with current RADIUS systems. Working Group Summary The solution is a result of a long process in the WG. One of the last sticking issue was multiplexing of DTLS and RADIUS over port 1812. WG decided against multiplexing and the DTLS can only be used on existing RADSEC port. The WG has reached a consensus on the entire documented protocol. Document Quality There are two known implementations and one planned (if not done already). Personnel Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise (bclaise@cisco.com) is the responsible AD. From nobody Mon Jul 7 19:21:50 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001781B29EC for ; Mon, 7 Jul 2014 19:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tPGK12A-wjd for ; Mon, 7 Jul 2014 19:21:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A1A1B29E9 for ; Mon, 7 Jul 2014 19:21:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGW85745; Tue, 08 Jul 2014 02:21:45 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 03:21:45 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 10:21:42 +0800 From: Xueli To: "radext@ietf.org" Thread-Topic: Gathering opinions on draft-xue-radext-key-management Thread-Index: Ac+aU1q4YvahpQSJTAKpJucCQYvthQ== Date: Tue, 8 Jul 2014 02:21:42 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/radext/CEIbcy1F2ew8AkUMJyavZs-PRaU Cc: Stefan Winter , Jouni Korhonen Subject: [radext] Gathering opinions on draft-xue-radext-key-management X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 02:21:49 -0000 Hello all As you know, we presented the draft-xue-radext-key-management (new version = http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt ) Which defines the Radius extensions for key delivery between BNG and AC in= some specific scenario. In practice, operators prefer to deploy BNG as Authenticator while AC is as= much as simple for AP management. In this scenario, an standard approach is required to help the WTP to obtai= n the PMK, especially, when AC and BNG are deployed by different vendors..= =20 This work tries to discuss the issues related with this topic and proposes = a RADIUS extension to address the problem. As before we discussed in the meeting, the scenario is already clear and re= asonable.=20 Now the argument is that whether this item is the genuine Radius/RADEXT pro= blem?=20 Radius packet is proposed to resolve this issue because of following reason= s: 1 transmit session authorization attributes (Key, which is produced during authentication and delivered by Radius from = Server to NAS) 2 unsolicited messages=20 3 It is not the issue of Radius, it may be the issue of EAP over Radius.. At this stage, the authors appreciate your opinions very much for the next = step of this draft. Can it be solved in RADEXT? If not, which WG could be the place? Thanks in advance Li On co-authors' behalf=20 From nobody Mon Jul 7 19:32:00 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA211B2A01 for ; Mon, 7 Jul 2014 19:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aewx4qHZrQDz for ; Mon, 7 Jul 2014 19:31:57 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAD0F1B29FB for ; Mon, 7 Jul 2014 19:31:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C8C122240499; Tue, 8 Jul 2014 04:31:55 +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 awJJ7ZibIwuM; Tue, 8 Jul 2014 04:31:51 +0200 (CEST) Received: from Thor.local (unknown [184.151.111.42]) by power.freeradius.org (Postfix) with ESMTPSA id 1B82B224006C; Tue, 8 Jul 2014 04:31:50 +0200 (CEST) Message-ID: <53BB5816.90704@deployingradius.com> Date: Mon, 07 Jul 2014 22:31:50 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Xueli References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> In-Reply-To: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/l_XXC2cpdO-biWv86jSK_qSMiaY Cc: "radext@ietf.org" Subject: Re: [radext] Gathering opinions on draft-xue-radext-key-management X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 02:32:00 -0000 Xueli wrote: > As you know, we presented the draft-xue-radext-key-management (new version http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt ) > Which defines the Radius extensions for key delivery between BNG and AC in some specific scenario. I think the general consensus was that this was outside of the scope of RADIUS. > Now the argument is that whether this item is the genuine Radius/RADEXT problem? RADIUS is usually about end-users. Authenticating them, authorizing them, and performing accounting for them. If you want a general purpose "remote API" protocol, see Diameter. > Radius packet is proposed to resolve this issue because of following reasons: > 1 transmit session authorization attributes > (Key, which is produced during authentication and delivered by Radius from Server to NAS) If the key is transmitted between a RADIUS client and server, then the transmission can be done as part of a normal RADIUS conversation. If the key is transmitted somewhere else, then that's a *huge* security problem. And it doesn't fit the standard RADIUS model. > 2 unsolicited messages > 3 It is not the issue of Radius, it may be the issue of EAP over Radius.. > > At this stage, the authors appreciate your opinions very much for the next step of this draft. > Can it be solved in RADEXT? If not, which WG could be the place? I think this proposal would have a hard time finding traction anywhere in the IETF. The security problems with sharing keys are very serious. Alan DeKok. From nobody Mon Jul 7 21:15:36 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1771B2A29 for ; Mon, 7 Jul 2014 21:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj7zg5hqbgVE for ; Mon, 7 Jul 2014 21:15:34 -0700 (PDT) Received: from BLU004-OMC1S21.hotmail.com (blu004-omc1s21.hotmail.com [65.55.116.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBE61B2A25 for ; Mon, 7 Jul 2014 21:15:33 -0700 (PDT) Received: from BLU406-EAS386 ([65.55.116.9]) by BLU004-OMC1S21.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Mon, 7 Jul 2014 21:15:32 -0700 X-TMN: [eh1KTHNneXXECeeg7t3Mi0rSBIxBS/mj] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> <53BB5816.90704@deployingradius.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <53BB5816.90704@deployingradius.com> Date: Mon, 7 Jul 2014 21:15:28 -0700 To: Alan DeKok X-OriginalArrivalTime: 08 Jul 2014 04:15:32.0787 (UTC) FILETIME=[42A96030:01CF9A63] Archived-At: http://mailarchive.ietf.org/arch/msg/radext/TaBMLqTfWXxtb5J0xycWg1bk_yY Cc: "radext@ietf.org" , Xueli Subject: Re: [radext] Gathering opinions on draft-xue-radext-key-management X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 04:15:35 -0000 RFC 5247 provides the Key Management model for EAP. It is standards track - a= nd updates are outside the Charter of RADEXT WG. > On Jul 7, 2014, at 7:32 PM, "Alan DeKok" wrote= : >=20 > Xueli wrote: >> As you know, we presented the draft-xue-radext-key-management (new versio= n http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt ) >> Which defines the Radius extensions for key delivery between BNG and AC i= n some specific scenario. >=20 > I think the general consensus was that this was outside of the scope > of RADIUS. >=20 >> Now the argument is that whether this item is the genuine Radius/RADEXT p= roblem? >=20 > RADIUS is usually about end-users. Authenticating them, authorizing > them, and performing accounting for them. If you want a general purpose > "remote API" protocol, see Diameter. >=20 >> Radius packet is proposed to resolve this issue because of following reas= ons: >> 1 transmit session authorization attributes >> (Key, which is produced during authentication and delivered by Radius fro= m Server to NAS) >=20 > If the key is transmitted between a RADIUS client and server, then the > transmission can be done as part of a normal RADIUS conversation. If > the key is transmitted somewhere else, then that's a *huge* security > problem. And it doesn't fit the standard RADIUS model. >=20 >> 2 unsolicited messages=20 >> 3 It is not the issue of Radius, it may be the issue of EAP over Radius..= >>=20 >> At this stage, the authors appreciate your opinions very much for the nex= t step of this draft. >> Can it be solved in RADEXT? If not, which WG could be the place? >=20 > I think this proposal would have a hard time finding traction anywhere > in the IETF. The security problems with sharing keys are very serious. >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Jul 8 05:02:28 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8011B2810 for ; Tue, 8 Jul 2014 05:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxeS8am0xR9E for ; Tue, 8 Jul 2014 05:02:20 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EC81B2ABA for ; Tue, 8 Jul 2014 05:02:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9EA0E20744; Tue, 8 Jul 2014 07:58:11 -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 5-FQCYBZrGGc; Tue, 8 Jul 2014 07:58:11 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 8 Jul 2014 07:58:11 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3349581BA5; Tue, 8 Jul 2014 08:01:59 -0400 (EDT) From: Sam Hartman To: Xueli References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> Date: Tue, 08 Jul 2014 08:01:59 -0400 In-Reply-To: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> (xueli@huawei.com's message of "Tue, 8 Jul 2014 02:21:42 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/radext/YbMrPbeSIHEJYXDXZTK4T5oApvI Cc: "radext@ietf.org" , Jouni Korhonen , Stefan Winter Subject: Re: [radext] Gathering opinions on draft-xue-radext-key-management X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:02:24 -0000 >>>>> "Xueli" == Xueli writes: Xueli> Hello all As you know, we presented the Xueli> draft-xue-radext-key-management (new version Xueli> http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt Xueli> ) Which defines the Radius extensions for key delivery Xueli> between BNG and AC in some specific scenario. Xueli> In practice, operators prefer to deploy BNG as Authenticator Xueli> while AC is as much as simple for AP management. As before Xueli> we discussed in the meeting, Xueli> the scenario is already clear and reasonable. With respect, when I consider this scenario I find myself confused and I'm hoping that if you decide to continue this work you will spend significantly more effort clarifying the scenario and working with the community to evaluate whether it is reasonable. As I understand it, operators would like to deploy with a model different than that described by RFC 5247. We spent a long time developing RFC 5247, working within the IETF to make sure our protocols support it, and working within the IEEE to make sure that their re-authentication and other protocols work within this model. When we hear that work is wrong, we feel skeptical Also, when I read this document I am concerned, because the security model is different than that proposed by RFC 5247. I do not wish to see the security of wireless access decreased, and I'd like to understand whether this proposed solution does that. I would request that you: * Approach this as an architectural issue at the RFC 5247 level rather than a RADIUS issue * Focus on clearly describing the scenario and having a discussion with the IETF community about whether this scenario is reasonable. * Discuss with the IETF community about whether a solution to this scenario is desirable. This is a much bigger change than one RADIUS attribute. Thanks for your consideration, Sam Hartman Painless Security, LLC From nobody Tue Jul 8 19:06:29 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F22B1A028E for ; Tue, 8 Jul 2014 19:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZugeeGMnzih for ; Tue, 8 Jul 2014 19:06:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DE01A0295 for ; Tue, 8 Jul 2014 19:06:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGX83718; Wed, 09 Jul 2014 02:06:20 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 03:06:19 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 10:06:15 +0800 From: Xueli To: Alan DeKok Thread-Topic: [radext] Gathering opinions on draft-xue-radext-key-management Thread-Index: Ac+aU1q4YvahpQSJTAKpJucCQYvthf//fLkA//3wBSA= Date: Wed, 9 Jul 2014 02:06:14 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448FD32FF@nkgeml504-mbx.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> <53BB5816.90704@deployingradius.com> In-Reply-To: <53BB5816.90704@deployingradius.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448FD32FFnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/radext/cIAbXug2IHrLv6aIapi1v0uj1qg Cc: "radext@ietf.org" Subject: Re: [radext] Gathering opinions on draft-xue-radext-key-management X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 02:06:27 -0000 --_000_01FE63842C181246BBE4CF183BD159B448FD32FFnkgeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Alan Thanks for your comments. >> 3 It is not the issue of Radius, it may be the issue of EAP over Radius.= . >> >> At this stage, the authors appreciate your opinions very much for the >next step of this draft. >> Can it be solved in RADEXT? If not, which WG could be the place? > > I think this proposal would have a hard time finding traction anywhere >in the IETF. The security problems with sharing keys are very serious. > Understand.. This scenario is the existing gap right now in WLAN network, also mentioned= in other SDO. We will think carefully this security issue. Regards Li >-----Original Message----- >From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok >Sent: Tuesday, July 08, 2014 10:32 AM >To: Xueli >Cc: radext@ietf.org >Subject: Re: [radext] Gathering opinions on >draft-xue-radext-key-management > >Xueli wrote: >> As you know, we presented the draft-xue-radext-key-management (new >version http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt ) >> Which defines the Radius extensions for key delivery between BNG and >AC in some specific scenario. > > I think the general consensus was that this was outside of the scope >of RADIUS. > >> Now the argument is that whether this item is the genuine >Radius/RADEXT problem? > > RADIUS is usually about end-users. Authenticating them, authorizing >them, and performing accounting for them. If you want a general purpose >"remote API" protocol, see Diameter. > >> Radius packet is proposed to resolve this issue because of following >reasons: >> 1 transmit session authorization attributes >> (Key, which is produced during authentication and delivered by Radius >from Server to NAS) > > If the key is transmitted between a RADIUS client and server, then the >transmission can be done as part of a normal RADIUS conversation. If >the key is transmitted somewhere else, then that's a *huge* security >problem. And it doesn't fit the standard RADIUS model. > >> 2 unsolicited messages >> 3 It is not the issue of Radius, it may be the issue of EAP over Radius.= . >> >> At this stage, the authors appreciate your opinions very much for the >next step of this draft. >> Can it be solved in RADEXT? If not, which WG could be the place? > > I think this proposal would have a hard time finding traction anywhere >in the IETF. The security problems with sharing keys are very serious. > > Alan DeKok. > >_______________________________________________ >radext mailing list >radext@ietf.org >https://www.ietf.org/mailman/listinfo/radext --_000_01FE63842C181246BBE4CF183BD159B448FD32FFnkgeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hell= o Alan

 

Than= ks for your comments.

>> 3 It is not the iss= ue of Radius, it may be the issue of EAP over Radius..

>> 

>> At this stage, the = authors appreciate your opinions very much for the

>next step of this draft.=

>> Can it be solved in= RADEXT? If not, which WG could be the place?

> =

>  I think this prop= osal would have a hard time finding traction anywhere

>in the IETF.  The s= ecurity problems with sharing keys are very serious.

> =

 

Unde= rstand..

This= scenario is the existing gap right now in WLAN network, also mentioned in = other SDO.

We w= ill think carefully this security issue.

 

Rega= rds

Li

 

>-----Original Message---= --

>From: radext [mailto:rad= ext-bounces@ietf.org] On Behalf Of Alan DeKok

>Sent: Tuesday, July 08, = 2014 10:32 AM

>To: Xueli

>Cc: radext@ietf.org=

>Subject: Re: [radext] Ga= thering opinions on

>draft-xue-radext-key-man= agement

> =

>Xueli wrote:<= /span>

>> As you know, we pre= sented the draft-xue-radext-key-management (new

>version http://tools.iet= f.org/id/draft-xue-radext-key-management-03.txt  )

>>  Which defines= the Radius extensions for key delivery between BNG and

>AC in some specific scen= ario.

> =

>  I think the gener= al consensus was that this was outside of the scope

>of RADIUS.

> =

>> Now the argument is= that whether this item is the genuine

>Radius/RADEXT problem?

> =

>  RADIUS is usually= about end-users.  Authenticating them, authorizing<= /p>

>them, and performing acc= ounting for them.  If you want a general purpose

>"remote API" p= rotocol, see Diameter.

> =

>> Radius packet is pr= oposed to resolve this issue because of following

>reasons:

>> 1 transmit session = authorization attributes

>> (Key, which is prod= uced during authentication and delivered by Radius

>from Server to NAS)=

> =

>  If the key is tra= nsmitted between a RADIUS client and server, then the

>transmission can be done= as part of a normal RADIUS conversation.  If

>the key is transmitted s= omewhere else, then that's a *huge* security

>problem.  And it do= esn't fit the standard RADIUS model.

> =

>> 2 unsolicited messa= ges

>> 3 It is not the iss= ue of Radius, it may be the issue of EAP over Radius..

>> 

>> At this stage, the = authors appreciate your opinions very much for the

>next step of this draft.=

>> Can it be solved in= RADEXT? If not, which WG could be the place?

> =

>  I think this prop= osal would have a hard time finding traction anywhere

>in the IETF.  The s= ecurity problems with sharing keys are very serious.

> =

>  Alan DeKok.<= /o:p>

> =

>________________________= _______________________

>radext mailing list=

>radext@ietf.org

>https://www.ietf.org/mai= lman/listinfo/radext

--_000_01FE63842C181246BBE4CF183BD159B448FD32FFnkgeml504mbxchi_-- From nobody Tue Jul 8 19:08:00 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793B61A028B for ; Tue, 8 Jul 2014 19:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhn2AGaJZEqu for ; Tue, 8 Jul 2014 19:07:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F791A0277 for ; Tue, 8 Jul 2014 19:07:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGX83773; Wed, 09 Jul 2014 02:07:52 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 03:07:51 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 10:07:48 +0800 From: Xueli To: Bernard Aboba , Alan DeKok Thread-Topic: [radext] Gathering opinions on draft-xue-radext-key-management Thread-Index: Ac+aU1q4YvahpQSJTAKpJucCQYvthf//fLkAgAAc9AD//gujIA== Date: Wed, 9 Jul 2014 02:07:48 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448FD330B@nkgeml504-mbx.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> <53BB5816.90704@deployingradius.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448FD330Bnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/radext/yE1aldxFrRh59T5ujY_l7qCy3zE Cc: "radext@ietf.org" Subject: Re: [radext] Gathering opinions on draft-xue-radext-key-management X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 02:07:56 -0000 --_000_01FE63842C181246BBE4CF183BD159B448FD330Bnkgeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks >-----Original Message----- >From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >Sent: Tuesday, July 08, 2014 12:15 PM >To: Alan DeKok >Cc: Xueli; radext@ietf.org >Subject: Re: [radext] Gathering opinions on >draft-xue-radext-key-management > >RFC 5247 provides the Key Management model for EAP. It is standards track >- and updates are outside the Charter of RADEXT WG. > >> On Jul 7, 2014, at 7:32 PM, "Alan DeKok" >wrote: >> >> Xueli wrote: >>> As you know, we presented the draft-xue-radext-key-management (new >version http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt ) >>> Which defines the Radius extensions for key delivery between BNG and >AC in some specific scenario. >> >> I think the general consensus was that this was outside of the scope >> of RADIUS. >> >>> Now the argument is that whether this item is the genuine >Radius/RADEXT problem? >> >> RADIUS is usually about end-users. Authenticating them, authorizing >> them, and performing accounting for them. If you want a general >purpose >> "remote API" protocol, see Diameter. >> >>> Radius packet is proposed to resolve this issue because of following >reasons: >>> 1 transmit session authorization attributes >>> (Key, which is produced during authentication and delivered by Radius >from Server to NAS) >> >> If the key is transmitted between a RADIUS client and server, then the >> transmission can be done as part of a normal RADIUS conversation. If >> the key is transmitted somewhere else, then that's a *huge* security >> problem. And it doesn't fit the standard RADIUS model. >> >>> 2 unsolicited messages >>> 3 It is not the issue of Radius, it may be the issue of EAP over Radius= .. >>> >>> At this stage, the authors appreciate your opinions very much for the >next step of this draft. >>> Can it be solved in RADEXT? If not, which WG could be the place? >> >> I think this proposal would have a hard time finding traction anywhere >> in the IETF. The security problems with sharing keys are very serious. >> >> Alan DeKok. >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext --_000_01FE63842C181246BBE4CF183BD159B448FD330Bnkgeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Than= ks

 

>-----Original Message---= --

>From: Bernard Aboba [mai= lto:bernard_aboba@hotmail.com]

>Sent: Tuesday, July 08, = 2014 12:15 PM

>To: Alan DeKok

>Cc: Xueli; radext@ietf.o= rg

>Subject: Re: [radext] Ga= thering opinions on

>draft-xue-radext-key-man= agement

> =

>RFC 5247 provides the Ke= y Management model for EAP. It is standards track

>- and updates are outsid= e the Charter of RADEXT WG.

> =

>> On Jul 7, 2014, at = 7:32 PM, "Alan DeKok" <aland@deployingradius.com>

>wrote:=

>> 

>> Xueli wrote:

>>> As you know, we= presented the draft-xue-radext-key-management (new

>version http://tools.iet= f.org/id/draft-xue-radext-key-management-03.txt  )

>>> Which defines t= he Radius extensions for key delivery between BNG and

>AC in some specific scen= ario.

>> 

>>  I think the g= eneral consensus was that this was outside of the scope

>> of RADIUS.

>> 

>>> Now the argumen= t is that whether this item is the genuine

>Radius/RADEXT problem?

>> 

>>  RADIUS is usu= ally about end-users.  Authenticating them, authorizing

>> them, and performin= g accounting for them.  If you want a general

>purpose

>> "remote API&qu= ot; protocol, see Diameter.

>> 

>>> Radius packet i= s proposed to resolve this issue because of following

>reasons:

>>> 1 transmit sess= ion authorization attributes

>>> (Key, which is = produced during authentication and delivered by Radius

>from Server to NAS)=

>> 

>>  If the key is= transmitted between a RADIUS client and server, then the=

>> transmission can be= done as part of a normal RADIUS conversation.  If

>> the key is transmit= ted somewhere else, then that's a *huge* security

>> problem.  And = it doesn't fit the standard RADIUS model.

>> 

>>> 2 unsolicited m= essages

>>> 3 It is not the= issue of Radius, it may be the issue of EAP over Radius..

>>> 

>>> At this stage, = the authors appreciate your opinions very much for the

>next step of this draft.=

>>> Can it be solve= d in RADEXT? If not, which WG could be the place?

>> 

>>  I think this = proposal would have a hard time finding traction anywhere=

>> in the IETF.  = The security problems with sharing keys are very serious.=

>> 

>>  Alan DeKok.

>> 

>> ___________________= ____________________________

>> radext mailing list=

>> radext@ietf.org

>> https://www.ietf.or= g/mailman/listinfo/radext

--_000_01FE63842C181246BBE4CF183BD159B448FD330Bnkgeml504mbxchi_-- From nobody Tue Jul 8 19:12:16 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F6D1A0202 for ; Tue, 8 Jul 2014 19:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR0dR-DrvEjf for ; Tue, 8 Jul 2014 19:12:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65C11A0294 for ; Tue, 8 Jul 2014 19:12:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT67296; Wed, 09 Jul 2014 02:12:09 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 03:12:08 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 10:12:03 +0800 From: Xueli To: Sam Hartman Thread-Topic: [radext] Gathering opinions on draft-xue-radext-key-management Thread-Index: Ac+aU1q4YvahpQSJTAKpJucCQYvthQAURi7UAB2J9sA= Date: Wed, 9 Jul 2014 02:12:02 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448FD331C@nkgeml504-mbx.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448FD331Cnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/radext/TU937xaiV-5_IgumaospOumPN0c Cc: "radext@ietf.org" , Jouni Korhonen , Stefan Winter Subject: Re: [radext] Gathering opinions on draft-xue-radext-key-management X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 02:12:14 -0000 --_000_01FE63842C181246BBE4CF183BD159B448FD331Cnkgeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam I appreciate it.. Make sense to me.. Thanks Regards Li >I would request that you: > >* Approach this as an architectural issue at the RFC 5247 level rather > than a RADIUS issue > >* Focus on clearly describing the scenario and having a discussion with > the IETF community about whether this scenario is reasonable. > >* Discuss with the IETF community about whether a solution to this > scenario is desirable. > >This is a much bigger change than one RADIUS attribute. > --_000_01FE63842C181246BBE4CF183BD159B448FD331Cnkgeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi S= am

 

I ap= preciate it.. Make sense to me..

Than= ks

Rega= rds

Li

 

>I would request that you= :

> =

>* Approach this as an ar= chitectural issue at the RFC 5247 level rather

>  than a RADIUS iss= ue

> =

>* Focus on clearly descr= ibing the scenario and having a discussion with

>  the IETF communit= y about whether this scenario is reasonable.

> =

>* Discuss with the IETF = community about whether a solution to this

>  scenario is desir= able.

> =

>This is a much bigger ch= ange than one RADIUS attribute.

> =

 

--_000_01FE63842C181246BBE4CF183BD159B448FD331Cnkgeml504mbxchi_-- From nobody Wed Jul 9 05:05:11 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CF41A04B0 for ; Wed, 9 Jul 2014 05:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8fTsqVz_RFE for ; Wed, 9 Jul 2014 05:05:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2843B1A04A1 for ; Wed, 9 Jul 2014 05:05:06 -0700 (PDT) Received: from localhost ([::1]:33398 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4qcG-000285-6v; Wed, 09 Jul 2014 05:04:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 09 Jul 2014 12:04:52 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/radext/trac/ticket/177#comment:2 Message-ID: <080.7942455d8bea7eea0179c4473e4403da@trac.tools.ietf.org> References: <065.849dac8b029f671ef52851a446d03857@trac.tools.ietf.org> X-Trac-Ticket-ID: 177 In-Reply-To: <065.849dac8b029f671ef52851a446d03857@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/2bk3Ynv1vg7k6zk-ElDoh7zzv00 Cc: radext@ietf.org Subject: Re: [radext] #177 (radius-fragmentation): text in section 11.2 up-to-date? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:05:08 -0000 #177: text in section 11.2 up-to-date? Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: Revision -07 has the corrected text, closing this issue as Resolved. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: fixed Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Jul 9 05:08:50 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35CD1A04B0 for ; Wed, 9 Jul 2014 05:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3Y1sG97qXjG for ; Wed, 9 Jul 2014 05:08:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7F51A04A1 for ; Wed, 9 Jul 2014 05:08:44 -0700 (PDT) Received: from localhost ([::1]:33607 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4qfu-0003te-OR; Wed, 09 Jul 2014 05:08:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 09 Jul 2014 12:08:38 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/radext/trac/ticket/178#comment:2 Message-ID: <080.0bbe0c63d8a49cede66e18a3be2e2fd5@trac.tools.ietf.org> References: <065.3a956fa45a00049e711dbe6a5fb8d6c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 178 In-Reply-To: <065.3a956fa45a00049e711dbe6a5fb8d6c9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/a0pWlVAq0Rhr_ceH1Quc_ZwR8Cs Cc: radext@ietf.org Subject: Re: [radext] #178 (radius-fragmentation): fragments going in both directions - allowed or not? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:08:48 -0000 #178: fragments going in both directions - allowed or not? Comment (by stefan.winter@restena.lu): This text is almost good, I only miss that the respectively "other" direction is not spelt out explicitly as forbidden. Maybe adding an "only" in the two sentences helps, as in "In this phase, *only* the (NAS|AS) can send a large packet ..." ? You can resolve this minor wordsmithing nit together with the early TSVDIR review comments (TSVDIR review has been requested and is currently ongoing). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Jul 9 05:18:08 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD871A04A1 for ; Wed, 9 Jul 2014 05:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjTVtmQOt0Bh for ; Wed, 9 Jul 2014 05:18:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6113D1A04B0 for ; Wed, 9 Jul 2014 05:18:01 -0700 (PDT) Received: from localhost ([::1]:34650 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4qot-0006th-04; Wed, 09 Jul 2014 05:17:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, stefan.winter@restena.lu, alex@um.es X-Trac-Project: radext Date: Wed, 09 Jul 2014 12:17:54 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/radext/trac/ticket/179#comment:3 Message-ID: <080.0a94d92e8b473e8b5d5cb0b6faacfcca@trac.tools.ietf.org> References: <065.e68e62499c1428e7ab8f6e73087bad4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 179 In-Reply-To: <065.e68e62499c1428e7ab8f6e73087bad4c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, stefan.winter@restena.lu, alex@um.es, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/gYO4IHnG2WKEsEYCGd8yWAB_1fU Cc: radext@ietf.org Subject: Re: [radext] #179 (radius-fragmentation): draft-ietf-radext-radius-fragmentation-06: IANA considerations X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:18:06 -0000 #179: draft-ietf-radext-radius-fragmentation-06: IANA considerations Comment (by stefan.winter@restena.lu): Looks very good, only one nit: when you write "from the Long Extended Space of [RFC2865]:" RFC2865 knows nothing of the Long Extended space. Long Extended was introduced with RFC6929. Please change that reference when updating the document following the TSVDIR review. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Jul 9 05:36:59 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC731A04D2 for ; Wed, 9 Jul 2014 05:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogwrO-Je-kou for ; Wed, 9 Jul 2014 05:36:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436061A04C5 for ; Wed, 9 Jul 2014 05:36:55 -0700 (PDT) Received: from localhost ([::1]:35325 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4r7A-0006Ux-CO; Wed, 09 Jul 2014 05:36:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, aland@deployingradius.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 09 Jul 2014 12:36:48 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/radext/trac/ticket/180#comment:3 Message-ID: <080.c22ca09f0a37f1fc628783bdf03a1bbc@trac.tools.ietf.org> References: <065.fe6830fb6d900ff63bd95d61218553db@trac.tools.ietf.org> X-Trac-Ticket-ID: 180 In-Reply-To: <065.fe6830fb6d900ff63bd95d61218553db@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, aland@deployingradius.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/TNYtu70cKo1qcwYBOfXjWa4s7i8 Cc: radext@ietf.org Subject: Re: [radext] #180 (radius-fragmentation): draft-ietf-radext-radius-fragmentation-06: mop-up of small comments X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:36:56 -0000 #180: draft-ietf-radext-radius-fragmentation-06: mop-up of small comments Comment (by stefan.winter@restena.lu): Thanks for the clarifying text and ASCII-art on CoA. I think it really helps the document. Most of the comments were fixed with -07; what remains is: * 1. Introduction, the first "bullet" paragraph. The last sentence "... entirely ..." sounds strange. Did you want to express that the approach is not useful in this context because it "... only ..." solves server-to-NAS? * second bullet: What is a SAML "Sentence"? I know SAML *messages* and *assertions* and *attributes*, but no sentences ... * The sentence in 7.1 now reads: "Should they are unable to add this information to the packet, they may silently discard forwarding it to its destination, leading to DoS situations." This still sounds a bit strange. A simple s/are/be/ would fix this. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Jul 9 05:39:25 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C81E1A0535 for ; Wed, 9 Jul 2014 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-2rNjXKjyNT for ; Wed, 9 Jul 2014 05:39:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E120D1A0546 for ; Wed, 9 Jul 2014 05:38:59 -0700 (PDT) Received: from localhost ([::1]:35368 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4r9E-0006mH-Rv; Wed, 09 Jul 2014 05:38:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 09 Jul 2014 12:38:56 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/radext/trac/ticket/181#comment:2 Message-ID: <080.5f771131dc5ebc9c76d6b6357ec22173@trac.tools.ietf.org> References: <065.9cf0de107a5a20b43d8717fb106e5469@trac.tools.ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <065.9cf0de107a5a20b43d8717fb106e5469@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Lr4KCVMWya_Qqox1t3xJh0YzYms Cc: radext@ietf.org Subject: Re: [radext] #181 (radius-fragmentation): MUST vs. configurable X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:39:14 -0000 #181: MUST vs. configurable Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: This has been fixed in -07, closing as "Resolved". -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: fixed Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Jul 9 05:43:21 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB121A0503 for ; Wed, 9 Jul 2014 05:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9SM0E5sAcre for ; Wed, 9 Jul 2014 05:43:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6471A04D2 for ; Wed, 9 Jul 2014 05:43:18 -0700 (PDT) Received: from localhost ([::1]:35466 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rDM-0007jI-Ns; Wed, 09 Jul 2014 05:43:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 09 Jul 2014 12:43:12 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/radext/trac/ticket/182#comment:2 Message-ID: <080.42c93d1f25f194120d3ebe43cebe7049@trac.tools.ietf.org> References: <065.43aead270fea325624ba7c979c6728de@trac.tools.ietf.org> X-Trac-Ticket-ID: 182 In-Reply-To: <065.43aead270fea325624ba7c979c6728de@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/8tF6TknARDWPpMy5CvRUj6te8Mw Cc: radext@ietf.org Subject: Re: [radext] #182 (radius-fragmentation): transport review questions X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:43:19 -0000 #182: transport review questions Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: The authors have added section 11.4 for transport considerations, which tackles the second bullet at least. Following discussions with the authors, we agreed that PMTUD is out of scope for this document - it is much rather a generic RADIUS question that needs to (additional) considerations here; the datagrams produced by this document are "normal-sized" RADIUS datagrams on the wire. Meanwhile, an early TSVDIR review has been requested, whose results will very likely supersede the open bullets in this ticket. I am closing the ticket now, and will open a new one with the results of the TSVDIR review by the time it's finished. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: fixed Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Jul 10 23:54:06 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005881B2836 for ; Thu, 10 Jul 2014 23:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmek3aE3smnT for ; Thu, 10 Jul 2014 23:54:01 -0700 (PDT) Received: from smptrelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5841B279C for ; Thu, 10 Jul 2014 23:54:01 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smptrelay.restena.lu (Postfix) with ESMTPS id 4843B43980 for ; Fri, 11 Jul 2014 08:54:00 +0200 (CEST) Message-ID: <53BF8A08.3020807@restena.lu> Date: Fri, 11 Jul 2014 08:54:00 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: radext@ietf.org References: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> <080.187563b7a98218620fe0f8797b2665a0@trac.tools.ietf.org> <53A16064.2000801@gmail.com> In-Reply-To: <53A16064.2000801@gmail.com> X-Enigmail-Version: 1.6 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="gHVfgmFX4QkDVqpgB2gGfjkkoKbINu8sW" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/ICGdPm_LmUL900WyiMX-XB1ijlo Subject: Re: [radext] #176 (nai): draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 06:54:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gHVfgmFX4QkDVqpgB2gGfjkkoKbINu8sW Content-Type: multipart/mixed; boundary="------------080509040609020602000508" This is a multi-part message in MIME format. --------------080509040609020602000508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I do not have technical reasoning for my position here but.. Personally= > I would not start renaming NAI. Quite a few documents refer to RFC4282 > and implicitly to this document and it would be confusing to change the= > name this late. IMHO what matters here is the functionality & technical= > corrections the I-D provides. If we need to finetune Section 1.1. > terminology, let's do it. That's fine - an update to section 1.1 could state that the name is there for historic reasons, but that the scope is positively meant to be wider than Network. There was only this one opinion on the list - so maybe it's worth asking the room how folks feel during the IETF90 meeting? I won't be there, unfortunately ... Greetings, Stefan --=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 --------------080509040609020602000508 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.22 (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----- --------------080509040609020602000508-- --gHVfgmFX4QkDVqpgB2gGfjkkoKbINu8sW 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.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTv4oIAAoJEMDeajWKOdxmdOUP/1GiS6t6uh0IsgI15O3+d89H oYUPsQ+zPrepf1xYg4aGvDxMbD/kwR2Wkf3eIFRKooXHmXkUuIw+cdp1DO0IC+SU N2yGv0GR//l10+iFGtBuD+be09z0el28zJ+82aXEeTh84dZ9o0AvhDZca2K9Sd6W PzqtrahLtosMx1akPFwOniiS6fKjxwr5Dh+/Bmfy7hoNmzgBRo3zWvenf+qxtLC5 32aUNVuqE0o6wPy34ndCkZlPWtTC6K+aoBi/PP0CZcEn7dsWrBSiV5ziRMLZzrx2 63nx5Sf7QtjshNGJnLkW1GsYKUtq4rAu1PMb+QYuspzheVIBnpoH7CDjY1/zFP5/ Af+OxuiO6i6GOUDxXut12krOJ/lbLlT+nmvgne4UqL0RqDWGlP00WqcW0awzNE8G 6pKe14aM3PsG4AAeJ4E3PrQF0NljwZgi+gtW29NermZccKhzyADCIPGMVhkCgKWp 8PL6iSqzjBpnrcWgVlHsXiiAqNLmVFJ1sybfcd7UTIzp19YqLDqrQhf9WUi989+9 1EwHr9fJmUuboJexEnXizlLXYxAf1E9f+f6+Kgix+mjh17wFZDk8I8Py8wLsWq9t aswhMn/hmSzA6kMLIfhwN5eUrwWEWQjVh+jLz+scsrCyyrBPfRSlgJXgeoZJwxDe Z3u5TNEwiq0padPKqkR+ =Qw1E -----END PGP SIGNATURE----- --gHVfgmFX4QkDVqpgB2gGfjkkoKbINu8sW-- From nobody Fri Jul 11 08:08:02 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67951B2B17 for ; Fri, 11 Jul 2014 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k5YICggDuCo for ; Fri, 11 Jul 2014 08:07:59 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C391B2B9C for ; Fri, 11 Jul 2014 08:07:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id F26B32074F; Fri, 11 Jul 2014 11:03:11 -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 1mqN7XJsvYtn; Fri, 11 Jul 2014 11:03:11 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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, 11 Jul 2014 11:03:11 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C8A4981C04; Fri, 11 Jul 2014 11:07:05 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> <080.187563b7a98218620fe0f8797b2665a0@trac.tools.ietf.org> <53A16064.2000801@gmail.com> <53BF8A08.3020807@restena.lu> Date: Fri, 11 Jul 2014 11:07:05 -0400 In-Reply-To: <53BF8A08.3020807@restena.lu> (Stefan Winter's message of "Fri, 11 Jul 2014 08:54:00 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/radext/IK_J9e9pMkE7kkSkERCj2Dma8oM Cc: radext@ietf.org Subject: Re: [radext] #176 (nai): draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 15:08:01 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> There was only this one opinion on the list - so maybe it's Stefan> worth asking the room how folks feel during the IETF90 Stefan> meeting? I won't be there, unfortunately ... I will not make the meeting. I do not support the rename. If we do want to rename, I recommend renaming it to "networked Access Identifier," emphasizing that the identifier is networked, rather than the access to a network. I think that's contrived and I've seen significant damage result from trying to rename thing. Mumble mumble NAT66 From nobody Thu Jul 17 12:26:45 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5671A01C5 for ; Thu, 17 Jul 2014 12:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nshBPd7bSOd3 for ; Thu, 17 Jul 2014 12:26:41 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39101A01C6 for ; Thu, 17 Jul 2014 12:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8461; q=dns/txt; s=iport; t=1405625197; x=1406834797; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=POk/aca08avZNdL12eaBPZsiBNdeWra5mT9fLqLABOY=; b=dfzrykPXXqJrPJn9RFgzqv+MesDO2J7k9whyfxSpPkgZsCk9RwKdY0s6 jRtAPJny7JY9VrskIybayFqjQsY2VbSmG7gxmwU9B++PJ8SmK9tV32nYy Qik0tVDlGmmLbE51ZTrTiyjbPvTJnsBB8gCpzULvbR1Rm6/NUo6srjl84 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYEAOwiyFOtJssW/2dsb2JhbABZg2BXsAuTeQEJh0MBgR12hAMBAQEEAQEBSyoNBBwDAQIKAxMPCQMCAQIBFQoVBwIIBg0GAgEBBQsHAgSIDQMRDcVLF4wcgQKBWkIYBoRABZkggX+BTIVIhnwDhhmDRjsvAYEL X-IronPort-AV: E=Sophos;i="5.01,679,1400025600"; d="scan'208,217";a="111047763" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 17 Jul 2014 19:26:35 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6HJQYKg003549 for ; Thu, 17 Jul 2014 19:26:34 GMT Message-ID: <53C8236A.2010801@cisco.com> Date: Thu, 17 Jul 2014 21:26:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20140717191710.4C23A18044F@rfc-editor.org> In-Reply-To: <20140717191710.4C23A18044F@rfc-editor.org> X-Forwarded-Message-Id: <20140717191710.4C23A18044F@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------090902010205030708010009" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/YlZoeQGkz7fMSwoXf_-26ZeddXc Subject: [radext] Fwd: RFC 7268 on RADIUS Attributes for IEEE 802 Networks X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 19:26:43 -0000 This is a multi-part message in MIME format. --------------090902010205030708010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes! Congrats to the authors, the WG chairs, and the WG. Regards, Benoit -------- Original Message -------- Subject: RFC 7268 on RADIUS Attributes for IEEE 802 Networks Date: Thu, 17 Jul 2014 12:17:10 -0700 From: Reply-To: To: , CC: , A new Request for Comments is now available in online RFC libraries. RFC 7268 Title: RADIUS Attributes for IEEE 802 Networks Author: B. Aboba, J. Malinen, P. Congdon, J. Salowey, M. Jones Status: Standards Track Stream: IETF Date: July 2014 Mailbox: Bernard_Aboba@hotmail.com, j@w1.fi, paul.congdon@tallac.com, jsalowey@cisco.com, mark@azu.ca Pages: 29 Characters: 56686 Updates: RFC 3580, RFC 4072 I-D Tag: draft-ietf-radext-ieee802ext-12.txt URL: http://www.rfc-editor.org/rfc/rfc7268.txt RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute. This document updates RFCs 3580 and 4072. This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC . --------------090902010205030708010009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes!
Congrats to the authors, the WG chairs, and the WG.

Regards, Benoit


-------- Original Message --------
Subject: RFC 7268 on RADIUS Attributes for IEEE 802 Networks
Date: Thu, 17 Jul 2014 12:17:10 -0700
From: <rfc-editor@rfc-editor.org>
Reply-To: <ietf@ietf.org>
To: <ietf-announce@ietf.org>, <rfc-dist@rfc-editor.org>
CC: <drafts-update-ref@iana.org>, <rfc-editor@rfc-editor.org> 


A new Request for Comments is now available in online RFC libraries.

        
        RFC 7268

        Title:      RADIUS Attributes for IEEE 802 
                    Networks 
        Author:     B. Aboba, J. Malinen,
                    P. Congdon, J. Salowey,
                    M. Jones
        Status:     Standards Track
        Stream:     IETF
        Date:       July 2014
        Mailbox:    Bernard_Aboba@hotmail.com, 
                    j@w1.fi, 
                    paul.congdon@tallac.com,
                    jsalowey@cisco.com, 
                    mark@azu.ca
        Pages:      29
        Characters: 56686
        Updates:    RFC 3580, RFC 4072

        I-D Tag:    draft-ietf-radext-ieee802ext-12.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7268.txt

RFC 3580 provides guidelines for the use of the Remote Authentication
Dial-In User Service (RADIUS) within IEEE 802 local area networks
(LANs).  This document defines additional attributes for use within
IEEE 802 networks and clarifies the usage of the EAP-Key-Name
Attribute and the Called-Station-Id Attribute.  This document
updates RFCs 3580 and 4072.

This document is a product of the RADIUS EXTensions Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


.


--------------090902010205030708010009-- From nobody Fri Jul 18 10:19:56 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B078A1B27CC for ; Fri, 18 Jul 2014 10:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd7Lu96d_01c for ; Fri, 18 Jul 2014 10:19:45 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C75E1B2894 for ; Fri, 18 Jul 2014 10:19:45 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so5833599pab.30 for ; Fri, 18 Jul 2014 10:19:44 -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:subject :content-type:content-transfer-encoding; bh=gALf2RQl7mYSZchyIpiPQWkh52Mz3m8JhCT3hndwYqU=; b=g4z8l//pMppdyPbLVH4FrOIFNuxezelUDEDiGC3aEwBCTQ+XGWwQ0eKPzqeGFivqMq +NqL4djd/66XdoWo8fMseDzUKpyvHRxivzlOK1A2c0l1EwKEZK8jaeWDvWzTMV/2RVxf l6RtiulpwzrxaqjtckAXKYIgZ9hKjd9rcR4j8dG5HQ7BMlfK6binig7nVYxWaQpT4Xyv 8ikF3Y/AlaCEy9ydD7G/NqXKTVVh6QzbTpFX0A5FAmfjScs4gYE0sbfR60kww/okW1Kb qc9qCqIe8jKVuENLMOYHceSNrTCyEsqQQnkZDmTBGTxSxBN4Jboj8DqQ8I0ivJF46b+Z 5CKg== X-Received: by 10.70.127.163 with SMTP id nh3mr6938520pdb.139.1405703982147; Fri, 18 Jul 2014 10:19:42 -0700 (PDT) Received: from [10.199.10.100] ([63.133.197.135]) by mx.google.com with ESMTPSA id sh5sm6155449pbc.21.2014.07.18.10.19.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 10:19:40 -0700 (PDT) Message-ID: <53C9572A.8030203@gmail.com> Date: Fri, 18 Jul 2014 20:19:38 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: radext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/A66aNCvKAeuoApHFbqq5P9vdgcM Subject: [radext] IETF90 presentation materials X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:19:48 -0000 Folks, Those who are on the agenda, send your slideware latest during Monday. - Jouni & Stefan From nobody Mon Jul 21 01:29:59 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8608F1B294E for ; Mon, 21 Jul 2014 01:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M3IxsskAvgT for ; Mon, 21 Jul 2014 01:29:55 -0700 (PDT) Received: from smptrelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587541B27B2 for ; Mon, 21 Jul 2014 01:29:55 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smptrelay.restena.lu (Postfix) with ESMTPS id 29FDA43194 for ; Mon, 21 Jul 2014 10:29:54 +0200 (CEST) Message-ID: <53CCCF82.1070004@restena.lu> Date: Mon, 21 Jul 2014 10:29:54 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "radext@ietf.org" X-Enigmail-Version: 1.6 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="Fpf5EQ3fM9ORdPwU4on8DsVWwLebpJi3D" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/1pudFpCnzb2QOXOBHzIXp4zFMVY Subject: [radext] Agenda updated X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 08:29:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Fpf5EQ3fM9ORdPwU4on8DsVWwLebpJi3D Content-Type: multipart/mixed; boundary="------------000302040504080207000404" This is a multi-part message in MIME format. --------------000302040504080207000404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I've uploaded an updated agenda to datatracker; see also below. I won't be in Toronto, but will attend remotely. Greetings, Stefan Winter RADEXT WG IETF 90 Agenda =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Chairs: Jouni Korhonen Stefan Winter Jabber room: radext at jabber.ietf.org (Please join) Time and Day: Wednesday, 1520-1650 local time, Afternoon Session II Place: Salon A Preliminaries (10 min) ---------------------- Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Working group draft discussion (35 minutes) ------------------------------------------- draft-ietf-radext-ip-port-radius-ext-01 : 10 min draft-ietf-radext-bigger-packets-01 : 10 min draft-ietf-radext-nai-06 : 5 min draft-ietf-radext-radius-fragmentation-07 : 5 min 5 min free remaining Individual draft discussions (19 minutes) ----------------------------------------- CoA proxying : 10 min https://datatracker.ietf.org/doc/draft-dekok-radext-datatypes/ : 5 min https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidenti= ty/ : 4 min Recharter discussion: 16 min ---------------------------- The three indidvidual drafts above are not currently covered by the charter. Should the charter be updated to fit these? Independent Stream documents of interest to radext -------------------------------------------------- eduroam architecture: 5 min Wrap-up (5 minutes) -------------------- Next Steps: WG Chairs & ADs --=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 --------------000302040504080207000404 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.22 (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----- --------------000302040504080207000404-- --Fpf5EQ3fM9ORdPwU4on8DsVWwLebpJi3D 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.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTzM+CAAoJEMDeajWKOdxm7ZQQALdUV6w2+egq1XJ6Vkyyc4Ia 0I9hRtZ0J/vbv8tQkWZKMf3TeCRunKrzy2uYwto5zocYpyGY4OwHQOhpFX93X+v4 wbJu44LgTaDzlstJp5nwMiBRCYlLHV4tvnUObsLshxBrGZ/MpyhnRcSYpXY3DKli I/ioEoLPCQuPRqNUbLT3KI72D6W15yCG27w9svkjYX+FA83bUozaIgk6U1WmKI8q OMo2TdgCkj7s1ShByNdlWz+HdD5fLZFb6v2Ji0IEEBF/B4Ev4iX/FfkKZopFjz6Y 9eORb8k1xuq14XVBbFgF8qXB9SY2h3nMnTwu4Qm5DwIEQv/cbMyKcYVJ3duWLvLI zApqmEZrV/9F7QAmAObKpASELybYpUBTNOUaiS2sxm9iC+gznUTf5TKCPIgfgXXJ NKhfZr4YGs5DGlngj2J9TE2ajOpYN6+oMNfzxRww4r8+Hhv4ynZ+0pUHjuwnDczA 1MM+hjKyqqnIfoxW1dx0x1DXlAmFctbPYS1FlzXIgS7wKLIGM/7DLBh1bySU1rIC QZ+gP9Jb6Y1zinsdrb4ERlv0D+qndKK3G2Bory1GYIIJpDfakSX4l71mvmzb58k3 oFXAibffkf9GNKi13y5WHXrtUzPXX/N16BNhwTlko2/y+pUlkrRW6bPh3c649uMK FwdkgwN4WvTSrtJ1FNpd =WpGQ -----END PGP SIGNATURE----- --Fpf5EQ3fM9ORdPwU4on8DsVWwLebpJi3D-- From nobody Fri Jul 25 11:34:05 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB241A049F for ; Fri, 25 Jul 2014 11:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4too6vzo9Ws for ; Fri, 25 Jul 2014 11:34:00 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF6C51A0452 for ; Fri, 25 Jul 2014 11:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6D1892240333 for ; Fri, 25 Jul 2014 20:33:58 +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 GeK5SK5TuFG1 for ; Fri, 25 Jul 2014 20:33:53 +0200 (CEST) Received: from [192.168.2.14] (unknown [70.50.219.241]) by power.freeradius.org (Postfix) with ESMTPSA id 63D6D2240168 for ; Fri, 25 Jul 2014 20:33:53 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_77A8BCC1-093D-4B3D-86ED-DCE4DEE59E13"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Pgp-Agent: GPGMail 2.1 (86d0425) From: Arran Cudbard-Bell In-Reply-To: Date: Fri, 25 Jul 2014 14:33:49 -0400 Message-Id: References: To: radext@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/radext/0TNhRZpSE-B-1XuGRpbf6y2IaHY Subject: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:34:02 -0000 --Apple-Mail=_77A8BCC1-093D-4B3D-86ED-DCE4DEE59E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Following up from the meeting at IETF90 SCTP/UDP encapsulation ---------------------- RFC6951 does allow SCTP to be encapsulated by UDP packets. The reasons stated in the RFC are for legacy NAT traversal, and to allow = SCTP to be implemented on hosts which do not allow direct access to the IP layer. When tunnelling SCTP UDP/9899 is used, though this is not a requirement, = and the RFC states=20 that other ports can be used. Do people feel that it would be useful to be able to represent = tunnelling with the attributes=20 of cgn-cfg? Protocol enumeration -------------------- Majority of NAT'd communications will likely be TCP/UDP ICMP, but there = is no reason why=20 SCTP and other more exotic protocols couldn't be NAT'd. To support arbitrary protocols, the extended IP-Port-Type attribute = could reference the=20 IANA protocol numbers registry, with the caveat that the protocol = referenced used ports=20 as connection identifiers. Multiple IP-Port-Type attributes could be included to represent a port = mapping in multiple=20 protocols (where enum values 1 and 2 are used currently). Explicit references to TCP/UDP/ICMP other than where used as examples = would then be removed. Reporting for dynamic CGN sessions (PCP) ---------------------------------------- ISPs are looking at NAT44 as a stopgap measure until v6 connectivity is = sufficient to run v6 only on CPEs. UPnP to PCP gateways on the CPE allow legacy applications to work, by = requesting specific public ports on the NAT44 device. Reporting for all N to 1 mappings required when used by ISPs for = compliance reasons=20 (in the UK at least). Law enforcement needs to be able to map Public = IP/Port to private IP and subscriber. Just to check, in these cases would IP-Port-Forwarding-Map would be used = to report these=20 mappings, in a similar way as to how IP-Port-Range is used in Section = 4.1.2? Clarification around IP Port Allocation/De-allocation ----------------------------------------------------- Section 4.1.2 describes a method of reporting range allocation and range = deallocation but=20 does not describe how to differentiate between the two. Making an inference from other parts of the document, it seems that each = Accounting-Request packet records information about a single IP-Port-Range or = IP-Port-Forwarding-Map=20 allocation/deallocation. Are separate RADIUS accounting sessions then, generated for each = IP-Port-Range or=20 IP-Port-Forwarding-Map? Should these sessions be linked to the = subscriber's BNG session=20 with Acct-Multi-Session-Id? Or alternatively are each of the Accounting-Requests just = Interim-Updates, and if so how do we know when a port allocation is being reported as opposed to = deallocation? -Arran --Apple-Mail=_77A8BCC1-093D-4B3D-86ED-DCE4DEE59E13 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT0qMNAAoJEP+k1YKfttfKp44P/0ztiSiJ1JXLPj2GMDAwtOMC eiHnpydj4mkXWJYuevUTWsJeqKtw7uW7s1bEMActP2//Fpyz/j+A/Dg0GUjkD1h7 yNh1rbpBdquT7aQ3YnAghZ78FMIbV+HwfFQlZK8SR2GszmtQ6Js4y7cyqd0XrDeW X5iHkg6iYyZF721wRHmmLXBZsAjiEOTaPmGalEKOoJvj6Neuoym7J2T+l3IQ+ca8 gyfKP3BcAcwO59L4qrIEs0uiIn7sGAA8pjS1aGJERZ/wv4HZwU/Nv8kxuFwDCbkW /0pHCmfbahwUwIP8RA3GQzuVOpZsaxCT+434diy86n1ycsO20c0LvfMF4tUIdt1M fyEPQv1PdyDmYaEEs1PNWMyq9xDm0hab0zDULey5Hb6zxRzHV44uV994QbctXsci oQwM6sZ7xGEHpDIs2IH0ms/M6bp2DP2tHxTBpOngrpx6Zx45Vykr6TydjpYtBXw3 2eBp38PunaMq903d9w+bEQz0FORKmYuYXQSrQzyZxgTOw02iBBgG4C6Q6sR51esT 6J/QtpXYoB0tHkpWbnbyJQCy4JJ6SA68X7ohYpbpuzQvQVjYOIdrGJ0hP63wmtcK ei4+g7qgMqFz+JjF2jV1DAPXJa67Bff4CCb0W5ul5WJsKRi8ROiRfwSMumg0V+GZ TwkbxRpZCKWTqemZc+Gn =UyUq -----END PGP SIGNATURE----- --Apple-Mail=_77A8BCC1-093D-4B3D-86ED-DCE4DEE59E13-- From nobody Fri Jul 25 11:47:45 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A024D1A0334 for ; Fri, 25 Jul 2014 11:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKVS_2HSI_us for ; Fri, 25 Jul 2014 11:47:41 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2F4C1A030C for ; Fri, 25 Jul 2014 11:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3144C22403BA; Fri, 25 Jul 2014 20:47:41 +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 6yuy2kSE4P90; Fri, 25 Jul 2014 20:47:37 +0200 (CEST) Received: from Thor.local (unknown [70.50.219.241]) by power.freeradius.org (Postfix) with ESMTPSA id 400B62240168; Fri, 25 Jul 2014 20:47:37 +0200 (CEST) Message-ID: <53D2A648.6090606@deployingradius.com> Date: Fri, 25 Jul 2014 14:47:36 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Arran Cudbard-Bell References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/X-whMeOpyzV-v4XqY-gpPNNqHb8 Cc: radext@ietf.org Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:47:43 -0000 After some other discussion with Arran, I think there is another way to solve this problem. As background, this document allows for a NAS to communicate a TCP/UDP port set information for specific hosts. It seems duplicate effort to re-define all of the port / protocol information in a RADIUS document. These information elements are already defined in IPFIX: http://www.iana.org/assignments/ipfix/ipfix.xhtml Port ranges, protocols, etc. are all there. I wrote a document for IPFIX to RADIUS mappings: http://tools.ietf.org/html/draft-dekok-radius-ipfix-00 The intent was to allow for flow-specific accounting in RADIUS. That goal was talked about a lot 2-3 years ago, but has since been ignored. I believe that we can re-use it here. The only change necessary to my IPFix document is to add the following: - use of Acct-Multi-Session-Id to have flow-specific accounting streams - use Acct-Multi-Session-Id and Acct-Status-Type start / stop to indicate port range allocate / de-allocate. The benefits here are numerous, I think. RADIUS gains flow-specific accounting, and port range allocation signaling. However, RADIUS does *not* need to manage any attributes related to ports, protocols, ranges, etc. All of that is already defined in IPFIX. We could just reference IPFIX, and be done. Alan DeKok. From nobody Fri Jul 25 12:04:21 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AF41A03CF for ; Fri, 25 Jul 2014 12:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk85uw-RoBSk for ; Fri, 25 Jul 2014 12:04:18 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25211A03BA for ; Fri, 25 Jul 2014 12:04:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id D013520186; Fri, 25 Jul 2014 15:01: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 yzr2tKjqKwmk; Fri, 25 Jul 2014 15:01:22 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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, 25 Jul 2014 15:01:22 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DC37981C12; Fri, 25 Jul 2014 15:04:11 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <53D2A648.6090606@deployingradius.com> Date: Fri, 25 Jul 2014 15:04:11 -0400 In-Reply-To: <53D2A648.6090606@deployingradius.com> (Alan DeKok's message of "Fri, 25 Jul 2014 14:47:36 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/radext/BVbXKxmzI0PloY1FHaM5ATRnn1Y Cc: radext@ietf.org, Arran Cudbard-Bell Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:04:19 -0000 Is this in accounting document, an authorization document or both? From nobody Fri Jul 25 12:16:57 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFB91A0310 for ; Fri, 25 Jul 2014 12:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT1iiP59oi7m for ; Fri, 25 Jul 2014 12:16:55 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 718131A0309 for ; Fri, 25 Jul 2014 12:16:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D5B952240333; Fri, 25 Jul 2014 21:16:24 +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 xMA5AndLNpgc; Fri, 25 Jul 2014 21:16:20 +0200 (CEST) Received: from Thor.local (unknown [70.50.219.241]) by power.freeradius.org (Postfix) with ESMTPSA id C2D722240168; Fri, 25 Jul 2014 21:16:19 +0200 (CEST) Message-ID: <53D2AD02.1040400@deployingradius.com> Date: Fri, 25 Jul 2014 15:16:18 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <53D2A648.6090606@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/k2OvrHAyrtKObmgIg_-nOQn1pfw Cc: radext@ietf.org, Arran Cudbard-Bell Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:16:56 -0000 Sam Hartman wrote: > Is this in accounting document, an authorization document or both? Right now, the IPFix document is both. It provides ways for the RADIUS server to request accounting on specific flows. And for the NAS to send accounting for those flows. The "behave" document is accounting only. The NAS pro-actively informs the RADIUS server that it has allocated ports to a user. I believe that the two uses can be supported by the IPFix document, with minimal changes to it. Alan DeKok. From nobody Fri Jul 25 12:24:06 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2E1A0195 for ; Fri, 25 Jul 2014 12:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbW0-i3tkWmq for ; Fri, 25 Jul 2014 12:24:04 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC711A0343 for ; Fri, 25 Jul 2014 12:24:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7F8E52240168; Fri, 25 Jul 2014 21:24:02 +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 8_5BpPpJMw63; Fri, 25 Jul 2014 21:23:57 +0200 (CEST) Received: from Thor.local (unknown [70.50.219.241]) by power.freeradius.org (Postfix) with ESMTPSA id 0AAFD2240333; Fri, 25 Jul 2014 21:23:56 +0200 (CEST) Message-ID: <53D2AECC.6040400@deployingradius.com> Date: Fri, 25 Jul 2014 15:23:56 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Arran Cudbard-Bell References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/GYi_piIsh0etVznvCLBvA979ZYY Cc: radext@ietf.org Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:24:06 -0000 And reviewing the document some more: - it doesn't use TLVs. It uses the 6929 attribute format. But it still packs multiple fields into one attribute. Each field needs to be a separate sub-TLV. e.g. Section 3.1: This attribute is of type complex [RFC6158] .. There is no need for a "complex" type. - ST (Session Type) This field defines identifiers for TCP, UDP, and ICMP. We already have identifiers defined in IPv6. This document should re-use those values, as it avoids the need for us to have more RADIUS-specific allocations. It could instead refer to the IPv6 protocol mappings, define "ST" as a TLV, and then say "if this rule applies to TCP and UDP, then list both TCP and UDP as protocols". Alan DeKok. From nobody Fri Jul 25 17:49:28 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F081A0AF1 for ; Fri, 25 Jul 2014 17:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-ZNHarumJbR for ; Fri, 25 Jul 2014 17:49:19 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809B91A0AEF for ; Fri, 25 Jul 2014 17:49:19 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so1798076wib.4 for ; Fri, 25 Jul 2014 17:49:18 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VVvnz8cSZL2YgS7HVLsWAZoCpJvQoBEMEV8reSw1GDk=; b=bRLnGvRs6D5/Q+OQxzM1Cyo8Zq0mVv10I4zrGcl3JqwpUTYxzHZTlDcFCO2TfKregj 3juQXwBKM9PwZVt5GF8HanYhlCFKpnoX/eCHKPBCr0cLBZmtlyAjFdtmErTW1m+u5EdB ODXIV3dpqqsHHK3HBaNC+H0AgnZY80IsYhesrdU3xC/C9k281IDphup7zsVLXsmOq0+w rKxicV9pBHH8UomaXFNgIDvzVYmHi+or5ZUtkMpFIud1GQNpIjekZFNdExQLrm+83oPE 7fgSRzEZqrdlu/KeoEBpOH3zVhua7bVXG3V4EWseuph8DbAek2pEwTvwmAm9RSPvOeAm t4RA== X-Received: by 10.194.216.163 with SMTP id or3mr25623039wjc.31.1406335758189; Fri, 25 Jul 2014 17:49:18 -0700 (PDT) Received: from [10.203.136.160] ([209.226.201.240]) by mx.google.com with ESMTPSA id eh10sm1444186wic.0.2014.07.25.17.49.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 17:49:17 -0700 (PDT) Message-ID: <53D2FB0A.1050002@gmail.com> Date: Sat, 26 Jul 2014 03:49:14 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Arran Cudbard-Bell , radext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/oj84AMT5IjtVgrXyF2SQWM1LFs4 Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 00:49:24 -0000 Just for my clarification, we did not handle draft-cheng-behave-cgn-cfg-radius-ext during the meeting, thus which document is meant here then? I assume draft-ietf-radext-ip-port-radius-ext is meant here, right. - Jouni 7/25/2014 9:33 PM, Arran Cudbard-Bell kirjoitti: > Following up from the meeting at IETF90 > > SCTP/UDP encapsulation > ---------------------- > RFC6951 does allow SCTP to be encapsulated by UDP packets. > The reasons stated in the RFC are for legacy NAT traversal, and to allow SCTP to be > implemented on hosts which do not allow direct access to the IP layer. > > When tunnelling SCTP UDP/9899 is used, though this is not a requirement, and the RFC states > that other ports can be used. > > Do people feel that it would be useful to be able to represent tunnelling with the attributes > of cgn-cfg? > > Protocol enumeration > -------------------- > Majority of NAT'd communications will likely be TCP/UDP ICMP, but there is no reason why > SCTP and other more exotic protocols couldn't be NAT'd. > > To support arbitrary protocols, the extended IP-Port-Type attribute could reference the > IANA protocol numbers registry, with the caveat that the protocol referenced used ports > as connection identifiers. > > Multiple IP-Port-Type attributes could be included to represent a port mapping in multiple > protocols (where enum values 1 and 2 are used currently). > > Explicit references to TCP/UDP/ICMP other than where used as examples would then be removed. > > Reporting for dynamic CGN sessions (PCP) > ---------------------------------------- > ISPs are looking at NAT44 as a stopgap measure until v6 connectivity is sufficient to > run v6 only on CPEs. > > UPnP to PCP gateways on the CPE allow legacy applications to work, by requesting specific > public ports on the NAT44 device. > > Reporting for all N to 1 mappings required when used by ISPs for compliance reasons > (in the UK at least). Law enforcement needs to be able to map Public IP/Port to private > IP and subscriber. > > Just to check, in these cases would IP-Port-Forwarding-Map would be used to report these > mappings, in a similar way as to how IP-Port-Range is used in Section 4.1.2? > > Clarification around IP Port Allocation/De-allocation > ----------------------------------------------------- > Section 4.1.2 describes a method of reporting range allocation and range deallocation but > does not describe how to differentiate between the two. > > Making an inference from other parts of the document, it seems that each Accounting-Request > packet records information about a single IP-Port-Range or IP-Port-Forwarding-Map > allocation/deallocation. > > Are separate RADIUS accounting sessions then, generated for each IP-Port-Range or > IP-Port-Forwarding-Map? Should these sessions be linked to the subscriber's BNG session > with Acct-Multi-Session-Id? > > Or alternatively are each of the Accounting-Requests just Interim-Updates, and if so how > do we know when a port allocation is being reported as opposed to deallocation? > > -Arran > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Fri Jul 25 18:52:25 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29651A0084 for ; Fri, 25 Jul 2014 18:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI-bmiqxWA0c for ; Fri, 25 Jul 2014 18:52:20 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E93DB1A007E for ; Fri, 25 Jul 2014 18:52:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 15A4B2240333; Sat, 26 Jul 2014 03:52:17 +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 TKrS4Y7QPQ6N; Sat, 26 Jul 2014 03:52:13 +0200 (CEST) Received: from [100.86.11.210] (unknown [207.164.79.82]) by power.freeradius.org (Postfix) with ESMTPSA id E71E62240168; Sat, 26 Jul 2014 03:52:12 +0200 (CEST) References: <53D2FB0A.1050002@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53D2FB0A.1050002@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2254D673-36FF-4B64-AC0C-A7AC9CE4991A@deployingradius.com> X-Mailer: iPhone Mail (11D257) From: Alan DeKok Date: Fri, 25 Jul 2014 21:52:12 -0400 To: Jouni Korhonen Archived-At: http://mailarchive.ietf.org/arch/msg/radext/iQiCl7ceZiX2h_WAufcq8SZaOps Cc: "radext@ietf.org" , Arran Cudbard-Bell Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 01:52:24 -0000 Yes. I'll double check the document contents. But the general idea was co= rrect, I think.=20 > On Jul 25, 2014, at 8:49 PM, Jouni Korhonen wrote= : >=20 >=20 > Just for my clarification, we did not handle draft-cheng-behave-cgn-cfg-ra= dius-ext during the meeting, thus which document is meant here then? I assum= e draft-ietf-radext-ip-port-radius-ext is meant here, right. >=20 > - Jouni >=20 > 7/25/2014 9:33 PM, Arran Cudbard-Bell kirjoitti: >> Following up from the meeting at IETF90 >>=20 >> SCTP/UDP encapsulation >> ---------------------- >> RFC6951 does allow SCTP to be encapsulated by UDP packets. >> The reasons stated in the RFC are for legacy NAT traversal, and to allow S= CTP to be >> implemented on hosts which do not allow direct access to the IP layer. >>=20 >> When tunnelling SCTP UDP/9899 is used, though this is not a requirement, a= nd the RFC states >> that other ports can be used. >>=20 >> Do people feel that it would be useful to be able to represent tunnelling= with the attributes >> of cgn-cfg? >>=20 >> Protocol enumeration >> -------------------- >> Majority of NAT'd communications will likely be TCP/UDP ICMP, but there i= s no reason why >> SCTP and other more exotic protocols couldn't be NAT'd. >>=20 >> To support arbitrary protocols, the extended IP-Port-Type attribute could= reference the >> IANA protocol numbers registry, with the caveat that the protocol referen= ced used ports >> as connection identifiers. >>=20 >> Multiple IP-Port-Type attributes could be included to represent a port ma= pping in multiple >> protocols (where enum values 1 and 2 are used currently). >>=20 >> Explicit references to TCP/UDP/ICMP other than where used as examples wou= ld then be removed. >>=20 >> Reporting for dynamic CGN sessions (PCP) >> ---------------------------------------- >> ISPs are looking at NAT44 as a stopgap measure until v6 connectivity is s= ufficient to >> run v6 only on CPEs. >>=20 >> UPnP to PCP gateways on the CPE allow legacy applications to work, by req= uesting specific >> public ports on the NAT44 device. >>=20 >> Reporting for all N to 1 mappings required when used by ISPs for complian= ce reasons >> (in the UK at least). Law enforcement needs to be able to map Public IP/P= ort to private >> IP and subscriber. >>=20 >> Just to check, in these cases would IP-Port-Forwarding-Map would be used t= o report these >> mappings, in a similar way as to how IP-Port-Range is used in Section 4.1= .2? >>=20 >> Clarification around IP Port Allocation/De-allocation >> ----------------------------------------------------- >> Section 4.1.2 describes a method of reporting range allocation and range d= eallocation but >> does not describe how to differentiate between the two. >>=20 >> Making an inference from other parts of the document, it seems that each A= ccounting-Request >> packet records information about a single IP-Port-Range or IP-Port-Forwar= ding-Map >> allocation/deallocation. >>=20 >> Are separate RADIUS accounting sessions then, generated for each IP-Port-= Range or >> IP-Port-Forwarding-Map? Should these sessions be linked to the subscriber= 's BNG session >> with Acct-Multi-Session-Id? >>=20 >> Or alternatively are each of the Accounting-Requests just Interim-Updates= , and if so how >> do we know when a port allocation is being reported as opposed to dealloc= ation? >>=20 >> -Arran >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Sat Jul 26 06:01:57 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40B51B27FA for ; Sat, 26 Jul 2014 06:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNeIjbc0RCqA for ; Sat, 26 Jul 2014 06:01:53 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A90661B27D9 for ; Sat, 26 Jul 2014 06:01:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 22A8E2240267; Sat, 26 Jul 2014 15:01:53 +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 yTttLjld6e0u; Sat, 26 Jul 2014 15:01:48 +0200 (CEST) Received: from [192.168.1.19] (192-0-132-212.cpe.teksavvy.com [192.0.132.212]) by power.freeradius.org (Postfix) with ESMTPSA id 51EDD224024E; Sat, 26 Jul 2014 15:01:47 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7537ECFF-8D52-4D4E-AAAE-5E90B387C149"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (86d0425) From: Arran Cudbard-Bell In-Reply-To: <2254D673-36FF-4B64-AC0C-A7AC9CE4991A@deployingradius.com> Date: Sat, 26 Jul 2014 09:01:44 -0400 Message-Id: <413B2EA8-AD1F-4EB1-9B92-2FD420F9F3EA@freeradius.org> References: <53D2FB0A.1050002@gmail.com> <2254D673-36FF-4B64-AC0C-A7AC9CE4991A@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/radext/BCwGtLr08hJcSl8lk6kgG51C_Mo Cc: "radext@ietf.org" , Jouni Korhonen Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:01:55 -0000 --Apple-Mail=_7537ECFF-8D52-4D4E-AAAE-5E90B387C149 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> On Jul 25, 2014, at 8:49 PM, Jouni Korhonen = wrote: >>=20 >>=20 >> Just for my clarification, we did not handle = draft-cheng-behave-cgn-cfg-radius-ext during the meeting, thus which = document is meant here then? I assume = draft-ietf-radext-ip-port-radius-ext is meant here, right. draft-ietf-radext-ip-port-radius-ext-01 appears to be a retitled version = of draft-cheng-behave-cgn-cfg-radius-ext with some updates. My points all still apply to draft-cheng-behave-cgn-cfg-radius-ext. Alan's point about IPFIX still applies.=20 draft-cheng-behave-cgn-cfg-radius-ext does now use Sub-TLVs. The bulk of the document is the same. I guess there's no meta data added to drafts when they're republished = under a different title? -Arran Arran Cudbard-Bell FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 --Apple-Mail=_7537ECFF-8D52-4D4E-AAAE-5E90B387C149 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT06a4AAoJEP+k1YKfttfK/8oP/1JvffIey2xj6r/rkDxz1qZ8 JHBJSo4EUFKGxUprPdExd31C6RPur6+AxbLgdAxb2LYwGy8OGMap8mh8y1lxKM15 EvnKrxsHANhg1qGJvQrVyJvA7tXRzVMm0pctegfZWPAM3Z9wG2pxKu+Wtpe1vEgY Jd0nUV080BPryRHzXhyzZoYVY1mCwbzeequJUxHByDSSBmZahMF91lJgNHIHwYiW rlLU+2NyWed1qpP6IlGBM+4jgZcdE3rPuzqyHeIVyIjcrbVSQyiUgARMmXbV5G9B kpEeC5K8CYTVDcwi2HvTJa8EWN9oPZPBxTD4WIxelL3MzRqKAkaEok7ToslCOvAo Nw3UzBWWUzgJL0ehpFqIPljZhcrkk6jNReju658INAabgD0OSBXSKi1KZ5PHC8SG 9nOzx9+nUZfR/LpcP6CyLCXuCk/jqz2iHWQ2OAnN2i1lioI0FT/914ejh34FZsrm uKoKL1EjafCtTRaRyZAxmVkFvcVC7d1W3tY2LCD6rwhZYLkXFrtO2GY3QAlBn7lW gI/JGFmfmrkEV/K+K13AY9cvO7QaNkF9dD3VPKRZgWz9Ue7bAvy2Izy2dXmXuAy7 xOLck8xHDeaO+Khq0at2Q9NqfTqpQcFEivGHq8ObVs46CHUSgmXcANZ13NSf5sJN P68wmPWqBqiW7OmyNO/l =7fmr -----END PGP SIGNATURE----- --Apple-Mail=_7537ECFF-8D52-4D4E-AAAE-5E90B387C149-- From nobody Sat Jul 26 06:03:06 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBB41B27D9 for ; Sat, 26 Jul 2014 06:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3cQyhINXkbL for ; Sat, 26 Jul 2014 06:03:04 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7311B27D6 for ; Sat, 26 Jul 2014 06:03:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 90C1422402F8; Sat, 26 Jul 2014 15:02:33 +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 MfpsJ1i-FjDe; Sat, 26 Jul 2014 15:02:33 +0200 (CEST) Received: from [192.168.1.19] (192-0-132-212.cpe.teksavvy.com [192.0.132.212]) by power.freeradius.org (Postfix) with ESMTPSA id 5CBB7224024E; Sat, 26 Jul 2014 15:02:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D3C810CA-DC6A-4FCF-9BCA-154202364D79"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (86d0425) From: Arran Cudbard-Bell In-Reply-To: <413B2EA8-AD1F-4EB1-9B92-2FD420F9F3EA@freeradius.org> Date: Sat, 26 Jul 2014 09:02:31 -0400 Message-Id: References: <53D2FB0A.1050002@gmail.com> <2254D673-36FF-4B64-AC0C-A7AC9CE4991A@deployingradius.com> <413B2EA8-AD1F-4EB1-9B92-2FD420F9F3EA@freeradius.org> To: Alan DeKok X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/radext/mXGVteU9OSRdNZwdHTzfVGCMkYM Cc: "radext@ietf.org" , Jouni Korhonen Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:03:05 -0000 --Apple-Mail=_D3C810CA-DC6A-4FCF-9BCA-154202364D79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Jul 2014, at 09:01, Arran Cudbard-Bell = wrote: >=20 >>> On Jul 25, 2014, at 8:49 PM, Jouni Korhonen = wrote: >>>=20 >>>=20 >>> Just for my clarification, we did not handle = draft-cheng-behave-cgn-cfg-radius-ext during the meeting, thus which = document is meant here then? I assume = draft-ietf-radext-ip-port-radius-ext is meant here, right. >=20 > draft-ietf-radext-ip-port-radius-ext-01 appears to be a retitled = version of draft-cheng-behave-cgn-cfg-radius-ext with some updates. >=20 > My points all still apply to draft-cheng-behave-cgn-cfg-radius-ext. make that draft-ietf-radext-ip-port-radius-ext > Alan's point about IPFIX still applies.=20 >=20 > draft-cheng-behave-cgn-cfg-radius-ext does now use Sub-TLVs. and draft-ietf-radext-ip-port-radius-ext. --Apple-Mail=_D3C810CA-DC6A-4FCF-9BCA-154202364D79 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT06bnAAoJEP+k1YKfttfKzM4QAKyA3JNC2cTRxUFV9kq6woMR XxyPc6gRzuUZZOM7KMQf65XC156EGA14dd2FHwKQX8eSo2ZhvXH3wfmOIa+WXsQn beUkgruVZ2r+ivK13e75eAg4JZgAB3gUDQlLInkb2gpZ2H6LgZ1cVhAeYOx+MMZ9 fRihCaRHYvEG5xUrEGa5ZPz2hjcoZJbp+CNMNk9lFEiUcg5A5VOOv0v+8s22Sy3y 3Xt+gbJnj4ZCt+fd9hzVOOaFKmLs3T20FTkUslHvJ25y3gQUg+35CeHsygfYpzdk DGf8rGueemoEA7vkPvE5IW3+902Frrv6GBtsvHrATSoyI3dLw4fv+WRz4kxm2o/h fNScLA4zFytWVCQG6aphfitbImmzWga8wZnvLS3JNNaJDn9YDvv1kSXJL0gSPVZp vG3FqIbDA6ZBmv1bq2Kz+0K6w7ZThJNTJb6/Zu6bQjuzIqBCxrtup54tEww8+NRE 2rZK7Ld7BDRyi4UhTKeQ23pFUGErG8Wr6vctEQXqYN7OJIi/aVzJH2qW8pnu0hTS /1/WXjXhq6kIb+jGhL85roVQ0KYZ6/XYBUAhpBa2B1tSxPjq6A9cbs/Wd4OZr1/M E4ha3h50W1ZV3jIA6vEuvuDk+xlzUKvh5EnhNmXu3Lu6n+6SHaXEW12aNtu3FzZo c+7CXEp6a3DOUdwzjS1X =Ntug -----END PGP SIGNATURE----- --Apple-Mail=_D3C810CA-DC6A-4FCF-9BCA-154202364D79-- From nobody Sat Jul 26 06:04:08 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD721B27D9 for ; Sat, 26 Jul 2014 06:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRJF3bS4_ufw for ; Sat, 26 Jul 2014 06:04:06 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7C1B27D6 for ; Sat, 26 Jul 2014 06:04:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2994F2240267; Sat, 26 Jul 2014 15:03:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo-tvUTO8Euq; Sat, 26 Jul 2014 15:03:31 +0200 (CEST) Received: from Thor.local (unknown [70.50.219.241]) by power.freeradius.org (Postfix) with ESMTPSA id 1B7DB224024E; Sat, 26 Jul 2014 15:03:31 +0200 (CEST) Message-ID: <53D3A721.6050706@deployingradius.com> Date: Sat, 26 Jul 2014 09:03:29 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <53D2FB0A.1050002@gmail.com> <2254D673-36FF-4B64-AC0C-A7AC9CE4991A@deployingradius.com> In-Reply-To: <2254D673-36FF-4B64-AC0C-A7AC9CE4991A@deployingradius.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/JTj6ZHxF6pRIGtF3pgFgrsFuSSc Cc: "radext@ietf.org" , Arran Cudbard-Bell Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:04:08 -0000 Alan DeKok wrote: > Yes. I'll double check the document contents. But the general idea was correct, I think. I've checked the documents again. The document draft-ietf-radext-ip-port-radius-ext uses good design for the TLVs, etc. My previous comments about IPFix still apply, though. I think that the ip-port document could leverage the IPFix document. That way the ip-port document would contain *no* new attribute definitions. Instead, it would explain how to use the RADIUS/IPFix attributes. Alan DeKok. From nobody Sat Jul 26 06:13:19 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17C81B27F5 for ; Sat, 26 Jul 2014 06:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j22utYObiL7D for ; Sat, 26 Jul 2014 06:13:15 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 503801B27FC for ; Sat, 26 Jul 2014 06:13:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id BB8242240267; Sat, 26 Jul 2014 15:12:44 +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 tyG9Z-fEq9LW; Sat, 26 Jul 2014 15:12:40 +0200 (CEST) Received: from [192.168.1.19] (192-0-132-212.cpe.teksavvy.com [192.0.132.212]) by power.freeradius.org (Postfix) with ESMTPSA id B419E224024E; Sat, 26 Jul 2014 15:12:39 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_71C512AC-D743-492C-98ED-932C9485098D"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (86d0425) From: Arran Cudbard-Bell In-Reply-To: Date: Sat, 26 Jul 2014 09:12:37 -0400 Message-Id: References: <53D2A648.6090606@deployingradius.com> To: Sam Hartman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/radext/YlfLMWEq7w-SDO48BWXMeRL4Trs Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:13:17 -0000 --Apple-Mail=_71C512AC-D743-492C-98ED-932C9485098D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 25 Jul 2014, at 15:04, Sam Hartman wrote: > Is this in accounting document, an authorization document or both? Both. It defines attributes that can be included in an Access-Accept or CoA-Request to configure explicit port ranges or mappings for a subscriber's NAT session. It also states that those attributes can be used for reporting purposes in Accounting-Requests, when a NAT device allocates an additional IP port range, to a subscriber but doesn't go into any more detail than that. Arran Cudbard-Bell FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 --Apple-Mail=_71C512AC-D743-492C-98ED-932C9485098D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT06lFAAoJEP+k1YKfttfKntYP/jMcVpFFXlSGGvZ4MA7Ymg/p bnCeJvs9HG0yNdIioPaiRP4tKub+6zr+hoiUHTx1zC2R4v6wthx6LmwEjFPUjvTJ BpmhFNW0bPJd4Jtv1qBYgYFdnwI5cNTuOXRWXxIC4oE4P3c7s569YjWPI1CNJwBW Pr8enpjht03IL0Eajz+S3oNDvWNtVu8RVD4hXWOFKDlq00CsnJ7PBoeK+Wzc9MY/ GB8ByW5ZIr/wbM6eJ7+jcmwP8YYhCQUaExHXOUFmTwibqjCYw2nMD1Car3Skifva IWHjFr3rnWznacHSgoZkmtoX4XDVAXMHZeNvUjJkcz4nZQnp7wbg0odWVHYvfsBE cj9dl5pWWbei5sEAbDYu9U4dzh+sAXPBNjP44SZozphB1W3iglHbeSy9R82UPcRC JeEjewMqEyxyCi/V88lui3/qFwECdc1KO3d+cjfH3ZIKbanOzbU7FTfhqBO38gmx J/PFLCs1ic0RD8eHtdZYLjkfKGNQo5Clp3aocbfo4nOCvXqIJhAj7rdmOrmVhUD/ 2EMbUKRAzGR4TmkHAD7YpMCjPX+GknvJ1tpAHzqcHnawxNqtrAWUoKaMsg+8Crvw q0JLPH1kyZllCT1qdxxERnUYABPsl9uVD/WISHX04k30LKAUJOWTBeFWA7o540De QWIoMdYo2b08F+bKrr4a =f/0/ -----END PGP SIGNATURE----- --Apple-Mail=_71C512AC-D743-492C-98ED-932C9485098D-- From nobody Mon Jul 28 05:26:40 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47761A0AE8 for ; Mon, 28 Jul 2014 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjDP8iLLCZTU for ; Mon, 28 Jul 2014 05:26:37 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412B71A04B0 for ; Mon, 28 Jul 2014 05:26:37 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id pv20so5425232lab.1 for ; Mon, 28 Jul 2014 05:26:35 -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:subject :content-type:content-transfer-encoding; bh=mAoJEkfSYbjIlLjiYinHhMpD94A+5tC+SyKYHmet7o8=; b=xzrDrUNh0hIQi5pwZzoj3pLUdphq/oGVdbLLH7IGRa14ULSMFwiKNQznrEJHwgfDAr PSL9Y9JCLkgGtMnKkwR463kC8MnI3gX5HhAGpCzK9OVg7Dn6S6k5fYqnt7vBw77vgRju 2foFp5MO2eO7NJe3grMwJgTe4S1TQrqugibC0x3hpwWse0J8eDxqnNqghmHUjezjeUSd vAxA9eJTM4p9Ju3kqK0nZJm84PPz7K1EeN6E9Y81VGqWMwTRNISg9Zc28FltNmG2FCmE B/dIBuyJFvSUS1n+Nd2GSSf6wgXl3MNpve6xK7PqHXAqsEUARnaKvBnt/2ES8sRqn1Ba 0nsw== X-Received: by 10.112.106.67 with SMTP id gs3mr8655919lbb.84.1406550395355; Mon, 28 Jul 2014 05:26:35 -0700 (PDT) Received: from [192.168.250.37] ([194.100.71.98]) by mx.google.com with ESMTPSA id jf2sm30622822lbc.34.2014.07.28.05.26.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 05:26:34 -0700 (PDT) Message-ID: <53D64179.6070705@gmail.com> Date: Mon, 28 Jul 2014 15:26:33 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: radext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/MbTJysjnOv5zDvfsYViFrjx106Y Subject: [radext] meeting minutes uploaded. X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:26:38 -0000 Thanks to Arran for great notes: http://tools.ietf.org/wg/radext/minutes?item=minutes-90-radext.html - Jouni From nobody Mon Jul 28 05:29:06 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82DE1A04B0 for ; Mon, 28 Jul 2014 05:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyQbKNZbhgfm for ; Mon, 28 Jul 2014 05:29:02 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE7EC1A0174 for ; Mon, 28 Jul 2014 05:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id EABE422403B3; Mon, 28 Jul 2014 14:29:00 +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 GqOWDzLYCuYH; Mon, 28 Jul 2014 14:28:57 +0200 (CEST) Received: from Thor.local (unknown [70.50.219.241]) by power.freeradius.org (Postfix) with ESMTPSA id B794D224024E; Mon, 28 Jul 2014 14:28:56 +0200 (CEST) Message-ID: <53D64206.7090105@deployingradius.com> Date: Mon, 28 Jul 2014 08:28:54 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <53D64179.6070705@gmail.com> In-Reply-To: <53D64179.6070705@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/wdrd6eZ3azb6dpn7uyT3xM0gdns Cc: radext@ietf.org Subject: Re: [radext] meeting minutes uploaded. X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:29:04 -0000 Jouni Korhonen wrote: > Thanks to Arran for great notes: > http://tools.ietf.org/wg/radext/minutes?item=minutes-90-radext.html - Alan: Can't do fragmentation across internet with CoA because 5176 doesn't support CoA. Make that last word "proxies" From nobody Mon Jul 28 06:53:45 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371FF1B281F for ; Mon, 28 Jul 2014 06:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRsjXofkQNpx for ; Mon, 28 Jul 2014 06:53:41 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8641B2818 for ; Mon, 28 Jul 2014 06:53:40 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id 10so5709559lbg.6 for ; Mon, 28 Jul 2014 06:53:39 -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=eRCeJh9Jkn+IMob2f7R60bAJ9RmBo86q4pjO9iitfqM=; b=s7J3uDPCd0j9+SKxfOhbpFhVvRrdd1Uo0fda4a51QwbN7z6+kxDEIU5oQ/93j9deHU 0zWQdBM8yA1O+2z6PVa7rs0fEK3ik53B9KBkxMVoScLwufBlKagOIlpyHszNb9ZnuLGX NgoQerV6N0jzuZuS7N67ew9a6zQjHV8MjPDZhi8D+P8GUrA8tCRd+ejK6pVZR4oFy9ob L7M2QsqTmgC2IB6ZeEzwXTBK97RsGXmAtIKDE0D224ZAihnAldNo9vv6zAGGBgG1xVks 6SWUdOwXL79xV0M2u/qbtf6sSSeUN86JKYnE5DJ7X7p4PE8SuXjuWRgBjU/biG5lpFny j6SQ== X-Received: by 10.112.151.237 with SMTP id ut13mr3193187lbb.104.1406555619406; Mon, 28 Jul 2014 06:53:39 -0700 (PDT) Received: from [83.245.197.169] (83-245-197-169.elisa-mobile.fi. [83.245.197.169]) by mx.google.com with ESMTPSA id wv7sm12390095lac.30.2014.07.28.06.53.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 06:53:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jouni X-Mailer: iPhone Mail (11D201) In-Reply-To: <53D64206.7090105@deployingradius.com> Date: Mon, 28 Jul 2014 16:53:35 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <53D64179.6070705@gmail.com> <53D64206.7090105@deployingradius.com> To: Alan DeKok Archived-At: http://mailarchive.ietf.org/arch/msg/radext/3IE-aMX4hjOiKj65_7kBJY8P_Xc Cc: "radext@ietf.org" Subject: Re: [radext] meeting minutes uploaded. X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:53:44 -0000 Ack. Jouni -- Jouni Korhonen Broadcom (Sent from my mobile..) > Alan DeKok kirjoitti 28.7.2014 kello 15.28: > > Jouni Korhonen wrote: >> Thanks to Arran for great notes: >> http://tools.ietf.org/wg/radext/minutes?item=minutes-90-radext.html > > - Alan: Can't do fragmentation across internet with CoA because > 5176 > doesn't support CoA. > > Make that last word "proxies" > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Jul 29 01:35:10 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB811A00AD for ; Tue, 29 Jul 2014 01:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IB7cwMZIsbwX for ; Tue, 29 Jul 2014 01:35:05 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAEF1A0086 for ; Tue, 29 Jul 2014 01:35:04 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so6568323lbv.2 for ; Tue, 29 Jul 2014 01:35:03 -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=F38fDBmaX8069TGv0EtOBPiitXDN+1sPAEKx2OnQiPw=; b=b7QjuIOLv+K0OfA6+RdgtjqlSFR2uofgdw2sILZtrHhjsVr9WoSGAKEgdVhrHM6DxR yBzSgHmnO3Vek155wBMulduzzNTNvcmiSJnrIBrSQ4ybX0kfxSsQcCuczLPtkvw0ipYd ZJf8lWTqj8n9E2tBFn28koqjvMbqNRxfpzmFoR7DPrvd56FYwareAKij5hXM7BSbl8XV bVaz2ZWIN6/iNhrrqTzMv3Z9ZAd5qDNaffbtU6/WMwZRTYWFcrU4LLpp3piXcDEdGfHB DfyOwygZFJ/IjBY5vagljxphay7XOXwOpc6AEYk4oa5/iGImwwEzin34kybaJtCXmOhi N5Lw== X-Received: by 10.152.207.76 with SMTP id lu12mr612267lac.49.1406622903363; Tue, 29 Jul 2014 01:35:03 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id la6sm13843064lac.12.2014.07.29.01.35.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 01:35:02 -0700 (PDT) Message-ID: <53D75CB4.8000908@gmail.com> Date: Tue, 29 Jul 2014 11:35:00 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Arran Cudbard-Bell , Alan DeKok References: <53D2FB0A.1050002@gmail.com> <2254D673-36FF-4B64-AC0C-A7AC9CE4991A@deployingradius.com> <413B2EA8-AD1F-4EB1-9B92-2FD420F9F3EA@freeradius.org> In-Reply-To: <413B2EA8-AD1F-4EB1-9B92-2FD420F9F3EA@freeradius.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/GjTtE8ETuMPZ07piSGhIbTrPa7s Cc: "radext@ietf.org" Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 08:35:08 -0000 7/26/2014 4:01 PM, Arran Cudbard-Bell kirjoitti: > >>> On Jul 25, 2014, at 8:49 PM, Jouni Korhonen wrote: >>> >>> >>> Just for my clarification, we did not handle draft-cheng-behave-cgn-cfg-radius-ext during the meeting, thus which document is meant here then? I assume draft-ietf-radext-ip-port-radius-ext is meant here, right. > > draft-ietf-radext-ip-port-radius-ext-01 appears to be a retitled version of draft-cheng-behave-cgn-cfg-radius-ext with some updates. > > My points all still apply to draft-cheng-behave-cgn-cfg-radius-ext. > > Alan's point about IPFIX still applies. > > draft-cheng-behave-cgn-cfg-radius-ext does now use Sub-TLVs. > > The bulk of the document is the same. > > I guess there's no meta data added to drafts when they're republished under a different title? Nope.. drafts are quite free terrotiry to do whatever folks want ;) - Jouni > > -Arran > > Arran Cudbard-Bell > FreeRADIUS development team > > FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 > From nobody Tue Jul 29 11:26:29 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9365B1B29AD for ; Tue, 29 Jul 2014 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_GAM33msu0r for ; Tue, 29 Jul 2014 11:26:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925521B2903 for ; Tue, 29 Jul 2014 11:26:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHS43759; Tue, 29 Jul 2014 18:23:30 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 19:23:30 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 11:23:25 -0700 From: Dean cheng To: Alan DeKok , Arran Cudbard-Bell Thread-Topic: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback Thread-Index: AQHPqDcJCcBQbKrtAk6emD97/90CcZuxlrgAgAXLN9A= Date: Tue, 29 Jul 2014 18:23:24 +0000 Message-ID: References: <53D2A648.6090606@deployingradius.com> In-Reply-To: <53D2A648.6090606@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/radext/B3KFLCdkQsdm1lhyjoguAHs7qpI Cc: "radext@ietf.org" Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 18:26:26 -0000 Alan, Arran, Thanks for the suggestions, I'll take a look of these and get back to you. Please note that this draft is now draft-ietf-radext-ip-port-radius-ext-01 that was discussed last week in Toronto. Dean > -----Original Message----- > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok > Sent: Friday, July 25, 2014 11:48 AM > To: Arran Cudbard-Bell > Cc: radext@ietf.org > Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback >=20 > After some other discussion with Arran, I think there is another way > to solve this problem. >=20 > As background, this document allows for a NAS to communicate a > TCP/UDP port set information for specific hosts. It seems duplicate > effort to re-define all of the port / protocol information in a RADIUS > document. > These information elements are already defined in IPFIX: >=20 > http://www.iana.org/assignments/ipfix/ipfix.xhtml >=20 > Port ranges, protocols, etc. are all there. >=20 > I wrote a document for IPFIX to RADIUS mappings: >=20 > http://tools.ietf.org/html/draft-dekok-radius-ipfix-00 >=20 > The intent was to allow for flow-specific accounting in RADIUS. That > goal was talked about a lot 2-3 years ago, but has since been ignored. > I believe that we can re-use it here. >=20 > The only change necessary to my IPFix document is to add the > following: >=20 > - use of Acct-Multi-Session-Id to have flow-specific accounting streams >=20 > - use Acct-Multi-Session-Id and Acct-Status-Type start / stop to > indicate port range allocate / de-allocate. >=20 >=20 > The benefits here are numerous, I think. RADIUS gains flow-specific > accounting, and port range allocation signaling. However, RADIUS does > *not* need to manage any attributes related to ports, protocols, ranges, > etc. All of that is already defined in IPFIX. We could just reference > IPFIX, and be done. >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext