[Pana] Re: Rate limiting (AD comment) draft-ietf-pana-pana-13

[Mark Townsley <townsley at cisco.com>]

Alper Yegin wrote:
> 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.
>   
You're right, it does depend on the deployment as well as the raw 
message processing power of the node running PANA.  Perhaps a warning, 
coupled with a SHOULD, is sufficient. I'm afraid that a MAY could get 
looked over too quickly.
>   
> > >    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? 
>   
Well, the problem is that a sender of a PANA-ping that considers a node 
dead after just a few unresponsive pings coupled with a PANA-ping 
responder that is rate-limiting, could lead to false-positives for a 
down link. At a minimum, please point this out.

Also, does the PANA-ping fall within the same set of sequence numbers 
for other PANA messages, and use the same retransmission parameters?
>   
> > >    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? 
>   
"certain threshold value" simply leaves one guessing. If there is a 
variable being defined here, or if you are referring to one of the 
existing PCI values, point that out along with whether or not it should 
be configurable as in section 9. If the certain threshold here is part 
of generic rate-limiting which is being left unspecified, say so.

Perhaps we need some input from the transport area to get this right.
> 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?
>   
The warning definitely needs to be there, along with which are 
"hot-spots" for attack. I think there is room at least to normalize the 
discussion of it in the text (e.g., no references to undefined "certain 
thresholds", rather a mention that the message may be subject to 
rate-limiting with a reference to a place in the document where this is 
discussed in more detail). As for whether you can define real 
parameters, I agree that this is a difficult thing to do, and perhaps 
best left up to an implementation to handle the best way it knows how.

- Mark
> Alper
>
>
>
>
>
>   

_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana