Last Call Review of draft-ietf-radext-radiusv11-10
review-ietf-radext-radiusv11-10-opsdir-lc-hares-2024-09-16-00
Request | Review of | draft-ietf-radext-radiusv11 |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2024-06-26 | |
Requested | 2024-06-12 | |
Authors | Alan DeKok | |
I-D last updated | 2024-09-16 | |
Completed reviews |
Genart Last Call review of -08
by Christer Holmberg
(diff)
Artart Last Call review of -07 by Claudio Allocchio (diff) Secdir Last Call review of -08 by Barry Leiba (diff) Opsdir Last Call review of -10 by Susan Hares (diff) Secdir Telechat review of -10 by Barry Leiba (diff) |
|
Assignment | Reviewer | Susan Hares |
State | Completed | |
Request | Last Call review on draft-ietf-radext-radiusv11 by Ops Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/ops-dir/zL8cYwbAvk5G1SdDSVNFylfjwCg | |
Reviewed revision | 10 (document currently at 11) | |
Result | Has issues | |
Completed | 2024-09-16 |
review-ietf-radext-radiusv11-10-opsdir-lc-hares-2024-09-16-00
This is an OPS-DIR review. The comments should be taken as any other WG LC or IETF-LC comments. Summary: The Text has good operational discussion except for a few minor issues. I found just 2 NITs that were glaring. Others may exist. The three minor issues arise not from the details of Radius ALPN but from the operation issues indicated in the text. However, I am not an operator or one who currently manages Radius servers or clients. I have not coded Radius. Therefore, take my issues simply as questions. Issue-1. section 4.2.1, paragraph 4, last sentence of the following method: Text:/ This counter method ensures that the Tokens are unique, and are also independent of any Code value in the RADIUS packet header. This method is mandated because any other method of generating unique and non-conflicting Token values is more complex, with no additional benefit and only the likelihood of increased bugs and interoperability issues. Any other method for generating Token values would require substantially more resources to track outstanding Token values and their associated expiry times. The chance that initial values are re-used across two connections is one in 2^32, which is acceptable./ The question is what is the time period and what group of 2 connections is the 2^32 acceptable? It leaves one with more questions than answers. Perhaps, there is something the authors forgot to add here? Issue-2: Section 6.1 - Protocol error. How does the operator detect that a client has received a Protocol-Error with an Error Cause. If the client keeps sending to different servers, and getting an Error (Request not Routable (502), or Other Proxy Processing Error (505), or Resources not available (506)), how does the client let the user know? If a radius server has a number of Protocol-errors from a particular client, is there a way to signal this to the management systems. Issue-3: How can the operator know if the security issues listed in section 10 occur? Are these issues operational attacks or edge cases? Editorial NITS: 1. Section 3.1, paragraph 2, first sentence, 2 periods. text with error:/ Where ALPN is configured, the client signals support by sending ALPN strings signaling which protocols it supports../ 2. Section 7.2, paragraph 5, sentence 2 current text:/ The proxy can determine if the contents of the EAP-Message are invalid, for example if the first octet has value larger than 4./ New text:/current text:/ The proxy can determine if the contents of the EAP-Message are invalid. One example of an invalid EAP-Message is if the first octet has a value larger than 4./