From nobody Thu Jul 13 06:28:14 2017 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 5B0871318A6 for ; Thu, 13 Jul 2017 06:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001, 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 a0HLi58GPmu0 for ; Thu, 13 Jul 2017 06:28:08 -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 82241131699 for ; Thu, 13 Jul 2017 06:28:08 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 15E1043A70 for ; Thu, 13 Jul 2017 15:28:06 +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: <83a0de2d-dd6a-f4e1-2491-35de7825615f@restena.lu> Date: Thu, 13 Jul 2017 15:28:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NlowxRdCxLJHk6VB3mIxTPjSv1e8R85rR" Archived-At: Subject: [radext] Agenda IETF99 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 13:28:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NlowxRdCxLJHk6VB3mIxTPjSv1e8R85rR Content-Type: multipart/mixed; boundary="4wp2xflE3CNxpbTomQTeO5hA2IUepPV8T"; protected-headers="v1" From: Stefan Winter To: "radext@ietf.org" Message-ID: <83a0de2d-dd6a-f4e1-2491-35de7825615f@restena.lu> Subject: Agenda IETF99 --4wp2xflE3CNxpbTomQTeO5hA2IUepPV8T Content-Type: multipart/mixed; boundary="------------713E7761264055DB8BA10276" Content-Language: lb-LU This is a multi-part message in MIME format. --------------713E7761264055DB8BA10276 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, my apologies for being late with the agenda this time. Nobody has sent requests for a presentation slot, so what I have at this point is a rather light agenda - we've requested 60 minutes, got 90, and actually have 50 minutes, including some open mic time at the end. Obviously, if you have something to say, don't be shy: there's still plenty of time to allocate. Let the chairs know. The agenda itself is at: https://datatracker.ietf.org/meeting/99/agenda/radext/ See you next week in Prague! 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 recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------713E7761264055DB8BA10276 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----- --------------713E7761264055DB8BA10276-- --4wp2xflE3CNxpbTomQTeO5hA2IUepPV8T-- --NlowxRdCxLJHk6VB3mIxTPjSv1e8R85rR 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 iQIcBAEBCgAGBQJZZ3VlAAoJEMDeajWKOdxmsC8QAMc5wLpxe3vQPpfxZox5H28x A80Z+Lrnxw+sWvVCS0nFXNVYSW06Kb0JvvyQzr+o8iB5TIGp+SbqHJbvCemy1a+n nNaOkoBnxAmeIm4l6aAIq3rMgjrxFNKN4Ood7fXVyY+IBIjqVSIS+0z5or7v8WBF IYP+hfWu4K8+4kAyeLGv2LfCsKBDRNkyxUKwDeMzeb8Z3ArYedmvEeIua/6zJjI2 Rex+39vMgOsiO4BSRVibUbowprXdjuz1RsNX9ufj+psgJHFIj3Irxgh0eTdNqbPy eBdKmbP4nF7fFiPOktvw620K3oHrAdauWTB8q8bIZXlh49u6wqL0XgjmS0cf1jWE eoMDjd4A0iffQJJ0/qN/jGpvGtPcJ4X/b2rHI6GZb8c144MloX4yGgZpY3qsETRc qKmdG+bJlEATTuNbFIPuew6HU9DXDBSpJhLrjhao9kEYqpQ8MCUhzEpIPNzjcPhs PKNhcANJHamBtuxCHl/ObBoHjYWFqu58IRUHBFzXwZZIwXSdy5yJkZePDoSFNmoJ GclA1kIRk75pVL34E9kM//3EdppXR4ksj+2qJQkWkIQuTj2bTrUtTe8EtRxn/5kj 5CafQAmZsy1nt1aBkBeIt7CrZtp+FA4vp8Kn820UFC5gIEjLoxOfQ+4R1kRDV8X1 2hp2T/ESwDcPStilNqtR =GYX/ -----END PGP SIGNATURE----- --NlowxRdCxLJHk6VB3mIxTPjSv1e8R85rR-- From nobody Thu Jul 13 06:39:42 2017 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 233081318C4 for ; Thu, 13 Jul 2017 06:39: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, SPF_PASS=-0.001, URIBL_BLOCKED=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 YM1VsJrIKsRb for ; Thu, 13 Jul 2017 06:39:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1C131699 for ; Thu, 13 Jul 2017 06:39:39 -0700 (PDT) Received: from [192.168.20.184] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id 3F76B506; Thu, 13 Jul 2017 13:39:38 +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: <83a0de2d-dd6a-f4e1-2491-35de7825615f@restena.lu> Date: Thu, 13 Jul 2017 09:39:37 -0400 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <94CAEC76-C88D-43D0-9608-545D42E4A47A@deployingradius.com> References: <83a0de2d-dd6a-f4e1-2491-35de7825615f@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Agenda IETF99 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 13:39:41 -0000 On Jul 13, 2017, at 9:28 AM, Stefan Winter = wrote: > Obviously, if you have something to say, don't be shy: there's still > plenty of time to allocate. Let the chairs know. - proxy considerations. No new developments here, just "are people = still interested?" - ID extension. Probably my draft && draft-chen-.... Personally, I'd like to see a discussion around the topic of ID = extension. It's been needed for ages. Vendors have implemented = proprietary extensions. Independent of the technical proposal, my draft contains a huge amount = of discussion of the costs / benefits / side effects of this kind of = solution. It would help if people read it and commented. Alan DeKok.= From nobody Thu Jul 13 06:46:45 2017 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 9805F131A70 for ; Thu, 13 Jul 2017 06:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 mUZ837YG5Zr3 for ; Thu, 13 Jul 2017 06:46:42 -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 146FE131699 for ; Thu, 13 Jul 2017 06:46: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 B69984395C for ; Thu, 13 Jul 2017 15:46:40 +0200 (CEST) To: radext@ietf.org References: <83a0de2d-dd6a-f4e1-2491-35de7825615f@restena.lu> <94CAEC76-C88D-43D0-9608-545D42E4A47A@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <11be16b9-195e-670a-5723-7d857b0b732e@restena.lu> Date: Thu, 13 Jul 2017 15:46:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <94CAEC76-C88D-43D0-9608-545D42E4A47A@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BDxR1IghaRenADxMQPq48ur2wRvH6VQTO" Archived-At: Subject: Re: [radext] Agenda IETF99 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 13:46:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BDxR1IghaRenADxMQPq48ur2wRvH6VQTO Content-Type: multipart/mixed; boundary="pb95OFpo1sRe9mp0i8oa6PKW9sTfsE6I1"; protected-headers="v1" From: Stefan Winter To: radext@ietf.org Message-ID: <11be16b9-195e-670a-5723-7d857b0b732e@restena.lu> Subject: Re: [radext] Agenda IETF99 References: <83a0de2d-dd6a-f4e1-2491-35de7825615f@restena.lu> <94CAEC76-C88D-43D0-9608-545D42E4A47A@deployingradius.com> In-Reply-To: <94CAEC76-C88D-43D0-9608-545D42E4A47A@deployingradius.com> --pb95OFpo1sRe9mp0i8oa6PKW9sTfsE6I1 Content-Type: multipart/mixed; boundary="------------B9A50F1C6A453BAB6C990378" Content-Language: lb-LU This is a multi-part message in MIME format. --------------B9A50F1C6A453BAB6C990378 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > - proxy considerations. No new developments here, just "are people sti= ll interested?" I've added a 5 min block to discuss that topic. > - ID extension. Probably my draft && draft-chen-.... > > Personally, I'd like to see a discussion around the topic of ID extens= ion. It's been needed for ages. Vendors have implemented proprietary e= xtensions. > > Independent of the technical proposal, my draft contains a huge amount= of discussion of the costs / benefits / side effects of this kind of sol= ution. It would help if people read it and commented. I already had a 15 min block on that topic: Individual Drafts (15 min) -------------------------- * Getting beyond the 256 packets-in-flight limit and other header changes - various approaches - draft-chen-radext-extended-header - - draft-dekok-radext-request-authenticator - : 15 min Slides are appreciated; and the earlier they come, the more appreciated t= hey are :-) 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 --------------B9A50F1C6A453BAB6C990378 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----- --------------B9A50F1C6A453BAB6C990378-- --pb95OFpo1sRe9mp0i8oa6PKW9sTfsE6I1-- --BDxR1IghaRenADxMQPq48ur2wRvH6VQTO 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 iQIcBAEBCgAGBQJZZ3nAAAoJEMDeajWKOdxm59sP/j/Cja3AMV55j97QMPFTs2wg FFStA/NW9yPLCsK+a5ypEdNeBUQWfzsqu7ZDObX0X5oZ5OG6L3MFxoxn5TtHUVOb Ozn54cvwi80ArnrX0VNKZ4vMML4afuKeOe5zKjvZg8MqAyuYs+Jl57xl5XD9vYF1 BC3jamGKH5BKOP9zsvd8Na3XRHNNgJTzI4nwXJYlG2lTzUkgjWXCd1CKGmQwsivE nvhjqBeD9Dq5UA+N1yXlyTplBh8+cuWOgapkIINdQtGmDTd49/7CU1nXshoIt+T5 KTeGZjBwmi7vqDEEyso2WZYJ/d9WEzgTlaWH3gIZp+jzGFNUzrxBLhdorGpGR8lj NsrKr8EZQKI07ZDaeGEQEJLQCPEnxIuRxluShlZDqQRcCYZ371muZw3Ls8he+r++ rD4lTul9vpy2JhkXWCb8A4FkVqaZiwhy1iHp8e98Ve2wvxArrP3AdEp+Zh0k2erS qasnJZTLtx+BYe/R1oaRuz4uhuQLmU23pQSV4CQmsKFfySOlcQ5lGylXKP0d93Fi aUc2cKIbthAGaIOWuA9adhNbivSz+JtNLm49fjthJVHmhBIi6xfKikRxyF5r8a1D 0mW1SQpW2z3q+Q8Wr5d3g75QaBbcUiUfBHCKHMg45EYP4mqE/j/esMs27dNHAYLZ Wjh430Jol7AoLL5Rkjsr =6iZ9 -----END PGP SIGNATURE----- --BDxR1IghaRenADxMQPq48ur2wRvH6VQTO-- From nobody Thu Jul 13 10:38:55 2017 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 9C24E131736 for ; Thu, 13 Jul 2017 10:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XaKNVOsU5JJ3 for ; Thu, 13 Jul 2017 10:38:52 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299DF129468 for ; Thu, 13 Jul 2017 10:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1007; q=dns/txt; s=iport; t=1499967532; x=1501177132; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3TesROJ9fzTMs2e+dTf8PqJZLEkFqnfEHs7WdJQI/FY=; b=jPacVMHkD15RpvOCinN0y0LOggjjYXd98/jFuCPI1x8WD2/H7ARpzKnD PVkfaP5yTPTJzUCpzNKiGEeLsX6ISi2Mm8xJ/TuSiFXUYyVB4/mbxE7RY YU+/uV8N2JcACh8h3FFIypDZ6WkKYDnAhZWBS7YkLp9i40PBSWY47Kcxk k=; X-IronPort-AV: E=Sophos;i="5.40,354,1496102400"; d="scan'208";a="454892554" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2017 17:38:51 +0000 Received: from [10.155.125.54] (dhcp-10-155-124-4-125-54.cisco.com [10.155.125.54]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6DHcpcn017919; Thu, 13 Jul 2017 17:38:51 GMT To: Stefan Winter References: <83a0de2d-dd6a-f4e1-2491-35de7825615f@restena.lu> Cc: "radext@ietf.org" , Enke Chen , Naiming Shen From: Enke Chen Message-ID: <45a9e9d7-2772-c011-80b6-9d4653db1cd6@cisco.com> Date: Thu, 13 Jul 2017 10:38:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <83a0de2d-dd6a-f4e1-2491-35de7825615f@restena.lu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Agenda IETF99 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 17:38:54 -0000 Hi, Stefan: Please note that draft-chen-radext-extended-header has been changed to draft-chen-radext-identifier-attr, and the latest version is draft-chen-radext-identifier-attr-01.txt Thanks. -- Enke On 7/13/17 6:28 AM, Stefan Winter wrote: > Hello, > > my apologies for being late with the agenda this time. > > Nobody has sent requests for a presentation slot, so what I have at this > point is a rather light agenda - we've requested 60 minutes, got 90, and > actually have 50 minutes, including some open mic time at the end. > > Obviously, if you have something to say, don't be shy: there's still > plenty of time to allocate. Let the chairs know. > > The agenda itself is at: > > https://datatracker.ietf.org/meeting/99/agenda/radext/ > > See you next week in Prague! > > Greetings, > > Stefan Winter > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Thu Jul 27 06:51:46 2017 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 0F2C1132167; Thu, 27 Jul 2017 06:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TgDkJFHtdxZK; Thu, 27 Jul 2017 06:51:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6463120721; Thu, 27 Jul 2017 06:51:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EF8EAB80C65; Thu, 27 Jul 2017 06:51:32 -0700 (PDT) To: aland@freeradius.org, stefan.winter@restena.lu, mikem@airspayce.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bclaise@cisco.com, iesg@ietf.org, radext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170727135132.EF8EAB80C65@rfc-editor.org> Date: Thu, 27 Jul 2017 06:51:32 -0700 (PDT) Archived-At: Subject: [radext] [Errata Held for Document Update] RFC7585 (4991) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 13:51:45 -0000 The following errata report has been held for document update for RFC7585, "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid4991 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Alan DeKok Date Reported: 2017-04-07 Held by: Benoit Claise (IESG) Section: GLOBAL Original Text ------------- Corrected Text -------------- Notes ----- The document describes how to look up realms, but doesn't describe what to do after that. i.e. are the lookups cached? Are the lookups done for every request that comes in? This gives little guidance for an implementor. I suggest leveraging the "logical AAA routing table" described in RFC 7542 Section 3. In short form: * a client MUST maintain a table of known dynamic realms. * the table MUST be keyed by the realm name, and the contents MUST be server-specific information as described in RFC 7542 Section 3 * when a realm is being looked up, the realm SHOULD be inserted into the table with a "pending" flag, so subsequent requests during the lookup process do not cause additional lookups to be made * if server validation fails, the realm SHOULD be updated with a "failed" state and a TTL, so that subsequent requests do not cause additional lookups for a period of time. No server information should be stored for this entry. i.e. the realm is marked as "failed", the corresponding server MUST NOT be marked as "failed". This prevents attacks where a malicious actor could point their realm to an unknowing third-party server, and cause poorly implemented proxies to mark it "failed". * if server validation succeeds, the realm MUST be updated with a "live" state (and a TTL), so that subsequent requests go to the same server without additional lookups * if server validation succeeds, all realms in the TLS "subject alternative names" presented by the server SHOULD be inserted into the realm table, all pointing to the same server definition, so that subsequent requests for those other realms do not cause additional lookups to be made. * servers which have been dynamically looked up MUST NOT be added to any global pool of servers. i.e. the lookup is always "realm -> server", and not "There's a known server at this IP address" I thought we had a short discussion of some of these topics on RADEXT, but I can't find it in the archives. I think these comments are substantial enough to warrant "wait for document update". I just wanted to ensure they weren't lost. -------------------------------------- RFC7585 (draft-ietf-radext-dynamic-discovery-15) -------------------------------------- Title : Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) Publication Date : October 2015 Author(s) : S. Winter, M. McCauley Category : EXPERIMENTAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Jul 27 06:52:22 2017 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 5F9F513216D for ; Thu, 27 Jul 2017 06:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 59hXrHolWAxz for ; Thu, 27 Jul 2017 06:52:14 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A915132167 for ; Thu, 27 Jul 2017 06:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5497; q=dns/txt; s=iport; t=1501163527; x=1502373127; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=J6dO3MBgaaregFvIsslh7Wik+86BZzkpUgyA3Ofe/k8=; b=l79yWK+xupmNcbm8OVun/IDdaePcAbX3KKKpFhUTfnCTQ8Kf+YcOCp2d uJ4n01QTyNtxbzZ6XziTkoX70S+7CvC0kvmM+QDy0iAPMDVYh0qK+wXx+ snMD5Gh7bOlqTvKRHz3/eYp01PGPw3UjfIa4jdCFcGDwXP0zXgeKxbA2u I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AAAK73lZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5tJ44Nc5BMInSVFoISIQuETE8ChCEYAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAQEBIQQRNgsQCxgCAiYCAicwBgEMBgIBAYojCBCwCYFsOotBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWBC4Idg02BYSsLgjo0gTyDIYMpgmEBBIlciGyNHos?= =?us-ascii?q?aiQuCDIknhwmJU4M6iGUfOIEKMiEIHBVJhSKBeT42h0IrghMBAQE?= X-IronPort-AV: E=Sophos;i="5.40,419,1496102400"; d="scan'208";a="654557727" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 13:52:03 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6RDq2Vh012570; Thu, 27 Jul 2017 13:52:03 GMT To: Alan DeKok , Winter Stefan Cc: radext@ietf.org References: <20170407153616.79D17B80CE5@rfc-editor.org> <0EC0AC7E-04FE-416F-ABF3-92FFB07C8EA4@deployingradius.com> From: Benoit Claise Message-ID: Date: Thu, 27 Jul 2017 15:52:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0EC0AC7E-04FE-416F-ABF3-92FFB07C8EA4@deployingradius.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [radext] [Technical Errata Reported] RFC7585 (4991) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 13:52:16 -0000 On 4/8/2017 1:01 AM, Alan DeKok wrote: > On Apr 7, 2017, at 1:58 PM, Stefan Winter wrote: >> Well, there's section 3.4.4 "Validity of results" which has some amount >> of text on that topic: > Essentially "subsequent packets for an open connection should re-use that connection". > >>> * when a realm is being looked up, the realm SHOULD be inserted into the table with a "pending" flag, so subsequent requests during the lookup process do not cause additional lookups to be made >> With the text above, is this needed? I would think that internal >> housekeeping like deciding to store the data in a table, and that it has >> keys, and what this key has to be is *too* much implementation specific >> and does not need to be in an RFC? > It would be good to recommend that only one connection discover is ongoing at a time. This is an issue of network overload, not implementation IMHO. > >>> * if server validation fails, the realm SHOULD be updated with a "failed" state and a TTL, so that subsequent requests do not cause additional lookups for a period of time. No server information should be stored for this entry. i.e. the realm is marked as "failed", the corresponding server MUST NOT be marked as "failed". This prevents attacks where a malicious actor could point their realm to an unknowing third-party server, and cause poorly implemented proxies to mark it "failed". >> The same section 3.4.4 goes on to state: >> >> "Should the algorithm above terminate with O-1 = { empty set }, the >> RADIUS server SHOULD NOT attempt another execution of this algorithm >> for the same target realm before the timeout O-2 has passed." >> >> Is that not enough? > Yes, it's largely the same thing. It also doesn't say what to do with requests for that realm. Discard them? Reject them? > > RADIUS is bad that way. :( > >> I you want to include a failed TLS connection setup >> phase result in the negative result state then that's probably more than >> an errata can do: it's not in scope of the RFC, it only defines the >> algorithm to find a set of servers to talk to. It hands off to RFC6614 >> once the server to talk to is known. > The dynamic discovery RFC should also say what to do when thing go wrong. This isn't an issue for RFC 6614, I think. > >> A tighter integration between those two phases is certainly desirable >> (and a useful thing to consider when thinking about the update & move of >> the specs from Experimental to Standards Track) > I agree. > >>> * if server validation succeeds, all realms in the TLS "subject alternative names" presented by the server SHOULD be inserted into the realm table, all pointing to the same server definition, so that subsequent requests for those other realms do not cause additional lookups to be made. >> That is in principle a good suggestion. However the discovery process >> also yielded some meta data about the server: there's a priority order >> of servers. For a different realm, there might be different discovery >> results with a different top-priority target; but the same server can >> still be configured to serve the realm, but with a lower priority. > Sure. > >> The mechanism above would mean that a client which has learned the >> target for one realm will also talk to that same target about another >> realm without validating that it is the one to talk to /in priority/. >> That may lead to results not expected by the owner of that realm. > Sure. It just would be nice to avoid the discovery phase in some cases. > >>> * servers which have been dynamically looked up MUST NOT be added to any global pool of servers. i.e. the lookup is always "realm -> server", and not "There's a known server at this IP address" >> Well, that's how the algorithm is set up. The input is a realm, the >> output is a set of servers. It is implicit that there's a link between >> the input and the output of the algorithm. Any other interpretation of >> the algorithm's results appear counter-intuitive to me. > It's described, but isn't as explicit as the text in RFC 7542. > > As an implementor, it's nice to know what information I need to track, and what state changes I need to make in order to implement the protocol. > > The existing document describes the lookup algorithm in detail, but is a little more vague about what information is tracked, and what state changes are made. > >>> I thought we had a short discussion of some of these topics on RADEXT, but I can't find it in the archives. >>> >>> I think these comments are substantial enough to warrant "wait for document update". I just wanted to ensure they weren't lost. >> There certainly was discussion at some meetings. Many of those led to >> text updates; which is why section 3.4.4 has corresponding text. >> >> Can you re-check the document with section 3.4.4 in mind and provide a >> more narrow description on what text exactly you think needs to be >> corrected/added, and where? > I'd like more text on what to do as an implementor, and what to do when things go wrong. > > I think we can leave the errata as "hold for document update", so that the next rev can add some more text based on my comments. Done. Regards, Benoit. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > . > From nobody Thu Jul 27 07:00:34 2017 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 7DA65131FF1; Thu, 27 Jul 2017 07:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PqRlJKTG-5xm; Thu, 27 Jul 2017 07:00:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F17131C8F; Thu, 27 Jul 2017 07:00:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9C48BB80CF9; Thu, 27 Jul 2017 07:00:14 -0700 (PDT) To: andrew.feren@plixer.com, dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bclaise@cisco.com, iesg@ietf.org, radext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170727140014.9C48BB80CF9@rfc-editor.org> Date: Thu, 27 Jul 2017 07:00:14 -0700 (PDT) Archived-At: Subject: [radext] [Errata Verified] RFC8045 (5009) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 14:00:27 -0000 The following errata report has been verified for RFC8045, "RADIUS Extensions for IP Port Configuration and Reporting". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5009 -------------------------------------- Status: Verified Type: Technical Reported by: Andrew Feren Date Reported: 2017-05-02 Verified by: Benoit Claise (IESG) Section: 7.1 Original Text ------------- o sourceTransportPortsLimit: * Name: sourceTransportPortsLimit * Element ID: 458 * Description: This Information Element contains the maximum number of IP source transport ports that can be used by an end user when sending IP packets; each user is associated with one or more (source) IPv4 or IPv6 addresses. This Information Element is particularly useful in address-sharing deployments that adhere to REQ-4 of [RFC6888]. Limiting the number of ports assigned to each user ensures fairness among users and mitigates the denial-of-service attack that a user could launch against other users through the address-sharing device in order to grab more ports. * Data type: unsigned16 * Data type semantics: totalCounter Corrected Text -------------- o sourceTransportPortsLimit: * Name: sourceTransportPortsLimit * Element ID: 458 * Description: This Information Element contains the maximum number of IP source transport ports that can be used by an end user when sending IP packets; each user is associated with one or more (source) IPv4 or IPv6 addresses. This Information Element is particularly useful in address-sharing deployments that adhere to REQ-4 of [RFC6888]. Limiting the number of ports assigned to each user ensures fairness among users and mitigates the denial-of-service attack that a user could launch against other users through the address-sharing device in order to grab more ports. * Data type: unsigned16 * Data type semantics: quantity Notes ----- Only change is * Data type semantics: totalCounter to * Data type semantics: quantity The description is pretty clear that this IE is a maximum value and not a counter. -------------------------------------- RFC8045 (draft-ietf-radext-ip-port-radius-ext-17) -------------------------------------- Title : RADIUS Extensions for IP Port Configuration and Reporting Publication Date : January 2017 Author(s) : D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar Category : PROPOSED STANDARD Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Jul 27 07:08:07 2017 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 63E1B131FF1; Thu, 27 Jul 2017 06:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BUYLBKcuhKEC; Thu, 27 Jul 2017 06:59:50 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3E9132168; Thu, 27 Jul 2017 06:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4057; q=dns/txt; s=iport; t=1501163990; x=1502373590; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=E4TSTRXW72JQMZGIQhNZFQBaRiRvAQ2EPOhXsXp9zIY=; b=YhJEnx+hIFOoSA5Plj4BRXiNoLi5toumFWEP1+ZiGyOdn6GSLTMoTaV5 nYRXQnhlalcQB1NfZqnK1aAQ9/3aWT5FMBtCrRmxZKgYdAfDx6gFbmlIA m2ig4kZr94htmzrsZP+fiCN4wRMg07PgDH/pHL6grFQXX3CRMY7X+5/DH A=; X-IronPort-AV: E=Sophos;i="5.40,419,1496102400"; d="scan'208";a="653535685" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 13:59:48 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6RDxm55028781; Thu, 27 Jul 2017 13:59:48 GMT To: "ie-doctors@ietf.org" , dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, warren@kumari.net, lionel.morand@orange.com, stefan.winter@restena.lu Cc: andrew.feren@plixer.com, radext@ietf.org References: <20170502134027.2A74EB80E97@rfc-editor.org> <53aed9b5-6e8c-3891-1561-e1fcd2a60ba8@cisco.com> From: Benoit Claise Message-ID: <2ffc59f8-21b1-7dec-dcc9-3c09f6d4603f@cisco.com> Date: Thu, 27 Jul 2017 15:59:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <53aed9b5-6e8c-3891-1561-e1fcd2a60ba8@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-Mailman-Approved-At: Thu, 27 Jul 2017 07:08:07 -0700 Subject: Re: [radext] [Technical Errata Reported] RFC8045 (5009) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 13:59:52 -0000 Hi, I have not heard from the IPFIX IE doctors. I believe this errata makes sense. Some limit-related IPFIX IE are quantity. Let me approve it. Regards, Benoit > Hi, > > [removing the rfc-editor and copying the IPFIX IE doctors] > If this errata is accepted by the IPFIX IE doctors, we would have to > change the IANA registry > https://www.iana.org/assignments/ipfix/ipfix.xhtml > So we would have to go for a new IPFIX IE revision, according to the > procedure in https://tools.ietf.org/html/rfc7013#section-5.2 > > Regards, B. > >> The following errata report has been submitted for RFC8045, >> "RADIUS Extensions for IP Port Configuration and Reporting". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/rfc8045/eid5009 >> >> -------------------------------------- >> Type: Technical >> Reported by: Andrew Feren >> >> Section: 7.1 >> >> Original Text >> ------------- >> o sourceTransportPortsLimit: >> >> * Name: sourceTransportPortsLimit >> >> * Element ID: 458 >> >> * Description: This Information Element contains the maximum >> number of IP source transport ports that can be used by an end >> user when sending IP packets; each user is associated with one >> or more (source) IPv4 or IPv6 addresses. This Information >> Element is particularly useful in address-sharing deployments >> that adhere to REQ-4 of [RFC6888]. Limiting the number of >> ports assigned to each user ensures fairness among users and >> mitigates the denial-of-service attack that a user could >> launch >> against other users through the address-sharing device in >> order >> to grab more ports. >> >> * Data type: unsigned16 >> >> * Data type semantics: totalCounter >> >> Corrected Text >> -------------- >> o sourceTransportPortsLimit: >> >> * Name: sourceTransportPortsLimit >> >> * Element ID: 458 >> >> * Description: This Information Element contains the maximum >> number of IP source transport ports that can be used by an end >> user when sending IP packets; each user is associated with one >> or more (source) IPv4 or IPv6 addresses. This Information >> Element is particularly useful in address-sharing deployments >> that adhere to REQ-4 of [RFC6888]. Limiting the number of >> ports assigned to each user ensures fairness among users and >> mitigates the denial-of-service attack that a user could >> launch >> against other users through the address-sharing device in >> order >> to grab more ports. >> >> * Data type: unsigned16 >> >> * Data type semantics: quantity >> >> Notes >> ----- >> Only change is >> >> * Data type semantics: totalCounter >> to >> * Data type semantics: quantity >> >> The description is pretty clear that this IE is a maximum value and >> not a counter. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8045 (draft-ietf-radext-ip-port-radius-ext-17) >> -------------------------------------- >> Title : RADIUS Extensions for IP Port Configuration and >> Reporting >> Publication Date : January 2017 >> Author(s) : D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar >> Category : PROPOSED STANDARD >> Source : RADIUS EXTensions >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> . >> > > . >