Subject: Re: [radext] Status of extensions document?

From: Peter Deacon <[email-masked]>
Date: Wed, 4 Jan 2012 11:28:01 -0800 (Pacific Standard Time)

On Wed, 21 Dec 2011, Alan DeKok wrote:

>  I haven't seen any comments on the latest draft.

>  There were some typos from Leaf, and IANA comments from Bernard.  Have
> they been addressed to the WGs satisfaction?

>  Having the document move forward would be a wonderful xmas present.

Still have a serious concern with data corruption in long attribute not 
addressed in the latest drafts.

The necessary ordering constraints do not seem to be there in existing 
RFCS to prevent long attributes from being corrupted.  This is important 
since a design goal was to allow attributes to be forwarded by systems not 
supporting this draft.

RFC 2138.3
"   Many Attributes may have multiple instances, in such a case the order
    of Attributes of the same Type SHOULD be preserved.  The order of
    Attributes of different Types is not required to be preserved."

There are two problems with this:

1. SHOULD is not enough.
2. Preserving order is not enough.

To show the problem example below uses two extended flag attributes 'Gear' 
and 'Cog' each of the extended flag attributes are using the same basic 
RADIUS attribute type.

'M' represents More flag set
'.' No flags are set

1. An implementation decides to ignore the advice of RFC 2138 jumbling the 
order of attributes of the same type:

OK:
[Gear M.1][Gear M.2][GEAR .3]

NOT OK:
[Gear M.2][Gear M.1][GEAR .3]

This not only corrupts the data but also corrupts the attributes extended 
type.  This can be dangerous in the wrong hands as the *payload* now has a 
say over the selection of extended type.

If this were a VSA it would corrupt both the vendor id and the vendors 
type.

2. An implementation follows the advice of RFC 2138 to the letter. 
Unfortunately preservation of order does not preclude insertion of Cogs 
into the middle of Gears as the outer RADIUS type is the same for both.

OK:
[Gear M.1][Gear M.2][GEAR .3][Cog .1]

NOT OK:
[Gear M.1][Gear M.2][Cog .1][GEAR .3]

 	- Gear is truncated
 	- Cog is appended to the truncated Gear further corrupting Gear
 	- Cog never appears as an attribute
 	- The *payload* of the last gear fragment determines a corrupt 
extended type (Or Vendor id and vendors type) and whats left over of 
Gear.3's data.. as with the previous example being able to control 
extended type via payload can be dangerous in the wrong hands.

Some ideas for solving the problems:

1. Use reserved field as a counter to allow attribute order to be 
verified.

2. Change the fragment format of extended flag attributes to include the 
inner extended type or vendorid/type fields in subsequent fragments.

3. Add a constraint requiring that at least on the granularity of the same 
outer basic RADIUS type if there are any long attributes which fail to 
fully validate all "successfully" decoded attributes MUST also be treated 
as invalid.

Examples of this would be a case of a counter field in the wrong order or 
an attribute with more flag set without a follow on ending fragment.

Other thoughts..

The system does not have to work with existing implementations that for 
whatever reason are not willing to impose rational ordering of attributes. 
At the same time a failure mode of silent data corruption is not something 
I would expect anyone to be willing to accept.

regards,
Peter
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Peter Deacon <[email-masked]>
Date: Wed, 4 Jan 2012 11:28:01 -0800 (Pacific Standard Time)

RFC 2138.3

1. SHOULD is not enough.

OK:

NOT OK:

OK:

NOT OK:

 	- Gear is truncated

Other thoughts..

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 05 Jan 2012 17:53:59 +0100

Peter Deacon wrote:
> since a design goal was to allow attributes to be forwarded by systems
> not supporting this draft.
..
> 2. Preserving order is not enough.

  I agree with (1).  However, most implementations *do* preserve
ordering.  Maybe the document could be updated to say implementations
MUST preserve ordering.

> This not only corrupts the data but also corrupts the attributes
> extended type.  This can be dangerous in the wrong hands as the
> *payload* now has a say over the selection of extended type.

  Yes.

> into the middle of Gears as the outer RADIUS type is the same for both.

  Hmm... that's allowed, yes.

> 1. Use reserved field as a counter to allow attribute order to be verified.

  A counter would help address, but not prevent the insertion problem.

> inner extended type or vendorid/type fields in subsequent fragments.

  That works, but is less efficient.

> 3. Add a constraint requiring that at least on the granularity of the
> same outer basic RADIUS type if there are any long attributes which fail
> to fully validate all "successfully" decoded attributes MUST also be
> treated as invalid.

  That worries me.

> whatever reason are not willing to impose rational ordering of
> attributes. At the same time a failure mode of silent data corruption is
> not something I would expect anyone to be willing to accept.

  I agree.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 05 Jan 2012 17:53:59 +0100

..

  Yes.

  That worries me.

  I agree.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 10 Jan 2012 12:55:08 +0100

> Still have a serious concern with data corruption in long attribute 
> not addressed in the latest drafts.
>
> RFCS to prevent long attributes from being corrupted.  This is 
> important since a design goal was to allow attributes to be forwarded 
> by systems not supporting this draft.
>
> RFC 2138.3
> To show the problem example below uses two extended flag attributes 
> 'Gear' and 'Cog' each of the extended flag attributes are using the 
> same basic RADIUS attribute type.
>
> 1. An implementation decides to ignore the advice of RFC 2138 jumbling 
> the order of attributes of the same type:
>
> OK:

I'm trying to figure it out why extended types are also corrupted, but I 
don't see a reason. I clearly appreciate how data is corrupted, but 
headers should not be affected. Could you please elaborate this a little 
more or refer me to further information on this topic?

Thanks and best regards,
Alejandro

> Unfortunately preservation of order does not preclude insertion of 
> Cogs into the middle of Gears as the outer RADIUS type is the same for 
> both.
>
> OK:
> 2. Change the fragment format of extended flag attributes to include 
> the inner extended type or vendorid/type fields in subsequent fragments.
>
> same outer basic RADIUS type if there are any long attributes which 
> fail to fully validate all "successfully" decoded attributes MUST also 
> be treated as invalid.
>
> Examples of this would be a case of a counter field in the wrong order 
> or an attribute with more flag set without a follow on ending fragment.
>
> Other thoughts..
>
> The system does not have to work with existing implementations that 
> for whatever reason are not willing to impose rational ordering of 
> attributes. At the same time a failure mode of silent data corruption 
> is not something I would expect anyone to be willing to accept.
>
> regards,
> Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 10 Jan 2012 12:55:08 +0100

Thanks and best regards,
Alejandro

---

From: Peter Deacon <[email-masked]>
Date: Tue, 10 Jan 2012 11:41:21 -0800 (Pacific Standard Time)

> more or refer me to further information on this topic?

Hi Alejandro,

There is a difference in the wire format between initial and 
subsequent fragments of a long attribute (4.5 and 4.6).

The initial format look like this:
Type + Len + ExtType + M + Flags + VID + VType + Value

Subsequent fragments:
Type + Len + ExtType + M + Flags + Values

If order of initial and subsequent fragment is changed system has no 
information preventing 'Value' from being interpreted as 'VID + VType + 
Value'.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Tue, 10 Jan 2012 11:41:21 -0800 (Pacific Standard Time)

Hi Alejandro,

Subsequent fragments:

regards,
Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 11 Jan 2012 09:02:15 +0100

El 10/01/12 20:41, Peter Deacon escribió:
>> I'm trying to figure it out why extended types are also corrupted, 
>> but I don't see a reason. I clearly appreciate how data is corrupted, 
>> but headers should not be affected. Could you please elaborate this a 
>> little more or refer me to further information on this topic?
>
> Hi Alejandro,
>
> information preventing 'Value' from being interpreted as 'VID + VType 
> + Value'.

Hi Peter,

you're right, but it seems that this would only affect to extended 
vendor specific attributes, and not to extended (flag) attributes (3.*). 
Am I right?

Regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 11 Jan 2012 09:02:15 +0100

Hi Peter,

Regards,
Alejandro

---

From: Peter Deacon <[email-masked]>
Date: Wed, 11 Jan 2012 09:17:12 -0800 (Pacific Standard Time)

Hi Alejandro,

Not entirely, TLVs inside of a Value field of a non-VSA extended type can 
suffer the same fate.

This is less of a problem since Value can't escape the non-VSA Extended 
type container.

Solution of making initial + subsequent fragment formats the same does not 
reach into TLVs.  These cases can only be _minimized_ by any machinery 
intended to prevent data corruption.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Wed, 11 Jan 2012 09:17:12 -0800 (Pacific Standard Time)

Hi Alejandro,

regards,
Peter

---

From: Fernando Pereñíguez <[email-masked]>
Date: Wed, 11 Jan 2012 18:49:57 +0100

Hi Peter,

I'm trying to understand the problems you mention regarding the use of extended attributes and the order preservation. Please, see my comments inline. 

> 
> The necessary ordering constraints do not seem to be there in existing RFCS to prevent long attributes from being corrupted.  This is important since a design goal was to allow attributes to be forwarded by systems not supporting this draft.
> 
> RFC 2138.3

I'm a bit confused about the preservation of order of attributes of the same type. Certainly, RFC 2138 does not force the preservation of such order. Nevertheless, in RFC 2865 it is said that:

If multiple Attributes with the same Type are present, the order of
   Attributes with the same Type MUST be preserved by any proxies.

For this reason, so far I've been assuming that order of attributes of the same type must be respected. In fact, the RADIUS extensions makes such assumption with the fragmentation based on bit 'M'. So, my question is: can we assume order preservation of attributes of the same Type or not ?

> 
> To show the problem example below uses two extended flag attributes 'Gear' and 'Cog' each of the extended flag attributes are using the same basic RADIUS attribute type.
> 
> 1. An implementation decides to ignore the advice of RFC 2138 jumbling the order of attributes of the same type:
> 
> OK:
> This not only corrupts the data but also corrupts the attributes extended type.  This can be dangerous in the wrong hands as the *payload* now has a say over the selection of extended type.
> 
> If this were a VSA it would corrupt both the vendor id and the vendors type.
> 

In this case, as mentioned by Alejandro in a previous e-mail, I think the corruption in attribute headers only affects to extended VSA. 

> 2. An implementation follows the advice of RFC 2138 to the letter. Unfortunately preservation of order does not preclude insertion of Cogs into the middle of Gears as the outer RADIUS type is the same for both.
> 
> OK:
> 	- The *payload* of the last gear fragment determines a corrupt extended type (Or Vendor id and vendors type) and whats left over of Gear.3's data.. as with the previous example being able to control extended type via payload can be dangerous in the wrong hands.
> 

In this situation, assuming the order of attributes of the same type is preserved, why [Cog.1] is allowed to be inserted between GEAR fragments 2 and 3 ? This alters the order (examining the outer RADIUS type) of the sequence [Gear M.1][Gear M.2][GEAR .3]. 

Regards,
Fernando.

--- 
------------------------------------------------------
Fernando Pereñíguez García, PhD 
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science, University of Murcia
E-30100, Espinardo, Murcia (Spain)
Phone: +34 868 887882 Fax: +34 868884151 
E-mail: [email-masked]
------------------------------------------------------

---

From: Fernando Pereñíguez <[email-masked]>
Date: Wed, 11 Jan 2012 18:49:57 +0100

Hi Peter,

Regards,
Fernando.

---

---

From: Fernando Pereñíguez <[email-masked]>
Date: Wed, 11 Jan 2012 21:34:07 +0100

Hi Peter,

Thanks for your response. I really appreciated your clarifications.

El 11/01/2012, a las 19:54, Peter Deacon escribió:

> On Wed, 11 Jan 2012, Fernando Pereñíguez wrote:
> 
>> I'm trying to understand the problems you mention regarding the use of
>> extended attributes and the order preservation. Please, see my comments
>> inline.
> 
>> I'm a bit confused about the preservation of order of attributes of the
>> same type. Certainly, RFC 2138 does not force the preservation of such
>> order. Nevertheless, in RFC 2865 it is said that:
> 
>> For this reason, so far I've been assuming that order of attributes of
>> the same type must be respected. In fact, the RADIUS extensions makes
>> such assumption with the fragmentation based on bit 'M'. So, my question
>> is: can we assume order preservation of attributes of the same Type or
>> not ?
> 
> Hi Fernando,
> 
> Lets assume order is universally respected.  What prevents new attributes from being inserted while respecting order of existing attributes?  From other text (below) my impression this is allowed and expected.

Yes, you are right. I was only thinking about order preservation and missing the fact that attributes can be continuous or not. Effectively, the order of a sequence of attributes of the same type is not altered when inserting new attributes. 

> 
> The Gear + Cog example can only fail to detect an error with VSAs when you assume order is respected however this is not end of story.
> 
> A new example with order preserved not using VSAs.. two gears - Gear-A and Gear-B.  Gear-A and Gear-B are instances of the same extended type.
> 
> OK:
> [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2]
> 
> NOT OK:
> [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3]
>                        ^^^^^^^^^^^^^^^^^^^^^^^
> 
> 	- Gear-A is truncated
> 	- Gear-B is lost never appearing as a separate attribute
> 	- Gear-B in its entirety is appended to Gear-A further corrupting Gear-A.
> 	- The last fragment of Gear-A becomes a standalone corrupt attribute of its own.
> 

Since Gear-A and Gear-B are extended attributes, it is obvious that the RADIUS implementation generating and inserting these attributes implements extended attributes. In such case, as stated in the draft, the new type space is formed by "Type.Extended-Type" so the implementation should be able to distinguish that Gear-A and Gear-B are different attributes and, consequently, detect that performing this insertion of [Gear-B M.1] violates the order preservation of Gear-A fragments. Is my understanding correct ?

> 
> We already have EAP bless its heart...
> 
> RFC 2865 5 (June 2000)
> "A RADIUS server or client MUST NOT require attributes of the same type to be contiguous."
> 
> RFC 2869 5.13 (June 2000)
> "If multiple EAP-
>      Messages are contained within an Access-Request or Access-
>      Challenge packet, they MUST be in order and they MUST be
>      consecutive attributes in the Access-Request or Access-Challenge
>      packet."
> 
> I think there are important differences between EAP as an example and extensions.
> 
> 1. If EAP does not work you don't authenticate.  The failure mode does not include silent data corruption / crazy authorization parameters.
> 
> 2. There is only one EAP-Message conduit possible per auth transaction as far as I know.  The scenario I raise above requires two or more to work.

I agree with you that EAP message fragmentation has been specifically designed according to the particularities of EAP. I think a more general fragmentation solution should be designed considering all possible cases. 

> 
>> In this case, as mentioned by Alejandro in a previous e-mail, I think the
>> corruption in attribute headers only affects to extended VSA.
> 
> VSAs outnumber standard attributes by at least 15 to 1.  It is a big deal.

Yes, the problem with extended VSAs exists and the problems in header corruption must be addressed regardless the quantity of defined VSAs :-)

Regards,
Fernando.

---

---

From: Fernando Pereñíguez <[email-masked]>
Date: Wed, 11 Jan 2012 21:34:07 +0100

Hi Peter,

Regards,
Fernando.

---

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 12 Jan 2012 09:47:47 +0100

El 11/01/12 18:17, Peter Deacon escribió:
>>> information preventing 'Value' from being interpreted as 'VID + 
>>> VType + Value'.
>
>> Hi Peter,
>> vendor specific attributes, and not to extended (flag) attributes 
>> (3.*). Am I right?
>
> Hi Alejandro,
>
> Not entirely, TLVs inside of a Value field of a non-VSA extended type 
> can suffer the same fate.
>
> This is less of a problem since Value can't escape the non-VSA 
> Extended type container.
>
> Solution of making initial + subsequent fragment formats the same does 
> not reach into TLVs.  These cases can only be _minimized_ by any 
> machinery intended to prevent data corruption.

Hi Peter,

well, but data corruption is always possible. Any proxy in the path 
could change a header byte, for example, and mess all up.

IMHO, it would be simpler to adopt the RADIUS EAP position. RFC 3579 states:

    If multiple
    EAP-Message attributes are contained within an Access-Request or
    Access-Challenge packet, they MUST be in order and they MUST be
    consecutive attributes in the Access-Request or Access-Challenge
    packet.

So, Alan's draft could say something similar:

    If multiple
    fragments of the same attribute are contained within an
    Access-Request or
    Access-Challenge packet, they MUST be in order and they MUST be
    consecutive attributes in the Access-Request or Access-Challenge
    packet. 

I think RADIUS EAP has been accepted and deployed enough to agree that 
is a viable solution.

What if a RADIUS server decides to omit this recommendation anyway? It 
should be managed the same way as RADIUS EAP does: let the upper layer 
application (e.g. EAP stack) to detect the error, not RADIUS.

If you re-order the attributes, most probably the result would not make 
sense at all (TLV length will not match with the actual one, RADIUS 
packet length will be invalid, checksum will fail...), and thus it will 
be detected.

Am I assuming something wrong?

Best regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 12 Jan 2012 09:47:47 +0100

Hi Peter,

    If multiple

    If multiple

Best regards,
Alejandro

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Jan 2012 09:54:20 +0100

> So, Alan's draft could say something similar:

  It does.  See page 11:

      ... When the More
      flag is set (1), the attribute SHOULD have a Length field of value
      255; it MUST NOT have a length Field of value 4; there MUST be an
      attribute following this one; and the next attribute MUST have
      both the same Type and Extended Type.  That is, multiple fragments
      of the same value MUST be in order and MUST be consecutive
      attributes in the packet, and the last attribute in a packet MUST
      NOT have the More flag set (1).

> application (e.g. EAP stack) to detect the error, not RADIUS.

  Any upper layer will likely detect malformed content, and ignore it.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Jan 2012 09:54:20 +0100

It does.  See page 11:

      ... When the More

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 11 Jan 2012 13:52:17 -0800 (Pacific Standard Time)

> Since Gear-A and Gear-B are extended attributes, it is obvious that the 
> RADIUS implementation generating and inserting these attributes 
> implements extended attributes. In such case, as stated in the draft, 
> the new type space is formed by "Type.Extended-Type" so the 
> implementation should be able to distinguish that Gear-A and Gear-B are 
> different attributes and, consequently, detect that performing this 
> insertion of [Gear-B M.1] violates the order preservation of Gear-A 
> fragments. Is my understanding correct ?

Hi Fernando,

If all systems in the chain support extended types there should be no room 
for excuses when it comes to mangling attributes.

An example of a problem are proxy systems inserting blobs on behalf of a 
mgmt station.  Proxy server does not necessarily need to understand 
attributes in order to apply policy and forward messages.  One of the 
goals is reasonable level of interop with systems not supporting extended 
attributes.

In the real world is this a problem?  What is the risk?  I don't have an 
answer.  The only thing I know for sure there are a huge number of 
sometimes ancient implementations out there.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Wed, 11 Jan 2012 10:54:39 -0800 (Pacific Standard Time)

Hi Fernando,

Lets assume order is universally respected.  What prevents new attributes 
from being inserted while respecting order of existing attributes?  From 
other text (below) my impression this is allowed and expected.

The Gear + Cog example can only fail to detect an error with VSAs when you 
assume order is respected however this is not end of story.

A new example with order preserved not using VSAs.. two gears - Gear-A and 
Gear-B.  Gear-A and Gear-B are instances of the same extended type.

OK:

NOT OK:

 	- Gear-A is truncated
 	- Gear-B is lost never appearing as a separate attribute
 	- Gear-B in its entirety is appended to Gear-A further corrupting 
Gear-A.
 	- The last fragment of Gear-A becomes a standalone 
corrupt attribute of its own.

RFC 2865 5 (June 2000)
"A RADIUS server or client MUST NOT require attributes of the same type to 
be contiguous."

I think there are important differences between EAP as an example and 
extensions.

1. If EAP does not work you don't authenticate.  The failure mode does not 
include silent data corruption / crazy authorization parameters.

2. There is only one EAP-Message conduit possible per auth transaction as 
far as I know.  The scenario I raise above requires two or more to work.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Wed, 11 Jan 2012 13:52:17 -0800 (Pacific Standard Time)

Hi Fernando,

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Wed, 11 Jan 2012 10:54:39 -0800 (Pacific Standard Time)

Hi Fernando,

OK:

NOT OK:

 	- Gear-A is truncated

RFC 2865 5 (June 2000)

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Jan 2012 12:25:51 +0100

Peter Deacon wrote:
> Lets assume order is universally respected.  What prevents new
> attributes from being inserted while respecting order of existing
> attributes?  From other text (below) my impression this is allowed and
> expected.

  Allowed, yes.  I'm less sure if it's expected, or widely used.

> "A RADIUS server or client MUST NOT require attributes of the same type

  I had forgotten about that.  I should update the extensions document
to specifically reference this, and over-ride it.

  From what I've seen, most proxy implementations ensure that attributes
of the same type can *remain* contiguous.  This goes back to 1999, the
Merit server (IIRC).

  Do you have a proposed change to the extensions document which fixes
this issue?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Jan 2012 12:25:51 +0100

Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 12 Jan 2012 12:41:58 +0100

> The Gear + Cog example can only fail to detect an error with VSAs when 
> you assume order is respected however this is not end of story.
>
> A new example with order preserved not using VSAs.. two gears - Gear-A 
> and Gear-B.  Gear-A and Gear-B are instances of the same extended type.
>
> OK:

I did not get this one. If order is preserved, Gear-B would never be 
moved between Gear-A attributes. As Gear-A and Gear-B are instances of 
the same extended type, order would be preserver within the 5 of them.

Best regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 12 Jan 2012 12:41:58 +0100

Best regards,
Alejandro

---

From: Peter Deacon <[email-masked]>
Date: Thu, 12 Jan 2012 11:25:20 -0800 (Pacific Standard Time)

On Thu, 12 Jan 2012, Alejandro Perez Mendez wrote:

> well, but data corruption is always possible. Any proxy in the path could
> change a header byte, for example, and mess all up.

Hi Alejandro,

We have a reasonable chance to mitigate this specific possibility for 
error at low low Internet draft discount rate.  Solution could be as 
simple as a counter field.  No heavy machinery required.

> I think RADIUS EAP has been accepted and deployed enough to agree that is
> a viable solution.

> application (e.g. EAP stack) to detect the error, not RADIUS.

This assumes attributes have their own upper layer error detection scheme 
to facilitate error detection.  I can't think of any Authorization or 
Accounting attributes that do.  I can't think of any EAP methods by their 
nature which do not.

In the absence of upper layer error detection lower layers are best 
positioned to ensure ensure valid data.

As mentioned earlier have to be careful about using EAP for comparison. 
There is only one EAP conversation allowed per RADIUS message.  Extended 
attributes allows multiple long attributes.

> Am I assuming something wrong?

If you reorder/mix long attributes carrying ACLs the most probable result 
will be an angry user or more seriously an angry operator.

We can disagree on the likelihood of the problem occurring and therefore 
what should be done about it.

Beyond this if it is agreed there is a reasonable chance of the problem 
occurring then something must be done.  Dice rolling and upper layer 
punting is not something I expect operators are willing to accept.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Thu, 12 Jan 2012 11:25:20 -0800 (Pacific Standard Time)

Hi Alejandro,

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Thu, 12 Jan 2012 11:34:11 -0800 (Pacific Standard Time)

> I did not get this one. If order is preserved, Gear-B would never be moved 
> between Gear-A attributes. As Gear-A and Gear-B are instances of the same 
> extended type, order would be preserver within the 5 of them.

Hi Alejandro,

Gear-B is being added to an existing RADIUS message containing only Gear-A 
attributes.

OK example is when Gear-B is appended to the end.

NOT OK is when Gear-B is inserted in the middle of Gear-A.

Note elements of Gear-A retain their ordering in the NOT OK example which 
is all that is required by existing RFCs.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Thu, 12 Jan 2012 11:34:11 -0800 (Pacific Standard Time)

Hi Alejandro,

regards,
Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 13 Jan 2012 08:51:48 +0100

El 12/01/12 20:25, Peter Deacon escribió:
>> could

Hi Peter

> simple as a counter field.  No heavy machinery required.

Yes, you are right.

> This assumes attributes have their own upper layer error detection 
> scheme to facilitate error detection.  I can't think of any 
> Authorization or Accounting attributes that do.  I can't think of any 
> EAP methods by their nature which do not.

I was thinking on an attribute representing a SAML message 
(http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-02). If fragments 
are reordered, most likely resulting XML will not be valid. Moreover, if 
signature is being used, the chance of error detection is 100%. But I 
can see this is not the most usual case.

> positioned to ensure ensure valid data.

Agree.

>
> As mentioned earlier have to be careful about using EAP for 
> comparison. There is only one EAP conversation allowed per RADIUS 
> message.  Extended attributes allows multiple long attributes.

Right.

> If you reorder/mix long attributes carrying ACLs the most probable 
> result will be an angry user or more seriously an angry operator.
>
> We can disagree on the likelihood of the problem occurring and 
> therefore what should be done about it.
>
> Beyond this if it is agreed there is a reasonable chance of the 
> problem occurring then something must be done.  Dice rolling and upper 
> layer punting is not something I expect operators are willing to accept.

You're right.

Thanks for the clarifications and best regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 13 Jan 2012 08:51:48 +0100

Hi Peter

Yes, you are right.

Agree.

Right.

You're right.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 13 Jan 2012 08:56:08 +0100

El 12/01/12 20:34, Peter Deacon escribió:
>>> attributes?  From other text (below) my impression this is allowed 
>>> and expected.
>
>>> The Gear + Cog example can only fail to detect an error with VSAs 
>>> when you assume order is respected however this is not end of story.
>
>>> A new example with order preserved not using VSAs.. two gears - 
>>> Gear-A and Gear-B.  Gear-A and Gear-B are instances of the same 
>>> extended type.
>
>>> OK:
>> moved between Gear-A attributes. As Gear-A and Gear-B are instances 
>> of the same extended type, order would be preserver within the 5 of 
>> them.
>
> Hi Alejandro,
>
> Gear-B is being added to an existing RADIUS message containing only 
> Gear-A attributes.
>
> Note elements of Gear-A retain their ordering in the NOT OK example 
> which is all that is required by existing RFCs.

hi Peter,

I was thinking that the RADIUS server was re-ordering already included 
attributes. Now I see the Gear-B attributes are included afterwards, and 
I understand the problem perfectly.

Best regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 13 Jan 2012 08:56:08 +0100

hi Peter,

Best regards,
Alejandro