From nobody Mon Apr 7 01:55: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 E7FBD1A06A4; Mon, 7 Apr 2014 01:55:47 -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 ux3GDGTnzCm4; Mon, 7 Apr 2014 01:55:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B701A0331; Mon, 7 Apr 2014 01:55:43 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407085543.17464.90407.idtracker@ietfa.amsl.com> Date: Mon, 07 Apr 2014 01:55:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/qDgAWFhHSSTKSPPtgaECJ8FZ2Qs Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 08:55:48 -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-06.txt Pages : 30 Date : 2014-04-07 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 7 01:56:26 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 5C54E1A0331 for ; Mon, 7 Apr 2014 01:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p16puVZZVHY1 for ; Mon, 7 Apr 2014 01:56:20 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 341A41A0355 for ; Mon, 7 Apr 2014 01:56:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 921CEBBEA for ; Mon, 7 Apr 2014 10:56:13 +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 lDW2jDqFIvRG for ; Mon, 7 Apr 2014 10:56:13 +0200 (CEST) Received: from [155.54.205.49] (inf-205-49.inf.um.es [155.54.205.49]) (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 6A464A4F for ; Mon, 7 Apr 2014 10:56:12 +0200 (CEST) Message-ID: <5342682C.3040103@um.es> Date: Mon, 07 Apr 2014 10:56:12 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: radext@ietf.org References: <20140407085543.17464.90407.idtracker@ietfa.amsl.com> In-Reply-To: <20140407085543.17464.90407.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050004070506000009020406" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/0bZvSLEoMl-MxaJpZvXN9DgnGeQ Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-06.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: Mon, 07 Apr 2014 08:56:25 -0000 This is a multi-part message in MIME format. --------------050004070506000009020406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have updated our fragmentation draft with the aim of capturing what has been agreed on the mailing list. In particular: * The Updates 6929 clause remains by now. * A new section called Operational considerations has bee included, with subsections for: o Flag T: summary of the "Updates 6929" discussion o Violation of RFC2865: discussion about the formal violation of RFC 2865 regarding the mandatory presence of authentication attributes on Access-Request packets, and why there are no known operation issues with it. o Proxying based on User-Name: indication that, in this specification, proxies are supposed to base their routing decision on the value of the User-Name attribute. We have also included a new Acknowledgements section. Regards, Alejandro > 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-06.txt > Pages : 30 > Date : 2014-04-07 > > 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-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------050004070506000009020406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

we have updated our fragmentation draft with the aim of capturing what has been agreed on the mailing list. In particular:
  • The Updates 6929 clause remains by now.
  • A new section called Operational considerations has bee included, with subsections for:
    • Flag T: summary of the "Updates 6929" discussion
    • Violation of RFC2865: discussion about the formal violation of RFC 2865 regarding the mandatory presence of authentication attributes on Access-Request packets, and why there are no known operation issues with it.
    • Proxying based on User-Name: indication that, in this specification, proxies are supposed to base their routing decision on the value of the User-Name attribute.

We have also included a new Acknowledgements section.

Regards,
Alejandro

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-06.txt
	Pages           : 30
	Date            : 2014-04-07

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-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--------------050004070506000009020406-- From nobody Tue Apr 15 07:32: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 730F61A0667 for ; Tue, 15 Apr 2014 07:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.372 X-Spam-Level: X-Spam-Status: No, score=-8.372 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 yrCjwv7D31cG for ; Tue, 15 Apr 2014 07:32:13 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 01E451A0430 for ; Tue, 15 Apr 2014 07:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7296; q=dns/txt; s=iport; t=1397572330; x=1398781930; h=message-id:date:from:mime-version:to:subject; bh=RuxZRly/HQ2IJX91/tmx8Y1EDFzd+Uc8a6Bn6C06+eY=; b=Cp00SvuHbj77o4PXVkwjuK6smyEbu6X8A/Brd5+T7jTeoDP7cuhfMOBo JdjbSurRtWV3zB7O1wgFEOwAIirzlAoHWQC9w9fTksobBi6/V/7EhFMbd qEqO6OqpFr93M2n6kBHqcicxXkck2jHqmddQfmIHJhhOFNsXR4TFVvUOl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkEAHFCTVOtJssW/2dsb2JhbABYg0G7DIosdIMkPRYYAwIBAgFLDQgBAYd4DZoDsg8XkyIEmGKBNoUei3GDMzs X-IronPort-AV: E=Sophos; i="4.97,864,1389744000"; d="scan'208,217"; a="18428464" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 15 Apr 2014 14:32:09 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3FEW8Dc028722 for ; Tue, 15 Apr 2014 14:32:08 GMT Message-ID: <534D42E8.8020501@cisco.com> Date: Tue, 15 Apr 2014 16:32:08 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: multipart/alternative; boundary="------------010108040308060104090103" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/f9PhCg7YSYgiyTDhsQwkslyC0Rk Subject: [radext] AD review http://tools.ietf.org/html/draft-ietf-radext-dtls-09 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, 15 Apr 2014 14:32:15 -0000 This is a multi-part message in MIME format. --------------010108040308060104090103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, - In section 5.1: A RADIUS/DTLS server MUST track ongoing DTLS client session based the following 4-tuple: Does the MUST also apply to the DTLS Data and Last Traffic as well? I guess so for the Last Traffic because I see later on "RADIUS/DTLS servers which do not implement an application-layer watchdog MUST also maintain a "Last Traffic" timestamp per DTLS session.", but it's not clear for the DTLS Data. Maybe it is "RADIUS/DTLS servers SHOULD also monitor the total number of open sessions.", but then it's a SHOULD, while the other is a MUST. I would make it clear in section 5.1, one way or the others (MUST/SHOULD, or forward references) - Any reason why this sentence is repeated. Maybe the third one wants to stress_for all DTLS sessions_? Once a DTLS session is established, a RADIUS/DTLS server SHOULD use DTLS Heartbeats [RFC6520 ] to determine connectivity between the two servers. Once a DTLS session is established, a RADIUS/DTLS client SHOULD use DTLS Heartbeats [RFC6520 ] to determine connectivity between the two systems. For these reasons, it is RECOMMENDED that RADIUS/DTLS clients implement DTLS heartbeats and/or watchdog packets for all DTLS sessions. - Section 7 "Implementation experience" should follow RFC 6982 "Implementation Status" format. Example: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ or https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ - IANA considerations. Please make sure to spell out the exact IANA registry. Editorial: - OLD: This specification does not, however, solve all of the problems associated with RADIUS. NEW: This specification does not, however, solve all of the problems associated with RADIUS/UDP - Some misalignement in section 5.1: Each 4-tuple points to a unique session entry, which contains the following information: DTLS Data An implementation-specific variable containing information about the active DTLS session. Last Taffic A variable containing a timestamp which indicates when this session last received valid traffic. Each entry may contain other information, such as idle timeouts, session lifetimes, and other implementation-specific data. - 10.1 . Legacy RADIUS Security protocol. We suggest that RADIUS clients and servers implement either this specification, or [RFC6614 ]. "protocol" looks lonely there :-) - please extend CSPRNG - When DTLS is used, the fixed IP address model can be relaxed. As discussed earlier inSection 2.2.1 , client identies should be determined from TLS parameters. identies? Regards, Benoit --------------010108040308060104090103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

- In section 5.1:
   A RADIUS/DTLS server MUST track ongoing DTLS client session based the
   following 4-tuple:
Does the MUST also apply to the DTLS Data and Last Traffic as well?
I guess so for the Last Traffic because I see later on "RADIUS/DTLS servers which do not implement an application-layer watchdog MUST also maintain a "Last Traffic" timestamp per DTLS session.", but it's not clear for the DTLS Data. Maybe it is "RADIUS/DTLS servers SHOULD also monitor the total number of open sessions.", but then it's a SHOULD, while the other is a MUST.
I would make it clear in section 5.1, one way or the others (MUST/SHOULD, or forward references)

- Any reason why this sentence is repeated. Maybe the third one wants to stress for all DTLS sessions?
   Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
   DTLS Heartbeats [RFC6520] to determine connectivity between the two
   servers. 

   Once a DTLS session is established, a RADIUS/DTLS client SHOULD use
   DTLS Heartbeats [RFC6520] to determine connectivity between the two
   systems. 

   For these reasons, it is RECOMMENDED that RADIUS/DTLS clients
   implement DTLS heartbeats and/or watchdog packets for all DTLS
   sessions.
- Section 7 "Implementation experience" should follow RFC 6982 "Implementation Status" format.
Example: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ or https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/

- IANA considerations.
Please make sure to spell out the exact IANA registry.




Editorial:
- OLD:
   This specification does not, however, solve all of the problems
   associated with RADIUS.

NEW:
   This specification does not, however, solve all of the problems
   associated with RADIUS/UDP

- Some misalignement in section 5.1:
   Each 4-tuple points to a unique session entry, which contains the
   following information:

DTLS Data
     An implementation-specific variable containing information about
     the active DTLS session.

Last Taffic
     A variable containing a timestamp which indicates when this session
     last received valid traffic.

     Each entry may contain other information, such as idle timeouts,
     session lifetimes, and other implementation-specific data.
- 
10.1.  Legacy RADIUS Security
   protocol.  We suggest that RADIUS clients and servers implement
   either this specification, or [RFC6614].

"protocol" looks lonely there :-)

- please extend CSPRNG

- 
   When DTLS is used, the fixed IP address model can be relaxed.  As
   discussed earlier in Section 2.2.1, client identies should be
   determined from TLS parameters.

identies?

Regards, Benoit
--------------010108040308060104090103-- From nobody Wed Apr 16 09:47:39 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 C33A11A00FB for ; Wed, 16 Apr 2014 09:47:37 -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 DqvYm-5uUynY for ; Wed, 16 Apr 2014 09:47:35 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADD3A1A01AC for ; Wed, 16 Apr 2014 09:47:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7D83622401C5; Wed, 16 Apr 2014 18:47: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 dnK2q9FEEvzL; Wed, 16 Apr 2014 18:46:57 +0200 (CEST) Received: from Thor.local (unknown [64.229.83.96]) by power.freeradius.org (Postfix) with ESMTPSA id D1E5722403B8; Wed, 16 Apr 2014 18:46:56 +0200 (CEST) Message-ID: <534EB3FF.5040507@deployingradius.com> Date: Wed, 16 Apr 2014 12:46:55 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise References: <534D42E8.8020501@cisco.com> In-Reply-To: <534D42E8.8020501@cisco.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/uHWMP58d4O3vGv3QMYSYuAI8kTM Cc: "radext@ietf.org" Subject: Re: [radext] AD review http://tools.ietf.org/html/draft-ietf-radext-dtls-09 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, 16 Apr 2014 16:47:37 -0000 Benoit Claise wrote: > - In section 5.1: > > A RADIUS/DTLS server MUST track ongoing DTLS client session based the > following 4-tuple: > > Does the MUST also apply to the DTLS Data and Last Traffic as well? The MUST means that the 4 tuple MUST contain the DTLS session information. The Last Traffic need be there only if it's used. The implementation-specific DTLS data information is there only if it's needed by the implementation. I'll update the text to make this clearer. > - Any reason why this sentence is repeated. Maybe the third one wants to > stress_ for all DTLS sessions_? Yes. I'll make that clear. > - Section 7 "Implementation experience" should follow RFC 6982 > "Implementation Status" format. > Example: > https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ or > https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ I'll take a look. > - IANA considerations. > Please make sure to spell out the exact IANA registry. Done. > Editorial: > - OLD: > > This specification does not, however, solve all of the problems > associated with RADIUS. > > NEW: > This specification does not, however, solve all of the problems > associated with RADIUS/UDP Done. > - Some misalignement in section 5.1: > Each 4-tuple points to a unique session entry, which contains the > following information: I'll update the text. > 10.1 > . > Legacy RADIUS Security > > protocol. We suggest that RADIUS clients and servers implement > either this specification, or [RFC6614 ]. > > "protocol" looks lonely there :-) Fixed. > - please extend CSPRNG Done. > - > When DTLS is used, the fixed IP address model can be relaxed. As > discussed earlier in Section 2.2.1 , client identies should be > determined from TLS parameters. > > identies? Fixed. Alan DeKok. From nobody Wed Apr 16 09:50: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 4A0561A0224; Wed, 16 Apr 2014 09:50:01 -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 fNcoqXr39g9y; Wed, 16 Apr 2014 09:50:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA0D1A019B; Wed, 16 Apr 2014 09:49:57 -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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416164957.3938.96380.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 09:49:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/sJqPnpORWraRFkPy9qxItmKMMN8 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-10.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, 16 Apr 2014 16:50:01 -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-10.txt Pages : 26 Date : 2014-04-16 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-10 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 Apr 16 09:52:23 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 828FB1A0240 for ; Wed, 16 Apr 2014 09:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 kHTHnSNg3Faw for ; Wed, 16 Apr 2014 09:52:20 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 010091A01E9 for ; Wed, 16 Apr 2014 09:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2350; q=dns/txt; s=iport; t=1397667137; x=1398876737; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2tDFjv063O4uZAQmES4aZwvOkiJ2UL6AZKXll9RvAow=; b=cfrxJEXVpIhqizpc1lEUs5Gd/jHyn3hYypXMfKqy1hTLltjdVn5Cdane sKBEZUsCL7he1JZwni42Lc4AtB55ym2OZRSVpth2TuEqzNxUsYz+fAa58 vWHfwq0TyHz8yUvfZuHg3e5jULmjWboKjQhyg33gNlC1KM4Tm4MvvRMnJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAAq0TlOQ/khL/2dsb2JhbABZgwY7xAyBIhZ0giUBAQEEOEEQCxgJJQ8CRgYNAQcBAYd4DckXF45iB4Q4AQOYZoE3hR+Lc4MzOw X-IronPort-AV: E=Sophos;i="4.97,872,1389744000"; d="scan'208";a="14350762" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 16 Apr 2014 16:52:16 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3GGqFfs028278; Wed, 16 Apr 2014 16:52:15 GMT Message-ID: <534EB53F.20204@cisco.com> Date: Wed, 16 Apr 2014 18:52:15 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alan DeKok References: <534D42E8.8020501@cisco.com> <534EB3FF.5040507@deployingradius.com> In-Reply-To: <534EB3FF.5040507@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/4xc4bhT-ys99rFPcrLp2R-u80Kc Cc: "radext@ietf.org" Subject: Re: [radext] AD review http://tools.ietf.org/html/draft-ietf-radext-dtls-09 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, 16 Apr 2014 16:52:21 -0000 Hi Alan, Thanks for the quick reply. Please provide a new version and I'll progress the draft. Regards, Benoit > Benoit Claise wrote: >> - In section 5.1: >> >> A RADIUS/DTLS server MUST track ongoing DTLS client session based the >> following 4-tuple: >> >> Does the MUST also apply to the DTLS Data and Last Traffic as well? > The MUST means that the 4 tuple MUST contain the DTLS session > information. The Last Traffic need be there only if it's used. The > implementation-specific DTLS data information is there only if it's > needed by the implementation. > > I'll update the text to make this clearer. > >> - Any reason why this sentence is repeated. Maybe the third one wants to >> stress_ for all DTLS sessions_? > Yes. I'll make that clear. > >> - Section 7 "Implementation experience" should follow RFC 6982 >> "Implementation Status" format. >> Example: >> https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ or >> https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ > I'll take a look. > >> - IANA considerations. >> Please make sure to spell out the exact IANA registry. > Done. > >> Editorial: >> - OLD: >> >> This specification does not, however, solve all of the problems >> associated with RADIUS. >> >> NEW: >> This specification does not, however, solve all of the problems >> associated with RADIUS/UDP > Done. > >> - Some misalignement in section 5.1: >> Each 4-tuple points to a unique session entry, which contains the >> following information: > I'll update the text. > >> 10.1 >> . >> Legacy RADIUS Security >> >> protocol. We suggest that RADIUS clients and servers implement >> either this specification, or [RFC6614 ]. >> >> "protocol" looks lonely there :-) > Fixed. > >> - please extend CSPRNG > Done. > >> - >> When DTLS is used, the fixed IP address model can be relaxed. As >> discussed earlier in Section 2.2.1 , client identies should be >> determined from TLS parameters. >> >> identies? > Fixed. > > Alan DeKok. > . > From nobody Wed Apr 16 10:33: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 2089A1A0235 for ; Wed, 16 Apr 2014 10:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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, RP_MATCHES_RCVD=-0.272, 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 DSzyi0Y977ev for ; Wed, 16 Apr 2014 10:32:55 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD071A024F for ; Wed, 16 Apr 2014 10:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3862; q=dns/txt; s=iport; t=1397669569; x=1398879169; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=Zj6dOe1SnS4FEHYBhLxk1Ro2EEM2WXs72pv2d+9UoiE=; b=j2JBd0X3AZmCCa18hIXRjQXMb8cVv/9102/Are6dY8lG6X2nrDUjFEzd t6qaKR8pnzFg+cSadx8bTaZfG2U+FAGMXEpGwftUs7j56bhW7H1oC0EEz 4dhcXm/3qDTB/x67/j/wr6Mr3j5JqFeBcuw7Hh0Q55PzP0Lzy33ft5vQK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAHO9TlOQ/khN/2dsb2JhbABZgwY7UYMYwCOBIhZ0giUBAQEEI1QOBA8NAwECCiECAg8CPAIIBg0GAgEBBYdzCAWmJKMMF45RGAaCaYFJBJhmgTeFH4tzgzM7 X-IronPort-AV: E=Sophos; i="4.97,873,1389744000"; d="scan'208,217"; a="14359085" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-4.cisco.com with ESMTP; 16 Apr 2014 17:32:48 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3GHWm08031950 for ; Wed, 16 Apr 2014 17:32:48 GMT Message-ID: <534EBEC0.400@cisco.com> Date: Wed, 16 Apr 2014 19:32:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20140416164958.3938.85523.idtracker@ietfa.amsl.com> In-Reply-To: <20140416164958.3938.85523.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140416164958.3938.85523.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080809050406010806080407" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/0wwnaKLWZQ0K1je5d60JppElhOQ Subject: [radext] Fwd: New Version Notification - draft-ietf-radext-dtls-10.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, 16 Apr 2014 17:33:00 -0000 This is a multi-part message in MIME format. --------------080809050406010806080407 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit New State: Last Call Requested Regards, Benoit -------- Original Message -------- Subject: New Version Notification - draft-ietf-radext-dtls-10.txt Date: Wed, 16 Apr 2014 09:49:58 -0700 From: To: , , A new version (-10) has been submitted for draft-ietf-radext-dtls: http://www.ietf.org/internet-drafts/draft-ietf-radext-dtls-10.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dtls/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-10 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. IETF Secretariat. . --------------080809050406010806080407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit New State: Last Call Requested

Regards, Benoit


-------- Original Message --------
Subject: New Version Notification - draft-ietf-radext-dtls-10.txt
Date: Wed, 16 Apr 2014 09:49:58 -0700
From: <internet-drafts@ietf.org>
To: <radext-chairs@tools.ietf.org>, <draft-ietf-radext-dtls@tools.ietf.org>, <bclaise@cisco.com> 


A new version (-10) has been submitted for draft-ietf-radext-dtls:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dtls-10.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-dtls/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-10

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.

IETF Secretariat.

.


--------------080809050406010806080407-- From nobody Wed Apr 16 10:38: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 B9E991A01C9; Wed, 16 Apr 2014 10:37:58 -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 0IiShcCx50nz; Wed, 16 Apr 2014 10:37:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9D81A024F; Wed, 16 Apr 2014 10:37:57 -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.3.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140416173757.11076.89129.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 10:37:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/r8Gqy_pdf9gNAhxFum3hkBKz12o Cc: radext@ietf.org Subject: [radext] Last Call: (DTLS as a Transport Layer for RADIUS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:37:58 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'DTLS as a Transport Layer for RADIUS' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-dtls/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-dtls/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 18 07:53:32 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 A09F21A0303 for ; Fri, 18 Apr 2014 07:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 RIZ43VjQDsU3 for ; Fri, 18 Apr 2014 07:53:26 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 68AB51A01AF for ; Fri, 18 Apr 2014 07:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2360; q=dns/txt; s=iport; t=1397832803; x=1399042403; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=IUrOZoGZrOLs3DcaNCFzqPAVuu3ts9l8vOklZM5uGcU=; b=KEpRmX/wOoEcoRCw+sGBm9M7CdnafMxbM40KSKa5rGKoFnUnDJPX+q8L wgSdS5aSKFB1bz04Z19XmtyHSh2UgCWLIRmmHnnkKkoBDbRbrbojfwjV6 4XDwQGVPORkPasyorJd7fjmDCYNU/NwbgDnzONDMGdLnuV/n6ZtKNrP9J g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAEQ7UVOtJssW/2dsb2JhbABag1W9C4ZrUYEzdIIlAQEBBAEBATU2Cg0ECw4DBAEBChYIBwkDAgECARUfCQgGAQwGAgEBiD0NzH8TBI4OWwaEMgEDmG6GWIt3gzM7 X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="19111333" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 18 Apr 2014 14:53:21 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3IErLB5010437; Fri, 18 Apr 2014 14:53:21 GMT Message-ID: <53513C61.1050101@cisco.com> Date: Fri, 18 Apr 2014 16:53:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jim Schaad , radext@ietf.org, draft-wierenga-ietf-eduroam@tools.ietf.org References: <52C486C6-B1FD-4310-A38E-2EBEA8CDFB6F@gmail.com> <53282135.5060309@cisco.com> <034201cf42d2$15b4a780$411df680$@augustcellars.com> In-Reply-To: <034201cf42d2$15b4a780$411df680$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/BKUGO222FWJJX0xnrnOeW8MUwRo Subject: Re: [radext] Rechartering RADEXT 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 Apr 2014 14:53:30 -0000 Jim, I've been thinking about this draft. Also, the ISE issue came up in a couple of recent IESG discussions. Since there is not much freedom to change the technical content in this document, I now agree with you that ISE is a better avenue for this document. Only fools never change their minds ! Regards, Benoit > How would you expect the WG to change a document that has the purpose of > documenting one version of a RADIUS deployment. While I think that asking > the group to review the document for readability makes sense, having the > document as a WG item does not. > > Jim > >> -----Original Message----- >> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Benoit Claise >> Sent: Tuesday, March 18, 2014 3:34 AM >> To: Jouni Korhonen; radext@ietf.org >> Cc: radext-chairs@tools.ietf.org >> Subject: Re: [radext] Rechartering RADEXT >> >> Dear all, >> >> I've been asked in the past to AD sponsor >> https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/ >> I always prefer to get proper WG review when possible... >> Therefore I'm more inclined to have this document part of the new RADEXT >> charter. >> >> Do you see any problems with this approach? >> >> Regards, Benoit >>> Folks, >>> >>> We are about to recharter soon, since the current charter work items are >> nearly done. >>> We got the CoA Proxying as a potential charter item. So, the question >>> is whether the WG is OK taking in the work in and at the same time >>> adding required words into the current charter. >>> >>> During the London WG meeting we had a presentation of >>> draft-cheng-behave-cgn-cfg-radius-ext >>> I-D. Surprisingly many people had read it and there was also interest >>> around the ongoing work. So, the question is whether the WG is OK >>> taking in the work in and at the same time adding required words into >>> the current charter. In general I would (personally) like to add text > into the >> charter allowing RADEXT take in similar work to this more easily. >>> Any other topics the WG feels need to be added into the charter? I'd >>> assume at least Alan has one or two in his sleeves ;) >>> >>> - Jouni & Stefan. >>> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > . > From nobody Fri Apr 18 16:54: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 104CE1A0527 for ; Fri, 18 Apr 2014 16:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 1x8c8l46j-6U for ; Fri, 18 Apr 2014 16:54:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8A31A053B for ; Fri, 18 Apr 2014 16:54:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFV32769; Fri, 18 Apr 2014 23:54:35 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 19 Apr 2014 00:52:47 +0100 Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 19 Apr 2014 00:54:30 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML701-CHM.china.huawei.com ([169.254.3.206]) with mapi id 14.03.0158.001; Fri, 18 Apr 2014 16:54:23 -0700 From: Dean cheng To: "radext@ietf.org" Thread-Topic: I-D Action: draft-cheng-radext-ip-port-radius-ext-00.txt Thread-Index: AQHPW14CVpYTJ7/wt0mJYt5t0ojkYJsYBb6g Date: Fri, 18 Apr 2014 23:54:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.180] 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/wjCGdtouVsL_Qgt99Y9X3QeRA20 Cc: Jouni Korhonen , "mohamed.boucadair@orange.com" , Senthil Sivakumar , "radext-chairs@tools.ietf.org" Subject: [radext] FW: I-D Action: draft-cheng-radext-ip-port-radius-ext-00.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, 18 Apr 2014 23:54:43 -0000 Hello RADEXT WG, We've just submitted this draft that proposes three new RADIUS attributes to support IP port=20 configuration and usage reporting. This draft was based on draft-cheng-behave-cgn-cfg-radius-ext that was presented in London meeting at the WG where there was some interest. We've therefore updated the draft with changes (in particular, from suggestions received from Alan Dekok and Lionel Morand on mailing list about using TLV). Please review and provide comments, and we're now asking the WG to consider take this draft with adoption. Thanks Authors. > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, April 18, 2014 4:29 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-cheng-radext-ip-port-radius-ext-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : RADIUS Extensions for IP Port Configuration > and Reporting > Authors : Dean Cheng > Jouni Korhonen > Mohamed Boucadair > Senthil Sivakumar > Filename : draft-cheng-radext-ip-port-radius-ext-00.txt > Pages : 24 > Date : 2014-04-18 >=20 > Abstract: > This document defines three new RADIUS attributes. For device that > implementing IP port ranges, these attributes are used to > communicate > with a RADIUS server in order to configure and report TCP/UDP ports > and ICMP identifiers, as well as mapping behavior for specific hosts. > This mechanism can be used in various deployment scenarios such as > CGN, NAT64, Provider WiFi Gateway, etc. >=20 > This document does not make any assumption about the deployment > context. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-cheng-radext-ip-port-radius-ext/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-cheng-radext-ip-port-radius-ext-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Apr 23 05:47:13 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 B5EFE1A02C5 for ; Wed, 23 Apr 2014 05:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, 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 Fe_VxSXuSA7R for ; Wed, 23 Apr 2014 05:47:08 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 08C8D1A0081 for ; Wed, 23 Apr 2014 05:47:07 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8353B10581 for ; Wed, 23 Apr 2014 14:47:01 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 75CFF10580 for ; Wed, 23 Apr 2014 14:47:01 +0200 (CEST) Message-ID: <5357B645.5050105@restena.lu> Date: Wed, 23 Apr 2014 14:47:01 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.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="l2PcbrftlSOMVpgJo5TofiJ7PxF3j0mxp" X-Virus-Scanned: ClamAV Archived-At: http://mailarchive.ietf.org/arch/msg/radext/jXWKdJZyhXYL8y1uMkBo3NOuPRU Subject: [radext] Adoption of draft-cheng-radext-ip-port-radius-ext-00.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, 23 Apr 2014 12:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l2PcbrftlSOMVpgJo5TofiJ7PxF3j0mxp Content-Type: multipart/mixed; boundary="------------040302000506020002010802" This is a multi-part message in MIME format. --------------040302000506020002010802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, as discussed recently, we believe radext is at a point where old items are finished and new work can be added to our workload. There was a good and positive discussion on what is now draft-cheng-radext-ip-port-radius-ext-00.txt in the London meeting. BEHAVE (where this work could fit into) is not taking on new work. The RADEXT charter already allows us to work on RADIUS extensions, so if there is support for adoption of this work here in our WG, we can take it on pretty much immediately. So, this work needs a home and we could be that home if we want to. This mail starts a two week call for adoption for this draft. Please reply to this mail indicating whether you are in favour for adoption or not. Since the discussions in London were of generic nature, and not directly asking for adoption, there is no default - silence does not count as acceptance. So don't be silent :-) The call for adoption ends 7 May 2014. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------040302000506020002010802 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----- --------------040302000506020002010802-- --l2PcbrftlSOMVpgJo5TofiJ7PxF3j0mxp 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/ iQIcBAEBCgAGBQJTV7ZFAAoJEMDeajWKOdxm+zkP/iaylpwGxDWa1dZ9DTkGNBOl 3szgVIDtTdJWriXhOlDZ7DlJCloIy6V8JrwGRKKe8/xt4F2T/5jJb4Qz2KfpL2wF Ohy2M+KnhC4GR00A9AsRq1MPAoFWMgnfXOcFwsy110Qxnml37oo3Uad7EbpQHoPE VS+Y++QjzmYF94HquxLCM1Hqx2a3b1yig9F7qEZb9Y8UMdBwp1CEQFBLUjDsK8Ju fF2e2PKil6tdz78OuXmtsC2uuh1xutDLrPKpqkNYwivor4TS/KFOTiEa8IWubq04 6pjY5Jxp0tL0G4PN8WIZVxnq76EnY2oFSlKJgj+VxomBfsZuQk1zOAAqU22vdDPt B1yln45SyaD+6gBQTtyk06hn7mYuEHPsGEsv9kpcRXptRlyjkjaoCwv3pRm9n3N9 nUTG5glQuzbK/RcAPbAuK/jyL3nA2p5v+R7Jdwwpd2ze9MfEF28aZyfph0aK42uo PphIz2btwyByPuCkKROnySoIDFykr82AP027opMiSznCVh7iSThI9tcRI77js/Za Pbkmn9Io0JEsbvuhgBzYjjChrQazTXqNA297eaUV6sGvrmAIaeRZAvFtfsaaiXCw Ic4UZDFTo9YZIopci5trZZf+l2X9Sv7Z5ZGHBOU76RFj82f1Rdd/RyuFf5R/Hk1D pnGkXasxR/Zqt+uCovKE =bZNg -----END PGP SIGNATURE----- --l2PcbrftlSOMVpgJo5TofiJ7PxF3j0mxp-- From nobody Wed Apr 23 13:37:18 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 0DA421A0650 for ; Wed, 23 Apr 2014 13:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 yPtqZJceYhBo for ; Wed, 23 Apr 2014 13:37:13 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF8211A064C for ; Wed, 23 Apr 2014 13:37:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 87BEC2240602; Wed, 23 Apr 2014 22:37:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GPmkN8RfKag; Wed, 23 Apr 2014 22:36:56 +0200 (CEST) Received: from Thor.local (unknown [64.229.83.96]) by power.freeradius.org (Postfix) with ESMTPSA id 7F27C2240050; Wed, 23 Apr 2014 22:36:54 +0200 (CEST) Message-ID: <53582465.1040701@deployingradius.com> Date: Wed, 23 Apr 2014 16:36:53 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <5357B645.5050105@restena.lu> In-Reply-To: <5357B645.5050105@restena.lu> 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/rsWlQbqT_Jr3kJ07hxuxceLq_WY Cc: "radext@ietf.org" Subject: Re: [radext] Adoption of draft-cheng-radext-ip-port-radius-ext-00.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, 23 Apr 2014 20:37:15 -0000 Stefan Winter wrote: > This mail starts a two week call for adoption for this draft. Please > reply to this mail indicating whether you are in favour for adoption or > not. Since the discussions in London were of generic nature, and not > directly asking for adoption, there is no default - silence does not > count as acceptance. So don't be silent :-) I support adoption. On a quick review of the document, there are still outstanding issues. These issues are around field sizes, data types, etc. These issues could be solved by referencing the "data types" draft. However, that draft isn't a WG item, and isn't on the charter. - IP-Port-Type should be "integer" not "one octet" - IP-Port-Limit TLVs should be "integer", and not "16-bit integer". I'm also not sure why this needs a TLV - IP-Port-Range should be multiple sub-TLVs, instead of one TLV with binary packed data - IP-Port-Forwarding-Map has the same comment as above The rest of the document seems clear in it's intent, design, and execution. Alan DeKok. From nobody Fri Apr 25 10:47:23 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 EE19F1A0662; Fri, 25 Apr 2014 10:47:17 -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 XiX0L0eOHLP8; Fri, 25 Apr 2014 10:47:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D30E71A05D1; Fri, 25 Apr 2014 10:47:15 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140425174715.32766.5887.idtracker@ietfa.amsl.com> Date: Fri, 25 Apr 2014 10:47:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/loidoFeSkmABMa0zUCvzu9X8-Q8 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-bigger-packets-00.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, 25 Apr 2014 17:47:18 -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-00.txt Pages : 8 Date : 2014-04-25 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. 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-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 27 07:23:47 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 1E4EE1A01D1 for ; Sun, 27 Apr 2014 07:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 CgkVXXNzYW7O for ; Sun, 27 Apr 2014 07:20:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CED1A04F8 for ; Sun, 27 Apr 2014 07:20:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: radext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140427142046.10312.93801.idtracker@ietfa.amsl.com> Date: Sun, 27 Apr 2014 07:20:46 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/radext/X1Xhd5tLOTEG52usUOJviybWZVM X-Mailman-Approved-At: Sun, 27 Apr 2014 07:23:46 -0700 Subject: [radext] Milestones changed for radext WG 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: Sun, 27 Apr 2014 14:20:49 -0000 URL: http://datatracker.ietf.org/wg/radext/charter/ From nobody Sun Apr 27 07:23: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 3DBB01A01D1 for ; Sun, 27 Apr 2014 07:21: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 zd0ld6XyQDSi for ; Sun, 27 Apr 2014 07:21:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A151A04F8 for ; Sun, 27 Apr 2014 07:21:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: radext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140427142141.19603.84837.idtracker@ietfa.amsl.com> Date: Sun, 27 Apr 2014 07:21:41 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/radext/WuF1v1W4g2EYPCvRkQqzlFNEkS4 X-Mailman-Approved-At: Sun, 27 Apr 2014 07:23:46 -0700 Subject: [radext] Milestones changed for radext WG 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: Sun, 27 Apr 2014 14:21:43 -0000 Changed milestone "RADIUS over DTLS I-D submitted as an Experimental RFC", resolved as "Done". URL: http://datatracker.ietf.org/wg/radext/charter/ From nobody Mon Apr 28 00:51:32 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 0502A1A08CB for ; Mon, 28 Apr 2014 00:51:29 -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 tKYW094KQZVX for ; Mon, 28 Apr 2014 00:51:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D021A08CF for ; Mon, 28 Apr 2014 00:50:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: radext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428075059.3608.26349.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 00:50:59 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/radext/sGIGVTISsFc3Ee0w_KOFnrxRYPw Subject: [radext] Milestones changed for radext WG 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, 28 Apr 2014 07:51:29 -0000 Changed milestone "Larger Packets for RADIUS over TCP I-D submitted as an Experimental RFC ", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/radext/charter/ From nobody Mon Apr 28 06:15:32 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 DC8471A078F for ; Mon, 28 Apr 2014 06:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 im9orqqxB2EF for ; Mon, 28 Apr 2014 06:15:27 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74A1A047C for ; Mon, 28 Apr 2014 06:15:26 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 3C8C910583 for ; Mon, 28 Apr 2014 15:15:25 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2F7EB1057E for ; Mon, 28 Apr 2014 15:15:25 +0200 (CEST) Message-ID: <535E546C.3000903@restena.lu> Date: Mon, 28 Apr 2014 15:15:24 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.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="WDdRQRKRFbTxrJS20FGaFaHQM4tunN4TF" X-Virus-Scanned: ClamAV Archived-At: http://mailarchive.ietf.org/arch/msg/radext/MQmHGoa-1AucC7zs1duN8V1aa08 Subject: [radext] WGLC for draft-ietf-radext-radius-fragmentation-06 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 Apr 2014 13:15:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WDdRQRKRFbTxrJS20FGaFaHQM4tunN4TF Content-Type: multipart/mixed; boundary="------------040903060605000406060006" This is a multi-part message in MIME format. --------------040903060605000406060006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all, you certainly still remember our extensive discussion in London around the "T" flag, and how to make sure that spec writers in the future will not forget about the existence of this flag in the document. The authors have now written extra documentation on the topic in their new draft (section 11.1). They have also decided on a route ahead (favouring "Updates:"). The next thing to do is to decide if these changes are good enough for the document to move ahead. This mail starts a two-week WGLC (deadline is 12 May 2014). All, please give the latest rev another read; and those of you who commented on this particularly contentious issue please verify if the document in general and the new section 11 in particular matches your expectations. Since the rest of the document has already gotten a good amount of scrutiny before and appears to have WG consensus, silence in this WGLC round is counted as being positive towards moving the document ahead for publication. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------040903060605000406060006 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----- --------------040903060605000406060006-- --WDdRQRKRFbTxrJS20FGaFaHQM4tunN4TF 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/ iQIcBAEBCgAGBQJTXlRtAAoJEMDeajWKOdxm1FYP/R8l2ekQO9fM/fK9jKNPcEJc fUogLt0gSdAQkUgOEbn99pW9ZVIU4N59lwoiV0Q4WWZ0rgERi5ifV+Z+vPQzcjRW 3RGmKabEWBtjuX/IFXT8HS96q0DR88WB1whAYFUlifM0tjJtc14M8ZhkDrPrAf49 0ka+c9Y8RwnKyAUOE1asqImxcKUxq7fr7efjd+HfZrdLtEQfbWMXxKkfNfGbPCYT IxhE5cbGaC4mqMdgZMc6ADNnJqmasnNKzti8VjwaZhX+GlxcoXadVdjKMtBe3AIr Vf/HgcSl/wmltxg7XEIuB8AphTlikNru9lxKLaIBtnycEOI/vwHvNWiOnqhbO2GG YRcmzyfSZ5VTDK9+AJu2uWkdOmXSMriRoQvMh3oslLMJ7OzEuVJz0vyj2JW4AUt1 50MSKQ9S9RXH/Md2SmnQQd5mw1aLHggxBcH4b63zb5ORiiIRoAcQVFPLqmZpMpZa v2yoLtTm9VZtuGwn6af3S1+lx3G39nS4k3k/qCv7Twj3vBF1GbbaPfJlZ8Rhuayv 2vYL/lUJG5XlnJzzdn0LTKcONb/h6kJTwkkCPPdlBqSxuaxrrbuPqbr4bnOoGIbO S+vKDUv8P1LyPwVGMmHp0sqSDA15EFwz32bcbiIKuyFZfBydv4i3PxtcnJ2jW33E 1PMAZGiTdkjLia5nGX1R =0gey -----END PGP SIGNATURE----- --WDdRQRKRFbTxrJS20FGaFaHQM4tunN4TF-- From nobody Mon Apr 28 07:59: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 E56801A0A16 for ; Mon, 28 Apr 2014 07:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 WUUpbgK9br07 for ; Mon, 28 Apr 2014 07:59:15 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A26FE1A6F03 for ; Mon, 28 Apr 2014 07:59:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id EB614206E6; Mon, 28 Apr 2014 10:58:10 -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 iSOeaCvw_HWk; Mon, 28 Apr 2014 10:58:06 -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; Mon, 28 Apr 2014 10:58:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9007B8104F; Mon, 28 Apr 2014 10:59:01 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <535E546C.3000903@restena.lu> Date: Mon, 28 Apr 2014 10:59:01 -0400 In-Reply-To: <535E546C.3000903@restena.lu> (Stefan Winter's message of "Mon, 28 Apr 2014 15:15:24 +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/R7iUaVDaXg_oVrpQn4-i6_ehsfM Cc: "radext@ietf.org" Subject: Re: [radext] WGLC for draft-ietf-radext-radius-fragmentation-06 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 Apr 2014 14:59:17 -0000 I'm happy with the approach described by the authors with regard to the T bit. From nobody Wed Apr 30 08:48:34 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 88DF11A0926; Wed, 30 Apr 2014 08:48:30 -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 hmPNMp3Yr4kb; Wed, 30 Apr 2014 08:48:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C461A08E8; Wed, 30 Apr 2014 08:48:28 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430154828.7741.83754.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 08:48:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/ssVeVbxAwQgpMK5kkVYSNBrj0qA Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-11.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, 30 Apr 2014 15:48:30 -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-11.txt Pages : 26 Date : 2014-04-30 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-11 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/