From nobody Mon Jul 4 04:45:41 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBE412D096 for ; Mon, 4 Jul 2016 04:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP-arnYbX2Ke for ; Mon, 4 Jul 2016 04:45:38 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.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 DF53F12B026 for ; Mon, 4 Jul 2016 04:45:37 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8722343A7A; Mon, 4 Jul 2016 13:45:36 +0200 (CEST) To: Alan DeKok , radext@ietf.org References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <577A4C60.2030008@restena.lu> Date: Mon, 4 Jul 2016 13:45:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LEgKsUkp6WslbXS1BXbJBTVptbCroXjEa" Archived-At: Subject: Re: [radext] CoA-proxy wording X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jul 2016 11:45:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LEgKsUkp6WslbXS1BXbJBTVptbCroXjEa Content-Type: multipart/mixed; boundary="QJH1XdWaMP0ETDSvKVjjg5U0G4WdPWacW" From: Stefan Winter To: Alan DeKok , radext@ietf.org Message-ID: <577A4C60.2030008@restena.lu> Subject: Re: [radext] CoA-proxy wording References: In-Reply-To: --QJH1XdWaMP0ETDSvKVjjg5U0G4WdPWacW Content-Type: multipart/mixed; boundary="------------070809010200040402070302" This is a multi-part message in MIME format. --------------070809010200040402070302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Alan, > As discussed today: > > ... > > Due to the requirements of Section 2.3 of [RFC5176], a Visited Network > MUST remove Operator-Name and Operator-NAS-Identifier from any > CoA-Request or Disconnect-Request packet prior to proxying that packet > to a CoA server. This requirement can be phrased more generically. > > All attributes added by a RADIUS proxy when sending packets from the > Visited Network to the Home Network Network MUST be removed by the > equivalent CoA proxy from packets which travel the reverse path. > > ... The deadline for new draft submission is approaching quite quickly. Do you think there's value in spinning up a new rev with the above (and Jouni's contact address changes), and/or discuss the current state of the draft in the meeting in Berlin? 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 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------070809010200040402070302 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----- --------------070809010200040402070302-- --QJH1XdWaMP0ETDSvKVjjg5U0G4WdPWacW-- --LEgKsUkp6WslbXS1BXbJBTVptbCroXjEa 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 iQIcBAEBCgAGBQJXekxgAAoJEMDeajWKOdxmmdcQAM5P6fzOed3djID6zAg5DwPW jTZlH/QT3J86EDXFC1w2hatHbIodVBDwZ1XSZRrNntCMFom8+T/c5rfHM+/jV4c4 B9vcSLzb7FThHHbtv/YWaRvkJKVmm9WG/RLplzTVsHcr6MtB1Wtd+W079np1rWfN f/hJmXTgBsNJafuk0Jr6Gp+/cBZfv0HIszMR2uNHoNY+aRGbgZWeNzNkgPVZmiQp DallUKHgmkwVdjQqJitLy1Pqc4Ce5ZN0UX2wTq/nyqSZY6Pp8txaFmrM9QwMxhfE LudL0iPoHkK3fzGoCC1gIXovjNSl122TFhotGVSLLzsOsqNWG70q50CVLXqq7r9q HUsbqxOY6KoeAINSKvR1Gtf1+gd7oUpcolxPmS6WN9wZRNbVkm6WAg4NUeuZhLRH Mm76Wy1OVfRnt1msw2BpSKtUSAjxNe9lFgrkzwAccQf/mA3ZkhdCWD+OBlkBMVap F7TJs3eZWkjyuRMudtba8PXUYBq4b72loUNm75nhqijaUJqwzdRAuz36+dixuFrY l20D1Rk7GxJjPFyCAdYwvUXSecRSg7P3vt7JI0kr0unPj1+xoPVBz0h7YHi/1q1p oamnpi2dqq7ojncmQ0HIDneEJmnFfuI/L5cdtiSiX6eKlEUTnr+e7DRGn5//JkJR tAPsID4Xvy7MHMB2x/fd =tscB -----END PGP SIGNATURE----- --LEgKsUkp6WslbXS1BXbJBTVptbCroXjEa-- From nobody Mon Jul 4 05:14:55 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E458212D0E5 for ; Mon, 4 Jul 2016 05:14:21 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjVCvM_GWFBP for ; Mon, 4 Jul 2016 05:14:17 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id BEF0D12B047 for ; Mon, 4 Jul 2016 05:14:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id B53CEC69; Mon, 4 Jul 2016 12:14:16 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axuEpz3-FnhP; Mon, 4 Jul 2016 12:14:16 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 25DDD5B1; Mon, 4 Jul 2016 12:14:16 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <577A4C60.2030008@restena.lu> Date: Mon, 4 Jul 2016 08:14:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <577A4C60.2030008@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] CoA-proxy wording X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jul 2016 12:14:22 -0000 On Jul 4, 2016, at 7:45 AM, Stefan Winter = wrote: > Do you think there's value in spinning up a new rev with the above = (and > Jouni's contact address changes), and/or discuss the current state of > the draft in the meeting in Berlin? I can release a new draft with updated wording. We can talk about the = draft in Berlin, but I don't know what there is to discuss. The only objection to the draft was un-specified concerns from Peter = Deacon. He hasn't been responsive for a while. Unless he explains what = his objections are, I think we're probably OK to issue the RFC. Alan DeKok. From nobody Mon Jul 4 05:44:56 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723E12D0A3 for ; Mon, 4 Jul 2016 05:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAv8Lzqq8eq5 for ; Mon, 4 Jul 2016 05:44:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379F4127058 for ; Mon, 4 Jul 2016 05:44:53 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E5CA422C29A; Mon, 4 Jul 2016 14:44:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C46DD27C0DD; Mon, 4 Jul 2016 14:44:51 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0294.000; Mon, 4 Jul 2016 14:44:51 +0200 From: To: "radext@ietf.org" Thread-Topic: Proposal to consider adding a new charter item Thread-Index: AdHV8dn9ItHonaU7QluR3qfhI+wyJg== Date: Mon, 4 Jul 2016 12:44:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DBCCA6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008DBCCA6OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.4.112415 Archived-At: Cc: "draft-boucadair-mptcp-radius@tools.ietf.org" Subject: [radext] Proposal to consider adding a new charter item X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jul 2016 12:44:55 -0000 --_000_787AE7BB302AE849A7480A190F8B933008DBCCA6OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear chairs, WG, Would it be possible to consider adding a charter item for https://tools.ie= tf.org/html/draft-boucadair-mptcp-radius-01? FWIW, the slides presented during the last IETF meeting are available at: h= ttps://www.ietf.org/proceedings/95/slides/slides-95-radext-0.pdf. Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B933008DBCCA6OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear chairs, WG,

 

Would it be possible to consider adding a c= harter item for htt= ps://tools.ietf.org/html/draft-boucadair-mptcp-radius-01?

 

FWIW, the slides presented during the last = IETF meeting are available at: https://www.ietf.org/proceedings/95/slides/slides-= 95-radext-0.pdf.

 

Thank you.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B933008DBCCA6OPEXCLILMA3corp_-- From nobody Tue Jul 5 07:39:45 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59EA12D5E3 for ; Tue, 5 Jul 2016 07:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bap25-NYQQEN for ; Tue, 5 Jul 2016 07:39:42 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.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 218DE12D5DB for ; Tue, 5 Jul 2016 07:39:42 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7302943978 for ; Tue, 5 Jul 2016 16:39:40 +0200 (CEST) To: radext@ietf.org References: <787AE7BB302AE849A7480A190F8B933008DBCCA6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <577BC6AC.1030401@restena.lu> Date: Tue, 5 Jul 2016 16:39:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DBCCA6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5m5TsBwmWgE2Gx7hPwnBVa0xQdhE0jxAF" Archived-At: Subject: Re: [radext] Proposal to consider adding a new charter item X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 14:39:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5m5TsBwmWgE2Gx7hPwnBVa0xQdhE0jxAF Content-Type: multipart/mixed; boundary="hmPnh5osKM4bbwuxFf0cLBLaBox4FN01k" From: Stefan Winter To: radext@ietf.org Message-ID: <577BC6AC.1030401@restena.lu> Subject: Re: [radext] Proposal to consider adding a new charter item References: <787AE7BB302AE849A7480A190F8B933008DBCCA6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DBCCA6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> --hmPnh5osKM4bbwuxFf0cLBLaBox4FN01k Content-Type: multipart/mixed; boundary="------------090804030100000205050002" This is a multi-part message in MIME format. --------------090804030100000205050002 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > Dear chairs, WG, > > =20 > > Would it be possible to consider adding a charter item for > https://tools.ietf.org/html/draft-boucadair-mptcp-radius-01? > > =20 > > FWIW, the slides presented during the last IETF meeting are available > at: https://www.ietf.org/proceedings/95/slides/slides-95-radext-0.pdf. > We can talk about adoption of this document in Berlin. In order to have a good discussion, may I suggest that the WG takes a look at this draft in the time before the meeting? Thanks, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------090804030100000205050002 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----- --------------090804030100000205050002-- --hmPnh5osKM4bbwuxFf0cLBLaBox4FN01k-- --5m5TsBwmWgE2Gx7hPwnBVa0xQdhE0jxAF 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 iQIcBAEBCgAGBQJXe8asAAoJEMDeajWKOdxmlSwP/jN4CNSTOmksycuND0mlq1Sb Cx/7w4R8gbEts4hgV88oXGwysqFHU6tiCAh0PCgq0CvgmPj1nJBUgwJ8BHQuKxZx Kq/iqtQU9LHLYwHAguufCf4mrKMrmDTxg2g06EdDp3c1grrkAocksmrnJa71aOWK midtZqJZbZTNIr2DrlX2bGKEWcf8mS687kSbIzQ4u7rcVCll9CXBM71CyBrs+EO3 V9vKMBWsuYIw3QClE9pGnbELv1pTgnCnv+AwfBF6EWInXW0GJ9TUlv+c07IeX95A yBs+CJoRULqQkf5THrTDnnNBwXx35EFE/xMB+AD8pWss+UF+x6Y1/MoLTf8f8Pxb oGJYmm9+Ex8sAvEEJ2vkCYQajQszmmggZCljA+1Ib73vBdrjaHvLPVAObFHijc1M 2KyFhDW1h7OmgdQ8ym2yRGlPdpfExYhZcmL56jjABXfnVZbGOyjcUNU45ddGeE5m SGemoFTyQJeyHzL6Xt+6+6gsK71Lr7acQUkOfewtOiiCgD0fqLa93n3gSfF4H7wb /V3+l7zHVd5jeBxnXwBjtc/LTT6IuJ4rkDlL/hq/RfWMavNUmr1boSQ8BJh15MGo 35ZzLDrHjHwHqk0SpS0qOjfAIuyg2Panf0lrQ+xAqogrJyJfBpXXTTHvhwcJIXO9 7CRggqmlU1zTHqZgDTau =SgWP -----END PGP SIGNATURE----- --5m5TsBwmWgE2Gx7hPwnBVa0xQdhE0jxAF-- From nobody Tue Jul 5 07:41:13 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD812D5FD for ; Tue, 5 Jul 2016 07:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcpB28JKnCY0 for ; Tue, 5 Jul 2016 07:41:10 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.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 5149F12D5EC for ; Tue, 5 Jul 2016 07:41:09 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id F00E743978 for ; Tue, 5 Jul 2016 16:41:07 +0200 (CEST) To: radext@ietf.org References: <577A4C60.2030008@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <577BC703.40005@restena.lu> Date: Tue, 5 Jul 2016 16:41:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gq4JWqa6DAo7XRTnJBbpsxDNaUcerI33t" Archived-At: Subject: Re: [radext] CoA-proxy wording X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 14:41:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gq4JWqa6DAo7XRTnJBbpsxDNaUcerI33t Content-Type: multipart/mixed; boundary="vAe8mafO8OqrLTBn8bGMIqh75trivcBgO" From: Stefan Winter To: radext@ietf.org Message-ID: <577BC703.40005@restena.lu> Subject: Re: [radext] CoA-proxy wording References: <577A4C60.2030008@restena.lu> In-Reply-To: --vAe8mafO8OqrLTBn8bGMIqh75trivcBgO Content-Type: multipart/mixed; boundary="------------050504000704080109020100" This is a multi-part message in MIME format. --------------050504000704080109020100 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >> Do you think there's value in spinning up a new rev with the above (an= d >> Jouni's contact address changes), and/or discuss the current state of >> the draft in the meeting in Berlin? > I can release a new draft with updated wording. We can talk about th= e draft in Berlin, but I don't know what there is to discuss. > > The only objection to the draft was un-specified concerns from Peter = Deacon. He hasn't been responsive for a while. Unless he explains what = his objections are, I think we're probably OK to issue the RFC. Okay. Please issue that new rev, and then let's start a WGLC afterwards. Maybe there are some discussion points ready to talk about in Berlin then= =2E 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 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------050504000704080109020100 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----- --------------050504000704080109020100-- --vAe8mafO8OqrLTBn8bGMIqh75trivcBgO-- --gq4JWqa6DAo7XRTnJBbpsxDNaUcerI33t 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 iQIcBAEBCgAGBQJXe8cDAAoJEMDeajWKOdxmgX0QAKzUzNplYb0cq72OPx8DFSe6 EOrJY9yIf+Yg5FBqyLfRLr7iPoFglReW9wccwiBgL7bED1Qy1YsqShZGITcYtOQA cVZvQH3El7T2n+Wd29gs0F+fzGhs4SE+QNgc24NpB/xDxptvrBj6BI1BfZuQQQHB LCjYsQrBppthmT4VrZyMBJkpPee5Bek6SbVznLZ2PbWsjIyUyMQDQc5T8sTFNDvP cSBh1ZPeGbccOhhIorEYHEit/UKpu00EOqqFtp9bDmzg7lNisQkRZqApDQ5I2rBC PtKBAztqpEQVSUYs8dC0DSDl/cXGVsbff/9vB8HAFRg740u+NdXEYznz8r7RU2ZK lloWN6bXThy94767r4JtA/PtHYTA4vGAsXVfdLLGuHMzEa9rBbHV3vvSu78OYvK8 RQ9l8rSMqKo3GYwPn9Wa+3nMQTIh7BFr41yi6JOVQA/NM5yLL86WzsncrSVJS/1x EvoTOevHrQyw+5669B9EXHDmTeNpWIBN3pZFKozhV/jCrSUALPB+noS+d70MW2ti 3zExlrbT5yGn5KiTP2ALB/M8BosGfapWZ5XDyZzIGHGUSjdK7uEvuULPfVciBEi3 0Gsznsnt/Kg2Zq1GV/xM+xE1LNSJy+7TzR8xbkfMlWa6LkH6+E+xHQo8xdFtF1FZ Tq70U3u+eO4YngaYUBEP =veJN -----END PGP SIGNATURE----- --gq4JWqa6DAo7XRTnJBbpsxDNaUcerI33t-- From nobody Wed Jul 6 00:25:47 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C558612D0F4 for ; Wed, 6 Jul 2016 00:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2ad-tBwehzf for ; Wed, 6 Jul 2016 00:25:43 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.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 11C7D12D68F for ; Wed, 6 Jul 2016 00:25:43 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 0942243A7A for ; Wed, 6 Jul 2016 09:25:41 +0200 (CEST) To: "radext@ietf.org" References: <5767FB3C.20007@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <577CB274.7090303@restena.lu> Date: Wed, 6 Jul 2016 09:25:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5767FB3C.20007@restena.lu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NR8C0uxcv4gXQ6jDI8iAo3SikA17kgkqH" Archived-At: Subject: Re: [radext] Error-Cause value allocation for draft-ietf-radext-bigger-packets X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jul 2016 07:25:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NR8C0uxcv4gXQ6jDI8iAo3SikA17kgkqH Content-Type: multipart/mixed; boundary="b6q6xiNTT7nCtXwxR2HGMXxo9A3gdNUGL" From: Stefan Winter To: "radext@ietf.org" Message-ID: <577CB274.7090303@restena.lu> Subject: Re: [radext] Error-Cause value allocation for draft-ietf-radext-bigger-packets References: <5767FB3C.20007@restena.lu> In-Reply-To: <5767FB3C.20007@restena.lu> --b6q6xiNTT7nCtXwxR2HGMXxo9A3gdNUGL Content-Type: multipart/mixed; boundary="------------020801060509080504010207" This is a multi-part message in MIME format. --------------020801060509080504010207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > If these categories are created, there should be corresponding text in = a > new rev of bigger-packets. > > Please let the list know how you think about this in the next two weeks= =2E > If noone speaks up against this, we'll continue along this path. The two weeks are now over, and we have unanimous consent (yay!). We'll proceed with the creation of the two new categories (IANA has been instructed to create them already, the text defining them will come in during RFC editor treatment of the draft). 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 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------020801060509080504010207 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----- --------------020801060509080504010207-- --b6q6xiNTT7nCtXwxR2HGMXxo9A3gdNUGL-- --NR8C0uxcv4gXQ6jDI8iAo3SikA17kgkqH 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 iQIcBAEBCgAGBQJXfLJ1AAoJEMDeajWKOdxmceMQALPJ37Bdr2HsGzulsz10vWT8 orhodnwBlB3S2iHfOe1KkJEQzjjRAd9Rh5WpuF4ZM0CqElUXrZli/Ow39aq1iRCL I1Ib/912fetaCaaH10f63pAWV0sa7Z0ykrfsM1p7xAXQtNOFJ4N5yurAP3TRIIm1 nIXwp2Red/iXZsp04AMy/lg1iLi+QTX/lImAxfF9aGoUmzjNCGJa/2L0dTxNeTVn rJWcgjnQeYhzcQbEA+wCq45KKBguUXCVNGgKw/7Mb7C50LPjD8QsabfCQFT/DC6X rfRHb6rwbwYkOOgCI7Az/pflFJZYhmCY1IQqXZHMull5mgjAPQzo05wEyXPkxRzH 30quG8e7ToptVwpu8H8PJUmPwZa0V86Diq00lvs2z0A3yfeOcB0MJiZsT8T4n19i QnvacauYzz48E+5BjAkjdkWszkDutiBZ5MSnHIQCGfc9KTVQBgll/dRzGhTaLrPH /4khKtJkloQcd+FKMDiTr7wh6bG46OCZn4EwhIyoUBr8CGoYL6AzLiuFs8dIw7QE wdBlnHLZ6HunkrV/bBOdmtAGWfHmCsXxiU9b+UXUK7CaTjNDxhq4rSqX7CkY5j6D DZk7Vviw6u03bYZIkh2hE3DGXx4AJWfsrY2D8q0B/pB3tUUFayMzUoo+ots7qw1Y 66V7lKuBKkd5CAaCoAgh =Becb -----END PGP SIGNATURE----- --NR8C0uxcv4gXQ6jDI8iAo3SikA17kgkqH-- From nobody Fri Jul 8 06:51:05 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C07012D1A4; Fri, 8 Jul 2016 06:51:04 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708135104.32201.95442.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 06:51:04 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:51:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Considerations regarding the correct use of EAP-Response/Identity Author : Stefan Winter Filename : draft-ietf-radext-populating-eapidentity-01.txt Pages : 10 Date : 2016-07-08 Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. One of these workarounds is a new requirement for EAP peers that the use of UTF-8 is required for the content of EAP-Response/Identity (which updates RFC3748). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-populating-eapidentity/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-populating-eapidentity-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-populating-eapidentity-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 09:45:08 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294B812D7FB for ; Fri, 8 Jul 2016 09:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2efk1VdQE8mw for ; Fri, 8 Jul 2016 09:45:04 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF6812D589 for ; Fri, 8 Jul 2016 09:45:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 4154769C2; Fri, 8 Jul 2016 18:45:03 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7jstRWMnJteF; Fri, 8 Jul 2016 18:45:03 +0200 (CEST) Received: from inf-205-170.inf.um.es (inf-205-170.inf.um.es [155.54.205.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon22.um.es (Postfix) with ESMTPSA id B6A5F69BE; Fri, 8 Jul 2016 18:45:02 +0200 (CEST) From: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2016 18:45:02 +0200 Message-Id: <924C024E-A533-41AE-82A0-9A22C1FD1BA2@um.es> To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= Subject: [radext] new version draft radius-lorawan X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 16:45:07 -0000 Dear all:=20 We have uploaded a new version of the draft aboug LoRaWAN = Authentication in RADIUS. https://datatracker.ietf.org/doc/draft-garcia-radext-radius-lorawan/ Best Regards, Dan Garcia.=20= From nobody Fri Jul 8 12:21:23 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C46126B6D; Fri, 8 Jul 2016 12:21:21 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708192121.32197.25694.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 12:21:21 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-coa-proxy-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:21:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) Authors : Alan DeKok Jouni Korhonen Filename : draft-ietf-radext-coa-proxy-01.txt Pages : 15 Date : 2016-07-08 Abstract: RFC 5176 defines Change of Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that document suggests that proxying these messages is possible, but gives no guidance as to how that is done. This specification corrects that omission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-coa-proxy-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 16:54:37 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0112D14D for ; Fri, 8 Jul 2016 16:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FaQOGsy7mJ6T for ; Fri, 8 Jul 2016 16:54:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6204128B44 for ; Fri, 8 Jul 2016 16:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1700; q=dns/txt; s=iport; t=1468022072; x=1469231672; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Y2ZtfEQm/qKRIv6/Z7pn1zNxvSwYQhyLqEHaCcBLOFE=; b=JKb5VO4s3vRn9/rL/AEGJD5aQqh43Qp9JQNRGYvNnmCP0YlC5BTP7C0o fK9z4tPknYprgDhMKbZIbkIeak8ddknmW4g8z9BJxXTa3+95N1Td48gU7 X2gcTzyeoNmL7t/3/k4///rymy+xrNJhJjYkWl52OGtZf1iaT9XO+xJU5 I=; X-IronPort-AV: E=Sophos;i="5.28,332,1464652800"; d="scan'208";a="127482342" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 23:54:30 +0000 Received: from [10.41.57.152] ([10.41.57.152]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u68NsUg7029134; Fri, 8 Jul 2016 23:54:30 GMT References: <20160708013912.18627.32277.idtracker@ietfa.amsl.com> To: radext@ietf.org From: Enke Chen X-Forwarded-Message-Id: <20160708013912.18627.32277.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 8 Jul 2016 16:54:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160708013912.18627.32277.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Naiming Shen , Enke Chen Subject: [radext] Fwd: I-D Action: draft-chen-radext-extended-header-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 23:54:35 -0000 Hi, Folks: Please let us know if you have any comments. Thanks. -- Enke -------- Forwarded Message -------- Subject: I-D Action: draft-chen-radext-extended-header-00.txt Date: Thu, 07 Jul 2016 18:39:12 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Packet Header for RADIUS Authors : Enke Chen Naiming Shen Filename : draft-chen-radext-extended-header-00.txt Pages : 8 Date : 2016-07-07 Abstract: The limitation with the one-octet "Identifier" field in the RADIUS packet is well known. In this document we propose extensions to the RADIUS protocol to address this fundamental limitation, and thus allowing for more efficient and more scalable implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-radext-extended-header/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-chen-radext-extended-header-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Jul 10 23:05:13 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C4C12B068 for ; Sun, 10 Jul 2016 23:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE_15CM-Ynho for ; Sun, 10 Jul 2016 23:05:10 -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 4738A12B062 for ; Sun, 10 Jul 2016 23:05:10 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 473D743B14 for ; Mon, 11 Jul 2016 08:05:08 +0200 (CEST) To: radext@ietf.org References: <20160708013912.18627.32277.idtracker@ietfa.amsl.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Mon, 11 Jul 2016 08:05:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TMKf0BAq6Pd4AnXOiHvIGgb550LBwP7RE" Archived-At: Subject: Re: [radext] Fwd: I-D Action: draft-chen-radext-extended-header-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 06:05:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TMKf0BAq6Pd4AnXOiHvIGgb550LBwP7RE Content-Type: multipart/mixed; boundary="8lHxcb4TWJvb5WOxGXu1N5TVlmDpo71Kx" From: Stefan Winter To: radext@ietf.org Message-ID: Subject: Re: [radext] Fwd: I-D Action: draft-chen-radext-extended-header-00.txt References: <20160708013912.18627.32277.idtracker@ietfa.amsl.com> In-Reply-To: --8lHxcb4TWJvb5WOxGXu1N5TVlmDpo71Kx Content-Type: multipart/mixed; boundary="------------6B3EA7FF09409B174DAE741F" This is a multi-part message in MIME format. --------------6B3EA7FF09409B174DAE741F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, do you want a presentation slot at the upcoming meeting? Greetings, Stefan Winter Am 09.07.2016 um 01:54 schrieb Enke Chen: > Hi, Folks: > > Please let us know if you have any comments. > > Thanks. -- Enke > > -------- Forwarded Message -------- > Subject: I-D Action: draft-chen-radext-extended-header-00.txt > Date: Thu, 07 Jul 2016 18:39:12 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > Title : Extended Packet Header for RADIUS > Authors : Enke Chen > Naiming Shen > Filename : draft-chen-radext-extended-header-00.txt > Pages : 8 > Date : 2016-07-07 > > Abstract: > The limitation with the one-octet "Identifier" field in the RADIUS > packet is well known. In this document we propose extensions to the > RADIUS protocol to address this fundamental limitation, and thus > allowing for more efficient and more scalable implementations. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-radext-extended-header/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-chen-radext-extended-header-00 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------6B3EA7FF09409B174DAE741F 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----- --------------6B3EA7FF09409B174DAE741F-- --8lHxcb4TWJvb5WOxGXu1N5TVlmDpo71Kx-- --TMKf0BAq6Pd4AnXOiHvIGgb550LBwP7RE 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 iQIcBAEBCgAGBQJXgzcUAAoJEMDeajWKOdxmu/gP/20Tio5l1HVU4kNSBtZw2Va8 V6Pqk+biUwdwsqsGMBdAGfp9kvngtr1ykdeeUHD8JZVEu9RAYkcrAj+JK1Omwi5g KK6Fgx2XLnZ+fp4jhgqr01gQI6+V1RhmI3IZtD+4om3Kql5TNXEB8fWeVcrh7fAH S3Yuz+FHo7h1AwC/27NQ5nh5ZNjcUwdNoMKCJAkxmMzkcXK3lSFaeV7m812CEjc7 dv9YOJnZ4t/S8GdpIOyq8i/jg8U1kvWClAqiM0V0wKCvWm63n1Kq6hbCo5nBOYCS 5AxdnKhfJODimK6AF1jTLlhDaQYF236zVajCt/IjJojTEiVzSNlOVMXwjb8YbzHL L4V7QoHyHTS1iAjWRddhXfLKz6euqA16OCg5sscEDR130UlJYBTMMkhMT+XgdFkx FXKA6qbpu1dv54nYnw+coRLh7v8LY7qTUf/xjPUQtkj85NgYxMDD2Fs1qNKbRfxW ZZk9MtYL3ls9m6CCRttXoTSOHMR5jUr6YS2uvHd2YrXzpbLy6KhK6focbJQfIzOD buqFOeNwqXbOEhDakJ/I8KVtzQlcLEReqKV0tbsv7c1lAPIwC5zqpUomDHCdekjr dpVkGKuEZ0fV8OTCqWh2gNUcohOtizQuw6OBvcM0LsQh6O94S3vxX2i0P86WZ5hw q42qJd58fB3Fs50jOEyI =NneZ -----END PGP SIGNATURE----- --TMKf0BAq6Pd4AnXOiHvIGgb550LBwP7RE-- From nobody Sun Jul 10 23:15:26 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44B12B00D for ; Sun, 10 Jul 2016 23:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii7sVx3NEfMy for ; Sun, 10 Jul 2016 23:15:23 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.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 659D712B00A for ; Sun, 10 Jul 2016 23:15: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 DD52F43B14 for ; Mon, 11 Jul 2016 08:15:21 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <4108da87-2745-baa9-fdae-4841fc761418@restena.lu> Date: Mon, 11 Jul 2016 08:15:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oaV7xi94LNHftE1irs9U0N3vChl1S1Rgq" Archived-At: Subject: [radext] Start of WGLC for draft-ietf-radext-coa-proxy-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 06:15:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oaV7xi94LNHftE1irs9U0N3vChl1S1Rgq Content-Type: multipart/mixed; boundary="ITmGCP8DfMo6BjAmShuGppvqmDJIR6BnR" From: Stefan Winter To: "radext@ietf.org" Message-ID: <4108da87-2745-baa9-fdae-4841fc761418@restena.lu> Subject: Start of WGLC for draft-ietf-radext-coa-proxy-01 --ITmGCP8DfMo6BjAmShuGppvqmDJIR6BnR Content-Type: multipart/mixed; boundary="------------8CDDC2F9C109F5D16611EACD" This is a multi-part message in MIME format. --------------8CDDC2F9C109F5D16611EACD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, following the discussion on the mailing list and submission of rev -01 of= this draft, the author and chairs believe this document is ready for a W= orking Group Last Call (WGLC). This email officially starts the WGLC which lasts two weeks from now. The= document is at https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-0= 1 Please send your comments and issues with the draft to the mailing list u= ntil 2016-07-25 2400 UTC. Since the WGLC period coincides with the Berlin meeting, we can make use = of the face-to-face time to discuss any issues brought up in the WGLC sho= uld they arrive on the mailing list before the meeting (21 July). In addition, following the strategy for promoting compliance with the IPR= disclosure rules (RFC6702), the chairs would like to check whether there are claims of Intellectual Property Rights (IPR) on the document th= at need to be disclosed. Therefore, the following questions are addressed= to the WG and especially Authors and Contributors of the draft: Are you personally aware of any IPR that applies to draft-ietf-radext-coa= -proxy-01 ? If so, has this IPR been disclosed in compliance with IETF IP= R rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, plea= se reply to this email message regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance th= is document to the next stage until we have received a reply from each author and listed contributor. If you are on the RADEXT WG email list but are not an author or listed co= ntributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you = want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------8CDDC2F9C109F5D16611EACD 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----- --------------8CDDC2F9C109F5D16611EACD-- --ITmGCP8DfMo6BjAmShuGppvqmDJIR6BnR-- --oaV7xi94LNHftE1irs9U0N3vChl1S1Rgq 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 iQIcBAEBCgAGBQJXgzl5AAoJEMDeajWKOdxmH3oQAMDceWZ/pi17IQnPhPsk5SEa h1KBSsxGfgSBblG2AStwhIc1e2B5yW6ncGnFE3FgUAbB44AJprpU5MaC+HgBBmaP v+YIhuESzwoRvCiOtUMZsC3nlh81PHiT9TYoPtOlL5o6+qSjZKnP1vLOoUEPHAMc Tj6dY58VrWX7EGcKTFbbdl899U/2Tn4TM8yYPYLywMIcENIG7oooQ9Q1NFxwhPZq COrfeHAEymS8qkM5GLWL17mPVJ8OXrVKgF5jvlR6bz+Wipinem7sDR6r9KIxg9a7 s2GQlLduWVln7EvYbHqQfXqwVlcPPip8yMGuQNfWcRT2Ug5jSEsXf3cAHcPhnFR+ xF5tz9OsjSTtnWo2VhF8xVPC8N1qN6vFKgCxMWQm1C1kSMz561WB6RC3vqpR6wYG 8quNLAvo4GRk+Kjbs1i9TQakDlnvrUAT9hRdDo918sqP0uNx28JWpZdO3lVmmP0K SF9+YPjsp4YXFFXZtLLxx+XG+UlGI+MbwzqIasQHFgQtAzO2JqcU/72XjtVkp+9x 6zyJmhmxPIS2Tcn1ecKLNb02zCrrSkpFwm6Ky1HnbkCCakClb8vbUtZimnRhV7Va jyJj1wE1C0gBlQKS2Z+L1WmJrUok9TO65SNdgAXV5U2RDZMd811HQxGyyufvQqva obg69bPwaTzoMSpqN48m =Qtek -----END PGP SIGNATURE----- --oaV7xi94LNHftE1irs9U0N3vChl1S1Rgq-- From nobody Mon Jul 11 06:09:15 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B078412D0ED for ; Mon, 11 Jul 2016 06:09:13 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqMA2cYfxxVz for ; Mon, 11 Jul 2016 06:09:12 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id F3C1A12B037 for ; Mon, 11 Jul 2016 06:09:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 2C25DC0E; Mon, 11 Jul 2016 13:09:11 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSox-2p09kTl; Mon, 11 Jul 2016 13:09:11 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id A6276229; Mon, 11 Jul 2016 13:09:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <4108da87-2745-baa9-fdae-4841fc761418@restena.lu> Date: Mon, 11 Jul 2016 09:09:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <430E6AE6-E23B-4039-AFEE-841E7AEDB3AA@deployingradius.com> References: <4108da87-2745-baa9-fdae-4841fc761418@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Start of WGLC for draft-ietf-radext-coa-proxy-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 13:09:13 -0000 On Jul 11, 2016, at 2:15 AM, Stefan Winter = wrote: > Are you personally aware of any IPR that applies to = draft-ietf-radext-coa-proxy-01 ? If so, has this IPR been disclosed in = compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 = for more details.) I am not aware of any IPR that applies to the draft. Alan DeKok. From nobody Mon Jul 11 07:33:47 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9284712D511 for ; Mon, 11 Jul 2016 07:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlVlSlxXaTTy for ; Mon, 11 Jul 2016 07:33:43 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.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 3923D12D187 for ; Mon, 11 Jul 2016 07:33:43 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id CECBF43B14 for ; Mon, 11 Jul 2016 16:33:41 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Mon, 11 Jul 2016 16:33:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fljDbtdcxePfDMEXQDiGHEOgrXKWgdgk0" Archived-At: Subject: [radext] Preliminary Agenda for IETF 96 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 14:33:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fljDbtdcxePfDMEXQDiGHEOgrXKWgdgk0 Content-Type: multipart/mixed; boundary="6d254ihXDPHQhK71aOamjBlusfG1b0TWF" From: Stefan Winter To: "radext@ietf.org" Message-ID: Subject: Preliminary Agenda for IETF 96 --6d254ihXDPHQhK71aOamjBlusfG1b0TWF Content-Type: multipart/mixed; boundary="------------F442B1033B5E35D8C2E49151" This is a multi-part message in MIME format. --------------F442B1033B5E35D8C2E49151 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I've uploaded a first preliminary version of the agenda to the meeting materials manager: https://www.ietf.org/proceedings/96/agenda/agenda-96-radext Please comment as you see fit! 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 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------F442B1033B5E35D8C2E49151 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----- --------------F442B1033B5E35D8C2E49151-- --6d254ihXDPHQhK71aOamjBlusfG1b0TWF-- --fljDbtdcxePfDMEXQDiGHEOgrXKWgdgk0 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 iQIcBAEBCgAGBQJXg65FAAoJEMDeajWKOdxm3GwP+wTI1OU0XDj5/8SoK8o1nLla 6IoFwGG7NXmgsed/qwB2T/NaaTnnVSf3YuPtW8fn1MBs0mwkwEZKeosIMFOGAmy3 QJvoL/aHpFgQ5dt40fbodIXnO/aic5xZjinrAadCX8VRU9pb62dwMvhb+11lmoeC 2TRcAXPSWNUY/qx/KZ96EmxGLBsqxvXvNovssBJnDaBPzJJCNRlZ8ber4tmWX2ti i/1jj5R9v4k4cRO9AObwws8mi5IVzFrJNzBf163jCGq0j2NTracrwjCVep5apSc/ baH4AAx0FhjdwdtpZh+vhTAW9XKrzJTkxZA3SuZ5Ngyo35KphrmMGe/Ji9BIRPNz nidOwczb3z0JU205xIrO93gpvfvEm2Gr5LpYb5/9b6SvVeX1q+Kz0+24QpNe9KVF qTByz6tFLeIAphUyTmyLL/KXpk1X0A+yIjeTQZrB4RS8kJHvjmmTurLF00LY+2jK dBDrsSvftETDAWW+qMTDkgNq1r5UhHPWKUlizSflEP7vDoMdWRhLd+aSkYXua9Tz eshntlYZDK/mtdxyF9XvEAGsWUg+KtJp8WdbbUdVY4oEi9eEqDBJ7kgSQQgloJi/ 9hFp07tmhbjMU+lReBdrtDP0Ua5UnlYIl8obGGs/7fsOyTfOD4DDLj0lsbc7VhXd E4oAixP2zvaxhOeWp2d4 =eib9 -----END PGP SIGNATURE----- --fljDbtdcxePfDMEXQDiGHEOgrXKWgdgk0-- From nobody Tue Jul 12 16:58:08 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C1912D6AD for ; Tue, 12 Jul 2016 16:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 B_hprfih5P7j for ; Tue, 12 Jul 2016 16:58:05 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A267412D0E3 for ; Tue, 12 Jul 2016 16:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=420; q=dns/txt; s=iport; t=1468367885; x=1469577485; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=bghUmpPCeDxbpnxpqdFpndaBsW1sF+5B8dHfR2FcrDQ=; b=FdD7wSY+myTbNez9iKeAYFfQTEunzUYows53T7VMF6PtZE6aELUg5tYF EVE1QfeNNkTvXXkbT7Gkn1RXOP2bue5FphypbHfLjgoynm4UiIAJo0dol PlD3YdTSegLSbXXodJnlA+fWAiwLlTuh/sfiIK9LBrmOjbyQyrpfULY8h I=; X-IronPort-AV: E=Sophos;i="5.28,354,1464652800"; d="scan'208";a="297095566" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 23:58:05 +0000 Received: from [10.41.57.238] ([10.41.57.238]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6CNw47A018503; Tue, 12 Jul 2016 23:58:04 GMT To: Stefan Winter From: Enke Chen Message-ID: <64d1393e-753e-4996-ad67-a32f631034c8@cisco.com> Date: Tue, 12 Jul 2016 16:58:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: radext@ietf.org, Enke Chen Subject: Re: [radext] Fwd: I-D Action: draft-chen-radext-extended-header-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 23:58:06 -0000 Hi, Stefan: Yes, I would like to present the draft. Can I have 10 minutes? Thanks. -- Enke Stefan Winter Mon, 11 July 2016 06:05 UTCShow header Hello, do you want a presentation slot at the upcoming meeting? Greetings, Stefan Winter Am 09.07.2016 um 01:54 schrieb Enke Chen: > Hi, Folks: > > Please let us know if you have any comments. > > Thanks. -- Enke From nobody Sat Jul 16 13:48:48 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559E212D10B for ; Sat, 16 Jul 2016 13:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 t4dXd6qol-tg for ; Sat, 16 Jul 2016 13:48:44 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 9A6C612B04E for ; Sat, 16 Jul 2016 13:48:44 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id w127so138079241vkh.2 for ; Sat, 16 Jul 2016 13:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Agt57sn7wwVqCUP/TEnmFdW4/3dMw/7AGthjdBo9BOo=; b=gYrcMzyxb4FJUfxdEdsWSHzLFSlwq2GLIu82FZ5ydyKGt+shNmunyxE/DgGOK7YMGh PfuPqusAaZ/Xd82P9YHBGl7cahuiZE//ipGTbgOq+R2k4xa4q4A7TNZRS9m0uXY8ykxc 3dihLj2XpfNhZlbP2DV4MgHdT3DaRZLIHCF23JIGznk6TYeycQ0LDNWP1bCGLrHjxIuc B8m3nwYx2toz0UPM9WRkw5kMN9sBW7xo4C6meo+ZBee5Je46XI7h/mbCw3CtObInr6tn VKEiCs0zWN/QVAfgK6tRM8SNInIQ07dgFhSJS3wSZEJitY1Au3cXxcji1LbHYM2zABsY P0RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Agt57sn7wwVqCUP/TEnmFdW4/3dMw/7AGthjdBo9BOo=; b=bl4CisKGNBJJMEJiO4IYntmbteDQR/yay30VV7KMWA3xU0YQicyPE+ufpbZUwi9tED PFbj8y2YtN4OmMuRmw4eRpsnFl5B8ymdg8y9QSnqO08+VCH8oqDMHhKLtAeN7DP+HzrW V2PFJlqfg+2oh6e75BLqhLcRWXno2Xs9Fi+7ZV2m89ECNi9lzL6z8TUUrX2rgHwB5vN2 upNvRRGFUVn9SVoqjD2IVSt70hY+Aisx0EirfYWjT068U9/XfcZSYWTlQIPaitEJCFs5 kTOzpXWRs1W4EEYM4htThS4b5GdCZTtyfvHavYf3QLML4mpaAB9tjwNpCgXrQAvY/UIq itQg== X-Gm-Message-State: ALyK8tIdjG2lq1+yYmQuK9hiUKXfFKBntYxNsQHvCQIs+HndugWegTRRgd1C/3dmkHnRRboAyRmG0i8bj8OXFA== X-Received: by 10.31.177.139 with SMTP id a133mr13903489vkf.151.1468702123595; Sat, 16 Jul 2016 13:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Sat, 16 Jul 2016 13:48:43 -0700 (PDT) From: Kathleen Moriarty Date: Sat, 16 Jul 2016 16:48:43 -0400 Message-ID: To: "radext@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jul 2016 20:48:46 -0000 Hello, Thank you for another very well written draft that serves a clear purpose and is easy to read and understand. I just have 2 questions that should be really easy and then would like to know when the WG prefers me to start IETF last call. And if you'd like IETF last call to start this week, should it be extended for a 3rd week? Comments/questions: Section 2.1.1 Should this say "be of a valid data type" Attr-Data The "Value" field of an Attribute as defined in [RFC2865] Section 5. The contents of this field MUST be a valid data type as defined in the RADIUS Data Type registry. IANA Section 4.2 Does the registration policy remain unchanged from rfc3575? If so, it would be helpful to state that since 4.1 defines the registration policy as requiring IETF review, different from what happens for 4.2 according to the description in rfc3575. -- Thank you. Best regards, Kathleen From nobody Tue Jul 19 08:36:38 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE0312D877 for ; Tue, 19 Jul 2016 08:36: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik6KagGehTp0 for ; Tue, 19 Jul 2016 08:36:32 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 600F612D894 for ; Tue, 19 Jul 2016 08:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 7B0EA1D9C; Tue, 19 Jul 2016 15:20:26 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rdhqKYoQcBa; Tue, 19 Jul 2016 15:20:26 +0000 (UTC) Received: from dhcp-9567.meeting.ietf.org (dhcp-9567.meeting.ietf.org [31.133.149.103]) by mail.networkradius.com (Postfix) with ESMTPSA id 43759A7B; Tue, 19 Jul 2016 15:20:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 19 Jul 2016 17:20:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 15:36:36 -0000 On Jul 16, 2016, at 10:48 PM, Kathleen Moriarty = wrote: >=20 > Hello, >=20 > Thank you for another very well written draft that serves a clear > purpose and is easy to read and understand. I just have 2 questions > that should be really easy and then would like to know when the WG > prefers me to start IETF last call. And if you'd like IETF last call > to start this week, should it be extended for a 3rd week? >=20 > Comments/questions: > Section 2.1.1 > Should this say "be of a valid data type" > Attr-Data >=20 > The "Value" field of an Attribute as defined in [RFC2865] > Section 5. The contents of this field MUST be a valid data > type as defined in the RADIUS Data Type registry. I'm fine with the change. I'm not sure it makes a substantive change, = tho. > IANA Section 4.2 > Does the registration policy remain unchanged from rfc3575? Yes. > If so, it > would be helpful to state that since 4.1 defines the registration > policy as requiring IETF review, The intent there is that new data types requires IETF review with = Standards Action. It doesn't change the registration requirements for = the RADIUS attributes registry. Maybe this is clearer: This section defines a new RADIUS registry, called "Data Type". Allocation in this registry requires IETF Review. The "Registration Procedures" for the Data Type Registry are "Standards Action".=20 > different from what happens for 4.2 > according to the description in rfc3575. OK. Maybe adding text here would be good: The existing registration requirements for the Attribute Type Registry are unchanged. Alan DeKok. From nobody Tue Jul 19 08:40:43 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4DB12DBF1 for ; Tue, 19 Jul 2016 08:40:41 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma1m4Zn11sfW for ; Tue, 19 Jul 2016 08:40:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C362612DB9D for ; Tue, 19 Jul 2016 08:25:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id C736F19C6 for ; Tue, 19 Jul 2016 15:25:29 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xUeBupinsSM for ; Tue, 19 Jul 2016 15:25:29 +0000 (UTC) Received: from dhcp-9567.meeting.ietf.org (dhcp-9567.meeting.ietf.org [31.133.149.103]) by mail.networkradius.com (Postfix) with ESMTPSA id 8F9115B1 for ; Tue, 19 Jul 2016 15:25:29 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5745F8F5-D3F0-4EBD-8AAC-4EBFFC6B7FD4@deployingradius.com> Date: Tue, 19 Jul 2016 17:25:29 +0200 To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [radext] Retransmission behaviour in proxies X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 15:40:42 -0000 I've had discussions in Berlin with Jim & Bernard about problems = related to proxying. This message describes the problems and proposed = solutions. The historical approach has to require that proxies do retransmits = only when the client retransmits. The idea here is that the traffic = should be shaped by end to end network behaviour. That is, the original = client sending the traffic should (somehow) get signalled about network = issues, and modify it's behaviour accordingly. All of the intermediate = nodes then act as simple packet forwarders. To recapitulate, RADIUS over TCP (RFC 6613) Section 2.5 ends with: Intrinsically, proxy systems operate with multiple control loops instead of one end-to-end loop, and so they are less stable. This is true even for TCP-TCP proxies. As discussed in [RFC3539], the only way to achieve stability equivalent to a single TCP connection is to mimic the end-to-end behavior of a single TCP connection. This typically is not achievable with an application-layer RADIUS implementation, regardless of transport. The current proxy retransmit works for UDP (sort of). It works less = well for TCP and UDP interaction. When going from UDP to TCP transport, a client can retransmit, and the = proxy will *not* retransmit over the TCP connection, because TCP is = reliable. That's OK. When going from TCP to UDP transport, the client will *not* = retransmit, so the proxy *should* do it's own retransmissions out the = UDP side. This situation is not covered in RFC 6613. So we need to fix = that. At the same time the UDP retransmission behaviour is terrible. While = RFC 5080 Section 2.2.1 describes suggested retransmission behaviour (and = is 10 years old at this point), most RADIUS clients do not implement = it's recommendations. They just use fixed retransmission intervals with = no jitter, exponential back off, etc. My suggestion is the following: - suggest that UDP to TCP proxies don't retransmit, as per RFC 6613. - suggest that TCP to TCP proxies are mostly OK, as per RFC 6613. - require that TCP to UDP proxies implement the retransmission behaviour = described in RFC 5080 Section 2.2.1 - suggest that UDP to UDP proxy behaviour is slightly more complicated - where there is no Proxy-State attribute in the packet, we can assume = that the previous hop was a RADIUS client. The current node is a RADIUS = server, and is much more likely to implement RFC 5080 correctly. In = that case, it MAY be beneficial for the proxy to quench duplicates from = the client, and to implement the RFC 5080 retransmissions itself. - where here is a Proxy-State attribute in the packet, we can assume = that the previous hop was a RADIUS proxy, and (hopefully) implements RFC = 5080 correctly. In that case, the proxy should just "pass through" the = retransmissions from the client to the next hop. The proxy SHOULD NOT = implement it's own retransmission behaviour. I think that solves the basic issues related to UDP / TCP transport. A related goal would be to determine how RADIUS clients can look at = traffic in order to optimize network behaviour. AS RFC 6613 notes, this = may be difficult. The hope is that we can do better than what we're = doing now. A simple approach would be to track traffic based on destination = realm. The assumption would be that each realm goes to one location = (whatever that is), and that analyzing traffic for that realm can be = done. And that such analysis would lead to the client better optimizing = traffic for that realm. The difficulty with RADIUS is that traffic is burst, and controlled by = users logging in. When TCP has 100K+ to transfer for a web page, it has = time to do traffic statistics. We're just not as lucky with RADIUS. Alan DeKok. From nobody Tue Jul 19 08:52:44 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F283C12D4FB for ; Tue, 19 Jul 2016 08:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 spqWCG9wdduQ for ; Tue, 19 Jul 2016 08:52:40 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 8585412D50D for ; Tue, 19 Jul 2016 08:42:46 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id w127so30101337vkh.2 for ; Tue, 19 Jul 2016 08:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rx7uYzRMJad9ksGgcfm/jR7l0F+wloV+p8rt8G4T/gc=; b=bKylMWMrw26FFRILNONlG13GV7QRUrpHEbSVOAIBO9Ln3BbW+vF5o+akb8prahnil1 6ofWFF3JluOM3kMjQ54uPXAcZyKKSakcn14004HjjrI+C0HpPE/N8KlCqFcSMsm8MZXR OKcYPHsRWwcm1iamr9g0J+OG/MVAVATBKkNGj6qLO+i5jpIdy5HiGu1SZijX8tHSzdlk 5FFZHkDeHQLpHLfbXmTwq9la60MeYC54ziFXiDBJwzRpSE6BbjcK89JaWo6CGzagOieA 8iyiY8sJV6OhD/9H1U2WHeKEIal7RP5xfGNwiIv2cDmHtG3nyp5W2Co+9lAgyGompZNe b58A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rx7uYzRMJad9ksGgcfm/jR7l0F+wloV+p8rt8G4T/gc=; b=WshdRKe1wyYvzOJSLwFyvAmZ7IjXFeTcv06f2+UYFxpjArjpRVWWYtsrwuqOXkwbHS mJfP/GRXb1XSBKuQ2gM200izwtTdDya67Y8xYNZyYplSgdNW3X5+nNh7dk49Qp68k5Hg EH/+E2zepfWg7KkgRMgHs9EJm61xwzEX//kxI4v1+/sq21TnPfeCSokan9k7Jl0rW3ZO Mm93ebr4GHTdJuiR4D4KnLA04lL+oSM3EBTiJPOtRLDIHcwRFpzj7kDQ/CV5VD8S4ele bIpqJ1RnarXkZ1/r9E426XmkESKBPhskd+r13iZYj6O+hcMWKjTrz1iAch1YFm8jTVhg JfCQ== X-Gm-Message-State: ALyK8tKQTpIWF38UklaxsLDy4rKXdYIUDnN4uil5EKkRFu4dnDkLj8OnSHoczGgLd7Pas0SIfqS8yz2q8mibZA== X-Received: by 10.159.33.248 with SMTP id 111mr17205868uac.99.1468942965620; Tue, 19 Jul 2016 08:42:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Tue, 19 Jul 2016 08:42:45 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Tue, 19 Jul 2016 11:42:45 -0400 Message-ID: To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 15:52:42 -0000 Hi Alan, Thanks for the quick response. inline. On Tue, Jul 19, 2016 at 11:20 AM, Alan DeKok wrote: > On Jul 16, 2016, at 10:48 PM, Kathleen Moriarty wrote: >> >> Hello, >> >> Thank you for another very well written draft that serves a clear >> purpose and is easy to read and understand. I just have 2 questions >> that should be really easy and then would like to know when the WG >> prefers me to start IETF last call. And if you'd like IETF last call >> to start this week, should it be extended for a 3rd week? >> >> Comments/questions: >> Section 2.1.1 >> Should this say "be of a valid data type" >> Attr-Data >> >> The "Value" field of an Attribute as defined in [RFC2865] >> Section 5. The contents of this field MUST be a valid data >> type as defined in the RADIUS Data Type registry. > > I'm fine with the change. I'm not sure it makes a substantive change, tho. Thanks. > >> IANA Section 4.2 >> Does the registration policy remain unchanged from rfc3575? > > Yes. > >> If so, it >> would be helpful to state that since 4.1 defines the registration >> policy as requiring IETF review, > > The intent there is that new data types requires IETF review with Standards Action. It doesn't change the registration requirements for the RADIUS attributes registry. > > Maybe this is clearer: > > This section defines a new RADIUS registry, called "Data Type". > Allocation in this registry requires IETF Review. The "Registration > Procedures" for the Data Type Registry are "Standards Action". > I'm fine with the text you have my question was about 4.2, but included the above for context on the question. > >> different from what happens for 4.2 >> according to the description in rfc3575. > > OK. > > Maybe adding text here would be good: > > The existing registration requirements for the Attribute Type Registry > are unchanged. Perfect, thanks. Kathleen > > Alan DeKok. > -- Best regards, Kathleen From nobody Tue Jul 19 09:19:18 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E77F12D852 for ; Tue, 19 Jul 2016 09:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1WOPrxJ8nwJ for ; Tue, 19 Jul 2016 09:19:06 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100AC12D781 for ; Tue, 19 Jul 2016 09:17:29 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id BCF0F202BB; Tue, 19 Jul 2016 18:17:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 8E6FD20067; Tue, 19 Jul 2016 18:17:27 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0301.000; Tue, 19 Jul 2016 18:17:27 +0200 From: To: Kathleen Moriarty , Alan DeKok Thread-Topic: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-datatypes-04.txt Thread-Index: AQHR36N1IEGpz2xzJE2dnt1eF1YkJaAfwVeAgAAGPYCAACluIA== Date: Tue, 19 Jul 2016 16:17:26 +0000 Message-ID: <29432_1468945047_578E5297_29432_1897_1_6B7134B31289DC4FAF731D844122B36E01F147FC@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 16:19:08 -0000 Hi, Would it better to add (or repeat) such clarifications in the IANA consider= ations section? As a new version (simple update so far) is required anyway, I think it is O= K to wait for this new version and launch the IETF LC with a normal 2-week = period at least the next week (or ASAP after publication of the draft). Regards, Lionel > -----Message d'origine----- > De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Kathleen Mor= iarty > Envoy=E9=A0: mardi 19 juillet 2016 17:43 > =C0=A0: Alan DeKok > Cc=A0: radext@ietf.org > Objet=A0: Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-ra= dext- > datatypes-04.txt >=20 > Hi Alan, >=20 > Thanks for the quick response. inline. >=20 > On Tue, Jul 19, 2016 at 11:20 AM, Alan DeKok > wrote: > > On Jul 16, 2016, at 10:48 PM, Kathleen Moriarty > wrote: > >> > >> Hello, > >> > >> Thank you for another very well written draft that serves a clear > >> purpose and is easy to read and understand. I just have 2 questions > >> that should be really easy and then would like to know when the WG > >> prefers me to start IETF last call. And if you'd like IETF last call > >> to start this week, should it be extended for a 3rd week? > >> > >> Comments/questions: > >> Section 2.1.1 > >> Should this say "be of a valid data type" > >> Attr-Data > >> > >> The "Value" field of an Attribute as defined in [RFC2865] > >> Section 5. The contents of this field MUST be a valid data > >> type as defined in the RADIUS Data Type registry. > > > > I'm fine with the change. I'm not sure it makes a substantive change= , tho. >=20 > Thanks. > > > >> IANA Section 4.2 > >> Does the registration policy remain unchanged from rfc3575? > > > > Yes. > > > >> If so, it > >> would be helpful to state that since 4.1 defines the registration > >> policy as requiring IETF review, > > > > The intent there is that new data types requires IETF review with Sta= ndards > Action. It doesn't change the registration requirements for the RADIUS > attributes registry. > > > > Maybe this is clearer: > > > > This section defines a new RADIUS registry, called "Data Type". > > Allocation in this registry requires IETF Review. The "Registration > > Procedures" for the Data Type Registry are "Standards Action". > > >=20 > I'm fine with the text you have my question was about 4.2, but included t= he > above for context on the question. >=20 > > > >> different from what happens for 4.2 > >> according to the description in rfc3575. > > > > OK. > > > > Maybe adding text here would be good: > > > > The existing registration requirements for the Attribute Type Registry > > are unchanged. >=20 > Perfect, thanks. >=20 > Kathleen >=20 > > > > Alan DeKok. > > >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jul 19 23:24:54 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B8012DACC for ; Tue, 19 Jul 2016 23:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3O0EEOqlTL4 for ; Tue, 19 Jul 2016 23:24:33 -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 CBC7812D8A1 for ; Tue, 19 Jul 2016 23:24: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 0722943B0B for ; Wed, 20 Jul 2016 08:24:22 +0200 (CEST) To: radext@ietf.org References: <64d1393e-753e-4996-ad67-a32f631034c8@cisco.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <26fd40f0-5eb0-a4b3-6225-4af018fff430@restena.lu> Date: Wed, 20 Jul 2016 08:24:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <64d1393e-753e-4996-ad67-a32f631034c8@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3FfxxMfLqqv6IJo026qFkaJ7cEfchlsir" Archived-At: Subject: Re: [radext] Fwd: I-D Action: draft-chen-radext-extended-header-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 06:24:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3FfxxMfLqqv6IJo026qFkaJ7cEfchlsir Content-Type: multipart/mixed; boundary="jaA5aV5ES2nXGQKRGRRbgP7vpcXKXkqR8" From: Stefan Winter To: radext@ietf.org Message-ID: <26fd40f0-5eb0-a4b3-6225-4af018fff430@restena.lu> Subject: Re: [radext] Fwd: I-D Action: draft-chen-radext-extended-header-00.txt References: <64d1393e-753e-4996-ad67-a32f631034c8@cisco.com> In-Reply-To: <64d1393e-753e-4996-ad67-a32f631034c8@cisco.com> --jaA5aV5ES2nXGQKRGRRbgP7vpcXKXkqR8 Content-Type: multipart/mixed; boundary="------------B3DCA033D77843F2286A753C" This is a multi-part message in MIME format. --------------B3DCA033D77843F2286A753C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, we had 10 minutes of spare time, so I have just extended your slot from 5 to 10 minutes. The updated agenda is online. Greetings, Stefan Winter Am 13.07.2016 um 01:58 schrieb Enke Chen: > Hi, Stefan: > > Yes, I would like to present the draft. > > Can I have 10 minutes? > > Thanks. -- Enke > > Stefan Winter Mon, 11 July 2016 06:05 UTCSho= w header > > Hello, > > do you want a presentation slot at the upcoming meeting? > > Greetings, > > Stefan Winter > > Am 09.07.2016 um 01:54 schrieb Enke Chen: >> Hi, Folks: >> >> Please let us know if you have any comments. >> >> Thanks. -- Enke --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------B3DCA033D77843F2286A753C 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----- --------------B3DCA033D77843F2286A753C-- --jaA5aV5ES2nXGQKRGRRbgP7vpcXKXkqR8-- --3FfxxMfLqqv6IJo026qFkaJ7cEfchlsir 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 iQIcBAEBCgAGBQJXjxkVAAoJEMDeajWKOdxm3PoP/iA7FpA40wARdzwG9zf1YC5/ pedF3Faj4uYv25A+mU3Shl4Y3s7arvoYaFJ3+cesoFYSZojWC/1aOquVCztqIvPP yMkRjh3Zz2BxUBsrwAnTuEFP+z3kXErnVy0EMZAOOBkpwJIIO9muTGcJyDtO6cau Efks1t/1w5ejUiKJeNzmamVPS75DBcQnl+cyaPiDt/CL1K4Hrvk0XoeYA1Tjc4cG IPmDOeEN3AVly+J1wDt2jnFrH1wJItsCQhC26hgPrmdlfVY+KUQ/W3eW6QxpnUn9 lsJNX8GkjSAyIwFG8QWpTVk1L3/K5ZU3l/97wMmROMR0dw1e4BetA1AarjXMDj0h +l3H7e0ciULuVCkrWRvcIAbuYilM6aSiew9z4caWpB/jJCvNVENK8MODPC1vzOzj OOXZ7FUDo1GGq/Ee7lFPEaHBRN79N4PyJBre9RwFOJs4VOwSgJ3yFFJKEO22zWtM 0rinw7BwoCTYTP1id+AUEdjFsnde0kUNpEtadWrkS8p1ZnCjDXIfpJ4dbscbrnm3 1ZYq5A5NXBCEVJn+6grpDg/2r8Jh0Ywkcju3qHz9ek+NUzJZJJsyqnk784j896T2 q7upLW23DBPnww7c83Lixkr4pl58ELCDufYwiLjK50T1Ghlj63q7rHllKx0hXSRs I5EDyhv5GAE7V/6BOnPK =pKDK -----END PGP SIGNATURE----- --3FfxxMfLqqv6IJo026qFkaJ7cEfchlsir-- From nobody Wed Jul 20 06:02:10 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019A612D5F0 for ; Wed, 20 Jul 2016 06:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vzw5C_QHjTq for ; Wed, 20 Jul 2016 06:02:05 -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 7328312D5FB for ; Wed, 20 Jul 2016 06:02:05 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id C6FFA43B1C for ; Wed, 20 Jul 2016 15:02:03 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Wed, 20 Jul 2016 15:02:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cuNhWgor6MnxsPjXM3UJgPPQjKD5rhcET" Archived-At: Subject: [radext] Reminder: Slides X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 13:02:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cuNhWgor6MnxsPjXM3UJgPPQjKD5rhcET Content-Type: multipart/mixed; boundary="r1dFV4qb5rtIpBWN2oTHs2QxQHmMG4BiS" From: Stefan Winter To: "radext@ietf.org" Message-ID: Subject: Reminder: Slides --r1dFV4qb5rtIpBWN2oTHs2QxQHmMG4BiS Content-Type: multipart/mixed; boundary="------------6F3B531FF11A576D195AD759" This is a multi-part message in MIME format. --------------6F3B531FF11A576D195AD759 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, if you are going to present && have slides && haven't sent them to the chairs already then please do so at your earliest convenience. 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 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------6F3B531FF11A576D195AD759 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----- --------------6F3B531FF11A576D195AD759-- --r1dFV4qb5rtIpBWN2oTHs2QxQHmMG4BiS-- --cuNhWgor6MnxsPjXM3UJgPPQjKD5rhcET 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 iQIcBAEBCgAGBQJXj3ZLAAoJEMDeajWKOdxm7h0P/jEAVcRFE9upuC6HDIE5IoGb OykQXh0hI0hhISSqQh6ztKrlri5dMpO39sEB5DAJ2RqUn4JslPQdJwrgGuWd6Le5 VJ6t4JflWx8igoo2S6iUBpMElydUvfwGyrTFrb3YdF1vL+ziqzz1teEvnY0gRtV+ KtepSKIz3ewygT8xZ7TOW5cN5O5nZASOUDpGL6mqDde10kOKj0mdg2WkCSEBbxlA /yAJiXpU528jRA+YB9wlSmptErfiEGojo9yOXDddCM9tMgRBkoUIHq34kVleUbJU hxz4BGf1sTv32WtvehssxWIfH8THGOzosnNr79q2dXEOgMFHf9eLPr225MDXVUUU gbYD2c8NK2TR0Tku8DbuYqfK7/OSTWF6KenVeKr5Rnc+f25ed8g3i7WH+Xh+B2S7 J8pPWK2CPKauaLcn7gd2RL6MPoI7bRM/0t9gS/85dyimM6zg+v40ZAKUChk3xGLS WYIWCKvGdKHVBe/QYfh2zS3pzSVvk+BUiBHCXeIYR5YqrIW2iMb83UYYHv9SwdUu FtXDb5cXEAfHVO2l7CSeMI8aZ5IFOwR73LcliQof+pjfu1nv4xE8UTU43k2D5qCf z+Fv5ktsXFs1JMpVExpkpRwPTVWfNPCaQi0sDRWgUCGNIZgikrfnrNykAMp/rtOZ IFgA8RAadEIaPcUZkFqV =6jSF -----END PGP SIGNATURE----- --cuNhWgor6MnxsPjXM3UJgPPQjKD5rhcET-- From nobody Thu Jul 21 08:27:02 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A304212D69A; Thu, 21 Jul 2016 08:27:01 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160721152701.31791.12910.idtracker@ietfa.amsl.com> Date: Thu, 21 Jul 2016 08:27:01 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-datatypes-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:27:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Author : Alan DeKok Filename : draft-ietf-radext-datatypes-05.txt Pages : 37 Date : 2016-07-21 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-datatypes-05 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 Thu Jul 21 11:28:50 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B625612D73C for ; Thu, 21 Jul 2016 11:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujsJIuTY6fki for ; Thu, 21 Jul 2016 11:28:46 -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 B674712D6B5 for ; Thu, 21 Jul 2016 11:28:46 -0700 (PDT) Received: from staffmail (horde-int.restena.lu [IPv6:2001:a18:1:6::237]) by smtprelay.restena.lu (Postfix) with ESMTPS id 32E4743978 for ; Thu, 21 Jul 2016 20:28:44 +0200 (CEST) Received: from dhcp-9994.meeting.ietf.org (dhcp-9994.meeting.ietf.org [31.133.153.148]) by staffmail.restena.lu (Horde Framework) with HTTP; Thu, 21 Jul 2016 20:28:44 +0200 Date: Thu, 21 Jul 2016 20:28:44 +0200 Message-ID: <20160721202844.Horde.YAbjG7mhlr3mfqYnXXi8yA2@staffmail.restena.lu> From: stefan.winter@restena.lu To: radext@ietf.org User-Agent: Internet Messaging Program (IMP) H5 (6.2.0) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [radext] Preliminary minutes online X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 18:28:49 -0000 Hello, thanks again to all (20!) attendees for a very productive meeting. Alan has already sent the preliminary minutes; they are now available on the meeting materials page. Please comment and/or request a change where needed. Greetings, Stefan Winter From nobody Mon Jul 25 03:49:20 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E745812D7A0 for ; Mon, 25 Jul 2016 03:49: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-jNdEORoZhp for ; Mon, 25 Jul 2016 03:49:16 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1249312D798 for ; Mon, 25 Jul 2016 03:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 4DC431B42 for ; Mon, 25 Jul 2016 10:49:15 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdFAU_rzmZXE for ; Mon, 25 Jul 2016 10:49:15 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id E7F7BB92 for ; Mon, 25 Jul 2016 10:49:14 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 25 Jul 2016 06:49:13 -0400 To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [radext] Comments on draft-chen-radext-extended-header X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 10:49:18 -0000 I have some comments after the presentation at IETF. Yes, something like this has been needed for about 10 years. However, = I don't think this proposal is a good solution. Let's say the RADEXT WG likes it, and tries to standardize it. I'm = pretty sure that everyone *outside* of RADEXT will shoot it down in = flames. For very good reason. We just can't make breaking changes to the RADIUS protocol. We can't = extend it in incompatible ways. Doing so would involve creating a new = protocol, and we'd be better off using a "next generation" AAA protocol. Something like Diameter. :) But I disagree with Lionel's suggestion = to use Diameter, for the simple reason that the RADIUS needs are *much* = simpler than the Diameter ones. i.e. using the Diameter protocol as a transport layer may be a good = idea. Requiring NASes to implement all of Diameter is not. The NAS = vendors don't want to implement Diameter, the enterprises / telcos don't = want to use Diameter. RADIUS is (mostly) good enough. So we're stuck with RADIUS for now. The problem then becomes how do = we fix the 8-bit ID problem? There's at least one commercial product which has a work-around. They = add a VSA with an extended ID to each packet. The extended ID is used = only when manually configured on both client and server. It's a simple solution, and works well. The requirement for manual = configuration also avoids the issue of capability negotiation. That has = been an unresolved topic in this WG for almost a decade. Alan DeKok. From nobody Mon Jul 25 04:22:29 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD5112D7AE for ; Mon, 25 Jul 2016 04:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHtsNkPQNYxD for ; Mon, 25 Jul 2016 04:22:25 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A096D12D7AB for ; Mon, 25 Jul 2016 04:22:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 0A0871B42 for ; Mon, 25 Jul 2016 11:22:25 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmQqgSt_pyPD for ; Mon, 25 Jul 2016 11:22:24 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id A02CFD15 for ; Mon, 25 Jul 2016 11:22:24 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9D55473B-704A-43E4-88F1-50FB6408CF96@deployingradius.com> Date: Mon, 25 Jul 2016 07:22:23 -0400 To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [radext] Requirements for extended ID X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 11:22:27 -0000 Following on my previous email, I'd like to have a discussion around = the requirements for extending the RADIUS ID space. I think changing the headers or protocol is forbidden. Which pretty = much leaves us with using an attribute that contains the extended ID. If the extended ID is used in packets without prior configuration or = negotiation, existing proxies may forward that attribute as-is. That = may lead subsequent servers to erroneously believe that the previous hop = was the source of the extended ID. So we can only send the extended ID when manually configured, or when = server capability is discovered. After some thinking, I think it's OK to ignore the problem for UDP = transport. the reason is that UDP has another issue, which is small = packets. Each UDP packet takes up one ethernet frame. Even if the = extended ID allows a NAS to send 1M packets/s over a UDP src/dst IP/port = pair, Ethernet can't always support that. Moving to TCP transport solves the Ethernet issue. It also helps with = the capability negotiation. Because if a TCP connection remains up, = you're pretty sure that you've stayed connected to a particular = application. In contrast, a UDP application can change between = reception of one UDP packet and the next. So adding capability = negotiation to UDP means that you're never really sure if the other end = actually is the same one now, that you negotiated with, 10 minutes ago. I think the text in Section 2.3 of = https://tools.ietf.org/html/draft-chen-radext-extended-header-00 is OK. = I'd add: * the Status-Server MUST only be sent over TCP/TLS connections, and it = MUST be the first packet sent over that connection.=20 * other packets MAY be sent over that connection before extended ID is = used, but those packets MUST NOT use the extended ID until it has been = negotiation. * in practice, it's probably better to just wait. * If a new TCP/TLS connection is brought up while an old one is still = active, the new one MAY just send extended ID without negotiation. * in practice, it's probably better to just negotiate every time. It = simplifies the code, and it's only one packet. * it can work with DTLS too, as there is an underlying TLS connection. * it can *sort of* work with UDP, subject to the problems noted above. = But I'd be OK with implementing it. I don't think there would be many = issues in practice. The next question is what *format* does the extended ID have? A = 32-bit token would be a good choice. I think we should take a serious = look at making it 64-bit. The reason is a different, but related problem. When proxies = fail-over, a duplicate packet can get routed across different paths. = Right now, the home server won't detect the new packet as a duplicate. = I think it should be able to do that. The solution may be to just re-use the Hop-by-Hop Identifier and = End-to-End Identifier from Diameter. :) The text in RFC 6733 is mostly OK for RADIUS. I'd replace the use of = Origin-Host AVP with the Opaque-NAS-Identifier from the CoA proxy = document. Hmm... for Status-Server, I'd argue that the End-to-End Identifier = MUST be zero. Which indicates that it's a message local to the current = hop, and must not be proxied. Alan DeKok. From nobody Mon Jul 25 07:24:17 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDB412D8BF for ; Mon, 25 Jul 2016 07:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DxrVWH6CteV4 for ; Mon, 25 Jul 2016 07:24:12 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 85D9D12D8CB for ; Mon, 25 Jul 2016 07:24:12 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id x72so64724624pfd.2 for ; Mon, 25 Jul 2016 07:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JJ1C7f53LxRSXBI6hSZFjHSZcgjDDUANYnuu/mIhdOc=; b=q2zm14BTEPgXEvp5LzxxkzHfTzMOzTQIcfln0nIQzacexpp6TcgQ3V6Zxdph+voZY7 vVwVycHC1dircVH8Hf3jWbaz+xmcSVjlaZn/ehoOQLuLKJcpOvrn50WYMxQBBdDIYAAR +f8ECt6gWne4EX8iqVVcIuTmSKbosBuYtpVKXDWzOBaEhF9MLIeN2mroGdkCqtPME9TP 4VSKeizvZHzAK3lkO1QtA23+PjgVgWxVx9LxK/cZ7vjsK6MUFRMhIVAp5J+HnWyZm8GB 05iTsBoTYmZaWNx4lvO+lINArAsYBcilh14MIuMD4M7GZ5TGLWakle7Q+LwEjMWLa94Y EExA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JJ1C7f53LxRSXBI6hSZFjHSZcgjDDUANYnuu/mIhdOc=; b=ggkgetuOrEPU4fnFWuxa3XNXuv+qTXDyrHF1Dun7+auITP1lFfUBuVa6e/ljvurEYU g4JYz/rp+n40x5+cHc9MAhfDN0YnmjAC8IStLJvWtxAjRF1q0E0B7p50NXfDsfPTkDat 21SWkRrbalbSkWdzx4qnEBNeusPOxiopZD6YMiTjqzEBDQ5l2sx2OdBJ3G69spMvnd8c 7CLKK7/VLknrUEoZ6XuHVlPp+TPnlLvqYaL0GO9t1WWxsMHzQGlaR88nKpuAy6J7FCv2 YVe1OYT5lW+6tDkA1p+ZgUVVQ/W0Nlbu8tLwlUZaDszAVrn7pzUGwMVU+rGxVqhJmJjS LlfQ== X-Gm-Message-State: AEkoouty6JzXFE4LDCKE1o0u4zdogP2J41Qxl3g+OdHW0+gvnTREKLlgYW2q4JgPVhWUNg== X-Received: by 10.98.102.221 with SMTP id s90mr29707724pfj.69.1469456649191; Mon, 25 Jul 2016 07:24:09 -0700 (PDT) Received: from [192.168.1.117] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id e2sm40717401pfd.45.2016.07.25.07.24.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jul 2016 07:24:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13G34) In-Reply-To: Date: Mon, 25 Jul 2016 07:24:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2268CB1A-9D6B-4488-B50B-A51B27BA8FC5@gmail.com> References: To: Alan DeKok Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Comments on draft-chen-radext-extended-header X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 14:24:15 -0000 Agree with Alan.=20 There is a real problem here but the proposed (backward incompatible) soluti= on is a non-starter. The VSA extended ID approach has been in use for a deca= de and is a much better example of how this problem should be approached. > On Jul 25, 2016, at 03:49, Alan DeKok wrote: >=20 > I have some comments after the presentation at IETF. >=20 > Yes, something like this has been needed for about 10 years. However, I d= on't think this proposal is a good solution. >=20 > Let's say the RADEXT WG likes it, and tries to standardize it. I'm prett= y sure that everyone *outside* of RADEXT will shoot it down in flames. For v= ery good reason. >=20 > We just can't make breaking changes to the RADIUS protocol. We can't ext= end it in incompatible ways. Doing so would involve creating a new protocol= , and we'd be better off using a "next generation" AAA protocol. >=20 > Something like Diameter. :) But I disagree with Lionel's suggestion to u= se Diameter, for the simple reason that the RADIUS needs are *much* simpler t= han the Diameter ones. >=20 > i.e. using the Diameter protocol as a transport layer may be a good idea.= Requiring NASes to implement all of Diameter is not. The NAS vendors don'= t want to implement Diameter, the enterprises / telcos don't want to use Dia= meter. RADIUS is (mostly) good enough. >=20 > So we're stuck with RADIUS for now. The problem then becomes how do we f= ix the 8-bit ID problem? >=20 > There's at least one commercial product which has a work-around. They ad= d a VSA with an extended ID to each packet. The extended ID is used only wh= en manually configured on both client and server. >=20 > It's a simple solution, and works well. The requirement for manual confi= guration also avoids the issue of capability negotiation. That has been an u= nresolved topic in this WG for almost a decade. >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Jul 26 14:07:49 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1130712D986 for ; Tue, 26 Jul 2016 14:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 O3drbR8UeB2W for ; Tue, 26 Jul 2016 14:07:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E6812D990 for ; Tue, 26 Jul 2016 14:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4312; q=dns/txt; s=iport; t=1469567253; x=1470776853; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xjkcPT+2famjCGHW735C/fTAaxCyJRQSmAc8lE+pNXg=; b=lVTa2bItiDBtDHSjlDPYt/r5Q7IYpbYsRi4I1IQeFnuKk7O65ynOVmg/ ayh3DJHWlXG0tKap8YCWlyuEYl8NOnCnXbReb6wp3JRhzUXSxMWXVVDxR bpAu1dup0HRrx72MJqe2xLfrOhaSC8/lEM+Nqe0dxFP9+ZXiac12zyFAo 0=; X-IronPort-AV: E=Sophos;i="5.28,426,1464652800"; d="scan'208";a="128122934" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jul 2016 21:07:32 +0000 Received: from [10.24.95.249] ([10.24.95.249]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6QL7TQZ023308; Tue, 26 Jul 2016 21:07:30 GMT To: Alan DeKok References: <9D55473B-704A-43E4-88F1-50FB6408CF96@deployingradius.com> From: Enke Chen Message-ID: Date: Tue, 26 Jul 2016 14:07:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <9D55473B-704A-43E4-88F1-50FB6408CF96@deployingradius.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: radext@ietf.org, Naiming Shen , Enke Chen Subject: Re: [radext] Requirements for extended ID X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 21:07:48 -0000 Hi, Alan: Thanks for your comments. My comments are inlined. On 7/25/16 4:22 AM, Alan DeKok wrote: > Following on my previous email, I'd like to have a discussion around the requirements for extending the RADIUS ID space. > > I think changing the headers or protocol is forbidden. Could you please elaborate on why changing the headers of a protocol is forbidden? AFAIK, it has been done in several other protocols for similar reasons that we are facing in Radius. I understand that such changes are not to be taken lightly ... > Which pretty much leaves us with using an attribute that contains the extended ID. > > If the extended ID is used in packets without prior configuration or negotiation, existing proxies may forward that attribute as-is. That may lead subsequent servers to erroneously believe that the previous hop was the source of the extended ID. > > So we can only send the extended ID when manually configured, or when server capability is discovered. Yes, that is right. We either use "capability discovery" or manually configuration. > > After some thinking, I think it's OK to ignore the problem for UDP transport. the reason is > that UDP has another issue, which is small packets. > Each UDP packet takes up one ethernet frame. Even if the extended ID allows a NAS to > send 1M packets/s over a UDP src/dst IP/port pair, > Ethernet can't always support that. How about the case of using multiple interfaces? > > Moving to TCP transport solves the Ethernet issue. It also helps with the capability negotiation. > Because if a TCP connection remains up, you're pretty sure that you've stayed connected to a > particular application. > In contrast, a UDP application can change between reception of one UDP packet and the next. > So adding capability negotiation to UDP means that you're never really sure if the other end > actually is the same one now, that you negotiated with, 10 minutes ago. TCP has the same issue with the "ID" field, though. > > I think the text in Section 2.3 of https://tools.ietf.org/html/draft-chen-radext-extended-header-00 is OK. I'd add: > > * the Status-Server MUST only be sent over TCP/TLS connections, and it MUST be the first packet sent over that connection. > > * other packets MAY be sent over that connection before extended ID is used, but those packets MUST NOT use the extended ID until it has been negotiation. > * in practice, it's probably better to just wait. Ok. > > * If a new TCP/TLS connection is brought up while an old one is still active, the new one MAY just send extended ID without negotiation. > * in practice, it's probably better to just negotiate every time. It simplifies the code, and it's only one packet. Yes, I agree. > > * it can work with DTLS too, as there is an underlying TLS connection. Ok. > > * it can *sort of* work with UDP, subject to the problems noted above. But I'd be OK with implementing it. > I don't think there would be many issues in practice. That is good - given your implementation experience. > > > The next question is what *format* does the extended ID have? A 32-bit token would be a good choice. > I think we should take a serious look at making it 64-bit. I am fine with 64-bit if it is indeed desirable. > > The reason is a different, but related problem. When proxies fail-over, a duplicate packet can get > routed across different paths. Right now, the home server won't detect the new packet as a duplicate. > I think it should be able to do that. > > The solution may be to just re-use the Hop-by-Hop Identifier and End-to-End Identifier from Diameter. :) > > The text in RFC 6733 is mostly OK for RADIUS. I'd replace the use of Origin-Host AVP with the > Opaque-NAS-Identifier from the CoA proxy document. > > Hmm... for Status-Server, I'd argue that the End-to-End Identifier MUST be zero. Which indicates > that it's a message local to the current hop, and must not be proxied. > > Alan DeKok. Thanks. Will incorporate your comments in the next revision. -- Enke > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Tue Jul 26 14:19:47 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655AF12D964 for ; Tue, 26 Jul 2016 14:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 v9HKYyZgoRDb for ; Tue, 26 Jul 2016 14:19:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16BC12D09A for ; Tue, 26 Jul 2016 14:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2574; q=dns/txt; s=iport; t=1469567984; x=1470777584; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=MRkLYXgT8WxVrkvEhLmyCQnoSB40QrFkpmXH3MBZ0FE=; b=Gm3FM8F5faj7dHWAXPORDp8bdbUK5VDbkwMsRr1PSFY1O7UPX0svNkmG mExMJFnCydqpR5VC+eVRJ17+HHZcyijmiZoPcslF9Gbujf2pcujuO8fXN //vcVNhEU6o7fSoVQeRoEgO0VMOYrBV/ik2A4GJXFrE7/rfNvVXfh1Pni g=; X-IronPort-AV: E=Sophos;i="5.28,426,1464652800"; d="scan'208";a="128127256" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jul 2016 21:19:44 +0000 Received: from [10.24.95.249] ([10.24.95.249]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6QLJbab015477; Tue, 26 Jul 2016 21:19:41 GMT To: Alan DeKok References: From: Enke Chen Message-ID: Date: Tue, 26 Jul 2016 14:19:38 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: radext@ietf.org, Naiming Shen , Enke Chen Subject: Re: [radext] Comments on draft-chen-radext-extended-header X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 21:19:46 -0000 Hi, Alan: Again thanks for your review and commands. My comments are inlined. On 7/25/16 3:49 AM, Alan DeKok wrote: > I have some comments after the presentation at IETF. > > Yes, something like this has been needed for about 10 years. However, I don't think this > proposal is a good solution. If there are specific suggestions, we will be happy to work you and others to make it better. > > Let's say the RADEXT WG likes it, and tries to standardize it. I'm pretty sure that everyone > *outside* of RADEXT will shoot it down in flames. For very good reason. > > We just can't make breaking changes to the RADIUS protocol. We can't extend it in > incompatible ways. Doing so would involve creating a new protocol, and we'd be better > off using a "next generation" AAA protocol. I agree - this has to be done in a backward compatible manner, and that is what the proposal tries to achieve. Which part of the proposal would break backward compatibility? > > Something like Diameter. :) But I disagree with Lionel's suggestion to use Diameter, > for the simple reason that the RADIUS needs are *much* simpler than the Diameter ones. > > i.e. using the Diameter protocol as a transport layer may be a good idea. Requiring NASes > to implement all of Diameter is not. The NAS vendors don't want to implement Diameter, > the enterprises / telcos don't want to use Diameter. RADIUS is (mostly) good enough. > > So we're stuck with RADIUS for now. The problem then becomes how do we fix the 8-bit ID problem? > > There's at least one commercial product which has a work-around. They add a VSA with an > extended ID to each packet. The extended ID is used only when manually configured on both > client and server. > > It's a simple solution, and works well. The requirement for manual configuration also avoids > the issue of capability negotiation. That has been an unresolved topic in this WG for almost > a decade. Certainly manual config is an option as listed in the draft. Regarding using the capability discovery, I do not understand the concerns or issues. Certainly it has been used by several recent extensions quite effectively. It seems to me that the capability discovery is quite nice in facilitating deployment of new features, and it is something that is needed. -- Enke > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Tue Jul 26 14:28:33 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7ED12D9A3 for ; Tue, 26 Jul 2016 14:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 TouuzxTMJpmg for ; Tue, 26 Jul 2016 14:28:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186CF12D9A0 for ; Tue, 26 Jul 2016 14:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2743; q=dns/txt; s=iport; t=1469568509; x=1470778109; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4KuycZC9uDIjxAHAn3YJ4NelB1/DDVg1vYSiLaveWdk=; b=mzvYb//JTl1baXSW9VFQ1mfTM1pKnu0iN2xsTFjWj85BWS5mTNyQgSzS DxvdNZS3ru6qTnyLvaGlaO2G1Ox6CV0dirBn+Y9Q0DT5gpo6zoc+9cz3N J2NildGRct4NHRuITrXMDVH5VzIROr+pFfMPcXoB2yNY2RAKt52DZEssk Q=; X-IronPort-AV: E=Sophos;i="5.28,426,1464652800"; d="scan'208";a="133843333" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2016 21:28:28 +0000 Received: from [10.24.95.249] ([10.24.95.249]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6QLSQ6q002253; Tue, 26 Jul 2016 21:28:27 GMT To: Bernard Aboba References: <2268CB1A-9D6B-4488-B50B-A51B27BA8FC5@gmail.com> From: Enke Chen Message-ID: <81889c4c-8ec7-0c4e-9706-acc27401f258@cisco.com> Date: Tue, 26 Jul 2016 14:28:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <2268CB1A-9D6B-4488-B50B-A51B27BA8FC5@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: radext@ietf.org, Naiming Shen , Enke Chen , Alan DeKok Subject: Re: [radext] Comments on draft-chen-radext-extended-header X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 21:28:31 -0000 Hi, Bernard: As I replied to Alan, the proposal tries to address the issue in a backward compatible manner. If there is something that would be of concern in the area, please let us know. Regarding the option of using a VSA attribute, it is something that we discussed before submitting the proposal. Since this is a fundamental issue, it would be better for customers and our industry if the issue is addressed by radius server vendors broadly. Thanks. -- Enke On 7/25/16 7:24 AM, Bernard Aboba wrote: > Agree with Alan. > > There is a real problem here but the proposed (backward incompatible) solution is a non-starter. The VSA extended ID approach has been in use for a decade and is a much better example of how this problem should be approached. > >> On Jul 25, 2016, at 03:49, Alan DeKok wrote: >> >> I have some comments after the presentation at IETF. >> >> Yes, something like this has been needed for about 10 years. However, I don't think this proposal is a good solution. >> >> Let's say the RADEXT WG likes it, and tries to standardize it. I'm pretty sure that everyone *outside* of RADEXT will shoot it down in flames. For very good reason. >> >> We just can't make breaking changes to the RADIUS protocol. We can't extend it in incompatible ways. Doing so would involve creating a new protocol, and we'd be better off using a "next generation" AAA protocol. >> >> Something like Diameter. :) But I disagree with Lionel's suggestion to use Diameter, for the simple reason that the RADIUS needs are *much* simpler than the Diameter ones. >> >> i.e. using the Diameter protocol as a transport layer may be a good idea. Requiring NASes to implement all of Diameter is not. The NAS vendors don't want to implement Diameter, the enterprises / telcos don't want to use Diameter. RADIUS is (mostly) good enough. >> >> So we're stuck with RADIUS for now. The problem then becomes how do we fix the 8-bit ID problem? >> >> There's at least one commercial product which has a work-around. They add a VSA with an extended ID to each packet. The extended ID is used only when manually configured on both client and server. >> >> It's a simple solution, and works well. The requirement for manual configuration also avoids the issue of capability negotiation. That has been an unresolved topic in this WG for almost a decade. >> >> Alan DeKok. >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Tue Jul 26 15:35:22 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BED112D544 for ; Tue, 26 Jul 2016 15:35:21 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL9_-5OYoQ74 for ; Tue, 26 Jul 2016 15:35:19 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 69D0112D5AD for ; Tue, 26 Jul 2016 15:35:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 74A911B42; Tue, 26 Jul 2016 22:35:17 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM3i1GHFPHMD; Tue, 26 Jul 2016 22:35:17 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id B6B13B92; Tue, 26 Jul 2016 22:35:15 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 26 Jul 2016 18:35:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D55473B-704A-43E4-88F1-50FB6408CF96@deployingradius.com> To: Enke Chen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: radext@ietf.org, Naiming Shen Subject: Re: [radext] Requirements for extended ID X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 22:35:21 -0000 On Jul 26, 2016, at 5:07 PM, Enke Chen wrote: > Could you please elaborate on why changing the headers of a protocol = is forbidden? Because changing the headers means it's no longer RADIUS. > AFAIK, it has been done in several other protocols for similar reasons = that we are > facing in Radius. I understand that such changes are not to be taken = lightly ... We already have a "next generation" RADIUS protocol. It's called = Diameter. We can't make substantial changes to RADIUS, or else we might = as well give up, and just use Diameter. >> After some thinking, I think it's OK to ignore the problem for UDP = transport. the reason is >> that UDP has another issue, which is small packets.=20 >> Each UDP packet takes up one ethernet frame. Even if the extended ID = allows a NAS to=20 >> send 1M packets/s over a UDP src/dst IP/port pair, >> Ethernet can't always support that. >=20 > How about the case of using multiple interfaces? It doesn't really change anything. Ethernet has an upper limit of = packets it can sustain. UDP packets use up one Ethernet frame, but only = carry a small amount of data. That limits the total bandwidth of the = ethernet link. If the goal is to allow more data between client and server, then we = should allow the maximum amount of data that can be carried via = ethernet. > Thanks. Will incorporate your comments in the next revision. My $0.02: * delete all the text about changing the header * move to using a 64-bit attribute, with text mostly taken from RFC = 6733. Alan DeKok. From nobody Wed Jul 27 17:58:16 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE54612D94E for ; Wed, 27 Jul 2016 17:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 At0caqg83ydb for ; Wed, 27 Jul 2016 17:58:13 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 9C9DC12D8E1 for ; Wed, 27 Jul 2016 17:58:13 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id l32so29350768ual.2 for ; Wed, 27 Jul 2016 17:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=AqzkJSZcZnZDmQv3HDxt2/hl5Bj58Z4VoAZYncj4o0w=; b=AuY2L0IhQV7rC7E/NsaK92ffVhDTXqa/hU76IEdF5+UbK+dxJ+DRtBKEtDSR/kpRVf OjBqnnNm+ygIdlFnDCqL+XSvbTzDk7MbpgM9D0ZV5a22Me8oMkosY41XJ58BlV4zodOo Ar/pIfAv7rGLwVfjjQwOv8Q2EPtaUyDj7vdGvvqOBJxv0sCUyQy7ZpArL+B4Ad+5fNP5 JP4fEj4ysSnH9nR05Ik7UW1ZdBVo9Dmek4Mb9ex6kTX+JZ3wDNXCXUtfiVi+YVkLxCAL 7AFSQovVldr57haTTVAZBJQ5tH5TIJ8eJyOAbLWaVOSX/VrM5kKdVhsgF/OlhA285F3B SvRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AqzkJSZcZnZDmQv3HDxt2/hl5Bj58Z4VoAZYncj4o0w=; b=AyOpTxaw8+XPoOPPYUiIAL6wzCmLVHnHkadWTRIyxPfIZ69If7pyRAk3nG7SFachlD /3GxQLczn1svmVxzOIbzbuRWOi+R8Ea0ZsSk+RFDcsD9o9seeP7AXL1MwPY7cNmTgh8M ka4Tx3rD6mrOcig7Fut26hRbGgk3jF0dHA/Iueyn6rph+FY7pNeNiHKH+NRlVYKK3BcE OVRWVFSta7eFmlFCn1UmTl+lYJGK74JW9a92gBzZPaPTilfaecCYHMvPMK0hOjGuOKZ+ M7avDompBxHyqoh7PMrJpCcNfxMXK7R9xpBd2q0tArH132Kr3wMUJh5M/UWwqgxDsVW5 qT9Q== X-Gm-Message-State: AEkoous71iQgyOK492zSwrcu0//FinUYSDBdL+h3w9oT1DfrEP/bHhKkvGnfW4NzkORKpXNMH2NKIT1ucC1jqg== X-Received: by 10.176.3.174 with SMTP id 43mr14744527uau.88.1469667492561; Wed, 27 Jul 2016 17:58:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Wed, 27 Jul 2016 17:58:12 -0700 (PDT) From: Kathleen Moriarty Date: Wed, 27 Jul 2016 20:58:12 -0400 Message-ID: To: "radext@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 00:58:15 -0000 Hello, Thank you for your work on draft-ietf-radext-ip-port-radius-ext. This is an easy to understand document. I found a few nits and think more text is needed in the security considerations section. My review is below. Abstract second sentence nit: s/implementing/implement/ From: For devices that implementing IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. To: For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. 2. Terminology I think some rewording is needed, 'in respective' doesn't quite fit in the following definition: External realm: refers to the networking segment where external IP addresses are used in respective of the device supporting port ranges. In the following definition, expand out CGN. I am pretty sure the others are acronyms that are in the do not have to expand list. This one isn't one that I am familiar with: o Port-based device: a device that is capable of providing IP address and IP port mapping services and in particular, with the granularity of one or more subsets within the 16-bit IP port number range. A typical example of this device is a CGN, CPE, Provider WLAN Gateway, etc. Section 4.1.2: s/once/one/ As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP identifiers once at a time for a specific user, Security considerations: Shouldn't there be some considerations about the communications for these attributes between the radius server and NAt44 or other devices? Since these attributes can be used to communicate a change in permissions (port/address mappings) that open/shut permissions for a user, the user could be subject to attacks by alterations or tampering of this stream. One might be to allow ports to be open that would make the system vulnerable to attack. The other would be to close ports off that are needed, resulting in a denial of service. I would think there are considerations to list with each of the new attributes along these lines. This would be specific text to the added attributes and communication of these attributes on the wire. Let me know if I am missing something as to why this is already covered in radius security considerations. I think the specific attribute addd should have their concerns listed. Thanks! -- Best regards, Kathleen From nobody Thu Jul 28 01:00:32 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DC912D647 for ; Thu, 28 Jul 2016 01:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EPYiUj-3tKr for ; Thu, 28 Jul 2016 01:00:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF7D12D625 for ; Thu, 28 Jul 2016 01:00:29 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CE6C32644AF; Thu, 28 Jul 2016 10:00:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AE83C4C086; Thu, 28 Jul 2016 10:00:27 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0301.000; Thu, 28 Jul 2016 10:00:27 +0200 From: To: Kathleen Moriarty , "radext@ietf.org" Thread-Topic: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext Thread-Index: AdHophdFKwCkjVQ8ShCWcps8MBMC/w== Date: Thu, 28 Jul 2016 08:00:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DEE831@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Subject: Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 08:00:32 -0000 Dear Kathleen, Thank you for the review.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Kathleen > Moriarty > Envoy=E9=A0: jeudi 28 juillet 2016 02:58 > =C0=A0: radext@ietf.org > Objet=A0: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext >=20 > Hello, >=20 > Thank you for your work on draft-ietf-radext-ip-port-radius-ext. This > is an easy to understand document. I found a few nits and think more > text is needed in the security considerations section. My review is > below. >=20 >=20 > Abstract > second sentence nit: s/implementing/implement/ [Med] Fixed.=20 > From: For devices that > implementing IP port ranges, these attributes are used to communicate > with a RADIUS server in order to configure and report TCP/UDP ports > and ICMP identifiers, as well as mapping behavior for specific hosts. > To: For devices that > implement IP port ranges, these attributes are used to communicate > with a RADIUS server in order to configure and report TCP/UDP ports > and ICMP identifiers, as well as mapping behavior for specific hosts. >=20 > 2. Terminology >=20 > I think some rewording is needed, 'in respective' doesn't quite fit in > the following definition: >=20 > External realm: refers to the networking segment where external IP > addresses are used in respective of the device supporting port > ranges. [Med] Changed to:=20 External realm: refers to the networking segment where external IP addresse= s are used as source addresses of outbound packets forwarded by a device su= pporting port ranges. Better? > In the following definition, expand out CGN. [Med] CGN is already expanded in the introduction. I am pretty sure the > others are acronyms that are in the do not have to expand list. This > one isn't one that I am familiar with: > o Port-based device: a device that is capable of providing IP > address and IP port mapping services and in particular, with the > granularity of one or more subsets within the 16-bit IP port > number range. A typical example of this device is a CGN, CPE, > Provider WLAN Gateway, etc. >=20 > Section 4.1.2: s/once/one/ [Med] Fixed.=20 > As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP > identifiers once at a time for a specific user, >=20 > Security considerations: >=20 > Shouldn't there be some considerations about the communications for > these attributes between the radius server and NAt44 or other devices? [Med] I don't think this is specific to these attributes but this is applic= able to all RADIUS applications.=20 > Since these attributes can be used to communicate a change in > permissions (port/address mappings) that open/shut permissions for a > user, the user could be subject to attacks by alterations or tampering > of this stream. One might be to allow ports to be open that would > make the system vulnerable to attack. The other would be to close > ports off that are needed, resulting in a denial of service. >=20 > I would think there are considerations to list with each of the new > attributes along these lines. This would be specific text to the > added attributes and communication of these attributes on the wire. [Med] The root cause of these attack vectors is the communication between t= he RADIUS client/server. Saying that, what about making this change to illu= strate some attacks as you suggested? OLD: This document does not introduce any security issue other than the ones already identified in RADIUS [RFC2865]. NEW: This document does not introduce any security issue other than the ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA messages. Known RADIUS vulnerabilities apply to this specification. For example, if RADIUS packets are sent in the clear, an attacker in the communication path between the RADIUS client and server may glean information that it will use to prevent a legitimate user to access the service by appropriately setting the maximum number of IP ports conveyed in an IP-Port-Limit-Info attribute, exhaust the port quota of a user by installing many mapping entries (IP-Port-Forwarding-Map attribute), prevent incoming traffic to be delivered to its legitimate destination by manipulating the mapping entries installed by means of an IP-Port-Forwarding-Map attribute, discover the IP address and port range assigned to a given user and which is reported in an IP-Port-Range attribute, etc. The root cause of these attack vectors is the communication between the RADIUS client and server. This document targets deployed where a trusted relationship is in place between the RADIUS client and server with communication optionally secured by IPsec or Transport Layer Security (TLS) [RFC6614]. Better? >=20 > Let me know if I am missing something as to why this is already > covered in radius security considerations. I think the specific > attribute addd should have their concerns listed. >=20 > Thanks! [Med] Thank you for the review. > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Thu Jul 28 07:08:31 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2530112D73D for ; Thu, 28 Jul 2016 07:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 t-NR3lo7tVuc for ; Thu, 28 Jul 2016 07:08:27 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 A672412D743 for ; Thu, 28 Jul 2016 07:08:27 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 52so48818973qtq.3 for ; Thu, 28 Jul 2016 07:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u5+PoSis4TJDtCJpQ1cIxaYi0kJJIMZmBZAlWUA8pAY=; b=rbt0sQW1iMB/YUFyTFFNi9cdbXCZf2F7gAKcem8nacEWL4qDiAXA5Zz2ouDOzSl0D3 el+eSdEec2eo9OceWKhzkZ5CYoRP89DvT6D4szSL8I4VwwrdrbQeNly407AIXzPcdMIM b5oavX7LIiQHOHykRngds4Ec4Vlpv+RYpbZsa2VW/KACMm70HSjFczCoIKjtvRYMMVAl sWDb3x7iLcF3zUMIPPJDnVpmoMHK1Aw8g5bM8DLbSgz3zs58UUdcV+9m2888KdSIeDR8 lBSwyfeGgtHnDC2X2Fpvi8MPhDfAv9Lnm4aeSPtBPT3zzwFfnshI/aOuNHstTlWUYw/A T61A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u5+PoSis4TJDtCJpQ1cIxaYi0kJJIMZmBZAlWUA8pAY=; b=m0u7pD4xQYVeh/eiVb5cPKNS8uMSA5WQfezPMjC2x/e1LvqDPEpIy6iK4wlAPFzjhz EuX8EAGlX3nWEB+qd1wamMXk1Cyxaern7QhJyBKbhFwzMgvrzZuX+ENtOz4JUgvhkKZi C0AqCFSV1VtBewuygFdr/tNx1vL3bS0iC0nYVFO3YAU7dRLbiY27DXQYFrbhkx6JoIcN 0Ihj32Yu4jGOnZ9PH+CbS9ze+gvFHXkox3L3kSYKBdRa/Mf/CcunA6JhCVuFOQT43+mw F2uhZMmdHYfu5r2iwohHe9NPzp85TZ5yCaPb6a8Y5zZW97M1vcsUqU84dKG9bOXQt1vp io2g== X-Gm-Message-State: AEkoouuQ2/NODHhYwPriT2c7NvfZfEZhj8/DD25Vvr297cShPFc8EFDhFjELOkpqTCEhDg== X-Received: by 10.200.52.182 with SMTP id w51mr57192251qtb.90.1469714906565; Thu, 28 Jul 2016 07:08:26 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id h25sm7337731qtc.38.2016.07.28.07.08.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jul 2016 07:08:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13F69) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DEE831@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 28 Jul 2016 10:08:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6CFAC713-3903-4947-A3F8-691A7008B567@gmail.com> References: <787AE7BB302AE849A7480A190F8B933008DEE831@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 14:08:30 -0000 Hello Mohamed, Thank you for the quick response. Inline Sent from my iPhone > On Jul 28, 2016, at 4:00 AM, wrote: >=20 > Dear Kathleen, >=20 > Thank you for the review.=20 >=20 > Please see inline. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : radext [mailto:radext-bounces@ietf.org] De la part de Kathleen >> Moriarty >> Envoy=C3=A9 : jeudi 28 juillet 2016 02:58 >> =C3=80 : radext@ietf.org >> Objet : [radext] AD Review of draft-ietf-radext-ip-port-radius-ext >>=20 >> Hello, >>=20 >> Thank you for your work on draft-ietf-radext-ip-port-radius-ext. This >> is an easy to understand document. I found a few nits and think more >> text is needed in the security considerations section. My review is >> below. >>=20 >>=20 >> Abstract >> second sentence nit: s/implementing/implement/ > [Med] Fixed.=20 >=20 >> From: For devices that >> implementing IP port ranges, these attributes are used to communicate >> with a RADIUS server in order to configure and report TCP/UDP ports >> and ICMP identifiers, as well as mapping behavior for specific hosts. >> To: For devices that >> implement IP port ranges, these attributes are used to communicate >> with a RADIUS server in order to configure and report TCP/UDP ports >> and ICMP identifiers, as well as mapping behavior for specific hosts. >>=20 >> 2. Terminology >>=20 >> I think some rewording is needed, 'in respective' doesn't quite fit in >> the following definition: >>=20 >> External realm: refers to the networking segment where external IP >> addresses are used in respective of the device supporting port >> ranges. > [Med] Changed to:=20 >=20 > External realm: refers to the networking segment where external IP address= es are used as source addresses of outbound packets forwarded by a device su= pporting port ranges. >=20 > Better? Yes, thank you! >=20 >> In the following definition, expand out CGN. >=20 > [Med] CGN is already expanded in the introduction. >=20 > I am pretty sure the >> others are acronyms that are in the do not have to expand list. This >> one isn't one that I am familiar with: >> o Port-based device: a device that is capable of providing IP >> address and IP port mapping services and in particular, with the >> granularity of one or more subsets within the 16-bit IP port >> number range. A typical example of this device is a CGN, CPE, >> Provider WLAN Gateway, etc. >>=20 >> Section 4.1.2: s/once/one/ > [Med] Fixed.=20 >=20 >> As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP >> identifiers once at a time for a specific user, >>=20 >> Security considerations: >>=20 >> Shouldn't there be some considerations about the communications for >> these attributes between the radius server and NAt44 or other devices? >=20 > [Med] I don't think this is specific to these attributes but this is appli= cable to all RADIUS applications.=20 >=20 >> Since these attributes can be used to communicate a change in >> permissions (port/address mappings) that open/shut permissions for a >> user, the user could be subject to attacks by alterations or tampering >> of this stream. One might be to allow ports to be open that would >> make the system vulnerable to attack. The other would be to close >> ports off that are needed, resulting in a denial of service. >>=20 >> I would think there are considerations to list with each of the new >> attributes along these lines. This would be specific text to the >> added attributes and communication of these attributes on the wire. >=20 > [Med] The root cause of these attack vectors is the communication between t= he RADIUS client/server. Saying that, what about making this change to illus= trate some attacks as you suggested? >=20 > OLD: > This document does not introduce any security issue other than the > ones already identified in RADIUS [RFC2865]. >=20 > NEW: >=20 > This document does not introduce any security issue other than the > ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA > messages. Known RADIUS vulnerabilities apply to this specification. > For example, if RADIUS packets are sent in the clear, an attacker in > the communication path between the RADIUS client and server may glean > information that it will use to prevent a legitimate user to access > the service by appropriately setting the maximum number of IP ports > conveyed in an IP-Port-Limit-Info attribute, exhaust the port quota > of a user by installing many mapping entries (IP-Port-Forwarding-Map > attribute), prevent incoming traffic to be delivered to its > legitimate destination by manipulating the mapping entries installed > by means of an IP-Port-Forwarding-Map attribute, discover the IP > address and port range assigned to a given user and which is reported > in an IP-Port-Range attribute, etc. The root cause of these attack > vectors is the communication between the RADIUS client and server. >=20 > This document targets deployed where a trusted relationship is in > place between the RADIUS client and server with communication > optionally secured by IPsec or Transport Layer Security (TLS) > [RFC6614]. >=20 > Better? Much, thanks! This hits the point on what can be fine with these attributes= over existing/known weak points in the protocol and I appreciate the recomm= endation to run it with an encrypted session. Once the shepherd report is ready, I'll put it in IETF last call. Thanks, Kathleen=20 >=20 >>=20 >> Let me know if I am missing something as to why this is already >> covered in radius security considerations. I think the specific >> attribute addd should have their concerns listed. >>=20 >> Thanks! >=20 > [Med] Thank you for the review. >=20 >> -- >>=20 >> Best regards, >> Kathleen >>=20 >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext From nobody Thu Jul 28 07:26:33 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2C312D0AD; Thu, 28 Jul 2016 07:26:33 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160728142633.12865.60605.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2016 07:26:33 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 14:26:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-10.txt Pages : 37 Date : 2016-07-28 Abstract: This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 28 07:28:23 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC3B12D520 for ; Thu, 28 Jul 2016 07:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59FaSvXDBF8J for ; Thu, 28 Jul 2016 07:28:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9BC12B030 for ; Thu, 28 Jul 2016 07:28:19 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 970B92DC251; Thu, 28 Jul 2016 16:28:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.61]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 74C5E35C097; Thu, 28 Jul 2016 16:28:17 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0301.000; Thu, 28 Jul 2016 16:28:17 +0200 From: To: "kathleen.moriarty.ietf@gmail.com" Thread-Topic: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext Thread-Index: AdHophdFKwCkjVQ8ShCWcps8MBMC/wAIqWWAAATXtPA= Date: Thu, 28 Jul 2016 14:28:17 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DEEB07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008DEE831@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6CFAC713-3903-4947-A3F8-691A7008B567@gmail.com> In-Reply-To: <6CFAC713-3903-4947-A3F8-691A7008B567@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.28.134516 Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 14:28:21 -0000 UmUtLA0KDQpUaGFuayB5b3UsIEthdGhsZWVuLiANCg0KRllJLCBhbiB1cGRhdGVkIHZlcnNpb24g d2l0aCB0aGVzZSBjaGFuZ2VzIGlzIGF2YWlsYWJsZSBvbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQg DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGthdGhsZWVuLm1vcmlh cnR5LmlldGZAZ21haWwuY29tDQo+IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFp bC5jb21dDQo+IEVudm95w6nCoDogamV1ZGkgMjgganVpbGxldCAyMDE2IDE2OjA4DQo+IMOAwqA6 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gQ2PCoDogcmFkZXh0QGlldGYub3JnDQo+IE9i amV0wqA6IFJlOiBbcmFkZXh0XSBBRCBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9y dC1yYWRpdXMtZXh0DQo+IA0KPiBIZWxsbyBNb2hhbWVkLA0KPiANCj4gVGhhbmsgeW91IGZvciB0 aGUgcXVpY2sgcmVzcG9uc2UuIElubGluZQ0KPiANCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiAN Cj4gPiBPbiBKdWwgMjgsIDIwMTYsIGF0IDQ6MDAgQU0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPg0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4NCj4g PiBEZWFyIEthdGhsZWVuLA0KPiA+DQo+ID4gVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3Lg0KPiA+ DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4N Cj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERlIDogcmFkZXh0IFttYWls dG86cmFkZXh0LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgS2F0aGxlZW4NCj4gPj4g TW9yaWFydHkNCj4gPj4gRW52b3nDqSA6IGpldWRpIDI4IGp1aWxsZXQgMjAxNiAwMjo1OA0KPiA+ PiDDgCA6IHJhZGV4dEBpZXRmLm9yZw0KPiA+PiBPYmpldCA6IFtyYWRleHRdIEFEIFJldmlldyBv ZiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQNCj4gPj4NCj4gPj4gSGVsbG8s DQo+ID4+DQo+ID4+IFRoYW5rIHlvdSBmb3IgeW91ciB3b3JrIG9uIGRyYWZ0LWlldGYtcmFkZXh0 LWlwLXBvcnQtcmFkaXVzLWV4dC4gIFRoaXMNCj4gPj4gaXMgYW4gZWFzeSB0byB1bmRlcnN0YW5k IGRvY3VtZW50LiAgSSBmb3VuZCBhIGZldyBuaXRzIGFuZCB0aGluayBtb3JlDQo+ID4+IHRleHQg aXMgbmVlZGVkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLiAgTXkgcmV2 aWV3IGlzDQo+ID4+IGJlbG93Lg0KPiA+Pg0KPiA+Pg0KPiA+PiBBYnN0cmFjdA0KPiA+PiBzZWNv bmQgc2VudGVuY2Ugbml0OiBzL2ltcGxlbWVudGluZy9pbXBsZW1lbnQvDQo+ID4gW01lZF0gRml4 ZWQuDQo+ID4NCj4gPj4gRnJvbTogRm9yIGRldmljZXMgdGhhdA0KPiA+PiAgIGltcGxlbWVudGlu ZyBJUCBwb3J0IHJhbmdlcywgdGhlc2UgYXR0cmlidXRlcyBhcmUgdXNlZCB0byBjb21tdW5pY2F0 ZQ0KPiA+PiAgIHdpdGggYSBSQURJVVMgc2VydmVyIGluIG9yZGVyIHRvIGNvbmZpZ3VyZSBhbmQg cmVwb3J0IFRDUC9VRFAgcG9ydHMNCj4gPj4gICBhbmQgSUNNUCBpZGVudGlmaWVycywgYXMgd2Vs bCBhcyBtYXBwaW5nIGJlaGF2aW9yIGZvciBzcGVjaWZpYyBob3N0cy4NCj4gPj4gVG86IEZvciBk ZXZpY2VzIHRoYXQNCj4gPj4gICBpbXBsZW1lbnQgSVAgcG9ydCByYW5nZXMsIHRoZXNlIGF0dHJp YnV0ZXMgYXJlIHVzZWQgdG8gY29tbXVuaWNhdGUNCj4gPj4gICB3aXRoIGEgUkFESVVTIHNlcnZl ciBpbiBvcmRlciB0byBjb25maWd1cmUgYW5kIHJlcG9ydCBUQ1AvVURQIHBvcnRzDQo+ID4+ICAg YW5kIElDTVAgaWRlbnRpZmllcnMsIGFzIHdlbGwgYXMgbWFwcGluZyBiZWhhdmlvciBmb3Igc3Bl Y2lmaWMgaG9zdHMuDQo+ID4+DQo+ID4+IDIuIFRlcm1pbm9sb2d5DQo+ID4+DQo+ID4+IEkgdGhp bmsgc29tZSByZXdvcmRpbmcgaXMgbmVlZGVkLCAnaW4gcmVzcGVjdGl2ZScgZG9lc24ndCBxdWl0 ZSBmaXQgaW4NCj4gPj4gdGhlIGZvbGxvd2luZyBkZWZpbml0aW9uOg0KPiA+Pg0KPiA+PiAgICBF eHRlcm5hbCByZWFsbTogcmVmZXJzIHRvIHRoZSBuZXR3b3JraW5nIHNlZ21lbnQgd2hlcmUgZXh0 ZXJuYWwgSVANCj4gPj4gICAgICBhZGRyZXNzZXMgYXJlIHVzZWQgaW4gcmVzcGVjdGl2ZSBvZiB0 aGUgZGV2aWNlIHN1cHBvcnRpbmcgcG9ydA0KPiA+PiAgICAgIHJhbmdlcy4NCj4gPiBbTWVkXSBD aGFuZ2VkIHRvOg0KPiA+DQo+ID4gRXh0ZXJuYWwgcmVhbG06IHJlZmVycyB0byB0aGUgbmV0d29y a2luZyBzZWdtZW50IHdoZXJlIGV4dGVybmFsIElQDQo+IGFkZHJlc3NlcyBhcmUgdXNlZCBhcyBz b3VyY2UgYWRkcmVzc2VzIG9mIG91dGJvdW5kIHBhY2tldHMgZm9yd2FyZGVkIGJ5IGENCj4gZGV2 aWNlIHN1cHBvcnRpbmcgcG9ydCByYW5nZXMuDQo+ID4NCj4gPiBCZXR0ZXI/DQo+IA0KPiBZZXMs IHRoYW5rIHlvdSENCj4gPg0KPiA+PiBJbiB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24sIGV4cGFu ZCBvdXQgQ0dOLg0KPiA+DQo+ID4gW01lZF0gQ0dOIGlzIGFscmVhZHkgZXhwYW5kZWQgaW4gdGhl IGludHJvZHVjdGlvbi4NCj4gPg0KPiA+IEkgYW0gcHJldHR5IHN1cmUgdGhlDQo+ID4+IG90aGVy cyBhcmUgYWNyb255bXMgdGhhdCBhcmUgaW4gdGhlIGRvIG5vdCBoYXZlIHRvIGV4cGFuZCBsaXN0 LiAgVGhpcw0KPiA+PiBvbmUgaXNuJ3Qgb25lIHRoYXQgSSBhbSBmYW1pbGlhciB3aXRoOg0KPiA+ PiAgbyAgUG9ydC1iYXNlZCBkZXZpY2U6IGEgZGV2aWNlIHRoYXQgaXMgY2FwYWJsZSBvZiBwcm92 aWRpbmcgSVANCj4gPj4gICAgICBhZGRyZXNzIGFuZCBJUCBwb3J0IG1hcHBpbmcgc2VydmljZXMg YW5kIGluIHBhcnRpY3VsYXIsIHdpdGggdGhlDQo+ID4+ICAgICAgZ3JhbnVsYXJpdHkgb2Ygb25l IG9yIG1vcmUgc3Vic2V0cyB3aXRoaW4gdGhlIDE2LWJpdCBJUCBwb3J0DQo+ID4+ICAgICAgbnVt YmVyIHJhbmdlLiAgQSB0eXBpY2FsIGV4YW1wbGUgb2YgdGhpcyBkZXZpY2UgaXMgYSBDR04sIENQ RSwNCj4gPj4gICAgICBQcm92aWRlciBXTEFOIEdhdGV3YXksIGV0Yy4NCj4gPj4NCj4gPj4gU2Vj dGlvbiA0LjEuMjogcy9vbmNlL29uZS8NCj4gPiBbTWVkXSBGaXhlZC4NCj4gPg0KPiA+PiAgIEFz IG9uZSBwcmFjdGljZSwgYSBDR04gbWF5IGFsbG9jYXRlIGEgYnVsayBvZiBUQ1AvVURQIHBvcnRz IG9yIElDTVANCj4gPj4gICBpZGVudGlmaWVycyBvbmNlIGF0IGEgdGltZSBmb3IgYSBzcGVjaWZp YyB1c2VyLA0KPiA+Pg0KPiA+PiBTZWN1cml0eSBjb25zaWRlcmF0aW9uczoNCj4gPj4NCj4gPj4g U2hvdWxkbid0IHRoZXJlIGJlIHNvbWUgY29uc2lkZXJhdGlvbnMgYWJvdXQgdGhlIGNvbW11bmlj YXRpb25zIGZvcg0KPiA+PiB0aGVzZSBhdHRyaWJ1dGVzIGJldHdlZW4gdGhlIHJhZGl1cyBzZXJ2 ZXIgYW5kIE5BdDQ0IG9yIG90aGVyIGRldmljZXM/DQo+ID4NCj4gPiBbTWVkXSBJIGRvbid0IHRo aW5rIHRoaXMgaXMgc3BlY2lmaWMgdG8gdGhlc2UgYXR0cmlidXRlcyBidXQgdGhpcyBpcw0KPiBh cHBsaWNhYmxlIHRvIGFsbCBSQURJVVMgYXBwbGljYXRpb25zLg0KPiA+DQo+ID4+IFNpbmNlIHRo ZXNlIGF0dHJpYnV0ZXMgY2FuIGJlIHVzZWQgdG8gY29tbXVuaWNhdGUgYSBjaGFuZ2UgaW4NCj4g Pj4gcGVybWlzc2lvbnMgKHBvcnQvYWRkcmVzcyBtYXBwaW5ncykgdGhhdCBvcGVuL3NodXQgcGVy bWlzc2lvbnMgZm9yIGENCj4gPj4gdXNlciwgdGhlIHVzZXIgY291bGQgYmUgc3ViamVjdCB0byBh dHRhY2tzIGJ5IGFsdGVyYXRpb25zIG9yIHRhbXBlcmluZw0KPiA+PiBvZiB0aGlzIHN0cmVhbS4g IE9uZSBtaWdodCBiZSB0byBhbGxvdyBwb3J0cyB0byBiZSBvcGVuIHRoYXQgd291bGQNCj4gPj4g bWFrZSB0aGUgc3lzdGVtIHZ1bG5lcmFibGUgdG8gYXR0YWNrLiAgVGhlIG90aGVyIHdvdWxkIGJl IHRvIGNsb3NlDQo+ID4+IHBvcnRzIG9mZiB0aGF0IGFyZSBuZWVkZWQsIHJlc3VsdGluZyBpbiBh IGRlbmlhbCBvZiBzZXJ2aWNlLg0KPiA+Pg0KPiA+PiBJIHdvdWxkIHRoaW5rIHRoZXJlIGFyZSBj b25zaWRlcmF0aW9ucyB0byBsaXN0IHdpdGggZWFjaCBvZiB0aGUgbmV3DQo+ID4+IGF0dHJpYnV0 ZXMgYWxvbmcgdGhlc2UgbGluZXMuICBUaGlzIHdvdWxkIGJlIHNwZWNpZmljIHRleHQgdG8gdGhl DQo+ID4+IGFkZGVkIGF0dHJpYnV0ZXMgYW5kIGNvbW11bmljYXRpb24gb2YgdGhlc2UgYXR0cmli dXRlcyBvbiB0aGUgd2lyZS4NCj4gPg0KPiA+IFtNZWRdIFRoZSByb290IGNhdXNlIG9mIHRoZXNl IGF0dGFjayB2ZWN0b3JzIGlzIHRoZSBjb21tdW5pY2F0aW9uDQo+IGJldHdlZW4gdGhlIFJBRElV UyBjbGllbnQvc2VydmVyLiBTYXlpbmcgdGhhdCwgd2hhdCBhYm91dCBtYWtpbmcgdGhpcw0KPiBj aGFuZ2UgdG8gaWxsdXN0cmF0ZSBzb21lIGF0dGFja3MgYXMgeW91IHN1Z2dlc3RlZD8NCj4gPg0K PiA+IE9MRDoNCj4gPiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW50cm9kdWNlIGFueSBzZWN1 cml0eSBpc3N1ZSBvdGhlciB0aGFuIHRoZQ0KPiA+ICAgb25lcyBhbHJlYWR5IGlkZW50aWZpZWQg aW4gUkFESVVTIFtSRkMyODY1XS4NCj4gPg0KPiA+IE5FVzoNCj4gPg0KPiA+ICAgVGhpcyBkb2N1 bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IHNlY3VyaXR5IGlzc3VlIG90aGVyIHRoYW4gdGhl DQo+ID4gICBvbmVzIGFscmVhZHkgaWRlbnRpZmllZCBpbiBSQURJVVMgW1JGQzI4NjVdIGFuZCBb UkZDNTE3Nl0gZm9yIENvQQ0KPiA+ICAgbWVzc2FnZXMuICBLbm93biBSQURJVVMgdnVsbmVyYWJp bGl0aWVzIGFwcGx5IHRvIHRoaXMgc3BlY2lmaWNhdGlvbi4NCj4gPiAgIEZvciBleGFtcGxlLCBp ZiBSQURJVVMgcGFja2V0cyBhcmUgc2VudCBpbiB0aGUgY2xlYXIsIGFuIGF0dGFja2VyIGluDQo+ ID4gICB0aGUgY29tbXVuaWNhdGlvbiBwYXRoIGJldHdlZW4gdGhlIFJBRElVUyBjbGllbnQgYW5k IHNlcnZlciBtYXkgZ2xlYW4NCj4gPiAgIGluZm9ybWF0aW9uIHRoYXQgaXQgd2lsbCB1c2UgdG8g cHJldmVudCBhIGxlZ2l0aW1hdGUgdXNlciB0byBhY2Nlc3MNCj4gPiAgIHRoZSBzZXJ2aWNlIGJ5 IGFwcHJvcHJpYXRlbHkgc2V0dGluZyB0aGUgbWF4aW11bSBudW1iZXIgb2YgSVAgcG9ydHMNCj4g PiAgIGNvbnZleWVkIGluIGFuIElQLVBvcnQtTGltaXQtSW5mbyBhdHRyaWJ1dGUsIGV4aGF1c3Qg dGhlIHBvcnQgcXVvdGENCj4gPiAgIG9mIGEgdXNlciBieSBpbnN0YWxsaW5nIG1hbnkgbWFwcGlu ZyBlbnRyaWVzIChJUC1Qb3J0LUZvcndhcmRpbmctTWFwDQo+ID4gICBhdHRyaWJ1dGUpLCBwcmV2 ZW50IGluY29taW5nIHRyYWZmaWMgdG8gYmUgZGVsaXZlcmVkIHRvIGl0cw0KPiA+ICAgbGVnaXRp bWF0ZSBkZXN0aW5hdGlvbiBieSBtYW5pcHVsYXRpbmcgdGhlIG1hcHBpbmcgZW50cmllcyBpbnN0 YWxsZWQNCj4gPiAgIGJ5IG1lYW5zIG9mIGFuIElQLVBvcnQtRm9yd2FyZGluZy1NYXAgYXR0cmli dXRlLCBkaXNjb3ZlciB0aGUgSVANCj4gPiAgIGFkZHJlc3MgYW5kIHBvcnQgcmFuZ2UgYXNzaWdu ZWQgdG8gYSBnaXZlbiB1c2VyIGFuZCB3aGljaCBpcyByZXBvcnRlZA0KPiA+ICAgaW4gYW4gSVAt UG9ydC1SYW5nZSBhdHRyaWJ1dGUsIGV0Yy4gIFRoZSByb290IGNhdXNlIG9mIHRoZXNlIGF0dGFj aw0KPiA+ICAgdmVjdG9ycyBpcyB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBSQURJVVMg Y2xpZW50IGFuZCBzZXJ2ZXIuDQo+ID4NCj4gPiAgIFRoaXMgZG9jdW1lbnQgdGFyZ2V0cyBkZXBs b3llZCB3aGVyZSBhIHRydXN0ZWQgcmVsYXRpb25zaGlwIGlzIGluDQo+ID4gICBwbGFjZSBiZXR3 ZWVuIHRoZSBSQURJVVMgY2xpZW50IGFuZCBzZXJ2ZXIgd2l0aCBjb21tdW5pY2F0aW9uDQo+ID4g ICBvcHRpb25hbGx5IHNlY3VyZWQgYnkgSVBzZWMgb3IgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5 IChUTFMpDQo+ID4gICBbUkZDNjYxNF0uDQo+ID4NCj4gPiBCZXR0ZXI/DQo+IA0KPiBNdWNoLCB0 aGFua3MhICBUaGlzIGhpdHMgdGhlIHBvaW50IG9uIHdoYXQgY2FuIGJlIGZpbmUgd2l0aCB0aGVz ZQ0KPiBhdHRyaWJ1dGVzIG92ZXIgZXhpc3Rpbmcva25vd24gd2VhayBwb2ludHMgaW4gdGhlIHBy b3RvY29sIGFuZCBJDQo+IGFwcHJlY2lhdGUgdGhlIHJlY29tbWVuZGF0aW9uIHRvIHJ1biBpdCB3 aXRoIGFuIGVuY3J5cHRlZCBzZXNzaW9uLg0KPiANCj4gT25jZSB0aGUgc2hlcGhlcmQgcmVwb3J0 IGlzIHJlYWR5LCBJJ2xsIHB1dCBpdCBpbiBJRVRGIGxhc3QgY2FsbC4NCj4gDQo+IFRoYW5rcywN Cj4gS2F0aGxlZW4NCj4gPg0KPiA+Pg0KPiA+PiBMZXQgbWUga25vdyBpZiBJIGFtIG1pc3Npbmcg c29tZXRoaW5nIGFzIHRvIHdoeSB0aGlzIGlzIGFscmVhZHkNCj4gPj4gY292ZXJlZCBpbiByYWRp dXMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuICBJIHRoaW5rIHRoZSBzcGVjaWZpYw0KPiA+PiBh dHRyaWJ1dGUgYWRkZCBzaG91bGQgaGF2ZSB0aGVpciBjb25jZXJucyBsaXN0ZWQuDQo+ID4+DQo+ ID4+IFRoYW5rcyENCj4gPg0KPiA+IFtNZWRdIFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4NCj4g Pg0KPiA+PiAtLQ0KPiA+Pg0KPiA+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+IEthdGhsZWVuDQo+ID4+ DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+IHJhZGV4dCBtYWlsaW5nIGxpc3QNCj4gPj4gcmFkZXh0QGlldGYub3JnDQo+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQo= From nobody Thu Jul 28 09:29:12 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823B212D129 for ; Thu, 28 Jul 2016 09:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NAtaB88vjqo4 for ; Thu, 28 Jul 2016 09:29:09 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 0D2CE12B025 for ; Thu, 28 Jul 2016 09:29:09 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 35so43545051uap.1 for ; Thu, 28 Jul 2016 09:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kYyjLEDefsXE4ADZWXXDypYxomc26YFXJgboz34Etvo=; b=0EiVPc9p3RkpYgggwI4DetK2KXWp+ysIFCvy2GjcCAbHXsj5X4+DHWin0LW0b2PmFa yyvUhyZzWiOTiio1FTcsv3T02yUSTZb68JJbIB+k/NZq8FyUA6jloFzwzhi8IJNu9YnU Ljh/k/CV3/MYaBpvqg3MLrKsLlJcPnO+vkJLjLkOtXRbTgYvmTrRLqOFKNZ0B3UAVfLY dQ4Gd9XaRZ00s6FfxpOkHogHCt3PPBWBD8otwSPFDnCx3Ci1DHWgjfu0Bq030bpQFR5g scAUPrQsof8ovF+IfhKGq/8U4UjAytYMuqxWVjnyszuZwlcgv4qgkWF8M9Hbj1hwlslV Uxgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kYyjLEDefsXE4ADZWXXDypYxomc26YFXJgboz34Etvo=; b=LgmQv/rAl/fsh9zeVLAWaHxeGimreQL4fMKZGkBEx9bHanHgRf8+iJWGJwEI7qFZCF fF+77jatgPOa+bTFrgmpdbYfLcxOxJQhLOFRLFMsyxbNn8S7Es+iLojGdfS5Q4g2pMFG 1jjqL7uBwPW808xy437eHawURNNkgNOZqpOvlFU42ZAFpxNjZApYc9GJSMxEHOYmuplY NhsuUq/QwZ8gXOl7bPY1/b/CG8zpwfZBrYqMbYIp4Uzd8Tc7FeAB7fYqBt65RgTj55LA Spvq/qz4a6R466hPjShfda8+aWVNZU9ymN/RM2pckO4l2U4qqxbxliwNCNdGKffNyt3K 8e9Q== X-Gm-Message-State: AEkoouv5uKOvVXmqi8XIhluoTc8E2aBAbLR498whqmtkWURHsFSOjXTk5RA3JhntPqS6++N6n5IxOBDQ+B8ndg== X-Received: by 10.159.39.193 with SMTP id b59mr16005567uab.109.1469723347955; Thu, 28 Jul 2016 09:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Thu, 28 Jul 2016 09:29:07 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DEEB07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008DEE831@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6CFAC713-3903-4947-A3F8-691A7008B567@gmail.com> <787AE7BB302AE849A7480A190F8B933008DEEB07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Kathleen Moriarty Date: Thu, 28 Jul 2016 12:29:07 -0400 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 16:29:11 -0000 On Thu, Jul 28, 2016 at 10:28 AM, wrote: > Re-, > > Thank you, Kathleen. > > FYI, an updated version with these changes is available online. > Excellent, thank you! I see the shepherd report id posted, so I'll review that and progress the draft to IETF review. This and the other Radext draft will likely be on the telechat in 3 weeks. Next weeks telechat is packed already, so I was avoiding it (Better reviews and less cranky ADs :-) . Thanks, Kathleen > Cheers, > Med > >> -----Message d'origine----- >> De : kathleen.moriarty.ietf@gmail.com >> [mailto:kathleen.moriarty.ietf@gmail.com] >> Envoy=C3=A9 : jeudi 28 juillet 2016 16:08 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN >> Cc : radext@ietf.org >> Objet : Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext >> >> Hello Mohamed, >> >> Thank you for the quick response. Inline >> >> Sent from my iPhone >> >> > On Jul 28, 2016, at 4:00 AM, >> wrote: >> > >> > Dear Kathleen, >> > >> > Thank you for the review. >> > >> > Please see inline. >> > >> > Cheers, >> > Med >> > >> >> -----Message d'origine----- >> >> De : radext [mailto:radext-bounces@ietf.org] De la part de Kathleen >> >> Moriarty >> >> Envoy=C3=A9 : jeudi 28 juillet 2016 02:58 >> >> =C3=80 : radext@ietf.org >> >> Objet : [radext] AD Review of draft-ietf-radext-ip-port-radius-ext >> >> >> >> Hello, >> >> >> >> Thank you for your work on draft-ietf-radext-ip-port-radius-ext. Thi= s >> >> is an easy to understand document. I found a few nits and think more >> >> text is needed in the security considerations section. My review is >> >> below. >> >> >> >> >> >> Abstract >> >> second sentence nit: s/implementing/implement/ >> > [Med] Fixed. >> > >> >> From: For devices that >> >> implementing IP port ranges, these attributes are used to communica= te >> >> with a RADIUS server in order to configure and report TCP/UDP ports >> >> and ICMP identifiers, as well as mapping behavior for specific host= s. >> >> To: For devices that >> >> implement IP port ranges, these attributes are used to communicate >> >> with a RADIUS server in order to configure and report TCP/UDP ports >> >> and ICMP identifiers, as well as mapping behavior for specific host= s. >> >> >> >> 2. Terminology >> >> >> >> I think some rewording is needed, 'in respective' doesn't quite fit i= n >> >> the following definition: >> >> >> >> External realm: refers to the networking segment where external IP >> >> addresses are used in respective of the device supporting port >> >> ranges. >> > [Med] Changed to: >> > >> > External realm: refers to the networking segment where external IP >> addresses are used as source addresses of outbound packets forwarded by = a >> device supporting port ranges. >> > >> > Better? >> >> Yes, thank you! >> > >> >> In the following definition, expand out CGN. >> > >> > [Med] CGN is already expanded in the introduction. >> > >> > I am pretty sure the >> >> others are acronyms that are in the do not have to expand list. This >> >> one isn't one that I am familiar with: >> >> o Port-based device: a device that is capable of providing IP >> >> address and IP port mapping services and in particular, with the >> >> granularity of one or more subsets within the 16-bit IP port >> >> number range. A typical example of this device is a CGN, CPE, >> >> Provider WLAN Gateway, etc. >> >> >> >> Section 4.1.2: s/once/one/ >> > [Med] Fixed. >> > >> >> As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP >> >> identifiers once at a time for a specific user, >> >> >> >> Security considerations: >> >> >> >> Shouldn't there be some considerations about the communications for >> >> these attributes between the radius server and NAt44 or other devices= ? >> > >> > [Med] I don't think this is specific to these attributes but this is >> applicable to all RADIUS applications. >> > >> >> Since these attributes can be used to communicate a change in >> >> permissions (port/address mappings) that open/shut permissions for a >> >> user, the user could be subject to attacks by alterations or tamperin= g >> >> of this stream. One might be to allow ports to be open that would >> >> make the system vulnerable to attack. The other would be to close >> >> ports off that are needed, resulting in a denial of service. >> >> >> >> I would think there are considerations to list with each of the new >> >> attributes along these lines. This would be specific text to the >> >> added attributes and communication of these attributes on the wire. >> > >> > [Med] The root cause of these attack vectors is the communication >> between the RADIUS client/server. Saying that, what about making this >> change to illustrate some attacks as you suggested? >> > >> > OLD: >> > This document does not introduce any security issue other than the >> > ones already identified in RADIUS [RFC2865]. >> > >> > NEW: >> > >> > This document does not introduce any security issue other than the >> > ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA >> > messages. Known RADIUS vulnerabilities apply to this specification. >> > For example, if RADIUS packets are sent in the clear, an attacker in >> > the communication path between the RADIUS client and server may glea= n >> > information that it will use to prevent a legitimate user to access >> > the service by appropriately setting the maximum number of IP ports >> > conveyed in an IP-Port-Limit-Info attribute, exhaust the port quota >> > of a user by installing many mapping entries (IP-Port-Forwarding-Map >> > attribute), prevent incoming traffic to be delivered to its >> > legitimate destination by manipulating the mapping entries installed >> > by means of an IP-Port-Forwarding-Map attribute, discover the IP >> > address and port range assigned to a given user and which is reporte= d >> > in an IP-Port-Range attribute, etc. The root cause of these attack >> > vectors is the communication between the RADIUS client and server. >> > >> > This document targets deployed where a trusted relationship is in >> > place between the RADIUS client and server with communication >> > optionally secured by IPsec or Transport Layer Security (TLS) >> > [RFC6614]. >> > >> > Better? >> >> Much, thanks! This hits the point on what can be fine with these >> attributes over existing/known weak points in the protocol and I >> appreciate the recommendation to run it with an encrypted session. >> >> Once the shepherd report is ready, I'll put it in IETF last call. >> >> Thanks, >> Kathleen >> > >> >> >> >> Let me know if I am missing something as to why this is already >> >> covered in radius security considerations. I think the specific >> >> attribute addd should have their concerns listed. >> >> >> >> Thanks! >> > >> > [Med] Thank you for the review. >> > >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> >> >> >> _______________________________________________ >> >> radext mailing list >> >> radext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/radext --=20 Best regards, Kathleen From nobody Thu Jul 28 11:34:11 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA3512D7E1 for ; Thu, 28 Jul 2016 11:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kkall1aEQ_mJ for ; Thu, 28 Jul 2016 11:34:07 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 553B512D748 for ; Thu, 28 Jul 2016 11:34:07 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 35so45961054uap.1 for ; Thu, 28 Jul 2016 11:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DSbhNVmPvqhJvY/p4zyehBpm1xSyMD7v8e2L35PtmSA=; b=HIoQ0303fbXB657X9avIPNxu7l1dMdXHRo3TiC1buOMV3p1p8WuFFYM4x+svRCxJP1 j82Qs63NAA34DPb+03eHEzZ98kTiQLDNNl7cwlIeu3mOrLoFVBwaBbxg/7jE9O7t916Y EaKEaoEJGRKo+jhxAkuAyIO+MDGiOiXbLk3uuy2KT3D91gSstGFc8W69BE3u6n/uuomU lwQeOhsgRiJunr/+YYlT/JtY0P67wxo0t7Xii7+I/dMH5gJE5kYEqRbTgRKTFFECP0QK yXTpFB2JAKWMuw6pklOFw33QjE5QIPHKFiNzc/K7hLKDBIrR6QJhujhJV9KKgw/2mDBD i1Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DSbhNVmPvqhJvY/p4zyehBpm1xSyMD7v8e2L35PtmSA=; b=ityZNaAXv4gbX7JWjj8z3Apn9ElVl9edGBztTlzrfwcktbYoCJSwUk1tOMpPYYJjad hrCxxK4Q6QM5+mWogRkjo+qtTKhrqSbkXQ+EDensNQKM4+a04hqpavlr0kvPcWT14EVN 6faal1sVDbgb4J80DmoQ6ei2SCmlmo5VLzvGzZq0XTjFK4aydupog1YLBI7tmOUEFN7X ZMTShDSDLV1CBTWsSWRzngLLE7N4LnVkMdCfl5cKe1Zcb+2bDl4+JkBEUormTyKevu9q CJEtcqi1udwy4B+8zd3VcSLdwiseRdJiCSt8cwYeFp/vF2z84xv97NNSrLX/soOtnYWE iq+Q== X-Gm-Message-State: AEkooutrI7y3Q2Bn4q0GTDFpua/n07YmjMsKXlsobIHmydatzTH2r5MybthgRAuXaoccvfoBuJei6O57mTe86w== X-Received: by 10.176.3.174 with SMTP id 43mr17022104uau.88.1469730846307; Thu, 28 Jul 2016 11:34:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Thu, 28 Jul 2016 11:34:05 -0700 (PDT) In-Reply-To: References: <787AE7BB302AE849A7480A190F8B933008DEE831@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6CFAC713-3903-4947-A3F8-691A7008B567@gmail.com> <787AE7BB302AE849A7480A190F8B933008DEEB07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Kathleen Moriarty Date: Thu, 28 Jul 2016 14:34:05 -0400 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 18:34:09 -0000 Hello Mohamed, I just read through the shepherd report and see that Stefan caught that the abstract doesn't list the RFC that this updates. Can you make that fix and once that is done, I'll start IETF last call so this comment doesn't come up again. Thanks, Kathleen On Thu, Jul 28, 2016 at 12:29 PM, Kathleen Moriarty wrote: > On Thu, Jul 28, 2016 at 10:28 AM, wrote: >> Re-, >> >> Thank you, Kathleen. >> >> FYI, an updated version with these changes is available online. >> > > Excellent, thank you! I see the shepherd report id posted, so I'll > review that and progress the draft to IETF review. This and the other > Radext draft will likely be on the telechat in 3 weeks. Next weeks > telechat is packed already, so I was avoiding it (Better reviews and > less cranky ADs :-) . > > Thanks, > Kathleen > >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : kathleen.moriarty.ietf@gmail.com >>> [mailto:kathleen.moriarty.ietf@gmail.com] >>> Envoy=C3=A9 : jeudi 28 juillet 2016 16:08 >>> =C3=80 : BOUCADAIR Mohamed IMT/OLN >>> Cc : radext@ietf.org >>> Objet : Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext >>> >>> Hello Mohamed, >>> >>> Thank you for the quick response. Inline >>> >>> Sent from my iPhone >>> >>> > On Jul 28, 2016, at 4:00 AM, >>> wrote: >>> > >>> > Dear Kathleen, >>> > >>> > Thank you for the review. >>> > >>> > Please see inline. >>> > >>> > Cheers, >>> > Med >>> > >>> >> -----Message d'origine----- >>> >> De : radext [mailto:radext-bounces@ietf.org] De la part de Kathleen >>> >> Moriarty >>> >> Envoy=C3=A9 : jeudi 28 juillet 2016 02:58 >>> >> =C3=80 : radext@ietf.org >>> >> Objet : [radext] AD Review of draft-ietf-radext-ip-port-radius-ext >>> >> >>> >> Hello, >>> >> >>> >> Thank you for your work on draft-ietf-radext-ip-port-radius-ext. Th= is >>> >> is an easy to understand document. I found a few nits and think mor= e >>> >> text is needed in the security considerations section. My review is >>> >> below. >>> >> >>> >> >>> >> Abstract >>> >> second sentence nit: s/implementing/implement/ >>> > [Med] Fixed. >>> > >>> >> From: For devices that >>> >> implementing IP port ranges, these attributes are used to communic= ate >>> >> with a RADIUS server in order to configure and report TCP/UDP port= s >>> >> and ICMP identifiers, as well as mapping behavior for specific hos= ts. >>> >> To: For devices that >>> >> implement IP port ranges, these attributes are used to communicate >>> >> with a RADIUS server in order to configure and report TCP/UDP port= s >>> >> and ICMP identifiers, as well as mapping behavior for specific hos= ts. >>> >> >>> >> 2. Terminology >>> >> >>> >> I think some rewording is needed, 'in respective' doesn't quite fit = in >>> >> the following definition: >>> >> >>> >> External realm: refers to the networking segment where external I= P >>> >> addresses are used in respective of the device supporting port >>> >> ranges. >>> > [Med] Changed to: >>> > >>> > External realm: refers to the networking segment where external IP >>> addresses are used as source addresses of outbound packets forwarded by= a >>> device supporting port ranges. >>> > >>> > Better? >>> >>> Yes, thank you! >>> > >>> >> In the following definition, expand out CGN. >>> > >>> > [Med] CGN is already expanded in the introduction. >>> > >>> > I am pretty sure the >>> >> others are acronyms that are in the do not have to expand list. Thi= s >>> >> one isn't one that I am familiar with: >>> >> o Port-based device: a device that is capable of providing IP >>> >> address and IP port mapping services and in particular, with th= e >>> >> granularity of one or more subsets within the 16-bit IP port >>> >> number range. A typical example of this device is a CGN, CPE, >>> >> Provider WLAN Gateway, etc. >>> >> >>> >> Section 4.1.2: s/once/one/ >>> > [Med] Fixed. >>> > >>> >> As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICM= P >>> >> identifiers once at a time for a specific user, >>> >> >>> >> Security considerations: >>> >> >>> >> Shouldn't there be some considerations about the communications for >>> >> these attributes between the radius server and NAt44 or other device= s? >>> > >>> > [Med] I don't think this is specific to these attributes but this is >>> applicable to all RADIUS applications. >>> > >>> >> Since these attributes can be used to communicate a change in >>> >> permissions (port/address mappings) that open/shut permissions for a >>> >> user, the user could be subject to attacks by alterations or tamperi= ng >>> >> of this stream. One might be to allow ports to be open that would >>> >> make the system vulnerable to attack. The other would be to close >>> >> ports off that are needed, resulting in a denial of service. >>> >> >>> >> I would think there are considerations to list with each of the new >>> >> attributes along these lines. This would be specific text to the >>> >> added attributes and communication of these attributes on the wire. >>> > >>> > [Med] The root cause of these attack vectors is the communication >>> between the RADIUS client/server. Saying that, what about making this >>> change to illustrate some attacks as you suggested? >>> > >>> > OLD: >>> > This document does not introduce any security issue other than the >>> > ones already identified in RADIUS [RFC2865]. >>> > >>> > NEW: >>> > >>> > This document does not introduce any security issue other than the >>> > ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA >>> > messages. Known RADIUS vulnerabilities apply to this specification= . >>> > For example, if RADIUS packets are sent in the clear, an attacker i= n >>> > the communication path between the RADIUS client and server may gle= an >>> > information that it will use to prevent a legitimate user to access >>> > the service by appropriately setting the maximum number of IP ports >>> > conveyed in an IP-Port-Limit-Info attribute, exhaust the port quota >>> > of a user by installing many mapping entries (IP-Port-Forwarding-Ma= p >>> > attribute), prevent incoming traffic to be delivered to its >>> > legitimate destination by manipulating the mapping entries installe= d >>> > by means of an IP-Port-Forwarding-Map attribute, discover the IP >>> > address and port range assigned to a given user and which is report= ed >>> > in an IP-Port-Range attribute, etc. The root cause of these attack >>> > vectors is the communication between the RADIUS client and server. >>> > >>> > This document targets deployed where a trusted relationship is in >>> > place between the RADIUS client and server with communication >>> > optionally secured by IPsec or Transport Layer Security (TLS) >>> > [RFC6614]. >>> > >>> > Better? >>> >>> Much, thanks! This hits the point on what can be fine with these >>> attributes over existing/known weak points in the protocol and I >>> appreciate the recommendation to run it with an encrypted session. >>> >>> Once the shepherd report is ready, I'll put it in IETF last call. >>> >>> Thanks, >>> Kathleen >>> > >>> >> >>> >> Let me know if I am missing something as to why this is already >>> >> covered in radius security considerations. I think the specific >>> >> attribute addd should have their concerns listed. >>> >> >>> >> Thanks! >>> > >>> > [Med] Thank you for the review. >>> > >>> >> -- >>> >> >>> >> Best regards, >>> >> Kathleen >>> >> >>> >> _______________________________________________ >>> >> radext mailing list >>> >> radext@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/radext > > > > -- > > Best regards, > Kathleen --=20 Best regards, Kathleen From nobody Thu Jul 28 11:42:49 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC6512DC37 for ; Thu, 28 Jul 2016 11:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XbUnGG7GMIrL for ; Thu, 28 Jul 2016 11:42:42 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 8083412DC3A for ; Thu, 28 Jul 2016 11:42:42 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id s189so38439832vkh.1 for ; Thu, 28 Jul 2016 11:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2TDzp9LotpLnxxj64LD1BaTrpXiJI5bpggaE6U5AFnE=; b=N/CHZKW2zNay5Z2zradx9hk4QSGMx3oRF8vHX6BNOXtC3wkbQcU6s2LMEMAY6TRrPa 3z4vyJeLVkNwlQ9Y7BC2bdPoDk5gSfI2zZKhjGHolWslGStHo3kmafps+6USl795Xo4r 5aQiHBgwDqzhB3ARS+SSQX6ic1cf2xTXuXZ42Elakg3Yr6wsWPzxIzYHjF39P+xM2hQO 1ALJtdXW8tWi9EfLvPzTIJkrDc5rdyUZVtj/GZVnwiUItldvxH2IfiZbo5NKkpwa9ZZj 8UwzVzJ/r7265c6KavKRZoYNOYXZlCCnPeup9uf8MK+CX/HSuw6Lop7sbPXJ0cLObADc HfmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2TDzp9LotpLnxxj64LD1BaTrpXiJI5bpggaE6U5AFnE=; b=RUlWpuL6DpPC+12DBTHGOpBZGW6NexhBqr7WeMo7uEPhqGdoMSCxet2pkjwrhW9cwN oHzCY4HqVOW2NIjc/XgEIsNNIhbbQHc1a/1SJFdloLx9Lq95Xp2tVUKlDrDQBt52E04I wBMdAdxroSFmYpzNoU3WaHj8ZDggTSAkT42j1txE8hCiNV8aPEHsQDeDqXKd1yKn2Qy1 slJMaLbdOXb2fyYRwkSnbhX9PNN6XaAzC9CTTlWLc8h2qXpqlfFmaTOC6mvKdNSkrBFe DgCgXmThZiFcndlkK0NxS30JEIjG4gftZrej31u9VDvEQEbLSrcuDIckVp7fHIPMjQyX WITQ== X-Gm-Message-State: AEkoous2Ro3ZkuusmSOWd/hjeNYvrIlfi/Xn9/4HH8ncx6uXm6DorS4ZA0beza4mw/7duTpSYFjAiW6g+0O66w== X-Received: by 10.31.174.141 with SMTP id x135mr16065691vke.25.1469731361312; Thu, 28 Jul 2016 11:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Thu, 28 Jul 2016 11:42:40 -0700 (PDT) In-Reply-To: References: <787AE7BB302AE849A7480A190F8B933008DEE831@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6CFAC713-3903-4947-A3F8-691A7008B567@gmail.com> <787AE7BB302AE849A7480A190F8B933008DEEB07@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Kathleen Moriarty Date: Thu, 28 Jul 2016 14:42:40 -0400 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 18:42:46 -0000 Oops, wrong radext draft! This shepherd report looks great, just one nit for Lionel to fix when he has a moment, but I won't hold up on a nit in the shepherd report - s/vie/view/ In the approach 1, using fixed values for sub-TLV used in any attribute is straightforward from a dictionary/configuration point of vie, i.e. Thanks, Kathleen On Thu, Jul 28, 2016 at 2:34 PM, Kathleen Moriarty wrote: > Hello Mohamed, > > I just read through the shepherd report and see that Stefan caught > that the abstract doesn't list the RFC that this updates. Can you > make that fix and once that is done, I'll start IETF last call so this > comment doesn't come up again. > > Thanks, > Kathleen > > On Thu, Jul 28, 2016 at 12:29 PM, Kathleen Moriarty > wrote: >> On Thu, Jul 28, 2016 at 10:28 AM, wrote: >>> Re-, >>> >>> Thank you, Kathleen. >>> >>> FYI, an updated version with these changes is available online. >>> >> >> Excellent, thank you! I see the shepherd report id posted, so I'll >> review that and progress the draft to IETF review. This and the other >> Radext draft will likely be on the telechat in 3 weeks. Next weeks >> telechat is packed already, so I was avoiding it (Better reviews and >> less cranky ADs :-) . >> >> Thanks, >> Kathleen >> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : kathleen.moriarty.ietf@gmail.com >>>> [mailto:kathleen.moriarty.ietf@gmail.com] >>>> Envoy=C3=A9 : jeudi 28 juillet 2016 16:08 >>>> =C3=80 : BOUCADAIR Mohamed IMT/OLN >>>> Cc : radext@ietf.org >>>> Objet : Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext >>>> >>>> Hello Mohamed, >>>> >>>> Thank you for the quick response. Inline >>>> >>>> Sent from my iPhone >>>> >>>> > On Jul 28, 2016, at 4:00 AM, >>>> wrote: >>>> > >>>> > Dear Kathleen, >>>> > >>>> > Thank you for the review. >>>> > >>>> > Please see inline. >>>> > >>>> > Cheers, >>>> > Med >>>> > >>>> >> -----Message d'origine----- >>>> >> De : radext [mailto:radext-bounces@ietf.org] De la part de Kathleen >>>> >> Moriarty >>>> >> Envoy=C3=A9 : jeudi 28 juillet 2016 02:58 >>>> >> =C3=80 : radext@ietf.org >>>> >> Objet : [radext] AD Review of draft-ietf-radext-ip-port-radius-ext >>>> >> >>>> >> Hello, >>>> >> >>>> >> Thank you for your work on draft-ietf-radext-ip-port-radius-ext. T= his >>>> >> is an easy to understand document. I found a few nits and think mo= re >>>> >> text is needed in the security considerations section. My review i= s >>>> >> below. >>>> >> >>>> >> >>>> >> Abstract >>>> >> second sentence nit: s/implementing/implement/ >>>> > [Med] Fixed. >>>> > >>>> >> From: For devices that >>>> >> implementing IP port ranges, these attributes are used to communi= cate >>>> >> with a RADIUS server in order to configure and report TCP/UDP por= ts >>>> >> and ICMP identifiers, as well as mapping behavior for specific ho= sts. >>>> >> To: For devices that >>>> >> implement IP port ranges, these attributes are used to communicat= e >>>> >> with a RADIUS server in order to configure and report TCP/UDP por= ts >>>> >> and ICMP identifiers, as well as mapping behavior for specific ho= sts. >>>> >> >>>> >> 2. Terminology >>>> >> >>>> >> I think some rewording is needed, 'in respective' doesn't quite fit= in >>>> >> the following definition: >>>> >> >>>> >> External realm: refers to the networking segment where external = IP >>>> >> addresses are used in respective of the device supporting port >>>> >> ranges. >>>> > [Med] Changed to: >>>> > >>>> > External realm: refers to the networking segment where external IP >>>> addresses are used as source addresses of outbound packets forwarded b= y a >>>> device supporting port ranges. >>>> > >>>> > Better? >>>> >>>> Yes, thank you! >>>> > >>>> >> In the following definition, expand out CGN. >>>> > >>>> > [Med] CGN is already expanded in the introduction. >>>> > >>>> > I am pretty sure the >>>> >> others are acronyms that are in the do not have to expand list. Th= is >>>> >> one isn't one that I am familiar with: >>>> >> o Port-based device: a device that is capable of providing IP >>>> >> address and IP port mapping services and in particular, with t= he >>>> >> granularity of one or more subsets within the 16-bit IP port >>>> >> number range. A typical example of this device is a CGN, CPE, >>>> >> Provider WLAN Gateway, etc. >>>> >> >>>> >> Section 4.1.2: s/once/one/ >>>> > [Med] Fixed. >>>> > >>>> >> As one practice, a CGN may allocate a bulk of TCP/UDP ports or IC= MP >>>> >> identifiers once at a time for a specific user, >>>> >> >>>> >> Security considerations: >>>> >> >>>> >> Shouldn't there be some considerations about the communications for >>>> >> these attributes between the radius server and NAt44 or other devic= es? >>>> > >>>> > [Med] I don't think this is specific to these attributes but this is >>>> applicable to all RADIUS applications. >>>> > >>>> >> Since these attributes can be used to communicate a change in >>>> >> permissions (port/address mappings) that open/shut permissions for = a >>>> >> user, the user could be subject to attacks by alterations or tamper= ing >>>> >> of this stream. One might be to allow ports to be open that would >>>> >> make the system vulnerable to attack. The other would be to close >>>> >> ports off that are needed, resulting in a denial of service. >>>> >> >>>> >> I would think there are considerations to list with each of the new >>>> >> attributes along these lines. This would be specific text to the >>>> >> added attributes and communication of these attributes on the wire. >>>> > >>>> > [Med] The root cause of these attack vectors is the communication >>>> between the RADIUS client/server. Saying that, what about making this >>>> change to illustrate some attacks as you suggested? >>>> > >>>> > OLD: >>>> > This document does not introduce any security issue other than the >>>> > ones already identified in RADIUS [RFC2865]. >>>> > >>>> > NEW: >>>> > >>>> > This document does not introduce any security issue other than the >>>> > ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA >>>> > messages. Known RADIUS vulnerabilities apply to this specificatio= n. >>>> > For example, if RADIUS packets are sent in the clear, an attacker = in >>>> > the communication path between the RADIUS client and server may gl= ean >>>> > information that it will use to prevent a legitimate user to acces= s >>>> > the service by appropriately setting the maximum number of IP port= s >>>> > conveyed in an IP-Port-Limit-Info attribute, exhaust the port quot= a >>>> > of a user by installing many mapping entries (IP-Port-Forwarding-M= ap >>>> > attribute), prevent incoming traffic to be delivered to its >>>> > legitimate destination by manipulating the mapping entries install= ed >>>> > by means of an IP-Port-Forwarding-Map attribute, discover the IP >>>> > address and port range assigned to a given user and which is repor= ted >>>> > in an IP-Port-Range attribute, etc. The root cause of these attac= k >>>> > vectors is the communication between the RADIUS client and server. >>>> > >>>> > This document targets deployed where a trusted relationship is in >>>> > place between the RADIUS client and server with communication >>>> > optionally secured by IPsec or Transport Layer Security (TLS) >>>> > [RFC6614]. >>>> > >>>> > Better? >>>> >>>> Much, thanks! This hits the point on what can be fine with these >>>> attributes over existing/known weak points in the protocol and I >>>> appreciate the recommendation to run it with an encrypted session. >>>> >>>> Once the shepherd report is ready, I'll put it in IETF last call. >>>> >>>> Thanks, >>>> Kathleen >>>> > >>>> >> >>>> >> Let me know if I am missing something as to why this is already >>>> >> covered in radius security considerations. I think the specific >>>> >> attribute addd should have their concerns listed. >>>> >> >>>> >> Thanks! >>>> > >>>> > [Med] Thank you for the review. >>>> > >>>> >> -- >>>> >> >>>> >> Best regards, >>>> >> Kathleen >>>> >> >>>> >> _______________________________________________ >>>> >> radext mailing list >>>> >> radext@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/radext >> >> >> >> -- >> >> Best regards, >> Kathleen > > > > -- > > Best regards, > Kathleen --=20 Best regards, Kathleen From nobody Thu Jul 28 11:44:59 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7582F12DBDF; Thu, 28 Jul 2016 11:44:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160728184457.12912.52403.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2016 11:44:57 -0700 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:44:57 -0000 IESG state changed to Publication Requested from AD is watching ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Thu Jul 28 11:45:23 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0512DC52; Thu, 28 Jul 2016 11:45:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160728184522.12885.41752.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2016 11:45:22 -0700 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:45:22 -0000 IESG state changed to Last Call Requested from Publication Requested ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Thu Jul 28 11:45:26 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0D612D844; Thu, 28 Jul 2016 11:45:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "DraftTracker Mail System" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160728184522.12885.80524.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2016 11:45:22 -0700 Archived-At: Cc: radext@ietf.org, Kathleen.Moriarty.ietf@gmail.com, lionel.morand@orange.com Subject: [radext] Last Call: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:45:22 -0000 Last Call Request has been submitted for https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Thu Jul 28 11:52:19 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6651012DD4A; Thu, 28 Jul 2016 11:52:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160728185218.12937.64499.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2016 11:52:18 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org, radext-chairs@ietf.org, lionel.morand@orange.com Subject: [radext] Last Call: (RADIUS Extensions for IP Port Configuration and Reporting) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:52:19 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'RADIUS Extensions for IP Port Configuration and Reporting' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 28 11:53:08 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5F012DC36 for ; Thu, 28 Jul 2016 11:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ep29pEDvBz9O for ; Thu, 28 Jul 2016 11:53:05 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 BBECE12DFFB for ; Thu, 28 Jul 2016 11:52:34 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id j59so46276582uaj.3 for ; Thu, 28 Jul 2016 11:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fnKlTifkCbIvEXxE7UhCSs4iVC37odDH1JNhLeYZBIk=; b=IJuguen4/bmxl8USmvM58nVlNod3CIsS9Cv8difMsB64QsIjlBYPivs+O+PJMCk6a5 d230NBnucVOp6uP7NOgvAIh1iemydJ4HWfdx+PJWy3a3ZGXN274yy57xAy5PfW/rgGkp LhiJuJSVfF4pRgxMvcUyqU/0CRfzedPHSgTVpcsX+tlEVyxn2JNH5v8u4jmClOYzSQIZ tk6yoXSSJjMZPwT/ft7UC+29faKX9U7wsPI36aGRoEeT2+MROZajZtEuASb2El9xXQ9D XfZ5iPqC5uegxlt9e4N14wRA+vLqF/pyiAnoFYOGp1zfxKNcup3ORlkojuEyAOz5Kk8A A9YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fnKlTifkCbIvEXxE7UhCSs4iVC37odDH1JNhLeYZBIk=; b=PFduOqfnIKII7mc1oS/QXRNbI6VPqY5SFZUOgNxSEceO1eGN6vqQzHzlGqB5xKOE+d m8yiyBC0MvUPs4n0yrevGbufT6WK27upeIPCPH5VE3hXZjsYOHxY+2I8KS5bHaTSOV69 OyPDEL9q38f11w72XCSISfImbI3ElUNzD0jLFlsmXRD2DfZJFSvyLJo7GHwoN+rq0aKx IazXIAJkphGOXCHHCh+TuA/S+l6Sc9YUuEoRxs287ndTCNFtAk9r5Dih77Hxb++wQOzB nYwHXxVaVF9CZNs4qJtxRAqhcUsqO59rc+Q0GIlWJMVFIiXZBlk4sUitziAgDx0A8fcN rsYw== X-Gm-Message-State: AEkoouvuDW4BqadcyNtzFRkfO+ZdFqXnjBmo4Q4iIN2FX1AUW4p/tE+qvBTfMaKa/nzyq+L3FpeYlrizflJqLQ== X-Received: by 10.176.3.174 with SMTP id 43mr17067181uau.88.1469731953853; Thu, 28 Jul 2016 11:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Thu, 28 Jul 2016 11:52:33 -0700 (PDT) In-Reply-To: <29432_1468945047_578E5297_29432_1897_1_6B7134B31289DC4FAF731D844122B36E01F147FC@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <29432_1468945047_578E5297_29432_1897_1_6B7134B31289DC4FAF731D844122B36E01F147FC@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Kathleen Moriarty Date: Thu, 28 Jul 2016 14:52:33 -0400 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 18:53:07 -0000 Hi, Sorry I didn't see this sooner. In reading the shepherd report, I see that the abstract should also list the RFCs this updates. Could that be added and then I'll kick off last call? I'll put it on the telechat in 3 weeks now. On Tue, Jul 19, 2016 at 12:17 PM, wrote: > Hi, > > Would it better to add (or repeat) such clarifications in the IANA consid= erations section? I think it's fine to refer back to a single location since there are no changes. It's a rather complex IANA section. > > As a new version (simple update so far) is required anyway, I think it is= OK to wait for this new version and launch the IETF LC with a normal 2-wee= k period at least the next week (or ASAP after publication of the draft). OK, thanks! I'll start last call as soon as the abstract fix is in as that should be very simple and I'd rather avoid more people commenting on the same thing. Thanks, Kathleen > > Regards, > > Lionel > >> -----Message d'origine----- >> De : radext [mailto:radext-bounces@ietf.org] De la part de Kathleen Mori= arty >> Envoy=C3=A9 : mardi 19 juillet 2016 17:43 >> =C3=80 : Alan DeKok >> Cc : radext@ietf.org >> Objet : Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-rad= ext- >> datatypes-04.txt >> >> Hi Alan, >> >> Thanks for the quick response. inline. >> >> On Tue, Jul 19, 2016 at 11:20 AM, Alan DeKok >> wrote: >> > On Jul 16, 2016, at 10:48 PM, Kathleen Moriarty >> wrote: >> >> >> >> Hello, >> >> >> >> Thank you for another very well written draft that serves a clear >> >> purpose and is easy to read and understand. I just have 2 questions >> >> that should be really easy and then would like to know when the WG >> >> prefers me to start IETF last call. And if you'd like IETF last call >> >> to start this week, should it be extended for a 3rd week? >> >> >> >> Comments/questions: >> >> Section 2.1.1 >> >> Should this say "be of a valid data type" >> >> Attr-Data >> >> >> >> The "Value" field of an Attribute as defined in [RFC2865] >> >> Section 5. The contents of this field MUST be a valid data >> >> type as defined in the RADIUS Data Type registry. >> > >> > I'm fine with the change. I'm not sure it makes a substantive chang= e, tho. >> >> Thanks. >> > >> >> IANA Section 4.2 >> >> Does the registration policy remain unchanged from rfc3575? >> > >> > Yes. >> > >> >> If so, it >> >> would be helpful to state that since 4.1 defines the registration >> >> policy as requiring IETF review, >> > >> > The intent there is that new data types requires IETF review with St= andards >> Action. It doesn't change the registration requirements for the RADIUS >> attributes registry. >> > >> > Maybe this is clearer: >> > >> > This section defines a new RADIUS registry, called "Data Type". >> > Allocation in this registry requires IETF Review. The "Registration >> > Procedures" for the Data Type Registry are "Standards Action". >> > >> >> I'm fine with the text you have my question was about 4.2, but included = the >> above for context on the question. >> >> > >> >> different from what happens for 4.2 >> >> according to the description in rfc3575. >> > >> > OK. >> > >> > Maybe adding text here would be good: >> > >> > The existing registration requirements for the Attribute Type Registry >> > are unchanged. >> >> Perfect, thanks. >> >> Kathleen >> >> > >> > Alan DeKok. >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > --=20 Best regards, Kathleen