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

[Mark Townsley <townsley at cisco.com>]

Alper Yegin wrote:
> > > 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.
> > >
> > >       
> > OK.
> >     
> > > > 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.
> > > >
> > > >         
> > > 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.
> > >
> > >       
> > 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
> >     
>
> s/is coupled/coupled
>
>
>   
> > 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.
> >     
> > >       
> > > > Also, does the PANA-ping fall within the same set of sequence numbers
> > > > for other PANA messages, and use the same retransmission parameters?
> > > >
> > > >         
> > > 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.
> >     
>
> 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. 
Right.
> 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.
>   
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
>  
>
>
>
>   
> > > > > > >    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.
> > > >
> > > >         
> > > 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.
> > >
> > >       
> > 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.
> >     
>
>
> 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
>
>
>
>
>   
> > - Mark
> >     
>
>   

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