[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADIUS attribute extension formats: Do we understand the proposals?
Here is the attribute format, that I am proposing:
+---------------------------------------------------------------+
| 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 (26) | Length | Vendor-Id (0) |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
+---------------+---------------+---------------+---------------+
|F| TAG | Value
+---------------+---------------
Type 26 for Vendor-Specific.
Length >= 10
Vendor-Id
The high-order octet is zero (0) and the low-order 3 octets are zeros
(0)s representing an extended IETF RADIUS attribute.
Extended-Type
One (1) Octet. Up-to-date values of the RADIUS Extended-Type field
are specified in the most recent "Assigned Numbers" IANA [5] .
Values XXXX-YYYY are reserved.
Length >= 4. The length of the Extended-Type, Length, Framentation,
Tag fields and the length of the Value field
Fragementation (F):
When set(1) the attribute is fragmented. When clear (0), the
attribute is not fragmented. When the value portion of an extended
attribute exceeds 246 octets the value is fragmented over one or more
extended attribute. In this case the Fragmentation Flag is set on
the attribute(s) that contain the fragmentated value.
Tag
The Tag field is 7-bits and MUST always be present. It is used to
group extended attributes. Attributes with the same non-zero value
belong to the same group. A tag value of zero(0) indicates that the
attribute is not grouped. A tag value of all-ones (0x7F) is
reserved.
Value
One or more octets.
Here are some examples:
Consider an attribute called Foo of type String. Foo is allocated an
Extended-Type by IANA of 10. The following figure shows the encoding
of Foo(0,10) = "Hello":
+---------------------------------------------------------------+
| 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 (26) | Length | Vendor-Id (0) |
| | (6+8 = 14) | |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (10) | (3 + 5 = 8) |
+---------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|0| (0) | (H) | (e) | (l) |
+---------------+---------------+-------------------------------+
| (l) | (o) |
+---------------+---------------+
The next figure shows the encoding of Foo when the length of Foo is
251 octets. Foo(0,10) = "Hello W....end.". In this case the value
is fragmented over two attributes. The first 246 octets are included
in the first fragment and the remaing 5 octets appear in the second
attributes which has the Framentation bit set to 1.
+---------------------------------------------------------------+
| 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 (26) | Length | Vendor-Id (0) |
| |(6 + 249 = 255)| |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (10) |(3 + 246 = 249)|
+---------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|0| (0) | (H) | (e) | (l) |
+---------------+---------------+-------------------------------+
| (l) | (o) | | (W) |
+---------------+---------------+---------------+---------------+
................
+---------------+---------------+-------------------------------+
| Type (26) | Length | Vendor-Id (0) |
| | (6+8 = 14) | |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (10) | (3 + 5 = 8) |
+---------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|1| (0) | ( ) | (e) | (n) |
+---------------+---------------+-------------------------------+
| (d) | (.) |
+---------------+---------------+
Next consider the following structure:
struct
Integer a;
String b;
Integer c;
endStruct
Element a is assigned and extended type of 20. Element b is assigned
an extended type of 25 and element c is assigned an exteded type of
27. The following figure illustrates the coding where a(0,20) =
0xDEADDEAD, b(0,25) = "He.....The end." and is of length 251 octets;
and c(0,27) = 0x12345678. The attributes are grouped together with
TAG=42.
+---------------------------------------------------------------+
| 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 (26) | Length | Vendor-Id (0) |
| |(6 + 7 = 13) | |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (20) |(3 + 4 = 7) |
+-+-------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|0| (42) | (0xde) | (0xad) | (0xde) |
+-+-------------+---------------+-------------------------------+
| (0xad) | Type(26) | Length | Vendor-Id(0) |
| | | (6 + 249 = 255| |
+---------------+---------------+---------------+---------------+
| Vendor-Id (0) | Extended-Type |
| | (25) |
+---------------+-+-------------+---------------+---------------+
| Length |F| TAG | Value | Value |
| (3+246) = 249 |0| (42) | (H) | (e) |
+---------------+-+-------------+---------------+---------------+
...........
+---------------+---------------+---------------+---------------+
| Value | Value | Value | Value |
| (.) | (T) | (h) | (e) |
+---------------+---------------+---------------+---------------+
| Type (26) | Length | Vendor-Id (0) |
| | (6+8 = 14) | |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (25) | (3 + 5 = 8) |
+---------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|1| (42) | ( ) | (e) | (n) |
+---------------+---------------+---------------+---------------+
| (d) | (.) | Type (26) | Length |
| | | | (6+7 = 13) |
+---------------+---------------+---------------+---------------+
| Vendor-Id (0) |
| |
+---------------+---------------+-+-------------+---------------+
|Extended-Type | Length |F| TAG | Value |
| (27) | (3+4 = 7) |0| (42) | (0x12) |
+---------------+---------------+-+-------------+---------------+
| Value | Value | Value |
| (0x34) | (0x56) | (0x78) |
+---------------+---------------+---------------+
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Friday, September 29, 2006 2:48 AM
> To: radiusext@ops.ietf.org
> Subject: Proposed Resolution to Issue 202: Diameter-RADIUS
> gateway behavior not spec'd
>
> The text of Issue 202 is enclosed below.
>
> The proposed resolution is as follows:
>
> In Section 4, Change:
>
> "Note that since a Diameter AVP can be larger than the maximum RADIUS
> packet size (4096), translation from Diameter to RADIUS may not be
> possible in all cases."
>
> To:
>
> "Note that a translated Diameter message can be larger than
> the maximum RADIUS packet size (4096). Where a
> Diameter/RADIUS gateway receives a Diameter message
> containing a NAS-Filter-Rule AVP that is too large to fit
> into a RADIUS packet, the Diameter/RADIUS gateway will
> respond to the originating Diameter peer with the
> DIAMETER_INVALID_AVP_LENGTH error (5014), and with a
> Failed-AVP AVP containing the NAS-Filter-Rule AVP.
> Since repairing the error will probably require re-working
> the filter rules, the originating peer should treat the
> combination of a DIAMETER_INVALID_AVP_LENGTH error and a
> Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal error."
>
>
> ------------------------
> Description of issue: Diameter-RADIUS gateway behavior not
> completely specified Submitter name: Glen Zorn Submitter
> email address: gwz@cisco.com Date first submitted: 26 Aug 06
> Document: draft-ietf-radext-filter-01.txt Comment type: T
> Priority: 1
> Section: 4
> Rationale/Explanation of issue:
>
> The last sentence of section 4 says
> "Note that since a Diameter AVP can be larger than the
> maximum RADIUS packet size (4096), translation from Diameter
> to RADIUS may not be possible in all cases." While this is
> true, the behavior of the Diameter-RADIUS gateway in this
> case is left unspecified. Is the response forwarded back
> toward the requests' originator without the untranslatable
> AVPs? In the case of an Access-Accept message, Section
> 1.2 says "If a NAS conforming to this specification receives
> an Access-Accept packet containing a NAS-Filter-Rule
> attribute which it cannot apply, it MUST act as though it had
> received an Access-Reject.", it might be reasonable for the
> gateway to translate the Access-Accept into an Access-Reject,
> since an attribute that is missing because untranslatable can
> obviously not be applied. In the case of a CoA message with
> an untranslatable attribute, should the message be translated
> into a Disconnect-Request or just discarded? Or in both
> cases, should the gateway respond to the
> originating/responding Diameter peer with an appropriate
> error (e.g., DIAMETER_INVALID_AVP_LENGTH) and let it figure
> out the next step? If so, it still seems that the peers
> behavior must be specified.
>
>
>
> --
> to unsubscribe send a message to
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>