From nobody Mon Aug 3 19:33:23 2015 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 8763A1B3383 for ; Mon, 3 Aug 2015 19:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrRI0jLXVzyL for ; Mon, 3 Aug 2015 19:33:21 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CE71B3382 for ; Mon, 3 Aug 2015 19:33:20 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=cbSKGDQJjsa7pnE0uDqQKM1rkY1p9LJOGyKi+nHqjM73ol8ZMzsvxNIJ /Cj3JNdnx0TCnaHBnKc6KHHSq7/q+lDN25/lr6RIryV3odizEpZ0jeZpb waxit9xhe4JMKCy/N5Y6sLoeaHuhSZjsGR/+iUcyI/hcUscJdfcgpIxKG Q=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1438655600; x=1470191600; h=from:to:cc:date:subject:message-id:mime-version: content-transfer-encoding; bh=jPT3rxbL8lOld1XEqfy9gCsm/ZURKf6bPto0T0tiQLs=; b=LLZYtz1KDGOFWhSKQca0ozD057l6/CGxzLgV1fQEX4I7brJXcONVUFHE vUbM2osi4pwHW4TFKV5CVrZekndbf1x1IfCA7mzJSWAubjHmFuFA2uykx tBvW5Xy69nfK+O7Qo2SSzA2uFA6cI9ZC4T/14xL6TMR+XK7jprs78otGz I=; X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="5.15,605,1432616400"; d="scan'208,217";a="686129167" From: To: Date: Tue, 4 Aug 2015 08:03:10 +0530 Thread-Topic: New Draft for RADIUS Message Bundling Thread-Index: AdDOXZ0fZZxLp1yvRQy+7gqd5JKz7A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=Internal Use;External=No;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GNyLGuT/MQ2tENPz7BHaBKJWmwE5n+2AMtXS0vNkx1ytoCQckw+EA9cNQjN+WGLvf/QzM8UFiDgD+Wh1dQLBJkwu1YjynZOfIKR0xN953J51lfEp1wlGkHygu6ONilGT+jNc5zYNyma6Eccnuk/9LlkyyomKxB10ZKVQXxwjslrnJvP/iKnG0U0BmOtN/TxgFl6bwQJ8sQ63VoDpY6X7PmW4aOr3lCC2NOx1ZbpLkHPP x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD5B30MAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: Aravind_Sridharan@Dell.com, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com Subject: [radext] New Draft for RADIUS Message Bundling 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, 04 Aug 2015 02:33:22 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD5B30MAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dell - Internal Use - Confidential Hi All, We have proposed a new draft for RADIUS Message Bundling. Name: draft-aravind-radext-message-bundling Revision: 00 Title: RADIUS Message Bundling Document date: 2015-08-04 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-aravind-radext-m= essage-bundling-00.txt Status: https://datatracker.ietf.org/doc/draft-aravind-radext-messa= ge-bundling/ Htmlized: https://tools.ietf.org/html/draft-aravind-radext-message-bu= ndling-00 Abstract: This draft proposes a mechanism to bundle multiple RADIUS requests in a single RADIUS Message which could assist in improving the overall performance and scalability. We would love to hear your reviews and comments. Thanks, S. Aravind Prasad --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD5B30MAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dell - Interna= l Use - Confidential

Hi All,=

 

We have proposed a new draft for RADIUS Message Bundling.

 

Name:          &n= bsp;       draft-aravind-radext-message-bundl= ing

Revision:&= nbsp;           &nbs= p; 00

Title:&n= bsp;            = ;         RADIUS Message Bundling

Document date:&= nbsp;           &nbs= p;  2015-08-04

Group:          &nb= sp;       Individual Submission

Pages:   &nb= sp;            =    5

URL:            https://www.ietf.org/internet-drafts= /draft-aravind-radext-message-bundling-00.txt

Status: &nb= sp;       htt= ps://datatracker.ietf.org/doc/draft-aravind-radext-message-bundling/=

Htmlized:=        https://tools.ietf.org/html/draf= t-aravind-radext-message-bundling-00

 

 

Abstract:

 &n= bsp; This draft proposes a mechanism to bundle multiple RADIUS requests in<= o:p>

   a single RADIUS Message = which could assist in improving the overall

   performance and scalability.

 

 

We would love to hear your reviews and comments.

 

&= nbsp;

Thanks,

S. Aravind Prasad

 <= /p>

= --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD5B30MAAX7MCDC101A_-- From nobody Mon Aug 3 23:43:26 2015 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 B9FB81B365E for ; Mon, 3 Aug 2015 23:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eCMzdTn0kIY for ; Mon, 3 Aug 2015 23:43:23 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDFD1B3667 for ; Mon, 3 Aug 2015 23:43:23 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id E7E30402D7; Tue, 4 Aug 2015 08:43:21 +0200 (CEST) To: Aravind_Sridharan@Dell.com, radext@ietf.org References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <55C05F04.3040505@restena.lu> Date: Tue, 4 Aug 2015 08:43:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RIUw6qN9NNonD8Rq9wMvHbjm1jT5vPIWT" Archived-At: Cc: Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com Subject: Re: [radext] New Draft for RADIUS Message Bundling 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, 04 Aug 2015 06:43:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RIUw6qN9NNonD8Rq9wMvHbjm1jT5vPIWT Content-Type: multipart/mixed; boundary="------------070707090000010401030202" This is a multi-part message in MIME format. --------------070707090000010401030202 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > *Dell - Internal Use - Confidential * This declaration of content is in conflict with the Note Well (which you've agreed to respect when subscribing to this mailing list). Please re-post the message without this statement. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------070707090000010401030202 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------070707090000010401030202-- --RIUw6qN9NNonD8Rq9wMvHbjm1jT5vPIWT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVwF8JAAoJEMDeajWKOdxmwgsQAIja6SqZmAZ9lzRPo1ILUdJ9 v4foTYkp5HRAa4GVKTA/Vo0o0cYTMhM7XonqGRnWN757H28hBWLZmK/bB/enfJID 7NDmxf16z4byOYXt+GtCYZwxYPi2CNZbFK8EiJU63OpCOb6e4DnhyEzCba7v8kpN n6pJCBR0DMWhi/a9W/xyvw78uApiH0LsSH2RTkn9O9frMdSSePC1pSnjNt2KMrgt JVkYNYMeSoCNb0GhB1UVVMS9KsSJcabP3f2Rg2QtlR55bK7QtbIRBsM5P5ANtGW8 3+KhGY3rnhqwiKWh/JkX2i62YIHzz/MeIpvCFRy3CjtS484Pvw3cHd1/5Zl1qCM+ 5ohWg0yGXj/0+0m/uBgagQA53+gK7ZUPpeSmawu/WCLFnjj7pl6uPhv71qhCq/cV pp3mxT/6rJo1ylxRYD9la39mydoVIvAdyYzo95lUq615Poz4N1DVe8OBIR1hFEKm rI7Ygbhm4avnw5d0JQyd6PN4/S6XQXvFEXM16fcYTda+bGUzwaaiOiuZptxqvNkj asUx6qzC8AO209OA6RLcIFOLHeq4MoIuDCtbMSh8CvJK+IYSbj3BziQ4lY8p7EdA L7PCGcxJTh/PMa89lk10DXnwJR1esMkNdbG6LNItjDWYFA+k0Rwt+Q1Mjx141ogE ROLCjsAz2GsHzQZfCqVT =ghjp -----END PGP SIGNATURE----- --RIUw6qN9NNonD8Rq9wMvHbjm1jT5vPIWT-- From nobody Mon Aug 3 23:49:36 2015 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 9CB071B365F for ; Mon, 3 Aug 2015 23:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khHfgNm2Ierq for ; Mon, 3 Aug 2015 23:49:33 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C561B3271 for ; Mon, 3 Aug 2015 23:49:32 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=bKOyQ22FUvGBII1Hq5lFngIrLBu8DNRrUxzg0RT6lEc0Frqcdzy1CPfQ DnOJbWHjdyPoEDzEur6HogVUTh7SlCVh/h6rt0atC0It66ROMcky1VoS6 ZUfOyfeNMtQXwsmEXCFi146dT4r/X4spg4Rhqgmp0Yb1VPILGn4QslYQW E=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1438670973; x=1470206973; h=from:to:cc:date:subject:message-id:mime-version: content-transfer-encoding; bh=GfiqmiLPCj9sdJ6GiNDUIp3JyOkxJYySTQuFXCiRI2c=; b=trvkhsRclhbCutUwylAC3Ci4r8kM+igNI4oJjQIOnpFlR7o2+2IB44pS 4fLLBDyiR30TckiYnStaiS0J7HsLppt1lKwQ4NkmO5Ha6/Cz26M941ROW pBEoGG574DDhC4U+u187Zg0wn9S2A/mqalP+gp5GkQKDKWyvd0pIIdA+C U=; X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.15,606,1432616400"; d="scan'208,217";a="714877017" From: To: Date: Tue, 4 Aug 2015 12:19:26 +0530 Thread-Topic: New Draft for RADIUS Message Bundling Thread-Index: AdDOgals3YjbYlv3QA2NyTAVgYKlBg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=No Restrictions;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GNyLGuT/MQ2tENPz7BHaBKJWmwE5n+2AMtXS0vNkx1ytoCQckw+EA9cNQjN+WGLvfyQeD27dkaIc7z9Eyz/ddOQydeAnx02O3BUpFVll1ffhyDSKCwI3J2cZuJgGo4BoP4+cTV+GLsJMokcrAPgEx8+VG+YLu+/0INggb06/e/SNhGJ/Mc1AH3ifQiFACu7zJhFjeGxpxaYWZP/jLdPYp5I= x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD5C4EMAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: Aravind_Sridharan@Dell.com, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com Subject: [radext] New Draft for RADIUS Message Bundling 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, 04 Aug 2015 06:49:34 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD5C4EMAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We have proposed a new draft for RADIUS Message Bundling. Name: draft-aravind-radext-message-bundling Revision: 00 Title: RADIUS Message Bundling Document date: 2015-08-04 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-aravind-radext-m= essage-bundling-00.txt Status: https://datatracker.ietf.org/doc/draft-aravind-radext-messa= ge-bundling/ Htmlized: https://tools.ietf.org/html/draft-aravind-radext-message-bu= ndling-00 Abstract: This draft proposes a mechanism to bundle multiple RADIUS requests in a single RADIUS Message which could assist in improving the overall performance and scalability. We would love to hear your reviews and comments. Thanks, S. Aravind Prasad --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD5C4EMAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,<= o:p>

 

We have proposed a new draft for RADIUS Message Bundling.

=

 

Name:          &nb= sp;       draft-aravind-radext-message-bundli= ng

Revision:&n= bsp;            = ; 00

Title:   &= nbsp;           &nbs= p;      RADIUS Message Bundling

Document date:       = ;        2015-08-04

Group:        &nb= sp;         Individual Submission

Pages:  &nbs= p;            &= nbsp;   5

URL:           &nbs= p;https://www.ietf.org/internet-d= rafts/draft-aravind-radext-message-bundling-00.txt

Status:&nbs= p;        https://datatracker.ietf.org/doc/draft-aravind-radext-message-bundling/

Htmlized:       https://tools.ietf.org/html/draft-aravind-radext-message-bundli= ng-00

 

 

Abstract:

   This draft proposes a mec= hanism to bundle multiple RADIUS requests in

   a single RADIUS Message which could assist in improvin= g the overall

   performanc= e and scalability.

 

=

 

We would lov= e to hear your reviews and comments.

 

 

Thanks,

S. Aravind Prasad

= --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD5C4EMAAX7MCDC101A_-- From nobody Mon Aug 10 03:14:21 2015 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 E51101B33FC for ; Mon, 10 Aug 2015 03:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG0hXgRUkwaU for ; Mon, 10 Aug 2015 03:14:18 -0700 (PDT) Received: from ausxippc110.us.dell.com (AUSXIPPC110.us.dell.com [143.166.85.200]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7F41B33FA for ; Mon, 10 Aug 2015 03:14:17 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=pJBP5RG4kTx9kCZRUBcb6avGzyQ/rwiHDcIIOQPhMEYbhtBe5SYGjCuG MN0rAdfRykHFQfkvnO7OCJ9fgtJX2usFp/czGV7aEHjkeXki4kxUlJv0z 4R8an7hOMdx6rIS0kfu3WLhBWrjPl95+C2eFp8B3aolRrx3VsDFD6N3zf w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1439201659; x=1470737659; h=from:to:cc:date:subject:message-id:mime-version: content-transfer-encoding; bh=904LEXpXeazdhuO4AjfDzVYigEx2MCeSSDiQOm7B6xo=; b=zRW0S2a1BnTcKYgR/oMiefDGtqquYQ39pzXKDeFRsYTR9Jv8kInQuAhM J2p5cnGvQ1QFqgv1tsWPNLrg4NhPqIOA+euVDWAYPi0JP+vlqv1TYst5c 5VBOFCHYNMrt2hM+sAXm2ZP1uQ+ClZUaVm726Ik1iCOa0YLNuYqnADMkg w=; X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="5.15,644,1432616400"; d="scan'208,217";a="203106866" From: To: Date: Mon, 10 Aug 2015 15:44:11 +0530 Thread-Topic: New Draft for RADIUS Message Bundling Thread-Index: AdDTVUp6LBygWzgtSU2JPNEgBBwz6w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=Internal Use;External=No;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GNyLGuT/MQ2tENPz7BHaBKJWmwE5n+2AMtXS0vNkx1ytoCQckw+EA9cNQjN+WGLvf/QzM8UFiDgD+Wh1dQLBJkwu1YjynZOfIKR0xN953J51lfEp1wlGkHygu6ONilGT+jNc5zYNyma6Eccnuk/9LlkyyomKxB10ZKVQXxwjslrnJvP/iKnG0U0BmOtN/TxgFl6bwQJ8sQ63VoDpY6X7PmW4aOr3lCC2NOx1ZbpLkHPP x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD6921MAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: Aravind_Sridharan@Dell.com, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com Subject: [radext] New Draft for RADIUS Message Bundling 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, 10 Aug 2015 10:14:20 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD6921MAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dell - Internal Use - Confidential Hi All, We have proposed a new draft for RADIUS Message Bundling. Name: draft-aravind-radext-message-bundling Revision: 00 Title: RADIUS Message Bundling Document date: 2015-08-04 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-aravind-radext-m= essage-bundling-00.txt Status: https://datatracker.ietf.org/doc/draft-aravind-radext-messa= ge-bundling/ Htmlized: https://tools.ietf.org/html/draft-aravind-radext-message-bu= ndling-00 Abstract: This draft proposes a mechanism to bundle multiple RADIUS requests in a single RADIUS Message which could assist in improving the overall performance and scalability. We would love to hear your reviews and comments. Thanks, S. Aravind Prasad --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD6921MAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dell - Interna= l Use - Confidential

 H= i All,

 

We have proposed a new draft for RADIUS Message Bundling.

 

Name:         &n= bsp;        draft-aravind-radext-message= -bundling

Revi= sion:           &nbs= p;  00

Ti= tle:            = ;          RADIUS Message Bund= ling

Document date:  = ;             2= 015-08-04

Group:   &nb= sp;            =   Individual Submission

Pages:          &= nbsp;        5

URL:      = ;      h= ttps://www.ietf.org/internet-drafts/draft-aravind-radext-message-bundling-0= 0.txt

Status:         = https://datatracker.ietf.org/doc/draft-arav= ind-radext-message-bundling/

Htmlized:    =    https://tools.ietf.org/html/draft= -aravind-radext-message-bundling-00

 

 

Abstract:

 &n= bsp; This draft proposes a mechanism to bundle multiple RADIUS requests in<= o:p>

   a single RADIUS Message = which could assist in improving the overall

   performance and scalability.

 

 

We would love to hear your reviews and comments.

 

&= nbsp;

Thanks,

S. Aravind Prasad

= --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD6921MAAX7MCDC101A_-- From nobody Mon Aug 10 03:17:20 2015 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 7FA631B340D for ; Mon, 10 Aug 2015 03:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQAiswcesQZ7 for ; Mon, 10 Aug 2015 03:17:17 -0700 (PDT) Received: from ausxipps310.us.dell.com (AUSXIPPS310.us.dell.com [143.166.148.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862491B33FC for ; Mon, 10 Aug 2015 03:17:17 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=yT2f9+R0mpFiTx7DAaxTqdBzRLwK0Z9Gms2LuP0GTDcNWniAX3YxHTuA rsXoFXAUuZ3Rhr/fL4FsIBtwGtaLqOecem6APMpZ1hm26LyDFZWovzNV4 UcWLWOC7XgQ/rzPy6j6DwYg1cpbjgqk03roaLcpB7OKk0GPBjPSM8T474 8=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1439201838; x=1470737838; h=from:to:cc:date:subject:message-id:mime-version: content-transfer-encoding; bh=t7ykephuC4qEjL1e2nhVkw8yzX4c/oO6UQ/qNEVGkp8=; b=aG05bDbVh27N0UMDjyqSuDBnTT00dYhyRjzzIcubt2H2E3WUfTsxfokZ UOqPRNISVOraVatx3R+STyR3nISyrdVPZmi1SbGZqX9YEho+44D5w6WHR W36P+pycut4W3m5eO1oaFvAckpb0AZcb/vKYGM8Vdf+sIGmsN/PJt0p5/ o=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.15,644,1432616400"; d="scan'208,217";a="212332616" From: To: Date: Mon, 10 Aug 2015 15:47:11 +0530 Thread-Topic: New Draft for RADIUS Message Bundling Thread-Index: AdDTVXgT5/R7DvssTfuS9cOri2iCyw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=No Restrictions;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GNyLGuT/MQ2tENPz7BHaBKJWmwE5n+2AMtXS0vNkx1ytoCQckw+EA9cNQjN+WGLvfyQeD27dkaIc7z9Eyz/ddOQydeAnx02O3BUpFVll1ffhyDSKCwI3J2cZuJgGo4BoP4+cTV+GLsJMokcrAPgEx8+VG+YLu+/0INggb06/e/SNhGJ/Mc1AH3ifQiFACu7zJhFjeGxpxaYWZP/jLdPYp5I= x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD6925MAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com Subject: [radext] New Draft for RADIUS Message Bundling 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, 10 Aug 2015 10:17:19 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD6925MAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Sorry for the earlier Mail with "*Dell - Internal Use - Confidential *" . = Removed it and reposting it again. We have proposed a new draft for RADIUS Message Bundling. Name: draft-aravind-radext-message-bundling Revision: 00 Title: RADIUS Message Bundling Document date: 2015-08-04 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-aravind-radext-m= essage-bundling-00.txt Status: https://datatracker.ietf.org/doc/draft-aravind-radext-messa= ge-bundling/ Htmlized: https://tools.ietf.org/html/draft-aravind-radext-message-bu= ndling-00 Abstract: This draft proposes a mechanism to bundle multiple RADIUS requests in a single RADIUS Message which could assist in improving the overall performance and scalability. We would love to hear your reviews and comments. Thanks, S. Aravind Prasad --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD6925MAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,<= o:p>

 

Sorry for the earlier Mail with “*Dell - Internal Use - Confidentia= l *” .  Removed it  and reposting it again.

=

 

We have prop= osed a new draft for RADIUS Message Bundling.

 

Name:&n= bsp;            = ;     draft-aravind-radext-message-bundling<= /span>

Revision:  &nbs= p;           00

Title:   = ;            &n= bsp;      RADIUS Message Bundling

Document date:     &n= bsp;         2015-08-04<= /p>

Group:       =            Individual Sub= mission

Pages: &= nbsp;           &nbs= p;     5

<= span lang=3DSV>URL:          &= nbsp; https://www.ietf.org/i= nternet-drafts/draft-aravind-radext-message-bundling-00.txt

St= atus:         https://datatracker.ietf.org/doc/draft-aravind-radext-message-bu= ndling/

Htmlized:       <= a href=3D"https://tools.ietf.org/html/draft-aravind-radext-message-bundling= -00">https://tools.ietf.org/html/draft-aravind-radext-messa= ge-bundling-00

 

 

Ab= stract:

   This draft propo= ses a mechanism to bundle multiple RADIUS requests in

   a single RADIUS Message which could assist in= improving the overall

   p= erformance and scalability.

 <= /o:p>

 

We = would love to hear your reviews and comments.

 

 

Thanks,

S. Aravind Prasad=

= --_000_D5A6F3355F664C40AFB65BB1277D8D45040EBD6925MAAX7MCDC101A_-- From nobody Mon Aug 10 07:57:04 2015 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 DB1E61B364C for ; Mon, 10 Aug 2015 07:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj3QY9iHZSi2 for ; Mon, 10 Aug 2015 07:57:02 -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 F3DAA1B3631 for ; Mon, 10 Aug 2015 07:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 897712078F; Mon, 10 Aug 2015 10:55:49 -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 kBH25vy7Vr_z; Mon, 10 Aug 2015 10:55:49 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (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, 10 Aug 2015 10:55:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A94880910; Mon, 10 Aug 2015 10:57:00 -0400 (EDT) From: Sam Hartman To: References: Date: Mon, 10 Aug 2015 10:57:00 -0400 In-Reply-To: (Aravind Sridharan's message of "Mon, 10 Aug 2015 15:47:11 +0530") 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: Cc: radext@ietf.org, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com Subject: Re: [radext] New Draft for RADIUS Message Bundling 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, 10 Aug 2015 14:57:03 -0000 The RADIUS community already has a specification for running RADIUS over TCP/TLS; see RFC 6613. Have you evaluated that specification for your use cases? I think that TCP can provide good bundling of requests, and unlike a RADIUS specific solution is likely to have better transport characteristics. If TCP can work for your use case, I'd recommend exploring that. If not, I'd recommend explaining the problems with TCP in your target environment. --Sam From nobody Wed Aug 12 00:41:32 2015 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 DFD621B2C29 for ; Wed, 12 Aug 2015 00:41: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 kieI9JPS4Njp for ; Wed, 12 Aug 2015 00:41:29 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id D55F51B2C28 for ; Wed, 12 Aug 2015 00:41:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7E75E22404C2; Wed, 12 Aug 2015 09:41:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsK9e0z9bI-D; Wed, 12 Aug 2015 09:41:26 +0200 (CEST) Received: from [10.192.1.135] (LStLambert-656-1-53-31.w80-13.abo.wanadoo.fr [80.13.34.31]) by power.freeradius.org (Postfix) with ESMTPSA id E8E3D22404AE; Wed, 12 Aug 2015 09:41:25 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Wed, 12 Aug 2015 09:41:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <15A2E89E-6AD6-43A1-A233-2DD91D5217C2@deployingradius.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Aravind_Sridharan@Dell.com, radext@ietf.org, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com Subject: Re: [radext] New Draft for RADIUS Message Bundling 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, 12 Aug 2015 07:41:31 -0000 I agree with Sam here. I've had discussions for ~3 years with various = people about putting multiple RADIUS packets into a UDP packet. In the = end, it just solves one problem: more packets to the RADIUS server. It compounds another problem: port / ID limitations. RADIUS has an = 8-bit ID, which you run into *very* quickly in high load situations. Even if this proposal would be standardized, the ID limitation problem = would mean that this proposal has minimal benefits. If we solve the RADIUS ID limitation, then we might as well just use = TCP for everything, which avoids UDP / PMTU limitations. And which = makes this proposal unnecessary. On Aug 10, 2015, at 4:57 PM, Sam Hartman = wrote: > The RADIUS community already has a specification for running RADIUS = over > TCP/TLS; see RFC 6613. >=20 > Have you evaluated that specification for your use cases? >=20 > I think that TCP can provide good bundling of requests, and unlike a > RADIUS specific solution is likely to have better transport > characteristics. >=20 > If TCP can work for your use case, I'd recommend exploring that. If > not, I'd recommend explaining the problems with TCP in your target > environment. >=20 > --Sam >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Sat Aug 15 15:52:50 2015 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 C1C5F1B2A8B for ; Sat, 15 Aug 2015 15:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvJRNnyADuUv for ; Sat, 15 Aug 2015 15:52:45 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE921B2A89 for ; Sat, 15 Aug 2015 15:52:45 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=uEy/0DAA3THpRAkMQjXVUdnDtb33Aza/rgzavnEpFlGl8ndWwC6C9Aji gJ+ddUtCBDvvP4gcLBCxYwjXwQrJbTaVJ+UrYCGvOa9R4JEulN2P4F732 n4WfjuoIIwl+FHt4ft4u+jhehJem9r+HI+r8U1EyFvfaj2DKEN8NLYLOQ 0=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1439679165; x=1471215165; h=from:to:cc:date:subject:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=WeRDdOtBd+w0DCXwYcA4GfcRMzM+2STEoj0bC8uHjyk=; b=0b2aPtAws1JEwBhLsTxtCqUefXeCYOehszCVV/xar8mPVHqXhX6L21hV 2GnVxOakiCSfrmr6nGFKPyJIjwIEQ77bHAS8lbgZUnixBANHR+MPi4pWP SN31cZDyj0He4NuMom2e+pvCMcGrtt+pPJ32akSrLBzNK45k/1t6cLzlD 0=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.15,686,1432616400"; d="scan'208,217";a="719709062" From: To: , Date: Sun, 16 Aug 2015 04:22:35 +0530 Thread-Topic: [radext] New Draft for RADIUS Message Bundling Thread-Index: AdDU0l7JQD9wq3I1SqutZAm63AlI+QC2Bb8g Message-ID: References: <15A2E89E-6AD6-43A1-A233-2DD91D5217C2@deployingradius.com> In-Reply-To: <15A2E89E-6AD6-43A1-A233-2DD91D5217C2@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=Internal Use;External=No;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Iq9nBwmvpQc0FJRNE2DD9Puq7ugTBx3sYS+jr4MbKpqv5LL8ZLoXvV2Lt4mn+rldzfgfVMPNmZP4aIlTN82rokJ/ZgqNfKCeIknGl6W8a2n0EGkLEWPBp0QWKjCKBnivK4XaPiOz2dnttRoPzPJvhtoyWG+fqOeasO4pO3aZco9CQ6f/FdPbFMgKw7YVQK9+u4bR1L1q+phJCjtMOS7ltLOJ/zTMdkReFIidmfoo42YPSHsTVUEv8SLcWOoKDR4S1w== x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45040ECC6D35MAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: radext@ietf.org, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com Subject: Re: [radext] New Draft for RADIUS Message Bundling X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 22:52:48 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45040ECC6D35MAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dell - Internal Use - Confidential Hi Alan/Sam, Thanks a lot for reviewing the draft and providing your comments. Hi Sam, Actually, even in RADIUS over TCP, each RADIUS Message can hold only one RA= DIUS request. TCP will take care of message delivery but still the RADIUS M= essages can't hold multiple requests currently. The proposed idea is to bundle multiple RADIUS requests in a single message= . No changes are made to individual RADIUS requests. Hence, this will help = to improve network bandwidth usage and possibly performance. Hi Alan, Yes, this draft will not solve the ID problem. It only proposes a way to bu= ndle multiple requests in a single RADIUS Message. But, as discussed above, the usage of TCP may not solve the bundling proble= m. Hence, this proposal is actually applicable to both TCP and UDP. Thanks again for reviewing the Draft and kindly let us know your views and = comments. Thanks, S. Aravind Prasad -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Wednesday, August 12, 2015 1:11 PM To: Sam Hartman Cc: Sridharan, Aravind; radext@ietf.org; Sivarama, Sanal Kumar; chandru.dav= @gmail.com Subject: Re: [radext] New Draft for RADIUS Message Bundling I agree with Sam here. I've had discussions for ~3 years with various peopl= e about putting multiple RADIUS packets into a UDP packet. In the end, it j= ust solves one problem: more packets to the RADIUS server. It compounds another problem: port / ID limitations. RADIUS has an 8-bit ID= , which you run into *very* quickly in high load situations. Even if this proposal would be standardized, the ID limitation problem woul= d mean that this proposal has minimal benefits. If we solve the RADIUS ID limitation, then we might as well just use TCP fo= r everything, which avoids UDP / PMTU limitations. And which makes this pro= posal unnecessary. On Aug 10, 2015, at 4:57 PM, Sam Hartman wrote: > The RADIUS community already has a specification for running RADIUS > over TCP/TLS; see RFC 6613. > > Have you evaluated that specification for your use cases? > > I think that TCP can provide good bundling of requests, and unlike a > RADIUS specific solution is likely to have better transport > characteristics. > > If TCP can work for your use case, I'd recommend exploring that. If > not, I'd recommend explaining the problems with TCP in your target > environment. > > --Sam > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --_000_D5A6F3355F664C40AFB65BB1277D8D45040ECC6D35MAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dell - Interna= l Use - Confidential

Hi A= lan/Sam,

 

Thanks a lot for reviewing the draft and providing your co= mments.

 

Hi Sam,  

Actually= , even in RADIUS over TCP, each RADIUS Message can hold only one RADIUS req= uest. TCP will take care of message delivery but still the RADIUS Messages = can’t hold multiple requests currently.

The proposed idea is to bundle multiple RADIUS requests in a single m= essage. No changes are made to individual RADIUS requests. Hence, this will= help to improve network bandwidth usage and possibly performance.  

 

Hi Alan,

Yes, this draft will not solve= the ID problem. It only proposes a way to bundle multiple requests in a si= ngle RADIUS Message.

But, as discussed = above, the usage of TCP may not solve the bundling problem. Hence, this pro= posal is actually applicable to both TCP and UDP.

 

Thanks again for review= ing the Draft and kindly let us know your views and comments.

Thanks,
S. Aravind Prasad

-----Original Message-----
From= : Alan DeKok [mailto:aland@deployingradius.com]
Sent: Wednesday, August= 12, 2015 1:11 PM
To: Sam Hartman
Cc: Sridharan, Aravind; radext@ietf= .org; Sivarama, Sanal Kumar; chandru.dav@gmail.com
Subject: Re: [radext]= New Draft for RADIUS Message Bundling

I agree with Sam here. I've h= ad discussions for ~3 years with various people about putting multiple RADI= US packets into a UDP packet. In the end, it just solves one problem: more = packets to the RADIUS server.

It compounds another problem: port / I= D limitations. RADIUS has an 8-bit ID, which you run into *very* quickly in= high load situations.

Even if this proposal would be standardized, = the ID limitation problem would mean that this proposal has minimal benefit= s.

If we solve the RADIUS ID limitation, then we might as well just = use TCP for everything, which avoids UDP / PMTU limitations. And which make= s this proposal unnecessary.

On Aug 10, 2015, at 4:57 PM, Sam Hartma= n wrote:

> The RADIUS community already has a specification for r= unning RADIUS
> over TCP/TLS; see RFC 6613.
>
> Have yo= u evaluated that specification for your use cases?
>
> I think= that TCP can provide good bundling of requests, and unlike a
> RADI= US specific solution is likely to have better transport
> characteri= stics.
>
> If TCP can work for your use case, I'd recommend ex= ploring that. If
> not, I'd recommend explaining the problems with T= CP in your target
> environment.
>
> --Sam
>
= > _______________________________________________
> radext mailing= list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo= /radext

= --_000_D5A6F3355F664C40AFB65BB1277D8D45040ECC6D35MAAX7MCDC101A_-- From nobody Mon Aug 17 07:25:51 2015 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 5690A1A1AA1 for ; Mon, 17 Aug 2015 07:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGAoQ6a5PSu8 for ; Mon, 17 Aug 2015 07:25:49 -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 DE68E1A1A9B for ; Mon, 17 Aug 2015 07:25:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0FCD8207A1; Mon, 17 Aug 2015 10:24:19 -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 Wl73jlgwXYnn; Mon, 17 Aug 2015 10:24:18 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (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, 17 Aug 2015 10:24:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4E5FD80B2F; Mon, 17 Aug 2015 10:25:47 -0400 (EDT) From: Sam Hartman To: References: <15A2E89E-6AD6-43A1-A233-2DD91D5217C2@deployingradius.com> Date: Mon, 17 Aug 2015 10:25:45 -0400 In-Reply-To: (Aravind Sridharan's message of "Sun, 16 Aug 2015 04:22:35 +0530") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Archived-At: Cc: radext@ietf.org, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com, aland@deployingradius.com Subject: Re: [radext] New Draft for RADIUS Message Bundling 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, 17 Aug 2015 14:25:50 -0000 >>>>> writes: > Hi Sam, > Actually, even in RADIUS over TCP, each RADIUS Message can hold > only one RADIUS request. TCP will take care of message delivery > but still the RADIUS Messages can€™t hold multiple > requests currently. > The proposed idea is to bundle multiple RADIUS requests in a > single message. No changes are made to individual RADIUS > requests. Hence, this will help to improve network bandwidth usage > and possibly performance. I can understand an argument that you run into a problem with a large number of packets generated with a lot of requests at once. However, TCP will help with that by allowing multiple requests to be in a single network packet. Am I correct in my understanding that if your TCP implementation is efficient about filling packets, the difference in these proposals is that: * in TCP a request can span multiple packets. That is, say the packet has not quite enough space for the final request in the packet. * The overhead/bookkeeping between the two proposals would be different in terms of overhead bytes in a packet. So, for the multiple requests proposal to be a advantage, its bookkeeping/overhead would need to be sufficiently better than TCP to justify better bandwidth utilization. Have I got that right? If so, can you help explain how that actually works out to be the case? From nobody Mon Aug 17 13:33:44 2015 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 8636E1A1AB3 for ; Mon, 17 Aug 2015 13:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uco3UXKeaf2b for ; Mon, 17 Aug 2015 13:33:42 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id C88AD1A1AFF for ; Mon, 17 Aug 2015 13:33:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 17FA72240490 for ; Mon, 17 Aug 2015 22:33:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuJf5PFNxwSX for ; Mon, 17 Aug 2015 22:33:40 +0200 (CEST) Received: from [10.59.133.158] (105.239.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.239.105]) by power.freeradius.org (Postfix) with ESMTPSA id 83E502240403 for ; Mon, 17 Aug 2015 22:33:40 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Mon, 17 Aug 2015 22:33:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <407268D1-289F-4E05-952F-BF9EBC2BCA9D@deployingradius.com> References: <15A2E89E-6AD6-43A1-A233-2DD91D5217C2@deployingradius.com> To: radext@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [radext] New Draft for RADIUS Message Bundling 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, 17 Aug 2015 20:33:43 -0000 On Aug 17, 2015, at 4:25 PM, Sam Hartman = wrote: > I can understand an argument that you run into a problem with a large > number of packets generated with a lot of requests at once. > However, TCP will help with that by allowing multiple requests to be = in > a single network packet. I agree. I see no reason to do packet bundling on TCP. Alan DeKok. From nobody Wed Aug 19 21:17:34 2015 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 3DD301A9252 for ; Wed, 19 Aug 2015 21:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeq0TG1UPpRJ for ; Wed, 19 Aug 2015 21:17:31 -0700 (PDT) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66A61A8787 for ; Wed, 19 Aug 2015 21:17:30 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=opePtCwOpI6W8+49yWYfvFFzrwAa02N97SLoiwREvcYe1exJli3W3bH1 dE+2baPEm6DPXWoqebR9FRgTpmgUqtueNHHTeqQ8B5KxkUa6s7tO5Q2kN fgIuz9rDLtqoZSfMLkhEzFAuFcACLqHrMNjz+tTRPiPaLJssxNmOukE1v M=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1440044251; x=1471580251; h=from:to:cc:date:subject:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=fUYQEZiY2WZSSDioo5L/fhp+RMxQ8hhrItYsb2iOdfI=; b=QGoCchshj6nHyrjOfaB+jtyGv9P0Dt+ywud24JSpqQ21EtiuffBXJENW zQW0aVvFg+5ClNB6vzg9IAOj1VvENGW37kYaZmZUd+J8CRUpyLWiLF96T erlF6oho16XXLGboFs4j6xtZ2mtME/KkIqWjdYuw8hYnQXlQK1OyMyzms M=; X-LoopCount0: from 10.170.28.41 X-IronPort-AV: E=Sophos;i="5.15,713,1432616400"; d="scan'208,217";a="695074848" From: To: Date: Thu, 20 Aug 2015 09:47:23 +0530 Thread-Topic: [radext] New Draft for RADIUS Message Bundling Thread-Index: AdDY+WeJBIJLquIySfC5zwkCLAWxYQCBXYNQ Message-ID: References: <15A2E89E-6AD6-43A1-A233-2DD91D5217C2@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=No Restrictions;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Iq9nBwmvpQc0FJRNE2DD9Puq7ugTBx3sYS+jr4MbKpqv5LL8ZLoXvV2Lt4mn+rldzfgfVMPNmZP4aIlTN82rokKLt0oiO8dGtgCiurNz1BmkHM6IM9G5ILIm+5mPuRk2i/HgNRwO+kNhx05SaO6AjVne+2Rl9YpdQCH2AxCtgASS2OvATFWXVGEFTaoB2vPDvAkiUINdOva5w0rMYyczbMK1l385xpRI1a2rhNq96de4 x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45040EDB301AMAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: radext@ietf.org, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com, aland@deployingradius.com Subject: Re: [radext] New Draft for RADIUS Message Bundling X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 04:17:33 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45040EDB301AMAAX7MCDC101A_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtLA0KDQpUaGFua3MgYSBsb3QgYWdhaW4gZm9yIHlvdXIgcmV2aWV3IGNvbW1lbnRzLg0K DQpZZXMsIGFncmVlIHdpdGggeW91LiBGaW5hbGx5IGl0IGNvbWVzIGRvd24gdG8gdGhlIGZvbGxv d2luZzoNCg0KDQoxKSAgICAgIFdpdGhvdXQgYnVuZGxpbmcgKGluIGNhc2Ugb2YgaW5kaXZpZHVh bCBwYWNrZXRzKSwgdGhlcmUgaXMgdGhlIG92ZXJoZWFkIG9mIGFkZGluZyBUQ1AgYW5kIEV0aGVy bmV0IGhlYWRlcnMgdG8gaW5kaXZpZHVhbCBSQURJVVMgcGFja2V0cyBzZW50IHRvIHNlcnZlci4N Cg0KMikgICAgICBXaXRoIEJ1bmRsaW5nLCB0aGUgb3ZlcmhlYWQgb2YgVENQIGFuZCBFdGhlcm5l dCBIZWFkZXIgYWRkaXRpb25zIGFyZSBhdm9pZGVkLiBJbnN0ZWFkLCBub3cgaXTigJlzIHRoZSBv dmVyaGVhZCBvZiBib29ra2VlcGluZyBhbmQgYnVuZGxpbmcgbXVsdGlwbGUgUkFESVVTIHJlcXVl c3RzIGluIHRoZSBzaW5nbGUgbWVzc2FnZS4NCg0KQXMgc3VjaCwgaXTigJlzIGEga2luZCBvZiB0 cmFkZSBvZmYgbm93IOKYui4gV2Ugd2lsbCB3b3JrIG9uIHRoaXMgZnVydGhlciBhbmQgd2lsbCBw cm92aWRlIHRoZSB1cGRhdGVzIGFmdGVyIHdlIGNvbWUgdXAgd2l0aCBzb21lIG9wdGltaXphdGlv bnMuDQoNClRoYW5rcyBhIGxvdCBhZ2FpbiBmb3Igc3BlbmRpbmcgeW91ciB2YWx1YWJsZSB0aW1l IHJldmlld2luZyBvdXIgZHJhZnQgYW5kIHByb3ZpZGluZyB5b3VyIGNvbW1lbnRzIOKYui4NCg0K VGhhbmtzLA0KUy4gQXJhdmluZCBQcmFzYWQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFNhbSBIYXJ0bWFuIFttYWlsdG86aGFydG1hbnNAcGFpbmxlc3Mtc2VjdXJpdHkuY29t XQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTcsIDIwMTUgNzo1NiBQTQ0KVG86IFNyaWRoYXJhbiwg QXJhdmluZA0KQ2M6IGFsYW5kQGRlcGxveWluZ3JhZGl1cy5jb207IHJhZGV4dEBpZXRmLm9yZzsg U2l2YXJhbWEsIFNhbmFsIEt1bWFyOyBjaGFuZHJ1LmRhdkBnbWFpbC5jb20NClN1YmplY3Q6IFJl OiBbcmFkZXh0XSBOZXcgRHJhZnQgZm9yIFJBRElVUyBNZXNzYWdlIEJ1bmRsaW5nDQoNCj4+Pj4+ IHdyaXRlczoNCg0KPiBIaSBTYW0sDQoNCj4gQWN0dWFsbHksIGV2ZW4gaW4gUkFESVVTIG92ZXIg VENQLCBlYWNoIFJBRElVUyBNZXNzYWdlIGNhbiBob2xkDQo+IG9ubHkgb25lIFJBRElVUyByZXF1 ZXN0LiBUQ1Agd2lsbCB0YWtlIGNhcmUgb2YgbWVzc2FnZSBkZWxpdmVyeQ0KPiBidXQgc3RpbGwg dGhlIFJBRElVUyBNZXNzYWdlcyBjYW7igqzihKJ0IGhvbGQgbXVsdGlwbGUNCj4gcmVxdWVzdHMg Y3VycmVudGx5Lg0KDQo+IFRoZSBwcm9wb3NlZCBpZGVhIGlzIHRvIGJ1bmRsZSBtdWx0aXBsZSBS QURJVVMgcmVxdWVzdHMgaW4gYQ0KPiBzaW5nbGUgbWVzc2FnZS4gTm8gY2hhbmdlcyBhcmUgbWFk ZSB0byBpbmRpdmlkdWFsIFJBRElVUw0KPiByZXF1ZXN0cy4gSGVuY2UsIHRoaXMgd2lsbCBoZWxw IHRvIGltcHJvdmUgbmV0d29yayBiYW5kd2lkdGggdXNhZ2UNCj4gYW5kIHBvc3NpYmx5IHBlcmZv cm1hbmNlLg0KDQpJIGNhbiB1bmRlcnN0YW5kIGFuIGFyZ3VtZW50IHRoYXQgeW91IHJ1biBpbnRv IGEgcHJvYmxlbSB3aXRoIGEgbGFyZ2UgbnVtYmVyIG9mIHBhY2tldHMgZ2VuZXJhdGVkIHdpdGgg YSBsb3Qgb2YgcmVxdWVzdHMgYXQgb25jZS4NCkhvd2V2ZXIsIFRDUCB3aWxsIGhlbHAgd2l0aCB0 aGF0IGJ5IGFsbG93aW5nIG11bHRpcGxlIHJlcXVlc3RzIHRvIGJlIGluIGEgc2luZ2xlIG5ldHdv cmsgcGFja2V0Lg0KDQpBbSBJIGNvcnJlY3QgaW4gbXkgdW5kZXJzdGFuZGluZyB0aGF0IGlmIHlv dXIgVENQIGltcGxlbWVudGF0aW9uIGlzIGVmZmljaWVudCBhYm91dCBmaWxsaW5nIHBhY2tldHMs IHRoZSBkaWZmZXJlbmNlIGluIHRoZXNlIHByb3Bvc2FscyBpcw0KdGhhdDoNCg0KKiBpbiBUQ1Ag YSByZXF1ZXN0IGNhbiBzcGFuIG11bHRpcGxlIHBhY2tldHMuIFRoYXQgaXMsIHNheSB0aGUgcGFj a2V0DQpoYXMgbm90IHF1aXRlIGVub3VnaCBzcGFjZSBmb3IgdGhlIGZpbmFsIHJlcXVlc3QgaW4g dGhlIHBhY2tldC4NCg0KKiBUaGUgb3ZlcmhlYWQvYm9va2tlZXBpbmcgYmV0d2VlbiB0aGUgdHdv IHByb3Bvc2FscyB3b3VsZCBiZSBkaWZmZXJlbnQNCmluIHRlcm1zIG9mIG92ZXJoZWFkIGJ5dGVz IGluIGEgcGFja2V0Lg0KDQpTbywgZm9yIHRoZSBtdWx0aXBsZSByZXF1ZXN0cyBwcm9wb3NhbCB0 byBiZSBhIGFkdmFudGFnZSwgaXRzIGJvb2trZWVwaW5nL292ZXJoZWFkIHdvdWxkIG5lZWQgdG8g YmUgc3VmZmljaWVudGx5IGJldHRlciB0aGFuIFRDUCB0byBqdXN0aWZ5IGJldHRlciBiYW5kd2lk dGggdXRpbGl6YXRpb24uDQoNCkhhdmUgSSBnb3QgdGhhdCByaWdodD8NCg0KSWYgc28sIGNhbiB5 b3UgaGVscCBleHBsYWluIGhvdyB0aGF0IGFjdHVhbGx5IHdvcmtzIG91dCB0byBiZSB0aGUgY2Fz ZT8NCg== --_000_D5A6F3355F664C40AFB65BB1277D8D45040EDB301AMAAX7MCDC101A_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjk4NTMy MDIyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY1 MDI2NDgyMiA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ IEhpIFNhbSwgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UaGFua3MgYSBsb3QgYWdhaW4gZm9yIHlvdXIgcmV2 aWV3IGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+WWVzLCBhZ3JlZSB3aXRoIHlvdS4gRmluYWxs eSBpdCBjb21lcyBkb3duIHRvIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGgg c3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MSk8c3BhbiBzdHls ZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPldpdGhvdXQgYnVuZGxpbmcgKGluIGNhc2Ug b2YgaW5kaXZpZHVhbCBwYWNrZXRzKSwgdGhlcmUgaXMgdGhlIG92ZXJoZWFkIG9mIGFkZGluZyBU Q1AgYW5kIEV0aGVybmV0IGhlYWRlcnMgdG8gaW5kaXZpZHVhbCBSQURJVVMgcGFja2V0cyBzZW50 IHRvIHNlcnZlci4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHls ZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4yKTxzcGFuIHN0eWxlPSdm b250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+V2l0aCBCdW5kbGluZywgdGhlIG92ZXJoZWFkIG9m IFRDUCBhbmQgRXRoZXJuZXQgSGVhZGVyIGFkZGl0aW9ucyBhcmUgYXZvaWRlZC4gSW5zdGVhZCwg bm93IGl04oCZcyB0aGUgb3ZlcmhlYWQgb2YgYm9va2tlZXBpbmcgYW5kIGJ1bmRsaW5nIG11bHRp cGxlIFJBRElVUyByZXF1ZXN0cyBpbiB0aGUgc2luZ2xlIG1lc3NhZ2UuIDxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+QXMgc3VjaCwgaXTigJlzIGEga2luZCBvZiB0cmFkZSBvZmYgbm93IDxzcGFuIHN0eWxlPSdm b250LWZhbWlseTpXaW5nZGluZ3MnPko8L3NwYW4+LiBXZSB3aWxsIHdvcmsgb24gdGhpcyBmdXJ0 aGVyIGFuZCB3aWxsIHByb3ZpZGUgdGhlIHVwZGF0ZXMgYWZ0ZXIgd2UgY29tZSB1cCB3aXRoIHNv bWUgb3B0aW1pemF0aW9ucy4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UaGFua3MgYSBsb3QgYWdhaW4gZm9y IHNwZW5kaW5nIHlvdXIgdmFsdWFibGUgdGltZSByZXZpZXdpbmcgb3VyIGRyYWZ0IGFuZCBwcm92 aWRpbmcgeW91ciBjb21tZW50cyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6V2luZ2RpbmdzJz5K PC9zcGFuPi4gPG86cD48L286cD48L3A+PHA+VGhhbmtzLDxicj5TLiBBcmF2aW5kIFByYXNhZDxi cj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTogU2FtIEhhcnRtYW4gW21h aWx0bzpoYXJ0bWFuc0BwYWlubGVzcy1zZWN1cml0eS5jb21dIDxicj5TZW50OiBNb25kYXksIEF1 Z3VzdCAxNywgMjAxNSA3OjU2IFBNPGJyPlRvOiBTcmlkaGFyYW4sIEFyYXZpbmQ8YnI+Q2M6IGFs YW5kQGRlcGxveWluZ3JhZGl1cy5jb207IHJhZGV4dEBpZXRmLm9yZzsgU2l2YXJhbWEsIFNhbmFs IEt1bWFyOyBjaGFuZHJ1LmRhdkBnbWFpbC5jb208YnI+U3ViamVjdDogUmU6IFtyYWRleHRdIE5l dyBEcmFmdCBmb3IgUkFESVVTIE1lc3NhZ2UgQnVuZGxpbmc8YnI+PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHdyaXRlczo8YnI+PGJyPiZndDsgSGkgU2FtLDxicj48YnI+Jmd0OyBBY3R1YWxseSwg ZXZlbiBpbiBSQURJVVMgb3ZlciBUQ1AsIGVhY2ggUkFESVVTIE1lc3NhZ2UgY2FuIGhvbGQ8YnI+ Jmd0OyBvbmx5IG9uZSBSQURJVVMgcmVxdWVzdC4gVENQIHdpbGwgdGFrZSBjYXJlIG9mIG1lc3Nh Z2UgZGVsaXZlcnk8YnI+Jmd0OyBidXQgc3RpbGwgdGhlIFJBRElVUyBNZXNzYWdlcyBjYW7igqzi hKJ0IGhvbGQgbXVsdGlwbGU8YnI+Jmd0OyByZXF1ZXN0cyBjdXJyZW50bHkuPGJyPjxicj4mZ3Q7 IFRoZSBwcm9wb3NlZCBpZGVhIGlzIHRvIGJ1bmRsZSBtdWx0aXBsZSBSQURJVVMgcmVxdWVzdHMg aW4gYTxicj4mZ3Q7IHNpbmdsZSBtZXNzYWdlLiBObyBjaGFuZ2VzIGFyZSBtYWRlIHRvIGluZGl2 aWR1YWwgUkFESVVTPGJyPiZndDsgcmVxdWVzdHMuIEhlbmNlLCB0aGlzIHdpbGwgaGVscCB0byBp bXByb3ZlIG5ldHdvcmsgYmFuZHdpZHRoIHVzYWdlPGJyPiZndDsgYW5kIHBvc3NpYmx5IHBlcmZv cm1hbmNlLjxicj48YnI+SSBjYW4gdW5kZXJzdGFuZCBhbiBhcmd1bWVudCB0aGF0IHlvdSBydW4g aW50byBhIHByb2JsZW0gd2l0aCBhIGxhcmdlIG51bWJlciBvZiBwYWNrZXRzIGdlbmVyYXRlZCB3 aXRoIGEgbG90IG9mIHJlcXVlc3RzIGF0IG9uY2UuPGJyPkhvd2V2ZXIsIFRDUCB3aWxsIGhlbHAg d2l0aCB0aGF0IGJ5IGFsbG93aW5nIG11bHRpcGxlIHJlcXVlc3RzIHRvIGJlIGluIGEgc2luZ2xl IG5ldHdvcmsgcGFja2V0Ljxicj48YnI+QW0gSSBjb3JyZWN0IGluIG15IHVuZGVyc3RhbmRpbmcg dGhhdCBpZiB5b3VyIFRDUCBpbXBsZW1lbnRhdGlvbiBpcyBlZmZpY2llbnQgYWJvdXQgZmlsbGlu ZyBwYWNrZXRzLCB0aGUgZGlmZmVyZW5jZSBpbiB0aGVzZSBwcm9wb3NhbHMgaXM8YnI+dGhhdDo8 YnI+PGJyPiogaW4gVENQIGEgcmVxdWVzdCBjYW4gc3BhbiBtdWx0aXBsZSBwYWNrZXRzLiBUaGF0 IGlzLCBzYXkgdGhlIHBhY2tldDxicj5oYXMgbm90IHF1aXRlIGVub3VnaCBzcGFjZSBmb3IgdGhl IGZpbmFsIHJlcXVlc3QgaW4gdGhlIHBhY2tldC48YnI+PGJyPiogVGhlIG92ZXJoZWFkL2Jvb2tr ZWVwaW5nIGJldHdlZW4gdGhlIHR3byBwcm9wb3NhbHMgd291bGQgYmUgZGlmZmVyZW50PGJyPmlu IHRlcm1zIG9mIG92ZXJoZWFkIGJ5dGVzIGluIGEgcGFja2V0Ljxicj48YnI+U28sIGZvciB0aGUg bXVsdGlwbGUgcmVxdWVzdHMgcHJvcG9zYWwgdG8gYmUgYSBhZHZhbnRhZ2UsIGl0cyBib29ra2Vl cGluZy9vdmVyaGVhZCB3b3VsZCBuZWVkIHRvIGJlIHN1ZmZpY2llbnRseSBiZXR0ZXIgdGhhbiBU Q1AgdG8ganVzdGlmeSBiZXR0ZXIgYmFuZHdpZHRoIHV0aWxpemF0aW9uLjxicj48YnI+SGF2ZSBJ IGdvdCB0aGF0IHJpZ2h0Pzxicj48YnI+SWYgc28sIGNhbiB5b3UgaGVscCBleHBsYWluIGhvdyB0 aGF0IGFjdHVhbGx5IHdvcmtzIG91dCB0byBiZSB0aGUgY2FzZT88bzpwPjwvbzpwPjwvcD48L2Rp dj48L2JvZHk+PC9odG1sPg== --_000_D5A6F3355F664C40AFB65BB1277D8D45040EDB301AMAAX7MCDC101A_-- From nobody Wed Aug 19 23:14:16 2015 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 0326A1B2C0E; Wed, 19 Aug 2015 23:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6WDwM5Umt0K; Wed, 19 Aug 2015 23:14:04 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310A81B2C0D; Wed, 19 Aug 2015 23:14:01 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id B131943A93; Thu, 20 Aug 2015 08:13:59 +0200 (CEST) To: "radext@ietf.org" , draft-ietf-radext-bigger-packets.authors@ietf.org From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <55D57021.8060308@restena.lu> Date: Thu, 20 Aug 2015 08:13:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iO8BuOTiwDnxcl9ujI36neDbokr7CXcim" Archived-At: Subject: [radext] Questions about draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:14:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iO8BuOTiwDnxcl9ujI36neDbokr7CXcim Content-Type: multipart/mixed; boundary="------------060409090606070000050308" This is a multi-part message in MIME format. --------------060409090606070000050308 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I'm currently writing the document writeup of draft-ietf-radext-bigger-packets-03 and have a few questions that came up during document review and the Technical Summary question. My apologies if they were already discussed on the list; please provide a pointer if so. I will be opening one TRAC issue for each item below. It would be nice if responses were made in TRAC, or at least in the thread which is started by the creation of the TRAC ticket. 1) Does the document require an "Updates" relationship to RFC2865? RFC2865 sets the maximum content of the Length field in a RADIUS datagram to 4096; this specification lifts that restriction. 2) In the Abstract, I read: "[...] this specification introduces no new experimental evaluation criteria beyond those in the base TCP specification" I wonder if this is really a clear-cut situation. Interoperability (backward/forward compatibility) is given a lot of thought and makes a number of assumptions. One such assumption is that bigger-packets is for new use cases (only?). It is however easy to construct cases where bigger-packets is also of use for existing RADIUS uses, like this one: IEEE 802.1X authentication on a wired network with jumbo frames enabled. Layer 2 EAPoL payloads could grow to 9K, which would typically be signalled by a Framed-MTU attribute; and which could trigger 9K of EAP-Message payload. I understand that the general statement of "SHOULD NOT generate a larger response than 4096 by default" catches this case (for implementation actually honoring the SHOULD NOT, which is sadly not a given). But it makes me wonder if the topic is indeed so easy. Another example which makes assumptions is that closure of a TCP session when sending a big packet is taken as an indicator for non-support of this specification. There are many other reasons why the TCP session might go down (firewall state timeouts...). The client would unjustifiedly reduce its transmission size for ... how long? Eternity? That would mean a permanent loss of the big-packets feature. As a suggestion: the Rationale section already has a better mechanism - after TCP closure, start the next TCP session with the Status-Server max-size discovery. It might be an idea to mandate this after every TCP closure which occurs for reasons where a doubt exists - not only for high-volume servers. So, how does the group feel about recognising that backward compatibility problems are something that should be evaluated in this experiment? I could imagine a text like OLD: "However, this specification introduces no new experimental evaluation criteria beyond those in the base TCP specification; this specification can be evaluated along with that one for advancement on the standards track." NEW: "This specification introduces backward compatibility issues with implementations of RFC6613 which do not support this experiment, and with proxies which need to proxy an incoming large packet to a size-constrained RFC2865 transport RADIUS server. The real-life consequences of this lack of backward compatibility are to be studied in and evaluated during the assessment of this experiment before the features are sent to Standards Track." 3) More specifically on Compatibility, section 3 states around dynamic discovery: "If dynamic discovery mechanisms are supported, configuration SHOULD be provided for the maximum size of clients and servers in each dynamic discovery category." It is unclear to me what such a "category" would be. During the discovery pahse, DNS has no leeway to discover maximum packet sizes. There is also only one service and protocol tag. It remains unclear to me how different groups of discovered servers could be put into distinct categories. If the use of distinct, and non-standard service and protocol tags is the vehicle to do this, this should be stated explicitly in the document. Maybe it would help to require a Status-Server negotiation as per section 3.2 as first packet exchange on newly established dynamic discovery TCP streams? This would obsolete the concept of configured categories. 4) Cexistence with RADIUS Fragmentation, clause 1. The notion of an endpoint is introduced. It appears to me like the decision to use either bigger-packets or RADIUS Fragementation is made on a hop-by-hop basis. Did you mean something like "next hop" (as that next hop may be an endpoint, or another proxy). I assume that when deciding to use RADIUS Fragmentation for a next hop whose support for this specification is not known, the generated request packet would still be augmented with a Response-Length attribute to learn about the next hop's capabilities? If so, can this be made explicit in the text? 5) For "Document quality", I would mention implementations which are known to implement the spec. Are there any? If so, you may want to add an RFC6982 "Implementation Status" section. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------060409090606070000050308 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------060409090606070000050308-- --iO8BuOTiwDnxcl9ujI36neDbokr7CXcim Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJV1XAnAAoJEMDeajWKOdxmtkIP/3z/55fhpjUf0SBRME0uTlpG vUjwtx3Tkpy31345hM9Er0vsUjMUthZdiSPSGFg5yUAcsDr92mtpY2EG5hooMoHL fllerAb03oa4mZT95Vur8lwwmqb/Y5ldBY/JuaP1P4rpdiQE7ertHuJBnRlh1bSG 4OaG3t+g6caRcjtPjSVSqX7P4E+EwzW0Yb+ndQlrktGAOha6uV7AcrV5zgSmvTwr eA20cTdey5XmLbJioi7YdYcgOuefMQ7GNeXm5HAsodI9WtSQcAiek0cZKHvHSQ5u MtOMAon6vjRGviGATiIVK+8EKGe8zzm3ssS8EN23543W8UENLMwGvgrY/gEF46B5 Rt0trXagE5psrJ5T5amqotR/F6lJnOkyzuwBGg7pkJNXrWe3tdsj3KtcUTKG9DPS d7oO1iaJwqN7PBC1I2MaSuNdF2b4vSiEbCd1FGXRNT8LuRR4hVvRj9cvdIZfkzia VTcmWqgHcWH08Bb1CbjV3Mg2dH6PI9iQ+Al9rt6C3LCh/q9y2CF5HziDC++UEBOx RfP4/oaSkqY+QGJqzSVyCmZOzghBnRbQNdQ3Von8QVBdz297VJPYsIrjEKwDlwss 9eL/11yUU6epMioSfsSDaHTRiJiDKZLq8KjhlfDOqADjVZjn3WbEk0NtjJqBKoB0 m1w9DlJ/AUZNZtYB/rW4 =KHhA -----END PGP SIGNATURE----- --iO8BuOTiwDnxcl9ujI36neDbokr7CXcim-- From nobody Wed Aug 19 23:17:59 2015 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 2EDE11B2C14 for ; Wed, 19 Aug 2015 23:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smN20782yCMj for ; Wed, 19 Aug 2015 23:17:56 -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 25AA61B2C12 for ; Wed, 19 Aug 2015 23:17:56 -0700 (PDT) Received: from localhost ([::1]:39543 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSJAg-00053E-S4; Wed, 19 Aug 2015 23:17:54 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 20 Aug 2015 06:17:54 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/190 Message-ID: <065.b540a7fe9686d3ebabdd62233b43113c@trac.tools.ietf.org> X-Trac-Ticket-ID: 190 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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 Archived-At: Cc: radext@ietf.org Subject: [radext] #190 (Crypto-Agility): Does the document require an "Updates" relationship to RFC2865? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:17:57 -0000 #190: Does the document require an "Updates" relationship to RFC2865? RFC2865 sets the maximum content of the Length field in a RADIUS datagram to 4096; this specification lifts that restriction. -- --------------------------------------+----------------- Reporter: stefan.winter@restena.lu | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Crypto-Agility | Version: Severity: - | Keywords: --------------------------------------+----------------- Ticket URL: radext From nobody Wed Aug 19 23:18:30 2015 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 25A781B2C18 for ; Wed, 19 Aug 2015 23:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hff2eSJV-0RT for ; Wed, 19 Aug 2015 23:18:25 -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 0C37D1B2C12 for ; Wed, 19 Aug 2015 23:18:25 -0700 (PDT) Received: from localhost ([::1]:39560 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSJB9-00074c-8p; Wed, 19 Aug 2015 23:18:23 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 20 Aug 2015 06:18:23 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/190#comment:1 Message-ID: <080.0087de562aeae1667bfc43d25a94b478@trac.tools.ietf.org> References: <065.b540a7fe9686d3ebabdd62233b43113c@trac.tools.ietf.org> X-Trac-Ticket-ID: 190 In-Reply-To: <065.b540a7fe9686d3ebabdd62233b43113c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20150820061825.0C37D1B2C12@ietfa.amsl.com> Resent-Date: Wed, 19 Aug 2015 23:18:25 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #190 (bigger-packets): Does the document require an "Updates" relationship to RFC2865? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:18:29 -0000 #190: Does the document require an "Updates" relationship to RFC2865? Changes (by stefan.winter@restena.lu): * owner: => draft-ietf-radext-bigger-packets@tools.ietf.org * type: defect => enhancement * component: Crypto-Agility => bigger-packets -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Aug 19 23:20:34 2015 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 165E31B2C16 for ; Wed, 19 Aug 2015 23:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 ssKiBnPCyGF0 for ; Wed, 19 Aug 2015 23:20:31 -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 E6DC21B2C14 for ; Wed, 19 Aug 2015 23:20:30 -0700 (PDT) Received: from localhost ([::1]:39655 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSJDC-0007RX-MW; Wed, 19 Aug 2015 23:20:30 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 20 Aug 2015 06:20:30 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/191 Message-ID: <065.6531aba1b0a79386444f20fdda1cfb0f@trac.tools.ietf.org> X-Trac-Ticket-ID: 191 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20150820062030.E6DC21B2C14@ietfa.amsl.com> Resent-Date: Wed, 19 Aug 2015 23:20:30 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: [radext] #191 (bigger-packets): Is evaluation of backwards compatibility part of the experiment's goals? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:20:34 -0000 #191: Is evaluation of backwards compatibility part of the experiment's goals? In the Abstract, I read: "[...] this specification introduces no new experimental evaluation criteria beyond those in the base TCP specification" I wonder if this is really a clear-cut situation. Interoperability (backward/forward compatibility) is given a lot of thought and makes a number of assumptions. One such assumption is that bigger-packets is for new use cases (only?). It is however easy to construct cases where bigger-packets is also of use for existing RADIUS uses, like this one: IEEE 802.1X authentication on a wired network with jumbo frames enabled. Layer 2 EAPoL payloads could grow to 9K, which would typically be signalled by a Framed-MTU attribute; and which could trigger 9K of EAP-Message payload. I understand that the general statement of "SHOULD NOT generate a larger response than 4096 by default" catches this case (for implementation actually honoring the SHOULD NOT, which is sadly not a given). But it makes me wonder if the topic is indeed so easy. Another example which makes assumptions is that closure of a TCP session when sending a big packet is taken as an indicator for non-support of this specification. There are many other reasons why the TCP session might go down (firewall state timeouts...). The client would unjustifiedly reduce its transmission size for ... how long? Eternity? That would mean a permanent loss of the big-packets feature. As a suggestion: the Rationale section already has a better mechanism - after TCP closure, start the next TCP session with the Status-Server max-size discovery. It might be an idea to mandate this after every TCP closure which occurs for reasons where a doubt exists - not only for high-volume servers. So, how does the group feel about recognising that backward compatibility problems are something that should be evaluated in this experiment? I could imagine a text like OLD: "However, this specification introduces no new experimental evaluation criteria beyond those in the base TCP specification; this specification can be evaluated along with that one for advancement on the standards track." NEW: "This specification introduces backward compatibility issues with implementations of RFC6613 which do not support this experiment, and with proxies which need to proxy an incoming large packet to a size-constrained RFC2865 transport RADIUS server. The real-life consequences of this lack of backward compatibility are to be studied in and evaluated during the assessment of this experiment before the features are sent to Standards Track." -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Aug 19 23:22:08 2015 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 541F71B2C1A for ; Wed, 19 Aug 2015 23:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 OxCx0Nmo_bvj for ; Wed, 19 Aug 2015 23:22:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0C01B2C16 for ; Wed, 19 Aug 2015 23:22:06 -0700 (PDT) Received: from localhost ([::1]:39753 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSJEj-0003tf-Ty; Wed, 19 Aug 2015 23:22:05 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 20 Aug 2015 06:22:05 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/192 Message-ID: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> X-Trac-Ticket-ID: 192 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20150820062206.3B0C01B2C16@ietfa.amsl.com> Resent-Date: Wed, 19 Aug 2015 23:22:06 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:22:07 -0000 #192: unclear meaning of "configured categories" of dynamically discovered servers "If dynamic discovery mechanisms are supported, configuration SHOULD be provided for the maximum size of clients and servers in each dynamic discovery category." It is unclear to me what such a "category" would be. During the discovery pahse, DNS has no leeway to discover maximum packet sizes. There is also only one service and protocol tag. It remains unclear to me how different groups of discovered servers could be put into distinct categories. If the use of distinct, and non-standard service and protocol tags is the vehicle to do this, this should be stated explicitly in the document. Maybe it would help to require a Status-Server negotiation as per section 3.2 as first packet exchange on newly established dynamic discovery TCP streams? This would obsolete the concept of configured categories. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Aug 19 23:22:59 2015 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 91EA31B2C1B for ; Wed, 19 Aug 2015 23:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 zF-V9RLywaWk for ; Wed, 19 Aug 2015 23:22:56 -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 80ACF1B2C16 for ; Wed, 19 Aug 2015 23:22:56 -0700 (PDT) Received: from localhost ([::1]:39855 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSJFY-0007Ao-8Q; Wed, 19 Aug 2015 23:22:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 20 Aug 2015 06:22:56 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/193 Message-ID: <065.5dfecdab2a3782e0ece43e585d9b8dfb@trac.tools.ietf.org> X-Trac-Ticket-ID: 193 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20150820062256.80ACF1B2C16@ietfa.amsl.com> Resent-Date: Wed, 19 Aug 2015 23:22:56 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: [radext] #193 (bigger-packets): clarify "endpoint" for coexistence with RADIUS fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:22:57 -0000 #193: clarify "endpoint" for coexistence with RADIUS fragmentation The notion of an endpoint is introduced. It appears to me like the decision to use either bigger-packets or RADIUS Fragementation is made on a hop-by-hop basis. Did you mean something like "next hop" (as that next hop may be an endpoint, or another proxy). I assume that when deciding to use RADIUS Fragmentation for a next hop whose support for this specification is not known, the generated request packet would still be augmented with a Response-Length attribute to learn about the next hop's capabilities? If so, can this be made explicit in the text? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Aug 19 23:23:41 2015 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 8BE431B2C1C for ; Wed, 19 Aug 2015 23:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 dY9qkeeJ_SX5 for ; Wed, 19 Aug 2015 23:23:35 -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 9276B1B2C1B for ; Wed, 19 Aug 2015 23:23:35 -0700 (PDT) Received: from localhost ([::1]:39960 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSJGB-0000OU-8Y; Wed, 19 Aug 2015 23:23:35 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 20 Aug 2015 06:23:35 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/194 Message-ID: <065.ef5bf9284d0e734516ceae66e2ae74f3@trac.tools.ietf.org> X-Trac-Ticket-ID: 194 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20150820062335.9276B1B2C1B@ietfa.amsl.com> Resent-Date: Wed, 19 Aug 2015 23:23:35 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: [radext] #194 (bigger-packets): find and list implementations X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:23:39 -0000 #194: find and list implementations For "Document quality", I would mention implementations which are known to implement the spec. Are there any? If so, you may want to add an RFC6982 "Implementation Status" section. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Aug 19 23:24:35 2015 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 1C2E01B2C1E for ; Wed, 19 Aug 2015 23:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 xknafakQaN3Q for ; Wed, 19 Aug 2015 23:24: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 EDBC91ACD2B for ; Wed, 19 Aug 2015 23:24:32 -0700 (PDT) Received: from localhost ([::1]:40132 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSJH6-0003PM-LZ; Wed, 19 Aug 2015 23:24:32 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 20 Aug 2015 06:24:32 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/195 Message-ID: <065.7a65c858f80799ca336eb6e4d4dc9eb2@trac.tools.ietf.org> X-Trac-Ticket-ID: 195 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20150820062432.EDBC91ACD2B@ietfa.amsl.com> Resent-Date: Wed, 19 Aug 2015 23:24:32 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: [radext] #195 (bigger-packets): minor nits X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:24:34 -0000 #195: minor nits 1) Abstract: "... to new use cases where the 4096-octet maximum RADIUS packet proves problematic." This sounds garbled or too complex for me as a non-native speaker. The following would do wonders: "... to new use cases where the 4096-octet maximum size limit of RADIUS packets proves problematic." 2) The correct reference for RADIUS over TCP is RFC6613, not RFC6113. There are multiple occurences of this typo. 3) please replace the reference [I-D.ietf-radext-radius-fragmentation] with [RFC7499]. 4) In section 4, you state "Proxies MUST not forward a Protocol-Error...". I believe you meant a capital NOT as in MUST NOT. 5) In section six, an s is missing: "In this case the attribute indicate ..." (indicates) 6) In Security Considerations, a reference to RFC6613 is not in the standard [] notation. 7) In the same section, an e is missing: "If these attacks ar accaptable ..." (are) -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: bigger-packets | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Aug 20 00:03:28 2015 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 784E41B2C3E for ; Thu, 20 Aug 2015 00:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 C1xhgRijmize for ; Thu, 20 Aug 2015 00:03:26 -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 676A81B2C3C for ; Thu, 20 Aug 2015 00:03:26 -0700 (PDT) Received: from localhost ([::1]:41925 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZSJsk-0000G2-5Q; Thu, 20 Aug 2015 00:03:26 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 20 Aug 2015 07:03:25 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/195#comment:1 Message-ID: <080.6971d2af308f76d0f8c8ada4823d6fef@trac.tools.ietf.org> References: <065.7a65c858f80799ca336eb6e4d4dc9eb2@trac.tools.ietf.org> X-Trac-Ticket-ID: 195 In-Reply-To: <065.7a65c858f80799ca336eb6e4d4dc9eb2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20150820070326.676A81B2C3C@ietfa.amsl.com> Resent-Date: Thu, 20 Aug 2015 00:03:26 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #195 (bigger-packets): minor nits X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 07:03:27 -0000 #195: minor nits Comment (by stefan.winter@restena.lu): One more: the References sections are labelled "Normative References" and "References". The second section should be labelled "Informative References". -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Aug 20 03:04:42 2015 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 8D52D1A8797 for ; Thu, 20 Aug 2015 03:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAVgFsMqbf2r for ; Thu, 20 Aug 2015 03:04:40 -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 2A0A61A1A92 for ; Thu, 20 Aug 2015 03:04:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id EA2E4207A5; Thu, 20 Aug 2015 06:03:02 -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 sIgGc45NaRo8; Thu, 20 Aug 2015 06:03:02 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (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; Thu, 20 Aug 2015 06:03:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 42D248094A; Thu, 20 Aug 2015 06:04:38 -0400 (EDT) From: Sam Hartman To: References: <15A2E89E-6AD6-43A1-A233-2DD91D5217C2@deployingradius.com> Date: Thu, 20 Aug 2015 06:04:36 -0400 In-Reply-To: (Aravind Sridharan's message of "Thu, 20 Aug 2015 09:47:23 +0530") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Archived-At: Cc: radext@ietf.org, Sanal_Kumar_Sivarama@Dell.com, chandru.dav@gmail.com, aland@deployingradius.com Subject: Re: [radext] New Draft for RADIUS Message Bundling X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 10:04:41 -0000 >>>>> writes: > Hi Sam, Thanks a lot again for your review comments. > Yes, agree with you. Finally it comes down to the following: > 1) Without bundling (in case of individual packets), there is > the overhead of adding TCP and Ethernet headers to individual > RADIUS packets sent to server. > 2) With Bundling, the overhead of TCP and Ethernet Header > additions are avoided. Instead, now it€™s the overhead > of bookkeeping and bundling multiple RADIUS requests in the single > message. Except that even without bundling TCP will stick more than one RADIUS message in a single packet. Let's say that your radius messages are 150 bytes or so, and you can get 9 of them into a TCP packet. So, the TCP and ethernet headers are amortized over 9 messages without your proposal. Let's say that you somehow save enough space that you can get a 10th request into the packet. That would be doing fairly good in my opinion for your proposal. Even if you could do that well, I don't understand how it's worth standardizing. It seems like you get a vast majority of the benefits simply from putting more than one RADIUS message into a single TCP packet, and we get that today. From nobody Thu Aug 20 07:12:20 2015 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 9E5B01A6EE6 for ; Thu, 20 Aug 2015 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SDqjT2gLH4t for ; Thu, 20 Aug 2015 07:12:17 -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 DDDD21ACE5E for ; Thu, 20 Aug 2015 07:12:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C7F40207A9; Thu, 20 Aug 2015 10:10:39 -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 Qdt6rlh-FDx4; Thu, 20 Aug 2015 10:10:39 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (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; Thu, 20 Aug 2015 10:10:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9D93980D3A; Thu, 20 Aug 2015 10:12:15 -0400 (EDT) From: Sam Hartman To: radext@ietf.org References: <065.b540a7fe9686d3ebabdd62233b43113c@trac.tools.ietf.org> Date: Thu, 20 Aug 2015 10:12:15 -0400 In-Reply-To: <065.b540a7fe9686d3ebabdd62233b43113c@trac.tools.ietf.org> (radext issue tracker's message of "Thu, 20 Aug 2015 06:17:54 -0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: stefan.winter@restena.lu Subject: Re: [radext] #190 (Crypto-Agility): Does the document require an "Updates" relationship to RFC2865? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:12:18 -0000 >>>>> "radext" == radext issue tracker writes: radext> #190: Does the document require an "Updates" relationship to radext> RFC2865? RFC2865 sets the maximum content of the Length radext> field in a RADIUS datagram to 4096; this specification lifts radext> that restriction. I don't know. I'd have argued the update happens when this goes standards track. I don't care though; please tell me whether you want an update. From nobody Thu Aug 20 07:14:32 2015 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 5B37A1ACE57 for ; Thu, 20 Aug 2015 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wJTyMSDMY7F for ; Thu, 20 Aug 2015 07:14:30 -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 6CF8C1A872D for ; Thu, 20 Aug 2015 07:14:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 44264207A8; Thu, 20 Aug 2015 10:12:53 -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 RBtQjDUJF1pQ; Thu, 20 Aug 2015 10:12:52 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (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; Thu, 20 Aug 2015 10:12:52 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 165E880D3A; Thu, 20 Aug 2015 10:14:29 -0400 (EDT) From: Sam Hartman To: radext@ietf.org References: <065.6531aba1b0a79386444f20fdda1cfb0f@trac.tools.ietf.org> Date: Thu, 20 Aug 2015 10:14:29 -0400 In-Reply-To: <065.6531aba1b0a79386444f20fdda1cfb0f@trac.tools.ietf.org> (radext issue tracker's message of "Thu, 20 Aug 2015 06:20:30 -0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] #191 (bigger-packets): Is evaluation of backwards compatibility part of the experiment's goals? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:14:31 -0000 >>>>> "Fradext" == radext issue tracker writes: Fradext> So, how does the group feel about recognising that Fradext> backward compatibility problems are something that should Fradext> be evaluated in this experiment? I could imagine a text Fradext> like I'd rather just fold this in when we bring TCP to standards track arguing that one of the experimental results of the TCP experiment is that we needed bigger packets. From nobody Thu Aug 20 07:15:56 2015 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 ABFA71A0404 for ; Thu, 20 Aug 2015 07:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIQ6i2UU09c1 for ; Thu, 20 Aug 2015 07:15:54 -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 922A51A026C for ; Thu, 20 Aug 2015 07:15:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 806C9207A8; Thu, 20 Aug 2015 10:14:17 -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 8b_4G5kLkHzQ; Thu, 20 Aug 2015 10:14:17 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (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; Thu, 20 Aug 2015 10:14:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5181680D3A; Thu, 20 Aug 2015 10:15:53 -0400 (EDT) From: Sam Hartman To: radext@ietf.org References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> Date: Thu, 20 Aug 2015 10:15:53 -0400 In-Reply-To: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> (radext issue tracker's message of "Thu, 20 Aug 2015 06:22:05 -0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:15:55 -0000 >>>>> "radext" == radext issue tracker writes: radext> #192: unclear meaning of "configured categories" of radext> dynamically discovered servers radext> "If dynamic discovery mechanisms are supported, radext> configuration SHOULD be provided for the maximum size of radext> clients and servers in each dynamic discovery category." Well, I'm aware of two categories today: * servers discovered via the DNS-based experimental document we're working on here * Servers discovered via Project moonshot's Trust Router architecture There may be more dynamic discovery mechanisms in the future. Can you suggest text to clarify this? From nobody Thu Aug 20 07:18:29 2015 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 5A2F01ACE9A for ; Thu, 20 Aug 2015 07:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3OQ5Mfxh0vl for ; Thu, 20 Aug 2015 07:18:27 -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 7051B1ACE5D for ; Thu, 20 Aug 2015 07:18:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 32F3D207A8; Thu, 20 Aug 2015 10:16:50 -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 hw5ObrxQ8W1O; Thu, 20 Aug 2015 10:16:50 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (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; Thu, 20 Aug 2015 10:16:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A12A80D3A; Thu, 20 Aug 2015 10:18:26 -0400 (EDT) From: Sam Hartman To: radext@ietf.org References: <065.5dfecdab2a3782e0ece43e585d9b8dfb@trac.tools.ietf.org> Date: Thu, 20 Aug 2015 10:18:26 -0400 In-Reply-To: <065.5dfecdab2a3782e0ece43e585d9b8dfb@trac.tools.ietf.org> (radext issue tracker's message of "Thu, 20 Aug 2015 06:22:56 -0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] #193 (bigger-packets): clarify "endpoint" for coexistence with RADIUS fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:18:28 -0000 I'm happy to address this in the next rev; it seems easy. From nobody Thu Aug 20 12:01:45 2015 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 5AF451A88BE; Thu, 20 Aug 2015 12:01:44 -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 RQ4L-Piyo-TU; Thu, 20 Aug 2015 12:01:41 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id C26541AD2D9; Thu, 20 Aug 2015 12:01:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E8B13224059A; Thu, 20 Aug 2015 21:01:34 +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 b6lxH89oa3jh; Thu, 20 Aug 2015 21:01:34 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 921CD2240371; Thu, 20 Aug 2015 21:01:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <55D57021.8060308@restena.lu> Date: Thu, 20 Aug 2015 15:01:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <183E3AC7-A5CB-43D4-ADCA-E0B7DD04B43C@deployingradius.com> References: <55D57021.8060308@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" , draft-ietf-radext-bigger-packets.authors@ietf.org Subject: Re: [radext] Questions about draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 19:01:44 -0000 On Aug 20, 2015, at 2:13 AM, Stefan Winter = wrote: > Another example which makes assumptions is that closure of a TCP = session > when sending a big packet is taken as an indicator for non-support of > this specification. There are many other reasons why the TCP session > might go down (firewall state timeouts...). The client would > unjustifiedly reduce its transmission size for ... how long? Eternity? > That would mean a permanent loss of the big-packets feature. As a > suggestion: the Rationale section already has a better mechanism - = after > TCP closure, start the next TCP session with the Status-Server = max-size > discovery. It might be an idea to mandate this after every TCP closure > which occurs for reasons where a doubt exists - not only for = high-volume > servers. Explicit signalling sounds good to me. > So, how does the group feel about recognising that backward > compatibility problems are something that should be evaluated in this > experiment? I could imagine a text like >=20 > OLD: > "However, this specification introduces no new > experimental evaluation criteria beyond those in the base TCP > specification; this specification can be evaluated along with that > one for advancement on the standards track." >=20 > NEW: > "This specification introduces backward compatibility issues with > implementations of RFC6613 which do not support this experiment, and > with proxies which need to proxy an incoming large packet to a > size-constrained RFC2865 transport RADIUS server. The real-life > consequences of this lack of backward compatibility are to be studied = in > and evaluated during the assessment of this experiment before the > features are sent to Standards Track." Sounds good. > Maybe it would help to require a Status-Server negotiation as per > section 3.2 as first packet exchange on newly established dynamic > discovery TCP streams? This would obsolete the concept of configured > categories. That's a good idea. > 4) > Cexistence with RADIUS Fragmentation, clause 1. > The notion of an endpoint is introduced. It appears to me like the > decision to use either bigger-packets or RADIUS Fragementation is made > on a hop-by-hop basis. Yes, and a protocol basis. UDP gets fragmented, TCP gets bigger = packets. I'd be wary of using bigger packets with UDP. The document should = probably recommend against it. > 5) For "Document quality", I would mention implementations which are > known to implement the spec. Are there any? If so, you may want to add > an RFC6982 "Implementation Status" section. Uh.... clickety click... I'll take a look at the implementation side = of things. :) But that requires IANA allocation of the packet code and = attributes. On that note: Response-Length is a 2-octet unsigned integer of = maximum response length. Can that be changed to be of data type "integer"? And maybe = reference data types? I'll refresh the data types document today. Alan DeKok. From nobody Thu Aug 20 23:06:25 2015 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 A84421A879B; Thu, 20 Aug 2015 23:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ikS2lZkR6gR; Thu, 20 Aug 2015 23:06:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 709F61A1BE7; Thu, 20 Aug 2015 23:06:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150821060622.26645.70583.idtracker@ietfa.amsl.com> Date: Thu, 20 Aug 2015 23:06:22 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-datatypes-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 06:06:23 -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 : Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Author : Alan DeKok Filename : draft-ietf-radext-datatypes-00.txt Pages : 33 Date : 2015-08-20 Abstract: RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-datatypes-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 21 00:00:15 2015 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 615D31A6FEF for ; Fri, 21 Aug 2015 00:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp7Te6wZXPch for ; Fri, 21 Aug 2015 00:00:12 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BA91A1F20 for ; Fri, 21 Aug 2015 00:00:11 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 481AC402D7 for ; Fri, 21 Aug 2015 09:00:10 +0200 (CEST) To: radext@ietf.org References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <55D6CC73.9020002@restena.lu> Date: Fri, 21 Aug 2015 09:00:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aiVcPeSBpkrNp8QCjDEIiQwDBttIBShXL" Archived-At: Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers 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, 21 Aug 2015 07:00:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aiVcPeSBpkrNp8QCjDEIiQwDBttIBShXL Content-Type: multipart/mixed; boundary="------------040408030304010405090700" This is a multi-part message in MIME format. --------------040408030304010405090700 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > radext> #192: unclear meaning of "configured categories" of > radext> dynamically discovered servers >=20 > radext> "If dynamic discovery mechanisms are supported, > radext> configuration SHOULD be provided for the maximum size of > radext> clients and servers in each dynamic discovery category." >=20 > Well, I'm aware of two categories today: >=20 > * servers discovered via the DNS-based experimental document we're > working on here >=20 > * Servers discovered via Project moonshot's Trust Router architecture >=20 > There may be more dynamic discovery mechanisms in the future. If you put max packet sizes into configuration, and there is one config item for DNS, and one for Trust Router, then the configuration is very coarse-grained, like: "all servers discovered by trust router support bigger packets; no servers discovered by DNS support bigger packets" I don't think it's realistic that this coarse-grained grouping maps into real deployment characteristics. DNS discovery might lead to some RADIUS/TLS hosts wwhich support bigger-TCP; some other discovered servers might only support 4096-TCP. And (probably) the same is true for discovered trust router entities. > Can you suggest text to clarify this? I don't think a mere text change for clarification helps here. I had suggested to change the protocol so that for any dynamically discovered server, first run a Status-Server discovery to find out about the supported sizes, and only then commence normal RADIUS traffic. Then there is no need for configuration at all, and the per-category concept can go away. I can suggest text for *that* :-) Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------040408030304010405090700 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040408030304010405090700-- --aiVcPeSBpkrNp8QCjDEIiQwDBttIBShXL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJV1sx6AAoJEMDeajWKOdxmXykQAJmJa3q1azCSLTQTiLehQvR6 fLK93JI9tH64W5RQXbXUsZmYJJF4mIvQ1xY2Qu5JUosPNZ/SBQ8geiEN5912qKNG XUZDyJBWZHzc7KAzgc28jX4oRdcdRXhC2ciV8h5g4K9Q9VlvL3ALLzezltkd3AXw fgpB7fanZjcAprDedzF1DrhY/I4mvzylxRxXy1Gc3LNknVwdpGmCRq0o1V4uz3C4 jBz1U0dErVD501j2zP1DPP+YbiZvgdsjGs0lKWXk2lJxJQ+/YDnVgq9s+mRgNo5o Xlvo0/pqXWUneO7g7AVWyZ1fLYfFR9TIJ/1fWY/62DAMc2jjaTWzee2/0wvlgdY9 q2aCTSmW19qloI8olLgfttHYKeoR9FdH27L+vmkHC+/e+DlmShcrb2VUmyvo4Z7k ASpYYIxaO/NrpeJoATDxkA1zh/npb/Zd9cconjeXYdNOOMuDX/JrR/VqEzIXcW0a xOLaSiCZfaM5mnTCNzsZ7Uxaadfbl3bvgQi5zdqBVaSSSTRHlN8b0H9abodZG86T Z9zDJS2WCrxD2dKqvrdmG9Zc9e5fG/c/Hc0VhvWJa8/4uZKEMiOzfdQRa28CZZ1i /ZvVEU41IfB0sRPciHS92Tm924AwqT4+7dvSXPyjaxtQCDNiSNXRF5oM4BehjzhZ TgJu/+z7lysatWJlg+J6 =1jiI -----END PGP SIGNATURE----- --aiVcPeSBpkrNp8QCjDEIiQwDBttIBShXL-- From nobody Fri Aug 21 06:18:58 2015 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 000DB1A8F3F for ; Fri, 21 Aug 2015 06:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDuZnYvJcNO9 for ; Fri, 21 Aug 2015 06:18:55 -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 25E711A8F3A for ; Fri, 21 Aug 2015 06:18:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B096C207A8; Fri, 21 Aug 2015 09:17:14 -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 MlO3ackthoZ5; Fri, 21 Aug 2015 09:17:14 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 21 Aug 2015 09:17:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C7B6682136; Fri, 21 Aug 2015 09:18:50 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> <55D6CC73.9020002@restena.lu> Date: Fri, 21 Aug 2015 09:18:50 -0400 In-Reply-To: <55D6CC73.9020002@restena.lu> (Stefan Winter's message of "Fri, 21 Aug 2015 09:00:03 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers 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, 21 Aug 2015 13:18:57 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Hi, radext> #192: unclear meaning of "configured categories" of radext> dynamically discovered servers >> radext> "If dynamic discovery mechanisms are supported, radext> configuration SHOULD be provided for the maximum size of radext> clients and servers in each dynamic discovery category." >> >> Well, I'm aware of two categories today: >> >> * servers discovered via the DNS-based experimental document >> we're working on here >> >> * Servers discovered via Project moonshot's Trust Router >> architecture >> >> There may be more dynamic discovery mechanisms in the future. Stefan> If you put max packet sizes into configuration, and there is Stefan> one config item for DNS, and one for Trust Router, then the Stefan> configuration is very coarse-grained, like: Stefan> "all servers discovered by trust router support bigger Stefan> packets; no servers discovered by DNS support bigger Stefan> packets" Stefan> I don't think it's realistic that this coarse-grained Stefan> grouping maps into real deployment characteristics. I actually do. I think the particular configuration you quote above might be a good fit for a system that uses both Moonshot and eduroam. Especially if you make it a bit finer grained by allowing each consortuim/set of CAs/whatever you want to describe it as for DNS have its own configuration. I think I need something like this as a minimum so I'd like to have a related SHOULd in the spec. I'd be happy to get input on what approaches would give me this but work for you. --Sam From nobody Fri Aug 21 08:14:36 2015 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 04AFC1AC3AC for ; Fri, 21 Aug 2015 08:14:36 -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 H3vvvxwZXfRx for ; Fri, 21 Aug 2015 08:14:34 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 497101AC39C for ; Fri, 21 Aug 2015 08:14:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id BA19A224048D for ; Fri, 21 Aug 2015 17:14:29 +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 3-meO_fTdoFm for ; Fri, 21 Aug 2015 17:14:29 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 0FEA42240465 for ; Fri, 21 Aug 2015 17:14:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <20150821060622.26645.70583.idtracker@ietfa.amsl.com> Date: Fri, 21 Aug 2015 11:14:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3BC4DD27-90D5-43E5-A4BF-15B8F3ACE75D@deployingradius.com> References: <20150821060622.26645.70583.idtracker@ietfa.amsl.com> To: radext@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-datatypes-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 15:14:36 -0000 I think the document is done. The only technical change from the = previous rev was to add the attributes from RFC 7499. I would request that the WG review the document in detail. = Specifically, the table in Section 3.2 needs validating. The problem is = that many RFCs are unclear or wrong about the data types of the = attributes they define. I've selected the data types which I *believe* are appropriate for the = attributes. But it never hurts for someone else to go over the = exhaustive list of ~200 attributes, and to check each one. :( Alan DeKok. From nobody Fri Aug 21 08:16:19 2015 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 D38461AC39F for ; Fri, 21 Aug 2015 08:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLeZRopH8woX for ; Fri, 21 Aug 2015 08:16:09 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7F31AC3A7 for ; Fri, 21 Aug 2015 08:16:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1637E224048D for ; Fri, 21 Aug 2015 17:16:09 +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 NEzF_wfrvwz7 for ; Fri, 21 Aug 2015 17:16:08 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 49FA92240371 for ; Fri, 21 Aug 2015 17:16:08 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <3BC4DD27-90D5-43E5-A4BF-15B8F3ACE75D@deployingradius.com> Date: Fri, 21 Aug 2015 11:16:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68E7420A-3F1A-42FA-89DE-88415BCE9A49@deployingradius.com> References: <20150821060622.26645.70583.idtracker@ietfa.amsl.com> <3BC4DD27-90D5-43E5-A4BF-15B8F3ACE75D@deployingradius.com> To: radext@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-datatypes-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 15:16:18 -0000 On Aug 21, 2015, at 11:14 AM, Alan DeKok = wrote: > I've selected the data types which I *believe* are appropriate for = the attributes. But it never hurts for someone else to go over the = exhaustive list of ~200 attributes, and to check each one. :( And... double checking it, User-Name is type "string", instead of = "text". I had hoped I could get the simplest things correct... Alan DeKok. From nobody Fri Aug 28 03:48:08 2015 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 28CD71A88EF for ; Fri, 28 Aug 2015 03:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 HxOkslDIk0h6 for ; Fri, 28 Aug 2015 03:48:07 -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 1E4BF1A0041 for ; Fri, 28 Aug 2015 03:48:07 -0700 (PDT) Received: from localhost ([::1]:34354 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZVHCX-00056P-Fv; Fri, 28 Aug 2015 03:48:05 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Fri, 28 Aug 2015 10:48:05 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/195#comment:2 Message-ID: <080.20b2bd7a73878a3d83346f43bdd5e4ad@trac.tools.ietf.org> References: <065.7a65c858f80799ca336eb6e4d4dc9eb2@trac.tools.ietf.org> X-Trac-Ticket-ID: 195 In-Reply-To: <065.7a65c858f80799ca336eb6e4d4dc9eb2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20150828104807.1E4BF1A0041@ietfa.amsl.com> Resent-Date: Fri, 28 Aug 2015 03:48:07 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #195 (bigger-packets): minor nits 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: Fri, 28 Aug 2015 10:48:08 -0000 #195: minor nits Comment (by stefan.winter@restena.lu): And one more: Introduction, line 1: RADIUS is "Remote Authentication Dial In User Service" (s/Access/Authentication/ and s/Server/Service/ and s/-/ / ) -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext