Subject: Re: [radext] Questions about draft-ietf-radext-bigger-packets-03

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2015 11:20:11 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> On Aug 20, 2015, at 2:13 AM, Stefan Winter <[email-masked]> wrote:
    >> Another example which makes assumptions is that closure of a TCP
    >> session when sending a big packet is taken as an indicator for
    >> non-support of this specification. There are many other reasons
    >> why the TCP session might go down (firewall state
    >> timeouts...). The client would unjustifiedly reduce its
    >> transmission size for ... how long? Eternity?  That would mean a
    >> permanent loss of the big-packets feature. As a suggestion: the
    >> Rationale section already has a better mechanism - after TCP
    >> closure, start the next TCP session with the Status-Server
    >> max-size discovery. It might be an idea to mandate this after
    >> every TCP closure which occurs for reasons where a doubt exists -
    >> not only for high-volume servers.

    Alan>   Explicit signalling sounds good to me.

I don't support a stronger recommendation for explicit signaling than is
present in the draft.

My rationale is that explicit signaling is very heavy weight for
client-side libraries.
This is particularly true in cases where it's not clear that you have
anything to do  if your request fails.
If what you're going to do is return some error code if you get a
premature close, and sometimes you get the wrong error code--request too
big instead of firewall timeout--I'm reasonably happy.

I do agree that the more your implementation does, the more explicit
discovery makes sense.

    >> So, how does the group feel about recognising that backward
    >> compatibility problems are something that should be evaluated in
    >> this experiment? I could imagine a text like
    >> 
    >> OLD: "However, this specification introduces no new experimental
    >> evaluation criteria beyond those in the base TCP specification;
    >> this specification can be evaluated along with that one for
    >> advancement on the standards track."
    >> 
    >> NEW: "This specification introduces backward compatibility issues
    >> with implementations of RFC6613 which do not support this
    >> experiment, and with proxies which need to proxy an incoming
    >> large packet to a size-constrained RFC2865 transport RADIUS
    >> server. The real-life consequences of this lack of backward
    >> compatibility are to be studied in and evaluated during the
    >> assessment of this experiment before the features are sent to
    >> Standards Track."

    Alan>   Sounds good.

I also don't support this.
TCP and DRADSEC in general don't have huge deployment and  are
experimental.
I'd rather see us be fairly liberal in our ability to fix them/improve
them as we move from experimental to PS, rather than carry on
backward-compatibility baggage for a long time.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Sep 2015 12:05:32 -0400

> My rationale is that explicit signaling is very heavy weight for

  I would support a SHOULD for explicit signalling, especially for proxies.  Failing that, the client SHOULD do signalling at least once, and then cache the results for some time.

  The alternative is clients trying large packets, failing, opening a new connection, trying large packets, failing, ad infinitum.

  I've seen clients do the most brain-damaged things in the interest of "simplicity".  I'm therefore in favour of trying to raise the bar on clients, even a little bit.

  And realistically, it's 2015.  The RADIUS client machines available today have more CPU /  RAM than RADIUS servers from 15 years ago.

> big instead of firewall timeout--I'm reasonably happy.

  OK.

> I do agree that the more your implementation does, the more explicit

  So RADIUS proxies should generally be smarter about discovery / caching.  i..e. if they're continually talking to a home server, there's no need to discovery on new TCP connections.  The home server capabilities can be cached for the lifetime of the home server.

  But if the home server goes down, the proxy SHOULD do discovery, just in case the home server changed.

> TCP and DRADSEC in general don't have huge deployment and  are

  I agree with that statement.

> backward-compatibility baggage for a long time.

  I think at the minimum, adding the text about RFC 2865 home servers is useful.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2015 12:07:52 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> On Sep 21, 2015, at 11:20 AM, Sam Hartman
    Alan> <[email-masked]> wrote:
    >> I don't support a stronger recommendation for explicit signaling
    >> than is present in the draft.
    >> 

    Alan>   I would support a SHOULD for explicit signalling, especially
    Alan> for proxies.  Failing that, the client SHOULD do signalling at
    Alan> least once, and then cache the results for some time.

I think there's already a SHOULD for explicit signaling.