Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06

From: Alan DeKok <[email-masked]>
Date: Mon, 02 Sep 2013 11:13:47 -0400

Peter Deacon wrote:
> Proposed 'T' bit in extended long attributes means existing systems
> supporting extended attributes may require enhancement to pass needed
> data.  Despite 'SHOULD' language from RFC6929 I do not believe it
> reasonable expectation proxy systems able to understand an attribute
> known to be broke would elect to forward such an attribute anyway.

  The draft authors had a conference call this morning about this, and
other issues.

  RFC 6929 Section 5.2 says:

   This practice is NOT RECOMMENDED.  Proxy servers SHOULD forward
   attributes, even attributes that they do not understand or that are
   not in a local dictionary.  When forwarded, these attributes SHOULD
   be sent verbatim, with no modifications or changes.  This requirement
   includes "invalid attributes", as there may be some other system in
   the network that understands them.

  I believe that this text directly addresses the "T" bit, and the
possibility of fragmenting attributes across multiple packets.  You say
that it's not reasonable to expect a proxy to forward such an attribute.
 You haven't given any reason for that opinion.

  Until we have such discussion, we have real-world data from Eduroam,
among other examples.  There have been real-world issues with proxies
receiving attributes they don't understand, or think are malformed.
Some proxies would then discard the packets or offending attributes.

  This misbehavior caused real-world deployment problems.  The solution
was to ensure that all proxies forwarded these attributes, even if they
didn't understand them.

  In conclusion, I believe we're safe in adding the "T" bit in the
fragmentation draft.  Implementations compliant with 6929 will ignore
the "T" bit, but SHOULD still forward the attributes they believe are
malformed (when the T bit is set)

  If you're saying that your implementation discards these attributes, I
would suggest that your implementation is incompatible with new
standards, and existing deployments.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 2 Sep 2013 10:42:53 -0700 (Pacific Daylight Time)

> You haven't given any reason for that opinion.

Yep, it sure is what I was referring to by "'SHOULD' language".

Seems like a fairly common and obvious security 101 precaution in our (my) 
space you just don't forward what you know to be broke especially where it 
involves authentication/authorization parameters.  I see no reason at all 
to allow such behavior to take place.

> was to ensure that all proxies forwarded these attributes, even if they

There are two issues which seem to be embedded in the above.

1. Forwarding of attributes you don't understand.

2. Incursions into standard space by vendor "A" and others.

Regarding #1

My opinion there certainly is value in administrative configuration 
allowing forwarding of unknown attributes.  I encourage all vendors to 
provide such an option to their customers.

Whether this is done or not seems to be orthogonal to the issue of 
rejecting a known attribute you know to be malformed.

Regarding #2

As far as I'm concerned this is ancient history, has been for years and
irrelevant in 2013.  Capitulating to an environment where nobody can be 
sure what an attribute even means is unacceptable.

Some attribute dictionaries have long memories and are quite easily 
changed.

As with #1 the underlying issue seems to be orthogonal.  With this issue 
the conflict is invoked by systems not agreeing on attribute "type". In 
case of fragment draft "type" is not in question.  The problem here a 
type's format has been changed retroactively in an incompatible manner.

I do not support use of above as "cover" to justify incompatible 
retroactive changes.

My recommendation going forward is to find an alternative option which 
does not depend on incompatible M flag behavior.

One option in the definition of any long attributes to convey eduroam/SAML 
data specify how partial content should be handled and allocate new flags 
to effect inter-packet continuation without changing existing behavior.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 02 Sep 2013 16:23:26 -0400

Peter Deacon wrote:
> Seems like a fairly common and obvious security 101 precaution in our
> (my) space you just don't forward what you know to be broke especially
> where it involves authentication/authorization parameters.  I see no
> reason at all to allow such behavior to take place.

  As I've said before, that attitude could prevent *any* new
functionality from being deployed.

  Some proxy implementations discarded any attributes which were not in
the local dictionary.  This idiocy isn't forbidden by the previous RFCs,
but is finally discouraged by 6929.  It prevents *any* changes to
RADIUS, which is madness.

> rejecting a known attribute you know to be malformed.

  No.  A known attribute which uses fields that had previously been
marked "reserved".  And even if it is malformed, there are ways to deal
with it.

> irrelevant in 2013.

  No.  Vendors still ship equipment which poaches on the standard space.
 Deployments still rely on those attributes.  Eduroam was running into
issues with these attributes in the recent past.  With widely-used,
in-support commercial RADIUS servers.

> type's format has been changed retroactively in an incompatible manner.

  I disagree, for reasons I've stated.

> One option in the definition of any long attributes to convey
> eduroam/SAML data specify how partial content should be handled and
> allocate new flags to effect inter-packet continuation without changing
> existing behavior.

  Where would those "new flags" exist?  In a new attribute format?

  Creating a brand-new incompatible standard isn't a solution to another
(allegedly) incompatible standard.

  For me, it's a simple principle.  Proxies have NO BUSINESS mucking
around with attributes they don't understand.  If the RADIUS packet is
well formed, the attributes (understood or not) should be sent onwards.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 2 Sep 2013 18:33:38 -0700 (Pacific Daylight Time)

> marked "reserved".  And even if it is malformed, there are ways to deal

To be clear the issue is not allocation of reserved fields it is M bit set 
where RFC6929 requires it not be.

> in-support commercial RADIUS servers.

Which vendors still use 241-246?

>  Where would those "new flags" exist?  In a new attribute format?

Allocation of reserved bits from RFC6929.

> well formed, the attributes (understood or not) should be sent onwards.

In this case lack of knowledge is NOT the problem.  The problem is proxies 
KNOWING something is WRONG and being expected to look the other way and 
forward the information on anyway.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 02 Sep 2013 22:18:49 -0400

Peter Deacon wrote:
> To be clear the issue is not allocation of reserved fields it is M bit
> set where RFC6929 requires it not be.

  OK.

> Which vendors still use 241-246?

  Large ones.  The functionality is disabled by default, but is still in
many products.  I deal with this all of the time.

> Allocation of reserved bits from RFC6929.

  Which suggests the question: how do we ever extend 6929 to use the
reserved bits?

> In this case lack of knowledge is NOT the problem.  The problem is
> proxies KNOWING something is WRONG and being expected to look the other
> way and forward the information on anyway.

  Yes.  That's EXACTLY what proxies should be doing.  Anything else
causes a disaster.

  I explained why I have my opinion, using real-world examples.  Your
counter-argument is to re-state that this is a problem.

  You don't dispute my examples, and you don't offer a counter-argument
to them.  I can only conclude that you're disagreeing because of some
un-named fear.

  Alan DeKok.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 03 Sep 2013 16:09:00 +0000

Hi,

> to them.  I can only conclude that you're disagreeing because of some

As I see it, there is a clear rule for proxy behavior with respect to this: Proxies have to behave in the most transparent possible way because they are simply relays for the communication. Validations (for security, semantics or whatever else) should occur only E2E. If you want to have a middlebox that breaks E2E validation for whatever the reason (as much legitimate as it can be) don't claim it to be a proxy.

In brief: Hop-by-hop security MUST be checked at each proxy, of course. But E2E security MUST NOT be checked at a proxy.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Peter Deacon <[email-masked]>
Date: Tue, 3 Sep 2013 10:37:07 -0700 (Pacific Daylight Time)

On Tue, 3 Sep 2013, Diego R. Lopez wrote:

> As I see it, there is a clear rule for proxy behavior with respect to 
> this: Proxies have to behave in the most transparent possible way 
> because they are simply relays for the communication. Validations (for 
> security, semantics or whatever else) should occur only E2E. If you want

While I appreciate many here are working on behalf of a specific network 
assumptions made above are not universal.

For example consider a roaming network enforcing data filtering rules for 
all participants.  It may check authorization parameters and inject 
additional rules to meet networks policy objectives if home authentication 
server has neglected to enforce agreed upon policy.

> to have a middlebox that breaks E2E validation for whatever the reason 
> (as much legitimate as it can be) don't claim it to be a proxy.

In this specific case the problem is 'M' bit in long extended type is set 
where RFC6929 says it ought not to be.  As any logical attribute can be 
conveyed the purpose "E2E" or otherwise does not seem to be knowable in 
advance.

> In brief: Hop-by-hop security MUST be checked at each proxy, of course. 
> But E2E security MUST NOT be checked at a proxy.

As stipulated when I originally responded to call for adoption my 
objections to this draft only apply when scope is not narrowed to where 
authors intend to use it. (e.g. Eduroam)

I don't support the above sentence with HOP/E2E/MUST/MUST NOT language in 
the general context although it may seem perfectly reasonable in the 
context of your network.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 03 Sep 2013 16:47:02 -0400

Peter Deacon wrote:
> For example consider a roaming network enforcing data filtering rules
> for all participants.  It may check authorization parameters and inject
> additional rules to meet networks policy objectives if home
> authentication server has neglected to enforce agreed upon policy.

  i.e. that proxy is largely *terminating* the authorization parameters,
and injecting new ones.

  I used to work at a roaming company where we did exactly that, so I'm
aware of the use-case.  I think the fragmentation draft needs to support
the use-case, too.

> In this specific case the problem is 'M' bit in long extended type is
> set where RFC6929 says it ought not to be.  As any logical attribute can
> be conveyed the purpose "E2E" or otherwise does not seem to be knowable
> in advance.

  The intention of the client is to convey the authorization data to the
home server.  That seems a fairly clear E2E purpose to me.

> authors intend to use it. (e.g. Eduroam)

  The draft can be useful outside of that context.  My suggestion allows
it to be used in a roaming context like you suggest.

  I see the objections as being largely artificial in nature.  If a
client needs to use the draft inside of a roaming consortium, it can:

   a) send the data, and proxies won't filter / modify it

   b) ask the proxies to upgrade to support the draft, at which point
      they can filter / modify the fragmented data.

  Both options are workable.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Sep 2013 18:48:06 -0400

>>>>> "Jouni" == Jouni Korhonen <[email-masked]> writes:

    Jouni> Folks,

    Jouni> We will take draft-perez-radext-radius-fragmentation-06 as
    Jouni> the _basis_ for the WG solution

Hi.
I'd be happy if you reword that sentence as "_a_ _basis_ for _a_ WG
solution."

I think there was significant support for the idea that this draft alone
is insufficient and that we want to revisit the RADIUS message size over
TCP.
I do not believe the discussion supports the idea that this draft will
be a singular solution.
So, I'd ask the chairs to clarify.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Wed, 04 Sep 2013 08:10:35 -0400

> is insufficient and that we want to revisit the RADIUS message size over

  I agree.

> I do not believe the discussion supports the idea that this draft will

  The discussion at the last IETF showed this.  There is wide-spread
support for large packets over TCP.

  From what I can see, the only issue with large packets is negotiation.
 How does each end know that the other supports large packets?

  Once that problem is solve, the rest of the draft is simple.  I don't
think that there are many other side effects of allowing large packets.

  Alan DeKok.