Alejandro Perez Mendez wrote:
> 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.
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.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
