Subject: [Pana] Rate limiting (AD comment)

From: "Alper Yegin" <[email-masked]>
Date: Sat, 10 Feb 2007 01:29:56 +0200

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-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Mark Townsley <[email-masked]>
Date: Wed, 14 Feb 2007 14:14:20 +0100

> 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.
> 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 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.
> own. Maybe we should remove all mentions of rate limiting from the spec.
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

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 15 Feb 2007 18:04:17 +0200

> coupled with a SHOULD, is sufficient. I'm afraid that a MAY could get

We can say:

	The PAA SHOULD limit the rate it processes incoming PANA-Client-
	Initiation messages in order not to subject itself to denial-of 
	service attacks. Details of rate limiting are outside the scope of 
	this specification.

> down link. At a minimum, please point this out.

By using your text:

	Sender of a PANA-Ping-Request that considers its peer dead after 
      just a few unresponsive pings coupled with the peer that is rate-
	limiting could lead to false-positives. Implementers shall pay
	attention as they decide the number of unresponsive pings used
	for detecting dead/unreachable peers. 

> for other PANA messages, and use the same retransmission parameters?

Yes it does. Do you see a particular issue with that?

> of generic rate-limiting which is being left unspecified, say so.

OK, it is meant to be the latter. 

Proposed text:

	The PaC and PAA SHOULD respond to duplicate requests. A request
	may be dropped due to rate limiting. Details of rate limiting
	are outside the scope of this specification.

Alper

---

From: Mark Townsley <[email-masked]>
Date: Thu, 15 Feb 2007 10:44:09 +0100

> 	service attacks. Details of rate limiting are outside the scope of 
OK.
> 	for detecting dead/unreachable peers. 
How about:

It should be noted that if a PAA or PaC  which considers its 
connectivity lost after a relatively small
number of unresponsive pings is coupled with a peer  that is 
aggressively rate-limiting
the PANA-Ping messages, false-positives could result. Care should be taken
when rate-limiting PANA-Ping messages to periodically respond, and a PAA 
or PaC should not rely on
PANA-Ping messages to quickly determine loss of connectivity.
> Yes it does. Do you see a particular issue with that?
Will, IMHO it was one of the mistakes I made with L2TP. In L2TP, the 
"Hello" message is used as a "keepalive" or "ping" for the L2TP tunnel. 
It is sent as any other control message. In retrospect, I really wish I 
had the Hello messages on their own sequencing and retransmission 
scheme, so that probing, OAM, and the like could happen outside the 
operation of the critical state machine processes. For example, an 
operator should feel free to send all the pana ping messages he or she 
wants without threatening the operation of the session itself. If all 
pings are sent reliably, in sequence with "real" messages that affect 
state, then the protocol could be left struggling to keep up with pings, 
missing out on more critical messages.

>>>> What is the "certain threshold value"? Is it a certain number of
>>>>         
>> packets
>>     
>>> Are there any guidelines from existing protocols that we can borrow?
>>>       
>> What is
>>     
How about:

"Unless dropped due to rate limiting, the PaC and PAA MUST respond to 
all duplicate request messages received."

Unless there is some other reason to not respond to duplicates other 
than rate limiting.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 16 Feb 2007 15:18:19 +0200

> number of unresponsive pings is coupled with a peer  that is

s/is coupled/coupled

> missing out on more critical messages.

If I understand it right, you are concerned about ping messages blocking the
progress of other messages if they use the same sequence number space. But,
if the peer is having hard time responding to a simple ping, probably it
won't be able to process the other messages anyways. Or at least, now the
first non-ping message will be the one blocking others.

OK.

One more thing. I think we shall say "MUST process" instead of "MUST
respond". For some legitimate reason, the peer may choose to silently ignore
the request (e.g., message authentication code failure). 

Alper

---

From: Mark Townsley <[email-masked]>
Date: Fri, 16 Feb 2007 12:10:10 +0100

Alper Yegin wrote:
> progress of other messages if they use the same sequence number space. 
Right.
> But,
Sure, but when you've debugged networks that shutdown sessions to 
thousands of users due to a problem with a Hello packet, well, you 
rethink these kinds of things. Certainly you wouldn't be the only 
protocol with a reliable probe inline with other messages, so perhaps I 
am being paranoid, but I got this way honestly. I won't press on this 
alone, but if you end up redesigning the transport for other reasons you 
should probably consider it.

- Mark
>>>>>> over a period of time? Something else? I don't think an implementor
>>>>>>             
>> has
>>     
>>>>>> enough information here. Please fully describe, include defaults and
>>>>>>             
>> a
>>