Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 04 Jan 2012 10:34:01 +0100

FYI.

This motivation of this document comes from the necessity in the ABFAB 
WG of sending SAML Messages transported into RADIUS attributes. These 
SAML Messages can potentially be bigger than 4 KB, thus a mechanism to 
fragment them is required.

-------- Mensaje original --------
Asunto: 	New Version Notification for 
draft-perez-radext-radius-fragmentation-00.txt
Fecha: 	Wed, 04 Jan 2012 01:21:53 -0800
De: 	[email-masked]
Para: 	[email-masked]

A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
    This document describes a mechanism providing fragmentation support
    of RADIUS attributes across several RADIUS packets.  This is intended
    to support attributes that exceed the 4 KB limit per RADIUS packet.

The IETF Secretariat

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 04 Jan 2012 10:34:01 +0100

FYI.

-------- Mensaje original --------

Abstract:

The IETF Secretariat

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 04 Jan 2012 09:19:14 -0500

> fragment them is required.

  My $0.02 after a quick read, this stood out:

---
Chunked-Attribute attribute.

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type (TBA)  |  Length       |      Ext-Type                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Total-Attribute-Length      |     Start-Position            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          End-Position         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
   Ext-Type

      Type of the attribute that is being chunked.  This field is
      encoded as an Ext-Type value, as described in
      [I-D.ietf-radext-extended-attributes], to be compatible with
      extended attributes.
----

  That won't work.  The type/ext-type is used to uniquely identify an
attribute.  As the RFC6158 says, the interpretation of the attribute is
based solely on the type code(s).  What you're doing above is changing
the meaning of the attribute based on its length.

  That's difficult, if not impossible, to do correctly.

  Attributes can also occur multiple times in a packet, with different
values.  e.g. Proxy-State.  The chunked encoding method should support
that, too.

  Perhaps another solution would be to leverage the "flags" field.  If a
particular bit is 1, then the attribute contains 4 32-bit fields
immediately after the "flags" field:

	identifier	for this attribute.  Allows multi-values
	total length	of the fragments with "identifier"
	start		as per above
	end		as per above

  If this document is published soon after the extensions document, then
it has a better likelihood of being implemented.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 04 Jan 2012 09:19:14 -0500

---

                            1                   2                   3

  Alan DeKok.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 04 Jan 2012 19:21:02 +0100

Hi Alan,

>  That's difficult, if not impossible, to do correctly.

I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containing chunks of attributes, as many as attributes they refer to. Chunks are intended to be encoded following the usual encoding methods.

It is true that the layout and the field names used in it are misleading (instead of "Ext-Type" we should call it "Type-ID" or "Attribute-ID" or something similar), and you are right in that the way of specifying this identifier should be better aligned with the way of coding types and extended types.

> values.  e.g. Proxy-State.

You are right. That should be addressed. A simple proposal could follow these rules:

* Chunked-Attribute must appear before the attribute it refers to in the packet

* If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are allowed in a given packet

* Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it

* As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary.

> it has a better likelihood of being implemented.

Good point!

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

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: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 04 Jan 2012 19:21:02 +0100

Hi Alan,

Good point!

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jan 2012 11:52:20 -0800

RFC 6158 Section 3.1 lays out the potential alternatives for solving this problem.  An example of
approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which enable EAP frames
larger than the MTU to be split across RADIUS packets.  This would not necessarily require a
change to the attribute format, just a mechanism that would define a SAML encapsulation handling
fragmentation/reassembly, as EAP methods such as EAP-TLS do.  After all, the EAP-Method
attribute did not require definition of a new data type or attribute format. 

Approach #2 could involve using a URL to enable retrieval of SAML out-of-band.  This approach 
has been used with other protocols encountering fragmentation issues, such as IKE,  and has worked
well. 

Approach #3 cannot be guaranteed to work in all circumstances, so that it needs to be used
alongside approaches #1 or #2. 

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process RADIUS
   packets larger than 4096 octets.

   Even when packets are less than 4096 octets, they may be larger than
   the Path Maximum Transmission Unit (PMTU).  Any packet larger than
   the PMTU will be fragmented, making communications more brittle as
   firewalls and filtering devices often discard fragments.  Transport
   of fragmented UDP packets appears to be a poorly tested code path on
   network devices.  Some devices appear to be incapable of transporting
   fragmented UDP packets, making it difficult to deploy RADIUS in a
   network where those devices are deployed.  We RECOMMEND that RADIUS
   messages be kept as small possible.

   If a situation is envisaged where it may be necessary to carry
   authentication, authorization, or accounting data in a packet larger
   than 4096 octets, then one of the following approaches is
   RECOMMENDED:

      1.  Utilization of a sequence of packets.
          For RADIUS authentication, a sequence of Access-
          Request/Access-Challenge packets would be used.  For this to
          be feasible, attribute designers need to enable inclusion of
          attributes that can consume considerable space within Access-
          Challenge packets.  To maintain compatibility with existing
          NASes, either the use of Access-Challenge packets needs to be
          permissible (as with RADIUS/EAP, defined in [RFC3579]) or
          support for receipt of an Access-Challenge needs to be
          indicated by the NAS (as in RADIUS Location [RFC5580]).  Also,
          the specification needs to clearly describe how attribute
          splitting is to be signaled and how attributes included within
          the sequence are to be interpreted, without requiring stateful
          operation.  Unfortunately, previous specifications have not
          always exhibited the required foresight.  For example, even
          though very large filter rules are conceivable, the NAS-
          Filter-Rule Attribute defined in [RFC4849] is not permitted in
          an Access-Challenge packet, nor is a mechanism specified to
          allow a set of NAS-Filter-Rule Attributes to be split across
          an Access-Request/Access-Challenge sequence.

          In the case of RADIUS accounting, transporting large amounts
          of data would require a sequence of Accounting-Request
          packets.  This is a non-trivial change to RADIUS, since RADIUS
          accounting clients would need to be modified to split the
          attribute stream across multiple Accounting-Requests, and
          billing servers would need to be modified to reassemble and
          interpret the attribute stream.

      2.  Utilization of names rather than values.
          Where an attribute relates to a policy that could conceivably
          be pre-provisioned on the NAS, then the name of the pre-
          provisioned policy can be transmitted in an attribute rather
          than the policy itself, which could be quite large.  An
          example of this is the Filter-Id Attribute defined in
          [RFC2865], Section 5.11, which enables a set of pre-
          provisioned filter rules to be referenced by name.

      3.  Utilization of Packetization Layer Path MTU Discovery
          techniques, as specified in [RFC4821].
          As a last resort, where the above techniques cannot be made to
          work, it may be possible to apply the techniques described in
          [RFC4821] to discover the maximum supported RADIUS packet size
          on the path between a RADIUS client and a home server.  While
          such an approach can avoid the complexity of utilization of a
          sequence of packets, dynamic discovery is likely to be time
          consuming and cannot be guaranteed to work with existing
          RADIUS implementations.  As a result, this technique is not
          generally applicable.

Date: Wed, 4 Jan 2012 10:34:01 +0100
From: [email-masked]
To: [email-masked]
Subject: [radext] Fwd: New Version Notification for	draft-perez-radext-radius-fragmentation-00.txt

    

    FYI. 

    This motivation of this document comes from the necessity in the
    ABFAB WG of sending SAML Messages transported into RADIUS
    attributes. These SAML Messages can potentially be bigger than 4 KB,
    thus a mechanism to fragment them is required.

    -------- Mensaje original --------

          Asunto: 
          New Version Notification for
            draft-perez-radext-radius-fragmentation-00.txt

          Fecha: 
          Wed, 04 Jan 2012 01:21:53 -0800

          De: 
          [email-masked]

          Para: 
          [email-masked]

Abstract:

The IETF Secretariat

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jan 2012 11:52:20 -0800

FYI. 

    -------- Mensaje original --------

          Asunto: 

          Fecha: 

          De: 
          [email-masked]

          Para: 
          [email-masked]

Abstract:

The IETF Secretariat

---

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

Hi Alan, Diego,

> It is true that the layout and the field names used in it are misleading (instead of "Ext-Type" we should call it "Type-ID" or "Attribute-ID" or something similar), and you are right in that the wa…

You are right. Maybe the name was not the best. We gave it 2 bytes in 
order to be able to refer  not only to "standard" RADIUS attributes, but 
also to extended attributes. But after your explanation, I think that we 
could either include both references (Type/Ext-Type, 3 bytes in total) 
or just refer only to the Type (1 byte). From the point of view of 
fragmentation, it could be enough to know that the attribute (e.g. 
Vendor-Specific) is fragmented, no matter the kind of Vendor Specific 
attribute we are dealing with.

> * Chunked-Attribute must appear before the attribute it refers to in the packet
Right.

> * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are all…

I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED, 
X, X) you can easily assumed that the first [X,X,X] is one attribute 
(X1) and the second [X,X] a different one (X2), as the five Xs do not 
appear in sequence.

Note that this situation can only occur in the packet where the last 
CHUNK of the first attribute coincide with the first CHUNK of the second 
attribute.
In the example, X1 and X2 are different attributes of type X.

PACKET1: CHUNCKED, X1, X1, X1, X1, X1, X1, X1, X1, X1
PACKET2: CHUNCKED, X1, X1, CHUNCKED, X2, X2, X2, X2
PACKET3: CHUNCKED, X2, X2

> * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it

I kinda don't like this one. We could force the inclusion of the 
CHUNCKED attribute in these situations, even when no needed. Example: 
CHUNCKED(type=X, total_length=200, start_pos=0, end_pos=199). As 
explained above, this would insert an attribute (the CHUNCKED attribute) 
between both occurrences of attribute X, thus breaking the misleading 
sequence.

> * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary.

Right, as depicted in the examples above.

Best regards,
Alejandro

---

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

Hi Alan, Diego,

Right.

Best regards,
Alejandro

---

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

> I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containin…

  IMHO, that kind of solution should be avoided.

> * Chunked-Attribute must appear before the attribute it refers to in the packet

  RADIUS doesn't impose ordering on attributes of different type.
That's a strong reason to integrate chunking inside of the attribute format.

> * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are all…

  Why?  RADIUS allows for multiple attributes of the same type, with
different value.

> * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it

  See comment about attribute ordering.

> * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary.

  I think this document is intended to solve one *very* limited
use-case.  It doesn't address any more general case.  It relies on fixed
attribute ordering, which is explicitly not required.

  I gave comments on your approach.  Do you have any comments on my
proposed alternative?  It would seem to (a) solve the same problem, and
(b) have none of the limitations.

  Alan DeKok.

---

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

Alan DeKok.

---

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

> attribute did not require definition of a new data type or attribute

  Another alternative would be to leverage the use of "Authorize Only".
 I think I've pointed that out previously on this list.

  i.e. after authentication, use State && Access-Request +
Authorize-Only, and Access-Challenge to get as much additional data as
you want.

  That doesn't solve the ">4K length attribute" problem, but it does
take one slice out of the problem space.

  Alan DeKok.

---

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

Alan DeKok.

---

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

Alejandro Perez Mendez wrote:
> But after your explanation, I think that we

  I don't understand how that would work.  My previous proposal to use a
flag field could potentially work for the new extended VSA format, too.

> (X1) and the second [X,X] a different one (X2), as the five Xs do not

  Which relies on attribute ordering.  That's a fatal flaw for any proposal.

  Alan DeKok.

---

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

Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 05 Jan 2012 17:33:56 +0100

Hello Bernard,

thanks for your response. Sadly, none of them work for our purposes.

Approach #1 does not work for us since we are looking for a generic 
fragmentation, valid for any attribute, not a fragmentation specific for 
the SAML attribute.

Approach #2 does not work for us since out-of-band protocols were 
already discussed in ABFAB group and rejected to be used for this 
specific matter. The SAML attribute must be transported over the RADIUS 
protocol, to avoid relaying on a different trust infrastructure. (see 
the discussion 
http://www.ietf.org/mail-archive/web/abfab/current/msg01116.html)

Best regards,
Alejandro

>     The Length field in the RADIUS packet header is defined in[RFC2865]
>     Section 3  <http://tools.ietf.org/html/rfc2865#section-3>.  It is noted there that the maximum length of a RADIUS
>            permissible (as with RADIUS/EAP, defined in [RFC3579  <http://tools.ietf.org/html/rfc3579>]) or
>            indicated by the NAS (as in RADIUS Location [RFC5580  <http://tools.ietf.org/html/rfc5580>]).  Also,
>            Filter-Rule Attribute defined in [RFC4849  <http://tools.ietf.org/html/rfc4849>] is not permitted in
>            [RFC2865], Section 5.11  <http://tools.ietf.org/html/rfc2865#section-5.11>, which enables a set of pre-
>            techniques, as specified in [RFC4821  <http://tools.ietf.org/html/rfc4821>].
>            [RFC4821  <http://tools.ietf.org/html/rfc4821>] to discover the maximum supported RADIUS packet size
> ------------------------------------------------------------------------
> Subject: [radext] Fwd: New Version Notification for 
> De: 	[email-masked] <mailto:[email-masked]>
> Para: 	[email-masked] <mailto:[email-masked]>
>
>
> _______________________________________________ radext mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/radext

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 05 Jan 2012 17:33:56 +0100

Hello Bernard,

Best regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 05 Jan 2012 17:35:38 +0100

>   I think I've pointed that out previously on this list.

Yes, you did. And I agree that would help for authorization data, but 
not for a generic attribute fragmentation solution.
Anyway, as you pointed out, that does not solve the >4K problem.

Best regards,
Alejandro

>
>    i.e. after authentication, use State&&  Access-Request +

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 05 Jan 2012 17:35:38 +0100

Best regards,
Alejandro

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 09 Jan 2012 09:55:05 +0100

> That's a strong reason to integrate chunking inside of the attribute format.

Ordering constraints here are applied to related attributes. I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows.

>  See comment about attribute ordering.

On these issues, I agree with the latest proposal from Alejandro, that rather simplifies ordering constraints.

> use-case.  It doesn't address any more general case.

The use case is that of an AuthN/AuthZ infrastructure that requires the exchange of data longer that the one that fits in a RADIUS packet, and intended to rely on a single trust infrastructure. I do think it is general enough.

>  It relies on fixed attribute ordering, which is explicitly not required.

It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules.

> (b) have none of the limitations.

One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 09 Jan 2012 09:55:05 +0100

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 09 Jan 2012 10:58:58 +0100

DIEGO LOPEZ GARCIA wrote:
> Ordering constraints here are applied to related attributes.

  RADIUS doesn't work that way.

  There are hundreds of thousands of deployments which assume that
ordering constraints do NOT apply to related attributes.  Changing such
a fundamental part of the protocol is impossible.

> I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows.

  I pointed you to RFC 2865, and explained why that restriction is
impossible.  Please go read those messages again.

> It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated pr…

  It relies on behavior which is mandated as NOT being part of RADIUS.

> One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more…

  Nonsense.

  It is incompatible with existing methods like EAP-Message.  Those
*already* have semantics defined.  Changing them by adding a "Chunked
Attribute" is impossible.  The extended format hasn't been deployed, so
compatibility with it is impossible.

  My proposal was to allow *new* attributes to span multiple packets.

  Changing the rules on attribute ordering is impossible.  Don't even try.

  Changing the meaning of existing attributes to allow more than 253
octets of data is impossible.  Don't even try.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 09 Jan 2012 10:58:58 +0100

Nonsense.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 09 Jan 2012 11:03:00 +0100

Alan DeKok wrote:
> ordering constraints do NOT apply to related attributes.

  Make that "UNrelated attributes"

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 09 Jan 2012 11:03:00 +0100

Alan DeKok.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 09 Jan 2012 12:05:11 +0100

>   Changing the rules on attribute ordering is impossible.  Don't even try.

Nodoby is trying to do so. We've probably not explained well the rules for CHUNKED and the related attribute. Let us get back to it with a (hopefully) clearer proposal.

> octets of data is impossible.  Don't even try.

Nobody is trying to do so either, but to achieve the goal of allowing attributes to span several packets in the simplest and cleanest way possible.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 09 Jan 2012 12:05:11 +0100

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

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

Hi Alan,

thanks for the clarifications and hints. We will think about them and 
their implications, and try to modify the proposal to make it address 
all the requirements.

Regards,
Alejandro

---

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

Hi Alan,

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Jan 2012 15:24:43 -0500

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    Alejandro> Hello Bernard, thanks for your response. Sadly, none of
    Alejandro> them work for our purposes.

    Alejandro> Approach #1 does not work for us since we are looking for
    Alejandro> a generic fragmentation, valid for any attribute, not a
    Alejandro> fragmentation specific for the SAML attribute.

Why have we decided that we want a generic approach?
It seems much harder than something specific to SAML that could be
reused in spirit for similar attributes in the future?

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Jan 2012 15:24:43 -0500

---

From: Alan DeKok <[email-masked]>
Date: Mon, 09 Jan 2012 21:46:49 +0100

> Why have we decided that we want a generic approach?

  I believe that we can come up with a solution which works for SAML and
for future attributes.

  Leveraging one of the unused fields from the extensions document seems
logical, and timely.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 09 Jan 2012 21:46:49 +0100

Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 16 Jan 2012 14:43:28 +0100

Hi Alan, all,

we have been thinking on this topic and we realized that a different 
approach could be more convenient to handle inter-packet fragmentation 
than our first proposal.

Taking draft-ietf-radext-radius-extensions as a base, we can assume that 
intra-packet fragmentation is already handled via the M flag. We can 
also assume that order between fragments is preserved when following 
draft-ietf-radext-radius-extensions. This may not be true now with the 
current spec (as Peter pointed out), but we can assume this will be 
solved somehow in the future (e.g. including offset field).

We propose the following:
1) Extended flag attributes are used to fragment big RADIUS attributes, 
as specified in draft-ietf-radext-radius-extensions.
2) If a fragmented attribute cannot be completely included into the 
remaining space of a 4KB RADIUS packet, it is truncated, that is, only 
the fragments that fit into the free space of the packet to be sent are 
included. It is also included a new RADIUS attribute, called 
"More-Data-Pending". The presence of this attribute indicates to the 
receiver that the RADIUS packet is not complete, and more data MUST be 
received from the sender before processing any of the received attributes.

Note that it is possible (and very likely), that the last fragment of a 
truncated attribute in a RADIUS packet has the M flag set. This case 
would be against what it is stated in 
draft-ietf-radext-radius-extensions. Nevertheless, we think this 
restriction can be easily relaxed when using the more-data-pending 
attribute. If it is present, it is allowed that the last fragment have 
the bit M set, which means the attribute is truncated. A good side 
effect of this is that if a  server does not understand 
more-data-pending and its semantics, a truncated attribute will be shown 
as an invalid attribute, and not taking the truncated portion as the whole.

The rest of the attribute fragments will be sent in successive packets, 
following the same procedure, using as many RADIUS packets as needed to 
transmit the required information.

Let me illustrate this with an example, where a RADIUS client sends a 
packet with a size > 4 KB (to make it simpler, we assume each RADIUS 
packet can include 8 RADIUS attributes/fragments, instead of using 
bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate 
successive fragments of the attribute Data.

The RADIUS client wants to send the following RADIUS packet:

Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M], 
Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], 
Data10, Other1[M], Other2[M], Other3

As only 8 attributes can be included in the packet, the RADIUS client 
truncates "Data" to fit into the packet, and includes the 
More-Data-Pending attribute:

Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M], 
Data3[M], Data4[M], Data5[M], More-Data-Pending

When the server receives the RADIUS packet containing the 
More-Data-Pending attribute, the processing of the packet is left until 
all the pending data is received. The pending data is requested by means 
of an Access-Challenge packet, using the State attribute to tie together 
this response with the subsequent request from the client.

Access-Challenge1 = State1

The client continues sending the data until another RADIUS packet is 
completed, including again the attribute More-Data-Pending

Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10, 
Other1[M], More-Data-Pending

The server stores the attributes into the state associated to State1 and 
replies:

Access-Challenge1 = State2

Finally, the client sends the last fragments of the original packet:

Access-Request3 = State2, Other2[M], Other3

The server now can process the totality of the received attributes as if 
they all had been received into a single RADIUS packet of more than 4 KB

The case where the server sends a fragmented packet to the client is 
very similar and makes no sense to expli

Best regards,
Alejandro

El 09/01/12 12:20, Alejandro Perez Mendez escribió:
>>> I don't see why this would go beyond the requirements imposed by the 
>>> current document on extended attributes, as the recent discussion on 
>>> it shows.
>>> It relies in the usage of an specific attribute that defines the 
>>> interpretation of the values of another attribute. Ordering rules 
>>> probably could be relaxed, but at the price of more complicated 
>>> processing rules.
>>> One of the main goals of the proposal was to be compatible with 
>>> current mechanisms for attribute encoding inside the packet 
>>> (EAP-style, extended attributes…) and deal only with values spanning 
>>> more than one packet. Using your alternative would break this 
>>> compatibility.
>>    Nonsense.
>>
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 16 Jan 2012 14:43:28 +0100

Hi Alan, all,

Best regards,
Alejandro

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jan 2012 15:24:23 +0100

> as specified in draft-ietf-radext-radius-extensions.

  That should be possible.

> received from the sender before processing any of the received attributes.

  I've had similar discussions with people off-list.

> as an invalid attribute, and not taking the truncated portion as the whole.

  I'm wary of that, but it's a good start.  There may be additional
minor fixes which could make the fragmentation explicit rather than
implicit.

  I think this proposal would require a new document at minimum.  The
document would discuss how to implement the above proposal.  That means
that others could use this specification, even if they don't need
attributes longer than 4K.

  A separate document could document the >4K attributes.

  I'll see if I can write a short proposal to the radext list.  If it's
acceptable to the WG, I can put a draft together.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jan 2012 15:24:23 +0100

That should be possible.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 16 Jan 2012 16:30:15 +0100

Hi Alan,

>    I've had similar discussions with people off-list.

that's good

> minor fixes which could make the fragmentation explicit rather than

We also thought that a new flag "T" could indicate the attribute is 
truncated across several packets.

> attributes longer than 4K.

Indeed, this proposal is not only for attributes longer than 4K, but to 
support that an attribute is fragmented across different packets, 
because the total length of the packet is longer than 4K.

That could happen even when the attribute is not very long, but it is 
placed at the end of the package.

>    A separate document could document the>4K attributes.

IMO support for attributes > 4K is a logic consequence of the 
fragmentation support given by our proposal.

> acceptable to the WG, I can put a draft together.

Precisely we were about to modify our document to reflect this, if the 
idea was reasonable. That was the intention of sending it first to the 
list, to see if there were objections before starting writing a new draft.

Regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 16 Jan 2012 16:30:15 +0100

Hi Alan,

that's good

Regards,
Alejandro

---

From: Dave Nelson <[email-masked]>
Date: Mon, 16 Jan 2012 10:38:40 -0500

> truncated across several packets.

Yeah.  I would favor the definition of another flag bit, rather than mixing
flags and "signal" attributes to accomplished related purposes.  It's just
more symmetrical.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Dave Nelson <[email-masked]>
Date: Mon, 16 Jan 2012 10:38:40 -0500

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jan 2012 16:39:51 +0100

> truncated across several packets.

  That sounds good.

> list, to see if there were objections before starting writing a new draft.

  My notes about this are:

- the first Access-Accept must contain Service-Type = Authorize-Only
  *or* a new Servicer-Type = Additional-Authorization

  This means that the user is not given network access when the
  implementation does not support the new method.

- the first Access-Accept must contain a State attribute
  for is already required for use of Authorize-Only

- additional authorization attributes are received via a series
  of Access-Request / Access-Challenge

  - each Access-Request MUST contain Service-Type = Authorize-Only
    and a State

  - the State MUST change for each Access-Challenge response
    I can get into that later

- the final Access-Accept contains the real Service-Type
  for the user

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jan 2012 16:39:51 +0100

That sounds good.

  My notes about this are:

  Alan DeKok.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 16 Jan 2012 17:02:13 +0100

>> truncated across several packets.

Apart that I think it would make the mechanisms simpler to deal with, I must say I like Dave's symmetry argument for the "T" flag.

>  implementation does not support the new method.

In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption...

>  - each Access-Request MUST contain Service-Type = Authorize-Only

Or, respectively, Additional-Authorization, isn't it?

>    I can get into that later

I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right?

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 16 Jan 2012 17:02:13 +0100

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jan 2012 17:11:14 +0100

DIEGO LOPEZ GARCIA wrote:>
> In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption...

  I agree.

> Or, respectively, Additional-Authorization, isn't it?

  The Access-Challenge should contain Additional-Authorization.  The
request should probably contain Authorize-Only.

> I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right?

  It's a way to guarantee ordering.  I'm not sure if MITM attacks are
anything we care about.  Every entity in the AAA system is trusted, and
the packets are signed to prevent non-AAA systems from modifying them..

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jan 2012 17:11:14 +0100

I agree.

  Alan DeKok.

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Mon, 16 Jan 2012 17:23:13 +0100

> In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption...

Agreed.

> Or, respectively, Additional-Authorization, isn't it?

No it's an extension/reworking of the concept described in RFC 3576 3.1, but the trigger is an Access-Accept packet with the Service-Type/Additional-Authorization attribute.

> I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right?

Yes, correct. The packets don't contain any explicit ordering information, so the attributes are just concatenated together in the order they're received.

-Arran

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Mon, 16 Jan 2012 17:23:13 +0100

Agreed.

-Arran

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 16 Jan 2012 20:04:19 +0100

Hi Dave:

El 16/01/2012, a las 16:38, Dave Nelson escribió:

> We also thought that a new flag "T" could indicate the attribute is truncated across several packets.
> 
> Yeah.  I would favor the definition of another flag bit, rather than mixing flags and "signal" attributes to accomplished related purposes.  It's just more symmetrical. 

Just a clarification here. Our goal (authors of draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism for fragmentation between RADIUS packets when they exceed 4K (inter-packet fragmentation). If we remove the signal attribute (e.g. "More-Data-Pending"), the flag T should mean that the RADIUS packet is truncated (and not necessarily the attribute where the flag T is activated). For example: 

A,B,C,... ,Y are attributes of different types in one RADIUS packet. Adding attribute Z exceeds 4K, so we should signal that. We could decide to activate the bit T in the last attribute Y[T], but, actually, it does not mean anything in the context of extended attribute Y[T], since we want to signal that more attributes (perhaps, of any other type as, for example, Z) are coming after this list in a different RADIUS packet.

In this sense, we believe that the presence of some kind of attribute "More-Data-Pending" (or any other type of signaling at packet level) can inform about this situation within the context of the RADIUS packet. 

Best regards.

> www.elbrys.com

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 16 Jan 2012 20:04:19 +0100

Hi Dave:

Best regards.