On Sep 16, 2024, at 7:13 PM, Susan Hares via Datatracker <noreply@xxxxxxxx> wrote: > 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. Thanks. I'll clarify below. > 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? I'll try to clarify, but it doesn't matter. The Token value is mandated to be tracked on a per-connection basis. The only reason to avoid Token re-use across multiple connections is to avoid confusing humans who are reading the output. See the paragraph after the quoted one for additional explanation. > Issue-2: Section 6.1 - Protocol error. > > How does the operator detect that a client has received a > Protocol-Error with an Error Cause. The client should read the Protocol-Error packet from the network, and automatically instigate fail-over, etc. > 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? It doesn't. RADIUS has no way of signalling the end user. > 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. "Implementation defined". This is new behavior, and as such it's perhaps not clear what to do. We define the new behaviour as being better than what we have now, but which is still imperfect. > Issue-3: How can the operator know if > the security issues listed in section 10 occur? > Are these issues operational attacks or edge cases? These are misconfigurations. The purpose of Section 10 is to explain that even in the case of a misconfiguration, there will be no security issue. > Editorial NITS: > 1. Section 3.1, paragraph 2, first sentence, 2 periods. Fixed, thanks. > text with error:/ > Where ALPN is configured, the client signals support by sending ALPN > strings signaling which protocols it supports../ Fixed. > 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./ Fixed, thanks. Alan DeKok. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
