Here are the comments related to rate limiting. > > The PAA MAY limit the rate it processes incoming > > PANA-Client-Initiation messages. > > > MAY? It seems to me that SHOULD would be better (if not MUST) for any > message that is subject to DOS attacks.
Would we also need to define parameters for the rate limiting? I think that'd be difficult, as it really depends on the deployments. > > Implementations MUST limit the rate of performing this test. The PaC > > and the PAA can handle rate limitation on their own, they do not have > > to perform any coordination with each other. There is no negotiation > > of timers for this purpose. Additionally, an implementation MAY > > rate-limit processing the incoming PANA-Ping-Requests. > > > I'm a little worried about lack of detail here as PANA-ping used for > liveness detection coupled with an aggressive rate-limiting policy could > be problematic. Any specific suggestions? > > The PaC and PAA MUST respond to duplicate requests as long as the > > responding rate does not exceed a certain threshold value. > What is the "certain threshold value"? Is it a certain number of packets > over a period of time? Something else? I don't think an implementor has > enough information here. Please fully describe, include defaults and a > recommendation as to whether it should be configurable or not (in > section 9, if you like). Are there any guidelines from existing protocols that we can borrow? What is the best way to get rate limiting factored into the protocol? I'm starting to think rate limiting is not for the protocol specification to talk about. It is a safe guard that implementations can utilize on their own. Maybe we should remove all mentions of rate limiting from the spec. Comments? Alper _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
