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

From: "radext issue tracker" <[email-masked]>
Date: Thu, 20 Aug 2015 06:22:05 -0000

#192: unclear meaning of "configured categories" of dynamically discovered
servers

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

 It is unclear to me what such a "category" would be. During the
 discovery pahse, DNS has no leeway to discover maximum packet sizes.
 There is also only one service and protocol tag. It remains unclear to
 me how different groups of discovered servers could be put into distinct
 categories. If the use of distinct, and non-standard service and
 protocol tags is the vehicle to do this, this should be stated
 explicitly in the document.

 Maybe it would help to require a Status-Server negotiation as per
 section 3.2 as first packet exchange on newly established dynamic
 discovery TCP streams? This would obsolete the concept of configured
 categories.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  [email-masked]           |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  bigger-packets           |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/radext/trac/ticket/192>
radext <http://tools.ietf.org/radext/>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Aug 2015 10:15:53 -0400

>>>>> "radext" == radext issue tracker <[email-masked]> writes:

    radext> #192: unclear meaning of "configured categories" of
    radext> dynamically discovered servers

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

Well, I'm aware of two categories today:

* servers discovered via the DNS-based experimental document we're
  working on here

* Servers discovered via Project moonshot's Trust Router architecture

There may be more dynamic discovery mechanisms in the future.

Can you suggest text to clarify this?

---

From: Stefan Winter <[email-masked]>
Date: Fri, 21 Aug 2015 09:00:03 +0200

Hi,

> There may be more dynamic discovery mechanisms in the future.

If you put max packet sizes into configuration, and there is one config
item for DNS, and one for Trust Router, then the configuration is very
coarse-grained, like:

"all servers discovered by trust router support bigger packets;
no servers discovered by DNS support bigger packets"

I don't think it's realistic that this coarse-grained grouping maps into
real deployment characteristics.

DNS discovery might lead to some RADIUS/TLS hosts wwhich support
bigger-TCP; some other discovered servers might only support 4096-TCP.

And (probably) the same is true for discovered trust router entities.

> Can you suggest text to clarify this?

I don't think a mere text change for clarification helps here.

I had suggested to change the protocol so that for any dynamically
discovered server, first run a Status-Server discovery to find out about
the supported sizes, and only then commence normal RADIUS traffic. Then
there is no need for configuration at all, and the per-category concept
can go away.

I can suggest text for *that* :-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Aug 2015 09:18:50 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Hi,
    >> * servers discovered via the DNS-based experimental document
    >> we're working on here
    >> 

    Stefan> If you put max packet sizes into configuration, and there is
    Stefan> one config item for DNS, and one for Trust Router, then the
    Stefan> configuration is very coarse-grained, like:

    Stefan> "all servers discovered by trust router support bigger
    Stefan> packets; no servers discovered by DNS support bigger
    Stefan> packets"

    Stefan> I don't think it's realistic that this coarse-grained
    Stefan> grouping maps into real deployment characteristics.

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

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

--Sam