Skip to main content

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./