From nobody Thu Sep 4 17:30:54 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 853631A030F; Thu, 4 Sep 2014 17:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C4qOxtgmCyJ; Thu, 4 Sep 2014 17:30:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 7C70B1A030B; Thu, 4 Sep 2014 17:30:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6EACE18047E; Thu, 4 Sep 2014 17:29:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140905002958.6EACE18047E@rfc-editor.org> Date: Thu, 4 Sep 2014 17:29:58 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/radext/hBCuKzp1okxTmo9sDvDLGQ-jjQs Cc: drafts-update-ref@iana.org, radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 7360 on Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS 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, 05 Sep 2014 00:30:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7360 Title: Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS Author: A. DeKok Status: Experimental Stream: IETF Date: September 2014 Mailbox: aland@freeradius.org Pages: 27 Characters: 60007 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-dtls-13.txt URL: https://www.rfc-editor.org/rfc/rfc7360.txt 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 coexist with current RADIUS systems. This document is a product of the RADIUS EXTensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 5 01:45: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 471A71A064F for ; Fri, 5 Sep 2014 01:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 bOx14Hg1_pVa for ; Fri, 5 Sep 2014 01:45:16 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BB61A064B for ; Fri, 5 Sep 2014 01:45:15 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id p9so584517lbv.38 for ; Fri, 05 Sep 2014 01:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:to; bh=ZFlIbKsNfruhoLKsUgOtgmfXX8WeNZUdDP2ysCOPiUg=; b=LQFQyU9I6FGxQkhxKLGIPHMG2rmQQh1MlUhqUc+oPTNWoVv9tCfx81cBlPC4CsvaS1 DEzgWKJk9eEzEyzbp6AoVqsY8CPXcq0GQZP6eSKLPNz4RjzOhSSVtKvaZuc/2DSRzzUS JrhcxrDXr5JaJ3ES8oU8iGCBN5l9zzExBCoQ5q88wNR7wQbtsKY/l96fV2MJkmgn4xMu 1lbbhxLMolquqZmB7QvvIVNTnbW3YouFk0XuukAu++2AmoZ+ODIfqhzrFJdOeQeCmK7q ytgxKL9tUOc5g1Cly27ZhGy66Kngu0hSO7CeviRySXN9grbKg8fq4V/izD8vVugP5yOr cQpw== X-Received: by 10.152.5.199 with SMTP id u7mr1975018lau.35.1409906713658; Fri, 05 Sep 2014 01:45:13 -0700 (PDT) Received: from [85.156.113.163] (85-156-113-163.elisa-mobile.fi. [85.156.113.163]) by mx.google.com with ESMTPSA id cm9sm500369lbb.39.2014.09.05.01.45.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Sep 2014 01:45:12 -0700 (PDT) From: Jouni Content-Type: multipart/alternative; boundary=Apple-Mail-F49FDE1E-A260-45AE-913D-B17CA03BC62F Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <88842B92-D554-4ED5-AFA6-0871C2983006@gmail.com> Date: Fri, 5 Sep 2014 11:45:07 +0300 References: <20140905002958.6EACE18047E@rfc-editor.org> To: radext@ietf.org X-Mailer: iPhone Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/radext/H47-MfYi_J68aa0tss8oYPqAx00 Subject: [radext] Fwd: RFC 7360 on Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS 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, 05 Sep 2014 08:45:18 -0000 --Apple-Mail-F49FDE1E-A260-45AE-913D-B17CA03BC62F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Congratulations to Alan and the WG for completing this RFC.=20 --=20 Jouni Korhonen Broadcom (Sent from my mobile..) V=C3=A4litetty viesti: > L=C3=A4hett=C3=A4j=C3=A4: rfc-editor@rfc-editor.org > P=C3=A4iv=C3=A4ys: 5. syyskuuta 2014 3.29.58 UTC+3 > Vastaanottaja: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Kopio: drafts-update-ref@iana.org, radext@ietf.org, rfc-editor@rfc-editor.= org > Aihe: [radext] RFC 7360 on Datagram Transport Layer Security (DTLS) as a T= ransport Layer for RADIUS >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7360 >=20 > Title: Datagram Transport Layer Security (DTLS)=20 > as a Transport Layer for RADIUS=20 > Author: A. DeKok > Status: Experimental > Stream: IETF > Date: September 2014 > Mailbox: aland@freeradius.org > Pages: 27 > Characters: 60007 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-radext-dtls-13.txt >=20 > URL: https://www.rfc-editor.org/rfc/rfc7360.txt >=20 > 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 coexist with > current RADIUS systems. >=20 > This document is a product of the RADIUS EXTensions Working Group of the I= ETF. >=20 >=20 > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet community. It does not specify an Internet standard of any > kind. Discussion and suggestions for improvement are requested. > Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html >=20 > 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. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --Apple-Mail-F49FDE1E-A260-45AE-913D-B17CA03BC62F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Congratulations to Alan and the WG for= completing this RFC. 

-- 
Jouni Korhonen
Broadcom

(Sent from my mobile..)

V= =C3=A4litetty viesti:

L=C3=A4= hett=C3=A4j=C3=A4: rfc-edit= or@rfc-editor.org
P=C3=A4iv=C3=A4ys: 5. syyskuuta 2014 3.29.58= UTC+3
Vastaanottaja: ie= tf-announce@ietf.org, rfc-dis= t@rfc-editor.org
Kopio: drafts-update-ref@iana.org, r= adext@ietf.org, rfc-editor@= rfc-editor.org
Aihe: [radext] RFC 7360 on Datagram Transpor= t Layer Security (DTLS) as a Transport Layer for RADIUS

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


       RFC 7360
=
       Title: &nb= sp;    Datagram Transport Layer Security (DTLS) <= br>            =         as a Transport Layer for RAD= IUS
       Author: &nbs= p;   A. DeKok
     =   Status:     Experimental
&n= bsp;      Stream:     IETF<= /span>
       Date:   = ;    September 2014
   &= nbsp;   Mailbox:    aland@freeradius.org
   &n= bsp;   Pages:      27
       Characters: 60007
       Updates/Obsoletes/SeeAlso: &nb= sp; None

    &nbs= p;  I-D Tag:    draft-ietf-radext-dtls-13.txt

       URL: &= nbsp;      https://www.rfc-editor.org/rfc/rfc7360.txt
The RADIUS protocol defined in RFC 2865 has limited s= upport for
authentication and encryption of RADIUS packets. &= nbsp;The protocol
transports data in the clear, although som= e parts of the packets can
have obfuscated content.  Pa= ckets may be replayed verbatim by an
attacker, and client-se= rver authentication is based on fixed shared
secrets.  = This document specifies how the Datagram Transport Layer
Sec= urity (DTLS) protocol may be used as a fix for these problems.  It
also describes how implementations of this proposal can coexist w= ith
current RADIUS systems.

This document is a product of the RADIUS EXTensions Working Group of the IE= TF.


EXPERIMENTAL: This mem= o defines an Experimental Protocol for the
Internet communit= y.  It does not specify an Internet standard of any
kin= d. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

Th= is announcement is sent to the IETF-Announce and rfc-dist lists.
<= span>To subscribe or unsubscribe, see
 https://www.ietf.org/mailma= n/listinfo/ietf-announce
 https://mailman.rfc-editor.org/= mailman/listinfo/rfc-dist

For searching= the RFC series, see https://w= ww.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.ht= ml

Requests for special distribution sh= ould be addressed to either the
author of the RFC in questio= n, 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


_______________________________________________
= radext mailing list
radex= t@ietf.org
https://www.ietf.org/mailman/listinfo/radext
= --Apple-Mail-F49FDE1E-A260-45AE-913D-B17CA03BC62F-- From nobody Fri Sep 5 01:59: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 528501A0487 for ; Fri, 5 Sep 2014 01:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 HV53S8Pr45Pa for ; Fri, 5 Sep 2014 01:59:23 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1C81A0478 for ; Fri, 5 Sep 2014 01:59:23 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id at20so890530iec.36 for ; Fri, 05 Sep 2014 01:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:thread-index:content-language; bh=SgYW8i5ndvB0+WlYD+lCNTAYtkR3qb4IWC9d58cfTU8=; b=Moi44XbO6uy2nMEhu1Dkn9Au74p/yjYwcbn6xBohEk0apBkx4kkB54T2mV11I1T8BI /UUlYJeX4MsG4b87H/QSMiPnPxEALsDPOoKk2Uhnvb8e7ge4MZOc6BY+hlVuQIHdgfEO wPKd6Jkiesn4NMroYwaYFFZBnxjLcHpT4wda6ULJ+2+/NECXcMG5GCXKsjY8TkOvwCm+ zGuwyJ6tEU17fYCy91vG/98GWBNsbKQWQHHKBZCxqO8DkSjeVd9woOzONLwSatIhAbDJ vLDLTUXQL6sFR12oTcIq8GqFTuaM6fMYD1siWsMEREq7ixghhVryJ0jblZuig8AOi05I 8ZmQ== X-Received: by 10.66.222.74 with SMTP id qk10mr19080374pac.70.1409907560790; Fri, 05 Sep 2014 01:59:20 -0700 (PDT) Received: from PC ([218.241.103.71]) by mx.google.com with ESMTPSA id gr5sm1223012pbc.33.2014.09.05.01.59.19 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 05 Sep 2014 01:59:20 -0700 (PDT) Message-ID: <54097b68.a5be440a.44af.4a98@mx.google.com> X-Google-Original-Message-ID: <001d01cfc8e7$82464e80$86d2eb80$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: References: <20140905002958.6EACE18047E@rfc-editor.org> <88842B92-D554-4ED5-AFA6-0871C2983006@gmail.com> In-Reply-To: <88842B92-D554-4ED5-AFA6-0871C2983006@gmail.com> Date: Fri, 5 Sep 2014 16:58:03 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01CFC92A.90698E80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/I5cvX5XriyltFRgy35LLDmpRYOAAAZo5w Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/radext/VQ1qbzkUWBUIMkBGk9HPXDDY8vo Subject: Re: [radext] Fwd: RFC 7360 on Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS 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, 05 Sep 2014 08:59:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001E_01CFC92A.90698E80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Congrats! =20 =20 +1 =20 =20 Best Regards, Leaf =20 =20 =20 From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Jouni Sent: Friday, September 05, 2014 4:45 PM To: radext@ietf.org Subject: [radext] Fwd: RFC 7360 on Datagram Transport Layer Security = (DTLS) as a Transport Layer for RADIUS =20 Congratulations to Alan and the WG for completing this RFC.=20 --=20 Jouni Korhonen Broadcom =20 (Sent from my mobile..) V=C3=A4litetty viesti: L=C3=A4hett=C3=A4j=C3=A4: rfc-editor@rfc-editor.org P=C3=A4iv=C3=A4ys: 5. syyskuuta 2014 3.29.58 UTC+3 Vastaanottaja: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Kopio: drafts-update-ref@iana.org, radext@ietf.org, = rfc-editor@rfc-editor.org Aihe: [radext] RFC 7360 on Datagram Transport Layer Security (DTLS) as a = Transport Layer for RADIUS A new Request for Comments is now available in online RFC libraries. RFC 7360 Title: Datagram Transport Layer Security (DTLS)=20 as a Transport Layer for RADIUS=20 Author: A. DeKok Status: Experimental Stream: IETF Date: September 2014 Mailbox: aland@freeradius.org Pages: 27 Characters: 60007 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-dtls-13.txt URL: https://www.rfc-editor.org/rfc/rfc7360.txt 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 coexist with current RADIUS systems. This document is a product of the RADIUS EXTensions Working Group of the = IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ------=_NextPart_000_001E_01CFC92A.90698E80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Congrats! =C2=A0

 

+1

 

 

Best Regards,

Leaf

 

 

 

From:= radext = [mailto:radext-bounces@ietf.org] On Behalf Of = Jouni
Sent: Friday, September 05, 2014 4:45 = PM
To: radext@ietf.org
Subject: [radext] Fwd: RFC = 7360 on Datagram Transport Layer Security (DTLS) as a Transport Layer = for RADIUS

 

Congratulations to = Alan and the WG for completing this = RFC. 

-- 

Jouni = Korhonen

Broadcom

 

(Sent from my = mobile..)


V=C3=A4litetty = viesti:

L=C3=A4hett=C3=A4j=C3=A4: rfc-editor@rfc-editor.orgP=C3=A4iv=C3=A4ys: 5. syyskuuta 2014 3.29.58 = UTC+3
Vastaanottaja: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Kopio: drafts-update-ref@iana.org= , radext@ietf.org, rfc-editor@rfc-editor.orgAihe: [radext] RFC 7360 on Datagram Transport Layer Security = (DTLS) as a Transport Layer for = RADIUS

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


       RFC = 7360

       Title: =      Datagram Transport Layer Security (DTLS) =
           &nb= sp;       as a Transport Layer for = RADIUS
       Author: =     A. = DeKok
       Status: =     Experimental
     &nb= sp; Stream: =     IETF
       = ;Date:       September = 2014
       Mailbox: =    aland@freeradius.org
 &n= bsp;     Pages: =      27
      &= nbsp;Characters: = 60007
       Updates/Obsoletes/SeeA= lso: =   None

       I-D = Tag: =    draft-ietf-radext-dtls-13.txt

   =     URL: =        https://www.rfc-edito= r.org/rfc/rfc7360.txt

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 coexist with
current RADIUS = systems.

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


EXPERIMENTAL: This memo defines an = Experimental Protocol for the
Internet community.  It does not = specify an Internet standard of any
kind. Discussion and suggestions = for improvement are requested.
Distribution of this memo is = unlimited.

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

For = searching the RFC series, see https://www.rfc-editor.org/sea= rch
For downloading RFCs, see https://www.rfc-editor.org/r= fc.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


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

------=_NextPart_000_001E_01CFC92A.90698E80-- From nobody Mon Sep 8 14:52:42 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 3C8051A03D9; Mon, 8 Sep 2014 14:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 HmDJ8HP9XwKh; Mon, 8 Sep 2014 14:52:33 -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 B4C8D1A02A5; Mon, 8 Sep 2014 14:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=172; q=dns/txt; s=iport; t=1410213153; x=1411422753; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=pPX8/N93gk/3Jo79kEAFhPZURk0uOGtnADpq0aEFuc8=; b=POElzzJOvjvXOJc3POLBDTQHeaUH3NCfqDIL8V7RG1TGO+7ELF8TZ0tQ S4drX6fJF4+vmW1QUHH7NUy5KVxRmmft9Jr584YWpPtUUh85WZQDW4DDW zudqOObXUiVUpgrO6DHVbCnINZQWZJqc942BGnGA01geXMtWx5l7KK4Iy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskIABskDlStJssW/2dsb2JhbABZg2COGLxAiHx4hEJAPRYYAwIBAgFLAQwIAQGIPg29PAETBJQgAQSccodBjWuDYzuCfgEBAQ X-IronPort-AV: E=Sophos;i="5.04,488,1406592000"; d="scan'208";a="166333889" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 08 Sep 2014 21:52:31 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s88LqU4S003249; Mon, 8 Sep 2014 21:52:30 GMT Message-ID: <540E251E.2050206@cisco.com> Date: Mon, 08 Sep 2014 23:52:30 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: dime mailing list , "radext@ietf.org" , "aaa-doctors@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/0khJ8iTvD3ePDY1keTmSE1qU1H0 Subject: [radext] AAA tutorial posted 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, 08 Sep 2014 21:52:35 -0000 Dear all, I (finally) posted the IETF 89 AAA tutorial. https://www.youtube.com/watch?v=7yMwP1D3Um4 The link is also on both DIME and RADEXT WIKIs. Regards, Benoit From nobody Tue Sep 9 01:04: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 13F831A0BEB; Tue, 9 Sep 2014 01:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 Fr2b28zxmRjL; Tue, 9 Sep 2014 01:04:07 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2671A0B7D; Tue, 9 Sep 2014 01:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=288; q=dns/txt; s=iport; t=1410249847; x=1411459447; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1SsgyAEr2fYHihgawLT8enTEQGXHAO4aiGk38cKXt3Y=; b=ZAkq9fv6djeUfEvcJ0Q6/5GcRQtPvWVs7YpbtMscwcxn0NHh8j/heFYI 7V3gf20XLXtZ0FFaieqLJIDAzf3INycBVlGTxfVb8mPSlg3/Z0wg12VEr +2XDihlnroHCfQ8GXqC4kKtllFrNJ8oPdd5vpfmynxmXrKW3ST4KyQIBp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHAEC0DlStJssW/2dsb2JhbABZg2COGLxRh0wBgSl4hAQBAQQ4UQshJQ8CRgYBDAgBAYg+DbxMARMEj1SETAEEnHOHQY1tg2M7gn4BAQE X-IronPort-AV: E=Sophos;i="5.04,491,1406592000"; d="scan'208";a="171501614" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Sep 2014 08:04:03 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s89843iH017674; Tue, 9 Sep 2014 08:04:03 GMT Message-ID: <540EB473.20302@cisco.com> Date: Tue, 09 Sep 2014 10:04:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: dime mailing list , "radext@ietf.org" , "aaa-doctors@ietf.org" References: <540E251E.2050206@cisco.com> In-Reply-To: <540E251E.2050206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/DdTKP__qO72fajYi7iqI30AAYDM Subject: Re: [radext] AAA tutorial posted 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, 09 Sep 2014 08:04:09 -0000 Dear all, I didn't realize that this video was posted as private. Now corrected. Regards, Benoit > Dear all, > > I (finally) posted the IETF 89 AAA tutorial. > https://www.youtube.com/watch?v=7yMwP1D3Um4 > The link is also on both DIME and RADEXT WIKIs. > > Regards, Benoit From nobody Mon Sep 15 14:41:55 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 A8C1D1A8784 for ; Mon, 15 Sep 2014 14:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.245 X-Spam-Level: *** X-Spam-Status: No, score=3.245 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lIiHS_87DoF for ; Mon, 15 Sep 2014 14:41:52 -0700 (PDT) Received: from power.freeradius.org (195-154-231-44.rev.poneytelecom.eu [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 125141A8783 for ; Mon, 15 Sep 2014 14:41:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CF11C22403D6 for ; Mon, 15 Sep 2014 23:41:43 +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 1l9XuiM4UWFH for ; Mon, 15 Sep 2014 23:41:43 +0200 (CEST) Received: from Thor.local (unknown [70.50.218.244]) by power.freeradius.org (Postfix) with ESMTPSA id 370E322400D0 for ; Mon, 15 Sep 2014 23:41:43 +0200 (CEST) Message-ID: <54175D15.1030807@deployingradius.com> Date: Mon, 15 Sep 2014 17:41:41 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" 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/k9m5V6UnYsxJAmz8xfC0z2AOIg8 Subject: [radext] Data types document 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, 15 Sep 2014 21:41:53 -0000 I've submitted an updated version of the Data types document: http://tools.ietf.org/html/draft-dekok-radext-datatypes-05 The main difference is the addition of a CSV table for updating the IANA RADIUS Attribute Type registry. The goal is to allow IANA to simply replace the existing table with the updated one. I've reviewed the updates, but they may contain an element of personal choice. In some cases, the attributes are clearly labeled "UTF-8 text". In others, it's less clear what the "correct" type should be. Some questions: 1) are the types correct? 2) The document has an "enum" data type. It's really "integer', but with enumerated values. Is this OK? 3) Some standard attributes should be automatically concatenated, e.g. EAP-Message, PKM-SS-Cert, and PKM-CA-Cert Should these be a separate data type, to highlight the fact that they're special? If we can get consensus quickly, I think the document should be publishable very soon. Alan DeKok. From nobody Mon Sep 15 14:43:43 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 BFFAF1A8783 for ; Mon, 15 Sep 2014 14:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-1.652] 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 hMyTECZiu9vD for ; Mon, 15 Sep 2014 14:43:41 -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 F2CB11A878D for ; Mon, 15 Sep 2014 14:43:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id CFE6A20208; Mon, 15 Sep 2014 17:42:38 -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 14A8kz2sTpzd; Mon, 15 Sep 2014 17:42:37 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-65-96-233-203.hsd1.ma.comcast.net [65.96.233.203]) (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, 15 Sep 2014 17:42:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D04EF89B3D; Mon, 15 Sep 2014 17:43:37 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <54175D15.1030807@deployingradius.com> Date: Mon, 15 Sep 2014 17:43:37 -0400 In-Reply-To: <54175D15.1030807@deployingradius.com> (Alan DeKok's message of "Mon, 15 Sep 2014 17:41:41 -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/97rWxpMU9zivDBKsimCIfORRS-o Cc: "radext@ietf.org" Subject: Re: [radext] Data types document 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, 15 Sep 2014 21:43:42 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> 2) The document has an "enum" data type. It's really Alan> "integer', but with enumerated values. Alan> Is this OK? Yes. Alan> 3) Some standard attributes should be automatically Alan> concatenated, e.g. EAP-Message, PKM-SS-Cert, and PKM-CA-Cert Alan> Should these be a separate data type, to highlight the fact Alan> that they're special? I think a special data type for this would be valuable. It would be helpful to implementations and to standards writers both. From nobody Sun Sep 21 23:31: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 478CA1A1A33 for ; Sun, 21 Sep 2014 23:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.586 X-Spam-Level: X-Spam-Status: No, score=-12.586 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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.786, 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 72PpmAlcXUrk for ; Sun, 21 Sep 2014 23:31:13 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29A31A1A43 for ; Sun, 21 Sep 2014 23:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6298; q=dns/txt; s=iport; t=1411367473; x=1412577073; h=from:to:subject:date:message-id:mime-version; bh=DB/FYUiD0CwJ1mi4UxxwRr9k6UVCfv0w8D4RuugL9ho=; b=GSoPTGPW2JpUUDInjTYOIV1OqBdpY+lrBE9oNeuawRmxRhqBe20W2UeQ eYbHTCPrQVrBctGbY7c/JRBJQrZJO9ZQHgVxMB723i/UOn3Ws8GkOd4hS x7Wsj/cbGpOEMBzizhNwC40NRfuGX6dFiprVhj9BZsfRfhpYyvC18v2dV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEGAETBH1StJA2D/2dsb2JhbABggkhGgS7TAxYBcQiECoELAYEAJwSIUZ5CpRMYlFgFkVeLP5VSgh6BQ4I0gQIBAQE X-IronPort-AV: E=Sophos; i="5.04,570,1406592000"; d="scan'208,217"; a="79999095" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP; 22 Sep 2014 06:31:12 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8M6VBEi026566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Sep 2014 06:31:11 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 01:31:11 -0500 From: "Satyanarayana Danda (sdanda)" To: "radext@ietf.org" Thread-Topic: Decoupling Authentication/Authorization with Accounting - Server side functionality Thread-Index: AQHP1i7MByc6PN4k/k6kogVoHpnecQ== Date: Mon, 22 Sep 2014 06:31:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.142.110.105] Content-Type: multipart/alternative; boundary="_000_D045C0001B2F7sdandaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/KFfebWSpKi9YHvhtRDN_G608CWw Subject: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality 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, 22 Sep 2014 06:31:15 -0000 --_000_D045C0001B2F7sdandaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Friends, Have been observing and facing challenges with a few Radius Servers on the= following aspect explained as follows. >From protocol stand point, we don=92t seem to have any standard behaviour a= nd hence Thought of checking with global audience on your valuable inputs and furthe= r steps to take this forward. Problem: Some of the Radius Servers doesn=92t seem to be allowing receiving of Accou= nting requests >From BRAS/NAS/BNG in case the respective Subscriber/User is not authenticat= ed/Authorised before when he was given network access. This restriction is making a few deployments to face challenges from BRAS/N= AS/BNG side. To mention a few known use-cases Use-Case 1: Most of the BRAS/NAS/BNG devices would support LOCAL Authentication/Authori= sation where the respective User/Subscriber gets Authenticated/Authorised locally. But due to space constraints or persisten= t restrictions, BRAS/NAS/BNG device would be using Radius protocol for Acco= unting. With the restriction/issue as outlined above, the Radius Server seems to be= dropping/ignoring the Accounting request. Use-Case 2: Another use-case is that, with the BRAS/NAS/BNG User/Subscriber redundancy = (e.g geo-redundancy) where the Subscriber/User session gets moved to different BRAS/NAS/BNG time to time. The Subscriber/User gets Auth= enticated/Authorised once with the Radius Server and the change of Subscrib= er's Current attachment point (BRAS/NAS/BNG) information would get exchanged tim= e to time by exchanging either Accounting START or Accounting INTERIM recor= ds with the Radius Server. In this case, the User/Subscriber was not Authenticated/Authorised = from the new BRAS/NAS/BNG device and hence respective Accounting records ge= t dropped. Having said that, we might have a few use-cases which I may not aware of, b= ut due to the restriction as mentioned might see same challenges. IMO, we should be looking at some means of standardising the behaviour at l= east as a an informational thing. Please let me know your comments/feedback to take this further. Thanks Satya --_000_D045C0001B2F7sdandaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3A049C30F2091F469507DCC89EE9BB51@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Friends,

Have been observing and facing challenges w= ith  a few Radius Servers on the following aspect explained as follows= . 
From protocol stand point, we don=92t seem = to have any standard behaviour and hence
Thought of checking with global audience on= your valuable inputs and further steps to take this forward.

Problem:

Some of the Radius Servers doesn=92t seem t= o be allowing receiving of Accounting requests
From BRAS/NAS/BNG in case the respective Su= bscriber/User is not authenticated/Authorised before when he was given netw= ork access.
This restriction is making a few deployment= s to face challenges from BRAS/NAS/BNG side. To mention a few known use-cas= es

Use-Case 1:

Most of the BRAS/NAS/BNG devices would supp= ort LOCAL Authentication/Authorisation where the respective User/Subscriber= gets
Authenticated/Authorised locally. But due t= o space constraints or persistent restrictions, BRAS/NAS/BNG device would b= e using Radius protocol for Accounting.
With the restriction/issue as outlined abov= e, the Radius Server seems to be dropping/ignoring the Accounting request.<= /div>

Use-Case 2:

Another use-case is that, with the BRAS/NAS= /BNG User/Subscriber redundancy (e.g geo-redundancy)  where the Subscr= iber/User session gets 
moved to different BRAS/NAS/BNG time to tim= e. The Subscriber/User gets Authenticated/Authorised once with the Radius S= erver and the change of Subscriber's
Current attachment point (BRAS/NAS/BNG) inf= ormation would get exchanged time to time by exchanging either Accounting S= TART or Accounting INTERIM records with the Radius
Server. In this case, the User/Subscriber w= as not Authenticated/Authorised from the new BRAS/NAS/BNG device and hence = respective Accounting records get dropped.

Having said that, we might have a few use-c= ases which I may not aware of, but due to the restriction as mentioned migh= t see same challenges.
IMO, we should be looking at some means of = standardising the behaviour at least as a an informational thing.

Please let me know your comments/feedback t= o take this further.

Thanks
Satya
--_000_D045C0001B2F7sdandaciscocom_-- From nobody Mon Sep 22 05:43: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 B18751A1AB8 for ; Mon, 22 Sep 2014 05:43:35 -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 tvwm7grbmpeE for ; Mon, 22 Sep 2014 05:43:33 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1AC1A1AB6 for ; Mon, 22 Sep 2014 05:43:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D041322407D8; Mon, 22 Sep 2014 14:43:31 +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 qT706P0nkHt1; Mon, 22 Sep 2014 14:43:31 +0200 (CEST) Received: from Thor.local (unknown [70.50.218.244]) by power.freeradius.org (Postfix) with ESMTPSA id 3B77222402FA; Mon, 22 Sep 2014 14:43:31 +0200 (CEST) Message-ID: <54201972.7050403@deployingradius.com> Date: Mon, 22 Sep 2014 08:43:30 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Satyanarayana Danda (sdanda)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/JAIODyVhLB29VSnp7YCR8xg_4nU Cc: "radext@ietf.org" Subject: Re: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality 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, 22 Sep 2014 12:43:35 -0000 Satyanarayana Danda (sdanda) wrote: > Some of the Radius Servers doesn’t seem to be allowing receiving of > Accounting requests > From BRAS/NAS/BNG in case the respective Subscriber/User is not > authenticated/Authorised before when he was given network access. > This restriction is making a few deployments to face challenges from This is technically within the standards. Only because the standards are silent on a *lot* of behavior. They assume that people implementing RADIUS are reasonable. > *Use-Case 1:* > > Most of the BRAS/NAS/BNG devices would support LOCAL > Authentication/Authorisation where the respective User/Subscriber gets > Authenticated/Authorised locally. But due to space constraints or > persistent restrictions, BRAS/NAS/BNG device would be using Radius > protocol for Accounting. > With the restriction/issue as outlined above, the Radius Server seems to > be dropping/ignoring the Accounting request. The only reason (IMHO) to drop Accounting-Request packets is when the server is *unable* to store packets locally. i.e. the server normally logs packets, but suddenly the disk is full, or the database is down, etc. So the server can't log accounting packets, and starts to ignore them. Ignoring packets in other situations is bad. > *Use-Case 2:* > > Another use-case is that, with the BRAS/NAS/BNG User/Subscriber > redundancy (e.g geo-redundancy) where the Subscriber/User session gets > moved to different BRAS/NAS/BNG time to time. The Subscriber/User gets > Authenticated/Authorised once with the Radius Server and the change of > Subscriber's > Current attachment point (BRAS/NAS/BNG) information would get exchanged > time to time by exchanging either Accounting START or Accounting INTERIM > records with the Radius > Server. In this case, the User/Subscriber was not > Authenticated/Authorised from the new BRAS/NAS/BNG device and hence > respective Accounting records get dropped. Which is exactly why the server should NOT drop accounting packets. I see the above scenario all of the time. Packets go to the wrong server, go missing, fail-over happens, etc. It is the responsibility of the RADIUS ecosystem (DB, etc.) to process all of the accounting data. This may mean post-processing, to merge records. It may mean discarding DB records for users which don't exist. etc. > Having said that, we might have a few use-cases which I may not aware > of, but due to the restriction as mentioned might see same challenges. > IMO, we should be looking at some means of standardising the behaviour > at least as a an informational thing. I can't think of any "normal operation" scenario where a server should drop accounting packets. That's just weird. So far as fixing RADIUS goes, I would put recommendations into an "implementation and deployment" guide. It should be informational, but could talk about "best practices" for operating a RADIUS server. If this is the only issue, the document would be small. It would be good to get a larger list of operational issues, too. Alan DeKok. From nobody Tue Sep 23 16:22: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 E409B1A897F; Tue, 23 Sep 2014 16:21:53 -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 T3IEViiZm1da; Tue, 23 Sep 2014 16:21:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB651A6F20; Tue, 23 Sep 2014 16:21:50 -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.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923232150.1601.20067.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 16:21:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/r4dAg-vHyAy9qIgi542_x3cVRyI Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-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: Tue, 23 Sep 2014 23:21:54 -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 : The Network Access Identifier Author : Alan DeKok Filename : draft-ietf-radext-nai-07.txt Pages : 25 Date : 2014-09-23 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-nai-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-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 Tue Sep 23 17:31:30 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 103761A6F3E for ; Tue, 23 Sep 2014 17:31:27 -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 pFG8mZdsHozM for ; Tue, 23 Sep 2014 17:31:25 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id E30A61A8963 for ; Tue, 23 Sep 2014 17:31:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id EA53622402FA for ; Wed, 24 Sep 2014 02:31:23 +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 rnJOwiAZsyit for ; Wed, 24 Sep 2014 02:31:23 +0200 (CEST) Received: from Thor.local (bas1-ottawa11-1176223843.dsl.bell.ca [70.27.192.99]) by power.freeradius.org (Postfix) with ESMTPSA id D252222401F0 for ; Wed, 24 Sep 2014 02:31:22 +0200 (CEST) Message-ID: <542210D8.10900@deployingradius.com> Date: Tue, 23 Sep 2014 20:31:20 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: radext@ietf.org References: <20140923232150.1601.20067.idtracker@ietfa.amsl.com> In-Reply-To: <20140923232150.1601.20067.idtracker@ietfa.amsl.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/U9U-Say7Zp2XCk1h1gYGYqwxo1g Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-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: Wed, 24 Sep 2014 00:31:27 -0000 I believe this revision addresses all open concerns. Maybe we could do a last call before the next meeting? internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : The Network Access Identifier > Author : Alan DeKok > Filename : draft-ietf-radext-nai-07.txt > Pages : 25 > Date : 2014-09-23 > > Abstract: > In order to provide inter-domain authentication services, it is > necessary to have a standardized method that domains can use to > identify each other's users. This document defines the syntax for > the Network Access Identifier (NAI), the user identity submitted by > the client prior to accessing network resources. This document is a > revised version of RFC 4282, which addresses issues with > international character sets, as well as a number of other > corrections to the previous document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-nai-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-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 Tue Sep 23 22:07: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 95BCD1A8A80 for ; Tue, 23 Sep 2014 22:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 0Yo5VUqInjUn for ; Tue, 23 Sep 2014 22:07:12 -0700 (PDT) Received: from BLU004-OMC2S9.hotmail.com (blu004-omc2s9.hotmail.com [65.55.111.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352A91A8A82 for ; Tue, 23 Sep 2014 22:07:12 -0700 (PDT) Received: from BLU181-W71 ([65.55.111.73]) by BLU004-OMC2S9.hotmail.com with Microsoft SMTPSVC(7.5.7601.22724); Tue, 23 Sep 2014 22:07:11 -0700 X-TMN: [w4Zp/ETaehq1AC22FRN58UX1Sky9bjBZ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_3381e883-e096-48ab-b1c1-b0d5cf8ab535_" From: Bernard Aboba To: Alan DeKok , "radext@ietf.org" Date: Tue, 23 Sep 2014 22:07:10 -0700 Importance: Normal In-Reply-To: <542210D8.10900@deployingradius.com> References: <20140923232150.1601.20067.idtracker@ietfa.amsl.com>, <542210D8.10900@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Sep 2014 05:07:11.0482 (UTC) FILETIME=[65D935A0:01CFD7B5] Archived-At: http://mailarchive.ietf.org/arch/msg/radext/2I9EV9DQf5gCQoQraYJnezvi02Y Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-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: Wed, 24 Sep 2014 05:07:14 -0000 --_3381e883-e096-48ab-b1c1-b0d5cf8ab535_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would not say that the revision addresses all concerns. Some of the adv= ice is quite brittle:=20 For example=2C much of the common realm routing can be done on the=0A= "utf8-realm" portion of NAI=2C through simple checks for equality.=0A= This routing can be done even if the AAA proxy is unaware of=0A= internalized domain names. All that is required is for the AAA proxy=0A= to be able to enter=2C store=2C and compare 8-bit data. Realm routing based on 8-bit data comparisons has never worked reliably=2C = since it fails even with latin character sets given inconsistent capitaliza= tion=2C let alone when international character sets are used. Given that n= ormalization on the end system is not common today=2C blessing 8-bit compar= isons for realm routing is a bad idea - since if followed it would be likel= y to result in continuing problems with routing of internationalized realms= .=20 In this particular case=2C there are more reliable ways to do the compariso= n that should be discussed.=20 > Date: Tue=2C 23 Sep 2014 20:31:20 -0400 > From: aland@deployingradius.com > To: radext@ietf.org > Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-07.txt >=20 > I believe this revision addresses all open concerns. Maybe we could > do a last call before the next meeting? >=20 > internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. > >=20 > > Title : The Network Access Identifier > > Author : Alan DeKok > > Filename : draft-ietf-radext-nai-07.txt > > Pages : 25 > > Date : 2014-09-23 > >=20 > > Abstract: > > In order to provide inter-domain authentication services=2C it is > > necessary to have a standardized method that domains can use to > > identify each other's users. This document defines the syntax for > > the Network Access Identifier (NAI)=2C the user identity submitted b= y > > the client prior to accessing network resources. This document is a > > revised version of RFC 4282=2C which addresses issues with > > international character sets=2C as well as a number of other > > corrections to the previous document. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > >=20 > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-radext-nai-07 > >=20 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-07 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_3381e883-e096-48ab-b1c1-b0d5cf8ab535_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would not say that the revisio= n addresses all concerns.  =3B Some of the advice is quite brittle:&nbs= p=3B

   Fo=
r example=2C much of the common realm routing can be done on the=0A=
   "utf8-realm" portion of NAI=2C through simple checks for equality.=0A=
   This routing can be done even if the AAA proxy is unaware of=0A=
   internalized domain names.  All that is required is for the AAA proxy=0A=
   to be able to enter=2C store=2C and compare 8-bit data.

Realm routing based on 8-bit data comparisons has= never worked reliably=2C since it fails even with latin character sets giv= en inconsistent capitalization=2C let alone when international character se= ts are used.  =3BGiven that normalization on the end system is not comm= on today=2C blessing 8-bit comparisons for realm routing is a bad idea - si= nce if followed it would be =3Blikely to result in continuing problems = with routing of internationalized realms. =3B

In this particular case=2C = there are more reliable ways to do the comparison that should be discussed.=  =3B


>=3B Date: Tue=2C 2= 3 Sep 2014 20:31:20 -0400
>=3B From: aland@deployingradius.com
>= =3B To: radext@ietf.org
>=3B Subject: Re: [radext] I-D Action: draft-i= etf-radext-nai-07.txt
>=3B
>=3B I believe this revision addres= ses all open concerns. Maybe we could
>=3B do a last call before the = next meeting?
>=3B
>=3B internet-drafts@ietf.org wrote:
>= =3B >=3B A New Internet-Draft is available from the on-line Internet-Draf= ts directories.
>=3B >=3B This draft is a work item of the RADIUS E= XTensions Working Group of the IETF.
>=3B >=3B
>=3B >=3B = Title : The Network Access Identifier
>=3B >=3B = Author : Alan DeKok
>=3B >=3B Filename : draft-i= etf-radext-nai-07.txt
>=3B >=3B Pages : 25
>=3B >= =3B Date : 2014-09-23
>=3B >=3B
>=3B >=3B Abstra= ct:
>=3B >=3B In order to provide inter-domain authentication ser= vices=2C it is
>=3B >=3B necessary to have a standardized method = that domains can use to
>=3B >=3B identify each other's users. T= his document defines the syntax for
>=3B >=3B the Network Access = Identifier (NAI)=2C the user identity submitted by
>=3B >=3B the = client prior to accessing network resources. This document is a
>=3B &= gt=3B revised version of RFC 4282=2C which addresses issues with
>= =3B >=3B international character sets=2C as well as a number of other<= br>>=3B >=3B corrections to the previous document.
>=3B >=3B =
>=3B >=3B
>=3B >=3B The IETF datatracker status page for th= is draft is:
>=3B >=3B https://datatracker.ietf.org/doc/draft-ietf-r= adext-nai/
>=3B >=3B
>=3B >=3B There's also a htmlized versi= on available at:
>=3B >=3B http://tools.ietf.org/html/draft-ietf-rad= ext-nai-07
>=3B >=3B
>=3B >=3B A diff from the previous vers= ion is available at:
>=3B >=3B http://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-radext-nai-07
>=3B >=3B
>=3B >=3B
>=3B >=3B= Please note that it may take a couple of minutes from the time of submissi= on
>=3B >=3B until the htmlized version and diff are available at to= ols.ietf.org.
>=3B >=3B
>=3B >=3B Internet-Drafts are also a= vailable by anonymous FTP at:
>=3B >=3B ftp://ftp.ietf.org/internet-= drafts/
>=3B >=3B
>=3B >=3B ________________________________= _______________
>=3B >=3B radext mailing list
>=3B >=3B radex= t@ietf.org
>=3B >=3B https://www.ietf.org/mailman/listinfo/radext>=3B
>=3B _______________________________________________
>= =3B radext mailing list
>=3B radext@ietf.org
>=3B https://www.iet= f.org/mailman/listinfo/radext
=
= --_3381e883-e096-48ab-b1c1-b0d5cf8ab535_-- From nobody Tue Sep 23 22:21: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 145F41A8A93 for ; Tue, 23 Sep 2014 22:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 y9Sap8QYK5LW for ; Tue, 23 Sep 2014 22:21:53 -0700 (PDT) Received: from BLU004-OMC2S28.hotmail.com (blu004-omc2s28.hotmail.com [65.55.111.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E509C1A8A8A for ; Tue, 23 Sep 2014 22:21:52 -0700 (PDT) Received: from BLU181-W49 ([65.55.111.73]) by BLU004-OMC2S28.hotmail.com with Microsoft SMTPSVC(7.5.7601.22724); Tue, 23 Sep 2014 22:21:51 -0700 X-TMN: [8eRvHJ368Tq6pwTfEJvscyb8a9J9MVdK] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_42774d64-b6a4-4ac8-800e-ff731a0e6535_" From: Bernard Aboba To: Alan DeKok , "radext@ietf.org" Date: Tue, 23 Sep 2014 22:21:51 -0700 Importance: Normal In-Reply-To: References: <20140923232150.1601.20067.idtracker@ietfa.amsl.com>, , <542210D8.10900@deployingradius.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 24 Sep 2014 05:21:51.0840 (UTC) FILETIME=[72952E00:01CFD7B7] Archived-At: http://mailarchive.ietf.org/arch/msg/radext/lxH4Zto7csrmc7QDq8qR8r0jciw Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-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: Wed, 24 Sep 2014 05:21:55 -0000 --_42774d64-b6a4-4ac8-800e-ff731a0e6535_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BTW=2C I realize that there is better advise elsewhere in the draft... but = given that=2C the paragraph below really is superfluous.=20 From: bernard_aboba@hotmail.com To: aland@deployingradius.com=3B radext@ietf.org Date: Tue=2C 23 Sep 2014 22:07:10 -0700 Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-07.txt =0A= =0A= =0A= I would not say that the revision addresses all concerns. Some of the adv= ice is quite brittle:=20 For example=2C much of the common realm routing can be done on the=0A= "utf8-realm" portion of NAI=2C through simple checks for equality.=0A= This routing can be done even if the AAA proxy is unaware of=0A= internalized domain names. All that is required is for the AAA proxy=0A= to be able to enter=2C store=2C and compare 8-bit data. Realm routing based on 8-bit data comparisons has never worked reliably=2C = since it fails even with latin character sets given inconsistent capitaliza= tion=2C let alone when international character sets are used. Given that n= ormalization on the end system is not common today=2C blessing 8-bit compar= isons for realm routing is a bad idea - since if followed it would be likel= y to result in continuing problems with routing of internationalized realms= .=20 In this particular case=2C there are more reliable ways to do the compariso= n that should be discussed.=20 > Date: Tue=2C 23 Sep 2014 20:31:20 -0400 > From: aland@deployingradius.com > To: radext@ietf.org > Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-07.txt >=20 > I believe this revision addresses all open concerns. Maybe we could > do a last call before the next meeting? >=20 > internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. > >=20 > > Title : The Network Access Identifier > > Author : Alan DeKok > > Filename : draft-ietf-radext-nai-07.txt > > Pages : 25 > > Date : 2014-09-23 > >=20 > > Abstract: > > In order to provide inter-domain authentication services=2C it is > > necessary to have a standardized method that domains can use to > > identify each other's users. This document defines the syntax for > > the Network Access Identifier (NAI)=2C the user identity submitted b= y > > the client prior to accessing network resources. This document is a > > revised version of RFC 4282=2C which addresses issues with > > international character sets=2C as well as a number of other > > corrections to the previous document. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > >=20 > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-radext-nai-07 > >=20 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-07 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext =0A= _______________________________________________=0A= radext mailing list=0A= radext@ietf.org=0A= https://www.ietf.org/mailman/listinfo/radext = --_42774d64-b6a4-4ac8-800e-ff731a0e6535_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
BTW=2C I realize that there is b= etter advise elsewhere in the draft... but given that=2C the paragraph belo= w really is superfluous. =3B

From: = bernard_aboba@hotmail.com
To: aland@deployingradius.com=3B radext@ietf.o= rg
Date: Tue=2C 23 Sep 2014 22:07:10 -0700
Subject: Re: [radext] I-D = Action: draft-ietf-radext-nai-07.txt

=0A= =0A= =0A=
I would not say that the revision addresses all concerns. =  =3B Some of the advice is quite brittle: =3B

For example=2C much of the common realm routing can be done on the= =0A= "utf8-realm" portion of NAI=2C through simple checks for equality.=0A= This routing can be done even if the AAA proxy is unaware of=0A= internalized domain names. All that is required is for the AAA proxy=0A= to be able to enter=2C store=2C and compare 8-bit data.

Realm routing based on 8-bit data comparisons has= never worked reliably=2C since it fails even with latin character sets giv= en inconsistent capitalization=2C let alone when international character se= ts are used.  =3BGiven that normalization on the end system is not comm= on today=2C blessing 8-bit comparisons for realm routing is a bad idea - si= nce if followed it would be =3Blikely to result in continuing problems = with routing of internationalized realms. =3B

In this particular case=2C = there are more reliable ways to do the comparison that should be discussed.=  =3B


>=3B Date: Tue=2C 2= 3 Sep 2014 20:31:20 -0400
>=3B From: aland@deployingradius.com
>= =3B To: radext@ietf.org
>=3B Subject: Re: [radext] I-D Action: draft-i= etf-radext-nai-07.txt
>=3B
>=3B I believe this revision addres= ses all open concerns. Maybe we could
>=3B do a last call before the = next meeting?
>=3B
>=3B internet-drafts@ietf.org wrote:
>= =3B >=3B A New Internet-Draft is available from the on-line Internet-Draf= ts directories.
>=3B >=3B This draft is a work item of the RADIUS E= XTensions Working Group of the IETF.
>=3B >=3B
>=3B >=3B = Title : The Network Access Identifier
>=3B >=3B = Author : Alan DeKok
>=3B >=3B Filename : draft-i= etf-radext-nai-07.txt
>=3B >=3B Pages : 25
>=3B >= =3B Date : 2014-09-23
>=3B >=3B
>=3B >=3B Abstra= ct:
>=3B >=3B In order to provide inter-domain authentication ser= vices=2C it is
>=3B >=3B necessary to have a standardized method = that domains can use to
>=3B >=3B identify each other's users. T= his document defines the syntax for
>=3B >=3B the Network Access = Identifier (NAI)=2C the user identity submitted by
>=3B >=3B the = client prior to accessing network resources. This document is a
>=3B &= gt=3B revised version of RFC 4282=2C which addresses issues with
>= =3B >=3B international character sets=2C as well as a number of other<= br>>=3B >=3B corrections to the previous document.
>=3B >=3B =
>=3B >=3B
>=3B >=3B The IETF datatracker status page for th= is draft is:
>=3B >=3B https://datatracker.ietf.org/doc/draft-ietf-r= adext-nai/
>=3B >=3B
>=3B >=3B There's also a htmlized versi= on available at:
>=3B >=3B http://tools.ietf.org/html/draft-ietf-rad= ext-nai-07
>=3B >=3B
>=3B >=3B A diff from the previous vers= ion is available at:
>=3B >=3B http://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-radext-nai-07
>=3B >=3B
>=3B >=3B
>=3B >=3B= Please note that it may take a couple of minutes from the time of submissi= on
>=3B >=3B until the htmlized version and diff are available at to= ols.ietf.org.
>=3B >=3B
>=3B >=3B Internet-Drafts are also a= vailable by anonymous FTP at:
>=3B >=3B ftp://ftp.ietf.org/internet-= drafts/
>=3B >=3B
>=3B >=3B ________________________________= _______________
>=3B >=3B radext mailing list
>=3B >=3B radex= t@ietf.org
>=3B >=3B https://www.ietf.org/mailman/listinfo/radext>=3B
>=3B _______________________________________________
>= =3B radext mailing list
>=3B radext@ietf.org
>=3B https://www.iet= f.org/mailman/listinfo/radext
=
=0A=
_______________________________________________=0A= radext mailing list=0A= radext@ietf.org=0A= https://www.ietf.org/mailman/listinfo/radext
= --_42774d64-b6a4-4ac8-800e-ff731a0e6535_-- From nobody Tue Sep 23 23:59:46 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 7E5CE1A70FD for ; Tue, 23 Sep 2014 23:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 DEk6ATt8gu5K for ; Tue, 23 Sep 2014 23:59:42 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B033D1A1ACD for ; Tue, 23 Sep 2014 23:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3670; q=dns/txt; s=iport; t=1411541982; x=1412751582; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MR1dwMs2af8YzYBKcn2BqtSG6Y/TFT5VGcs81vcnhl8=; b=nHLDj0JawDMcekn7L29O5KK6eV/qiiA+7fZHYMNBsuLHA+YdCknvfCFw uLuDkSgWEmKY6FSYNYQ2FDaqVzxFHeAsNX4TuUDJBysd9Tmn4e0wjj48a NYcG6bcydB54sEo/jNs+04UmUr44865dqyv2Hm8o8q3vr8yuJHokq2flq s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAIBrIlStJV2c/2dsb2JhbABggw6BKgTSDwGBBBYBeoQEAQEEeRACAQgYLjIlAgQOBYg+wmEBF5AeB4RLAQSLDIZPi0KVVIIfgUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,587,1406592000"; d="scan'208";a="80672727" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 24 Sep 2014 06:59:41 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8O6xf1P025562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 06:59:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 01:59:41 -0500 From: "Satyanarayana Danda (sdanda)" To: Alan DeKok Thread-Topic: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality Thread-Index: AQHP1i7MByc6PN4k/k6kogVoHpnecZwNbRMAgAMgygA= Date: Wed, 24 Sep 2014 06:59:40 +0000 Message-ID: References: <54201972.7050403@deployingradius.com> In-Reply-To: <54201972.7050403@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.142.110.105] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/AOtdskzLM-9xKY7czTJAk7L9A7E Cc: "radext@ietf.org" Subject: Re: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality 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, 24 Sep 2014 06:59:44 -0000 Thanks a lot Alan for your response! On 22/09/14 6:13 pm, "Alan DeKok" wrote: >Satyanarayana Danda (sdanda) wrote: >> Some of the Radius Servers doesn=B9t seem to be allowing receiving of >> Accounting requests >> From BRAS/NAS/BNG in case the respective Subscriber/User is not >> authenticated/Authorised before when he was given network access. >> This restriction is making a few deployments to face challenges from > > This is technically within the standards. Only because the standards >are silent on a *lot* of behavior. They assume that people implementing >RADIUS are reasonable. > >> *Use-Case 1:* >>=20 >> Most of the BRAS/NAS/BNG devices would support LOCAL >> Authentication/Authorisation where the respective User/Subscriber gets >> Authenticated/Authorised locally. But due to space constraints or >> persistent restrictions, BRAS/NAS/BNG device would be using Radius >> protocol for Accounting. >> With the restriction/issue as outlined above, the Radius Server seems to >> be dropping/ignoring the Accounting request. > > The only reason (IMHO) to drop Accounting-Request packets is when the >server is *unable* to store packets locally. i.e. the server normally >logs packets, but suddenly the disk is full, or the database is down, >etc. So the server can't log accounting packets, and starts to ignore >them. > > Ignoring packets in other situations is bad. That case is understandable, but we can able to see the server is not accepting with the simple reason is that, Authentication/Authorization was not done with that. This is wired as you mentioned. > >> *Use-Case 2:* >>=20 >> Another use-case is that, with the BRAS/NAS/BNG User/Subscriber >> redundancy (e.g geo-redundancy) where the Subscriber/User session gets >> moved to different BRAS/NAS/BNG time to time. The Subscriber/User gets >> Authenticated/Authorised once with the Radius Server and the change of >> Subscriber's >> Current attachment point (BRAS/NAS/BNG) information would get exchanged >> time to time by exchanging either Accounting START or Accounting INTERIM >> records with the Radius >> Server. In this case, the User/Subscriber was not >> Authenticated/Authorised from the new BRAS/NAS/BNG device and hence >> respective Accounting records get dropped. > > Which is exactly why the server should NOT drop accounting packets. > > I see the above scenario all of the time. Packets go to the wrong >server, go missing, fail-over happens, etc. It is the responsibility of >the RADIUS ecosystem (DB, etc.) to process all of the accounting data. > > This may mean post-processing, to merge records. It may mean >discarding DB records for users which don't exist. etc. > >> Having said that, we might have a few use-cases which I may not aware >> of, but due to the restriction as mentioned might see same challenges. >> IMO, we should be looking at some means of standardising the behaviour >> at least as a an informational thing. > > I can't think of any "normal operation" scenario where a server should >drop accounting packets. That's just weird. > > So far as fixing RADIUS goes, I would put recommendations into an >"implementation and deployment" guide. It should be informational, but >could talk about "best practices" for operating a RADIUS server. > > If this is the only issue, the document would be small. It would be >good to get a larger list of operational issues, too. I am not aware if any such kind of document exist already. If they are, we can edit them otherwise, let me know how we can make use of this. > > Alan DeKok. From nobody Wed Sep 24 06:07:33 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 8FC5F1A00CA for ; Wed, 24 Sep 2014 06:07: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 sTgbqJtSjxFb for ; Wed, 24 Sep 2014 06:07:28 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id A37AD1A00DF for ; Wed, 24 Sep 2014 06:07:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 725BB2240495; Wed, 24 Sep 2014 15:07:15 +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 QHvopfvYVonF; Wed, 24 Sep 2014 15:07:15 +0200 (CEST) Received: from Thor.local (bas1-ottawa11-1176223843.dsl.bell.ca [70.27.192.99]) by power.freeradius.org (Postfix) with ESMTPSA id E309F224037C; Wed, 24 Sep 2014 15:07:14 +0200 (CEST) Message-ID: <5422C201.7090406@deployingradius.com> Date: Wed, 24 Sep 2014 09:07:13 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <20140923232150.1601.20067.idtracker@ietfa.amsl.com>, , <542210D8.10900@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/ielaXD0aH_z3dFGJ-uGonDrmbgA Cc: "radext@ietf.org" Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-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: Wed, 24 Sep 2014 13:07:30 -0000 Bernard Aboba wrote: > BTW, I realize that there is better advise elsewhere in the draft... but > given that, the paragraph below really is superfluous. I'll remove it and re-issue the draft. If that's the only comment, I'm hopeful for publication... Alan DeKok. From nobody Wed Sep 24 06:12:30 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 C226C1A00B6 for ; Wed, 24 Sep 2014 06:12:28 -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 FJYRamenvtAH for ; Wed, 24 Sep 2014 06:12:28 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 372D81A00DA for ; Wed, 24 Sep 2014 06:12:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 9CC2D2240495; Wed, 24 Sep 2014 15:12: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 tBjvlm4emGvd; Wed, 24 Sep 2014 15:12:24 +0200 (CEST) Received: from Thor.local (bas1-ottawa11-1176223843.dsl.bell.ca [70.27.192.99]) by power.freeradius.org (Postfix) with ESMTPSA id 24CC72240267; Wed, 24 Sep 2014 15:12:24 +0200 (CEST) Message-ID: <5422C337.6030404@deployingradius.com> Date: Wed, 24 Sep 2014 09:12:23 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Satyanarayana Danda (sdanda)" References: <54201972.7050403@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/HxEPxNG7P8lA9KsStceMN1EnsI8 Cc: "radext@ietf.org" Subject: Re: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality 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, 24 Sep 2014 13:12:28 -0000 Satyanarayana Danda (sdanda) wrote: >> If this is the only issue, the document would be small. It would be >> good to get a larger list of operational issues, too. > > I am not aware if any such kind of document exist already. If they are, > we can edit them otherwise, let me know how we can make use of this. We would need another 3-4 issues to make a document. For now, I don't think there's enough content to gain WG adoption. Alan DeKok. From nobody Wed Sep 24 06:20: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 0B72E1A0118; Wed, 24 Sep 2014 06:20:33 -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 EAc4Lkv2T6Da; Wed, 24 Sep 2014 06:20:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8014D1A00CD; Wed, 24 Sep 2014 06:20:31 -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.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924132031.7556.21265.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 06:20:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/aGPVnn_EWSBwEifK3rhPk88vmL8 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-08.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, 24 Sep 2014 13:20:33 -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 : The Network Access Identifier Author : Alan DeKok Filename : draft-ietf-radext-nai-08.txt Pages : 25 Date : 2014-09-24 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-nai-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 24 06:43: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 B1D861A0100 for ; Wed, 24 Sep 2014 06:43:55 -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 urqw4Oc4RqX2 for ; Wed, 24 Sep 2014 06:43:54 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 577481A00D0 for ; Wed, 24 Sep 2014 06:43:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 9037A2240495 for ; Wed, 24 Sep 2014 15:43:23 +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 KnkFZ0kjFMwM for ; Wed, 24 Sep 2014 15:43:22 +0200 (CEST) Received: from Thor.local (bas1-ottawa11-1176223843.dsl.bell.ca [70.27.192.99]) by power.freeradius.org (Postfix) with ESMTPSA id 6D9EE224037C for ; Wed, 24 Sep 2014 15:43:22 +0200 (CEST) Message-ID: <5422CA79.6070203@deployingradius.com> Date: Wed, 24 Sep 2014 09:43:21 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: radext@ietf.org References: <20140924132031.7556.21265.idtracker@ietfa.amsl.com> In-Reply-To: <20140924132031.7556.21265.idtracker@ietfa.amsl.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/w53-2Uc0NLx5UFKbRu25ueqjrgI Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-08.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, 24 Sep 2014 13:43:55 -0000 This addresses Bernard's comments. internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : The Network Access Identifier > Author : Alan DeKok > Filename : draft-ietf-radext-nai-08.txt > Pages : 25 > Date : 2014-09-24 > > Abstract: > In order to provide inter-domain authentication services, it is > necessary to have a standardized method that domains can use to > identify each other's users. This document defines the syntax for > the Network Access Identifier (NAI), the user identity submitted by > the client prior to accessing network resources. This document is a > revised version of RFC 4282, which addresses issues with > international character sets, as well as a number of other > corrections to the previous document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-nai-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Mon Sep 29 23:47:44 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 4F0761A0235 for ; Mon, 29 Sep 2014 23:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 A2SFqtPNpo8D for ; Mon, 29 Sep 2014 23:47:42 -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 25BEC1A0231 for ; Mon, 29 Sep 2014 23:47:42 -0700 (PDT) Received: from localhost ([::1]:35889 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XYrDc-0001AC-Ex; Mon, 29 Sep 2014 23:47:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.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: Tue, 30 Sep 2014 06:47:28 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/178#comment:3 Message-ID: <080.8a14d2da60a156e795e3cedd77d089a2@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/vnoqph-1NnW3XXOzsrdSeMIc4cA 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: Tue, 30 Sep 2014 06:47:43 -0000 #178: fragments going in both directions - allowed or not? Comment (by alex@um.es): I've changed that paragraph to: * Indicate that the exchange of authorization data is not mandatory * Add the word MAY to reflect that * Add a sentence explicitly forbidding the "other" direction [...] We can distinguish two phases, which can be omitted if there is no authorization data to be sent: 1. Pre-authorization. In this phase, the NAS MAY send a large packet with authorization information to the AS before the end user is authenticated. Only the NAS is allowed to send authorization data during this phase. 2. Post-authorization. In this phase, the AS MAY send a large packet with authorization data to the NAS after the end user has been authenticated. Only the AS is allowed to send authorization data during this phase. [...] -- -------------------------------------+------------------------------------- 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 Mon Sep 29 23:49:03 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 704961A0233 for ; Mon, 29 Sep 2014 23:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 K--raHu4lefz for ; Mon, 29 Sep 2014 23:48:59 -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 87FFE1A0222 for ; Mon, 29 Sep 2014 23:48:59 -0700 (PDT) Received: from localhost ([::1]:35960 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XYrEy-0003fE-Eu; Mon, 29 Sep 2014 23:48: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, stefan.winter@restena.lu, alex@um.es X-Trac-Project: radext Date: Tue, 30 Sep 2014 06:48:52 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/179#comment:4 Message-ID: <080.d85eb9577687559e336dd669aaebad93@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/YsBax8NBloWoyEE0RLuICzejoJQ 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: Tue, 30 Sep 2014 06:49:01 -0000 #179: draft-ietf-radext-radius-fragmentation-06: IANA considerations Comment (by alex@um.es): Fixed -- -------------------------------------+------------------------------------- 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 Tue Sep 30 00:22:38 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 A694E1A0276 for ; Tue, 30 Sep 2014 00:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 CKiQubsaAhPu for ; Tue, 30 Sep 2014 00:22:32 -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 18A361A0270 for ; Tue, 30 Sep 2014 00:22:31 -0700 (PDT) Received: from localhost ([::1]:38266 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XYrlM-0002kr-2X; Tue, 30 Sep 2014 00:22:20 -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: Tue, 30 Sep 2014 07:22:19 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/180#comment:4 Message-ID: <080.d370e2c5ac18dc77e0b62f506bfe7d94@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/pY9SjqZjdZzlkgKgZ8dd3gkQpF8 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: Tue, 30 Sep 2014 07:22:34 -0000 #180: draft-ietf-radext-radius-fragmentation-06: mop-up of small comments Comment (by alex@um.es): 1. No. What we wanted to express is what the RFC6158 says about the NAS- Filter-Rule attribute: that it is not allowed to be in an Access-Challenge packet. The text now says: [...]this approach does entirely solve the problem of sending large amounts of data from a server to a NAS, as many current RADIUS attributes are not permitted in an Access-Challenge packets. [...] 2. English-Spanish "false friend". It has been modified to "SAML statement". 3. If reworded the sentence to: [...] If they are unable to add this information to the packet [...] -- -------------------------------------+------------------------------------- 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 manganes@cisco.com Tue Sep 30 03:32:42 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 6ADE71A0332 for ; Tue, 30 Sep 2014 03:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 UqUzJKx9C5F9 for ; Tue, 30 Sep 2014 03:32:37 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693981A0331 for ; Tue, 30 Sep 2014 03:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1149; q=dns/txt; s=iport; t=1412073157; x=1413282757; h=from:to:subject:date:message-id:mime-version; bh=eKlaaJAP3hPk53Y8KliV2GxyG5GCZzA6aDp1QTTshbg=; b=H7zRAYRB/FGlpwil/ZamGPPO+sVbWJ+uHRRZKlAFLLY2rMJk8jrjVLgY iXJqAwwy2+cO5ByoxtlsD7QX5KCuFd66veUv2X28OFrGsCYeLPK7CRj2n X9gRO+QPoCQVBkvvICVmYDtI8456gMEQ4tOvoyg4hgQ7yA1enbkwpqooN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFAPGFKlStJV2S/2dsb2JhbABggkhGgS7SfxYBcgmDehCBCwELAXQnBIhRmVOlX5RwBZFli0OVXYNjgjSBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,625,1406592000"; d="scan'208,217"; a="82669708" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 30 Sep 2014 10:32:35 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8UAWYLd007740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Sep 2014 10:32:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 05:32:34 -0500 From: "Manigandan Ganesan (manganes)" To: "radext@ietf.org" Thread-Topic: Interim accouting Thread-Index: AQHP3JnYr0eRtv2hKUyiODg15IQxDA== Date: Tue, 30 Sep 2014 10:32:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.108.55] Content-Type: multipart/alternative; boundary="_000_D05084961067Amanganesciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/L7BVB83Dw_hiOX35xvy9nAoSxXo X-Mailman-Approved-At: Tue, 30 Sep 2014 05:22:37 -0700 Subject: [radext] Interim accouting 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, 30 Sep 2014 10:37:48 -0000 --_000_D05084961067Amanganesciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, If radius client is not able to collect statistics like input octets, packe= ts etc, is it possible for it to indicate that in radius interim accounting= packet? Thanks, Manigandan --_000_D05084961067Amanganesciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

If radius client is not able to collect statistics like input octets, = packets etc, is it possible for it to indicate that in radius interim accou= nting packet?

Thanks,
Manigandan
--_000_D05084961067Amanganesciscocom_--