Re: [radext] Issue with draft-ietf-radext-radius-fragmentation, pre-authorization phase and authentication attributes.

[Stefan Winter <[e-mail]>]

Hi,

> However, in draft-ietf-radext-radius-fragmentation, the first chunk of
> the pre-authorization phase may not contain any of these attributes,
> as it would depend on the type of the attributes being transported, as
> well as the specific distribution of these attributes along the
> different chunks. This issue would be circumscribed to this first
> chunk, as the rest will contain a State attribute, accepted by RFC 2865.
>
> draft-ietf-radext-radius-fragmentation already states that compliant
> servers will postpone all authorization and authentication handling
> until all of the chunks have been received. We have added (for version
> 04, that will be uploaded next Monday when the submission process
> reopen) some lines clarifying that this postponement also includes
> disabling the verification of the inclusion of authentication
> attributes until the original large packet has been rebuilt. Hence,
> any server implementing draft-ietf-radext-radius-fragmentation would
> not fail if the first chunk does not contain any authentication
> attribute.
>
> We expect that proxies will not drop these packets either, as
> otherwise they will be precluding any future extension foreseen by RFC
> 2865.

Which they are allowed to do. It's very arguable whether a proxy should
police this particular RFC constraint at all; but if it does, the
fragmentation process will be permanently DoSed.

> In our opinion, these lines are sufficient to overcome RFC2865's
> restriction. However, if the WG members think they are not, then we
> might need to include some kind of phony authentication attribute on
> this first chunk, just to make it compliant with what it would be
> generally expected. For example, an empty EAP-Message attribute
> (called EAP-Start in RFC 3579), or a phony CHAP-Password.

I would be against phony authentication attributes - especially since
the frag draft is very explicitly stating that it does not do any
authentication at all. Omitting authentication attributes makes it easy
to spot that this is an authorization exchange; adding a "CHAP-Password"
makes it unnecessarily hard.

I don't understand yet what the issue is that prevents adding a phony
*State* though. Couldn't you just state that a first-fragment gets two
new attributes? One being Frag-Status; the other one being a State
attribute which could be a fixed 0x0 (or allow arbitrary values and
simply discard server-side).

State shouldn't be in the original Access-Request before splitting
(because State is used in echoing a *server's* State attribute back, and
has no reason for existence in the first Access-Request); so if you add
one together with Frag-Status, it would be the only one; so there should
be no ambiguity...

Greetings,

Stefan Winter