Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers

Stefan Winter <stefan.winter@restena.lu> Thu, 29 October 2015 11:56 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333D51B2DC2 for <radext@ietfa.amsl.com>; Thu, 29 Oct 2015 04:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1iGZ7waHLJP for <radext@ietfa.amsl.com>; Thu, 29 Oct 2015 04:56: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 74E901B2DB0 for <radext@ietf.org>; Thu, 29 Oct 2015 04:56: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 D30CB43AA0; Thu, 29 Oct 2015 12:56:08 +0100 (CET)
To: Sam Hartman <hartmans@painless-security.com>
References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> <tsl7foqjbae.fsf@mit.edu> <55D6CC73.9020002@restena.lu> <tslr3mwhj9h.fsf@mit.edu>
From: Stefan Winter <stefan.winter@restena.lu>
Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
X-Enigmail-Draft-Status: N1111
Message-ID: <56320958.2000403@restena.lu>
Date: Thu, 29 Oct 2015 12:56:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <tslr3mwhj9h.fsf@mit.edu>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="fNRMcVNMbK6dpQjSoc3BF5BJ5KtwxbJw9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/D92_qXTw0f0nqfr2uALLwq-LSuU>
Cc: radext@ietf.org
Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2015 11:56:12 -0000

Hi,

> I think the particular configuration you quote above might be a good fit
> for a system that uses both Moonshot and eduroam.
> Especially if you make it a bit finer grained by allowing  each
> consortuim/set of CAs/whatever you want to describe it as for DNS have
> its own configuration.

The "whatever you want" makes it difficult to prescribe how exactly a
classification of servers should be done - and was the reason why I
considered the wording unclear.

> I think I need something like this as a minimum so I'd like to have a
> related SHOULd in the spec.
> I'd be happy to get input on what approaches would give me this but work
> for you.

Okay... We both agree that this parameter needs to be configurable. None
of us really knows how "categories" should be defined exactly (nor do we
know what will be useful classification criteria in the field).

I think this is something actual implementations - and their customer
demand - can and will sort out themselves.

The important bit is that it must be configurable in principle IMHO; and
that more than one global default is something to consider for an
implementation. So how about this as a text proposal:

OLD:

If dynamic discovery mechanisms are supported, configuration SHOULD be
provided for the maximum size of clients and servers in each dynamic
discovery category.

NEW:
If dynamic discovery mechanisms are supported, the default maximum
packet sizes for sending packets SHOULD be configurable. Implementations
MAY choose to allow configuration of different defaults in different
parts of their dynamic discovery configuration.

How about that?

Greetings,

Stefan Winter


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
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=get&search=0xC0DE6A358A39DC66