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