Subject: Re: [Pana] pana-pana Issue227: Comments on Access Phase

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 03 Jan 2006 16:06:52 -0500

Hi Alper,

On Fri, Dec 30, 2005 at 12:51:14PM +0200, Alper Yegin wrote:
> 
> I'm not sure if we really need to allow rate limiting the Ping-Answer.
> 
> If the sender is misbehaving and sending bursts of Ping-Requests, the value
> of rate limiting the answers is diminished (processing and bandwidth is
> already taxed).

I think the tax could be doubled if ping-answers are not rate-limited.

> 
> Also, when in a system absence of Ping-Answers lead to termination of the
> session, the rate limiting leads to unintended session break down.

When a ping answer is not returned due to the rate limiting, the ping
request will be retransmitted with an increased retransmission
interval, and the exponential backoff nature will reduce the
transmission rate and will finally make some retransmitted request get
answered.  So I think the unintended session break-down is less likely
to happen as long as the requester is well-behaving in terms of
retransmissions.

Yoshihiro Ohba

> 
> I'm thinking that suggesting rate limiting the Ping-Request is the right
> choice.
> 
> 
> Alper
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Yoshihiro Ohba
> > Sent: Thursday, December 29, 2005 5:56 PM
> > To: Jari Arkko
> > Cc: W. Mark Townsley; Yoshihiro Ohba; [email-masked]
> > Subject: Re: [Pana] pana-pana Issue227: Comments on Access Phase
> > 
> > On Thu, Dec 29, 2005 at 08:49:06AM +0200, Jari Arkko wrote:
> > >
> > > Implementations MUST limit the rate of performing this test.
> > > =>
> > > The rate at which PANA-Ping-Requests are generated and the
> > > rate at which responses to them can be sent MUST be limited.
> > 
> > I agree.
> > 
> > >
> > > >I assume ping requests can overlap answers, with the sequence number
> > > >being used to match up requests with answers?
> > > >
> > > >
> > > Apparently, no. The spec (Section 5.2) says that a peer can only have
> > one
> > > outstanding request at a time. So one side can not send a new ping
> > > before it has gotten an answer. But both sides may be pinging
> > > simultaneously,
> > > though, because the sequence number space is always the request
> > > initiator's space.
> > >
> > > >What are the ramifications of an unanswered ping request? Is it
> > > >retransmitted? Is the sequence number listed here part of the same
> > > >number space as other PANA messages (I would suggest it NOT being a
> > part
> > > >of the same number space)?
> > > >
> > > >
> > > Apparently it is the same space. Given that no more than one
> > > outstanding request may exist at any time, an unanswered ping
> > > essentially kills the session (unless retransmissions succeed in
> > > getting a ping answer).
> > >
> > > This could be changed, but appears to have a significant effect
> > > on message structures etc because then the ping messages would
> > > be different from other PANA messages, and treated differently.
> > 
> > I agree with Jari.  Having a separate sequence number space for
> > PANA-Ping will significantly impact the protocol design.  IMO, we
> > should avoid significant design change unless the change is expected
> > to significantly improve performance or security.
> > 
> > >
> > > By the way, text in 5.2 (" The PaC and PAA MUST respond to
> > > duplicate requests.") may be in conflict with the rate limitation
> > > requirement.
> > 
> > Hmm, it looks like that.  How about the following change?
> > 
> > In Section 5.2, change:
> > 
> > "
> >    The PaC and PAA MUST respond to duplicate requests.  The last
> >    transmitted answer MAY be cached in case it is not received by the
> >    peer and that generates a retransmission of the last request.  When
> >    available, the cached answer can be used instead of fully processing
> >    the retransmitted request and forming a new answer from scratch.
> > "
> > 
> > to:
> > 
> > "
> >    The PaC and PAA MUST respond to duplicate requests as long as the
> >    responding rate does not exceed a certain threshold value.  The
> >    last transmitted answer MAY be cached in case it is not received by
> >    the peer and that generates a retransmission of the last request.
> >    When available, the cached answer can be used instead of fully
> >    processing the retransmitted request and forming a new answer from
> >    scratch.
> > "
> > 
> > Yoshihiro Ohba
> > 
> > 
> > 
> > >
> > > --Jari
> > >
> > >
> > > _______________________________________________
> > > Pana mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pana
> > >
> > 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> 
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 4 Jan 2006 19:45:57 +0200

I agree.

> to happen as long as the requester is well-behaving in terms of

Yes I expect that the retransmissions will overrun the rate limiting. So, is
it sufficient to say "MAY rate limit the ping responses"? I hope we don't
have to get into how this rate limiting shall be implemented (parameter
negotiations, etc.). Also, do we also need to do the same on any other
messages? I'm trying to assess the impact of this on the design.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 04 Jan 2006 13:48:57 -0500

On Wed, Jan 04, 2006 at 07:45:57PM +0200, Alper Yegin wrote:
> it sufficient to say "MAY rate limit the ping responses"? 

"MAY" works for me.

> I hope we don't

I think we need to have the same rule for PANA-Notification as
notification exchange can repeatedly occur in the same way as
PANA-Ping in any phase other than Termination Phase.

I don't think we need to do the same thing for other messages that are
allowed only in specific phases, except for rate-limiting *duplicate*
answers which should be a "MUST" to deal with replay attacks.

Yoshihiro Ohba