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
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.
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.
- Mark
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
