Subject: [radext] Review of draft-ietf-radext-bigger-packets-02.txt

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 26 Feb 2015 14:58:59 +0100

Hi Sam,

here is my review of the new version of draft. Most of them are just typos.
Overall, I think the document is ready for the WGLC, although as I 
mention below, I would appreciate more information about the handling of 
the Protocol-Error messages and the  in the Proxies.

1. Abstract. RADIUS over TCP experiment needs a reference (RFC6613) as 
for the RADIUS over TLS experiment mentioned in the first sentence.

2. Abstract and Introduction. I'm not convinced that the reason of 
having new use cases where more than 4096 bytes are required in RADIUS 
is motivated only by RFC6614. Other security mechanisms such as IPsec or 
a trusted network would be enough to motivate use cases such as those 
described in ABFAB and/or in the aaa-saml draft. In our RADIUS 
fragmentation draft we mention ABFAB as the motivation.

3. Section 1. s/the RADIUS layer.RADIUS Fragmentation/the RADIUS layer. 
RADIUS Fragmentation/

4. Section 1. Reference to draft-ietf-radext-radius-fragmentation seems 
quite old (-04, April 2014). Nevertheless, it should be an RFC sooner 
than later, so it can be updated then.

5. Section 1. s/arrises/arises/

6. Section 2. While the text indicates that RADIUS Servers and CLients 
MUST be able to receive a packet of maximum length, proxies only SHOULD 
be able to do that. What's the reason of such a difference? Besides, I 
think the text should say "Proxies implementing this specification MUST 
be....".

7. Section 2. It has been difficult to me to understand the following 
paragraph:

Proxies MUST include the Response-Length attribute when
    forwarding a request received over a transport with a 4096-octet
    maximum length over a transport with a higher maximum length.

I would suggest to reword it, with something like this: (note that I 
also indicated that the value of the attribute should be 4096. Remove it 
if that's not correct)

When a proxy receives a request over a transport with a 4096-octet
    maximum length, and this request is to be forwarded over a transport with
    a higher maximum length, the proxy MUST include a Response-Length
    attribute with a value of 4096 in such a request.

8. Section 2.1. s/Status-Request messages/Status-Server messages

9. Section 2.1. s/by including the attribute/By including the attribute

10. Section 3. s/When an RFc/When an RFC/

11. Section 3. This section says that Respone-Length attribute MAY be 
included in a request to indicate that larger responses are desirable. 
Shouldn't it say "acceptable" instead of "desirable"?

12. Section 4. The section is titled "Protocol Error Type". Shouldn't it 
be "Protocol-Error code" instead?

13. Section 4. It is not clear to me what's the purpose of the 
Original-Packet-Code attribute. It is mentioned in the text, and 
described which values it should take. However, it is not explained how 
this value is used.

14. Section 4. s/TBD/TBDCODE/ (according to section 6)

15. Section 4. It is not clear to me how the messages with this code are 
handled by Proxies. Are they supposed to forward them back to the 
Client? Should they handle them individually?

16. Section 6. s/the maximum size RADIUS request that is/the maximum 
size of a RADIUS request that is/

17. Section 7. s/these attacks/These attacks/

18. Section 7. Does the sentence "This specification updates RFC 6613 
and will be used with [RFC6614]" implies that TLS is mandatory for this 
specification? (see my comment for abstract and introduction)

Regards,
Alejandro

---

From: Alan DeKok <[email-masked]>
Date: Thu, 26 Feb 2015 11:21:07 -0500

On Feb 26, 2015, at 8:58 AM, Alejandro Perez Mendez <[email-masked]> wrote:
> 13. Section 4. It is not clear to me what's the purpose of the Original-Packet-Code attribute. It is mentioned in the text, and described which values it should take. However, it is not explained how this value is used.

  The problem is that there are multiple packet types (Access-Request, Accounting-Request, etc.) which could theoretically trigger a Protocol-Error response.  We can’t send a normal response (Access-Reject, Accounting-Response), because the error is in the *transport* stage.  So we have to send a Protocol-Error packet.

  But… we don’t want multiple protocol error codes.  e.g. Access-Request-Protocol-Error, Accounting-Request-Protocol-Error, etc.  We just want Protocol-Error.

  The problem then becomes how do you match Protocol-Error to an original packet?  RADIUS/TCP allows for Access-Request and Accounting-Request packets to share the same TCP connection.  So if the client receives Protocol-Error with ID 34, is it for Access-Request ID 34, or Accounting-Request ID 34?

  Putting the Original-Packet-Code into Protocol-Error solves this problem.  The client can now look up the original packet code (Access-Request or Accounting-Request), along with the ID (34), and get the original packet.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 26 Feb 2015 19:01:59 +0100

>    Putting the Original-Packet-Code into Protocol-Error solves this problem.  The client can now look up the original packet code (Access-Request or Accounting-Request), along with the ID (34), and…

Hi Alan,

thanks for the explanation. It is now clear. It serves to build a unique 
key in the form of (ID, Original-Packet-Code) which is used by the 
Client to match it with the corresponding request, as ID by itself 
cannot do it (is the Client allowed to create parallel Access-Requests 
and Accounting-Requests with the same ID?)

Anyway, I think that this kind of explanation (perhaps not so detailed, 
but at least a summary) should be in the document.

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Feb 2015 13:06:46 -0500

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

    Alejandro> Hi Alan,

    Alejandro> thanks for the explanation. It is now clear. It serves to
    Alejandro> build a unique key in the form of (ID,
    Alejandro> Original-Packet-Code) which is used by the Client to
    Alejandro> match it with the corresponding request, as ID by itself
    Alejandro> cannot do it (is the Client allowed to create parallel
    Alejandro> Access-Requests and Accounting-Requests with the same
    Alejandro> ID?)

>From my edit buffer:

      <t>A Protocol-Error packet MUST contain a Original-Packet-Code
      attribute,
      along with an Error-Cause attribute.  Other attributes MAY be
      included if desired.  The Original-Packet-Code contains the code
      from the reque\
      st that generated the protocol error so that clients can
      disambiguate requests \
      with different codes and the same ID.  

Is that sufficient?

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 26 Feb 2015 19:13:29 +0100

>        with different codes and the same ID.

It is for me.