Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 5 May 2006 07:16:20 -0700

Keep in mind that the discovery is NOT secured. So if you assume that
this unsecured packet implies the peer is dead, then you've created a
very simple DoS attack.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: sujay [mailto:[email-masked]] 
> Sent: Thursday, May 04, 2006 11:22 PM
> To: Pat Calhoun (pacalhou); 'Saravanan Govindan'; 'Dorothy Stanley'
> Cc: 'capwap'
> Subject: RE: [Capwap] Proposed Resolution to Issue 45 
> -Issueoncombiningmessages
> 
> Nevertheless, a discovery recvd in the run state should 
> ideally indicate the peer has gone down, Probably a reboot. 
> It may turn out to be a faster way of detecting Nbr Down than 
> waiting for Nbr dead interval.
> (Of course subject to the packet being authentic)
> 
> In general, perhaps the draft should specify about "treatment 
> of messages when recvd in the incorrect state".
> i.e should it be dropped or any action is to be taken.
> 
> Comments?
> 
> Regds,
> Sujay
> 
> 
> 
> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> Sent: Friday, May 05, 2006 4:24 AM
> To: sujay; Saravanan Govindan; Dorothy Stanley
> Cc: capwap
> Subject: RE: [Capwap] Proposed Resolution to Issue 45 
> -Issueoncombiningmessages
> 
> 
> But we seem to be ignoring the state machine. Keep in mind that this
> scheme has to co-exist with the state machine, so a discovery received
> while in the Run state is not a valid packet to reset the timer. All
> other packets would.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
> > -----Original Message-----
> > From: sujay [mailto:[email-masked]]
> > Sent: Thursday, May 04, 2006 5:25 AM
> > To: 'Saravanan Govindan'; Pat Calhoun (pacalhou); 'Dorothy Stanley'
> > Cc: 'capwap'
> > Subject: RE: [Capwap] Proposed Resolution to Issue 45 
> > -Issueoncombiningmessages
> > 
> > Saravanan,
> > 
> > A valid point, yet ALL control messages should be monitored
> > for which are VALID in the RUN state.
> > 
> > There is no reason for giving special treatment to statistics
> > messages alone.
> > 
> > Considering an implementation, I see no significant overhead
> > in assuming  say a Configure Request packet as a keepalive 
> > packet from the peer.
> > 
> > Regds,
> > Sujay
> > 
> > 
> > 
> > -----Original Message-----
> > From: Saravanan Govindan 
> [mailto:[email-masked]]
> > Sent: Thursday, May 04, 2006 2:29 PM
> > To: Pat Calhoun (pacalhou); Dorothy Stanley
> > Cc: capwap
> > Subject: RE: [Capwap] Proposed Resolution to Issue 45
> > -Issueoncombiningmessages
> > 
> > 
> > Without the text below, the specifications will require an AC
> > to monitor
> > the arrival of "all" control packet with respect to the 
> > EchoInterval and
> > NeighbourDeadInterval timers. There were concerns earlier on 
> > this thread
> > that this is not ideal.  
> >  
> >  
> > Furthermore, not all control packets indicate that a WTP is 
> alive and 
> > doing well. A WTP could fail, re-start and then send Discovery 
> > Requests to an AC. This should not be construed as an 
> indication that
> > the WTP is
> > well. On the other hand, by focusing only on Statistics (WTP Event
> > Request) control messages, it is unambiguous that a WTP is 
> > operational. 
> >  
> > So the text in the specifications should reflect this by 
> having Echo 
> > Requests sent in the absence of Statistics (WTP Event
> > Request) messages.
> > 
> >  
> > Saravanan
> >  
> >  
> >  
> > 
> > 
> > 
> > From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> > Sent: Thursday, May 04, 2006 12:50 PM
> > To: Saravanan Govindan; Dorothy Stanley
> > Cc: Scott G Kelly; capwap
> > Subject: RE: [Capwap] Proposed Resolution to Issue 45
> > -Issueoncombiningmessages
> >  
> > The text you are proposing doesn't change the behavior of the
> > protocol.
> > I'm not sure that it really adds anything since we are 
> stating that an
> > echo is sent if no control packets are sent. You are free to send
> > periodic Statistics messages, which with the new language would not
> > require any Echos to be sent.
> >  
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> >  
> >  
> > 
> > 
> > 
> > From: Saravanan Govindan 
> [mailto:[email-masked]]
> > Sent: Wednesday, May 03, 2006 8:18 PM
> > To: Dorothy Stanley; Pat Calhoun (pacalhou)
> > Cc: Scott G Kelly; capwap
> > Subject: RE: [Capwap] Proposed Resolution to Issue 45
> > -Issueoncombiningmessages
> > Hi Dorothy,
> >  
> > I suggest that the Echo Request MAY only be send in the absence of 
> > specifically Statistics control packets as opposed to any control 
> > packets. The reason for this is that Statistics packets are 
> the only 
> > regular exchanges, so the AC has just one type of packet to monitor 
> > for the timer.
> >  
> > So I'd like to suggest the following text:
> >  
> > From:
> > "If another Echo Request or other control message is not
> > received by the
> > AC when the timer expires, the AC
> > SHOULD consider the WTP to be unreachable"
> >  
> > To:
> > "If another Echo Request or Statistics message is not
> > received by the AC
> > when the timer expires, the AC
> > SHOULD consider the WTP to be unreachable"
> >  
> > Cheers,
> > 
> > Saravanan
> >  
> >  
> >  
> >  
> >  
> > 
> > 
> > 
> > From: Dorothy Stanley [mailto:[email-masked]]
> > Sent: Thursday, May 04, 2006 3:03 AM
> > To: Pat Calhoun (pacalhou)
> > Cc: Scott G Kelly; Saravanan Govindan; capwap
> > Subject: Re: [Capwap] Proposed Resolution to Issue 45
> > -Issueoncombiningmessages
> >  
> > All,
> > 
> > After the lengthy discussion on this topic, I believe that the 
> > conclusion is still to reject the comment, and as Pat 
> summarized, the 
> > echo remains, does not include any
> > statistics, and MAY only be sent in the absence of any 
> > control packets. 
> > 
> > Changes to the text:
> > 
> > Change text in 6.2" Echo Response" from:
> > "If another Echo Request message is not received by the AC when the 
> > timer expires, the AC SHOULD consider the WTP to be unreachable" to
> > 
> > "If another Echo Request or other control message is not
> > received by the
> > AC when the timer expires, the AC
> > SHOULD consider the WTP to be unreachable" 
> > 
> > and from
> > 
> > "If the NeighborDeadInterval timer expires prior to 
> receiving an Echo 
> > Response message, message, the WTP enters the Reset State."
> > to
> > "If the NeighborDeadInterval timer expires prior to 
> receiving an Echo
> > Response message, or other control
> > message, the WTP enters the Reset State."
> > 
> > 
> > Thanks,
> > 
> > Dorothy
> > 
> > Issue 45, Issue on Combining messages currently has the following 
> > discussion in the issues database: Currently, the keepalive and 
> > statistics messages are separated. Separate
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > messages for keepalive signaling and statistics can lead to high 
> > overhead.
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > Initial analysis have shown that these overhead can be reduced 
> > significantly
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > if the messages can be combined.
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > Recommendation:
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > To combine the keepalive and statistics message into one combined 
> > message,
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > thus reducing overhead significantly.
> > 
> > Discussion:
> > 
> > The CAPWAP protocol specification currently supports the
> > Echo Request Message and Echo Response Messages, which are used for 
> > keep-alive purposes, and do not carry message elements.
> > 
> > There is an IEEE 802.11 Statistics measurement 
> element(11.7.2.1), and 
> > several CAPWAP statistics related measurement elements: decryption 
> > error report, WTP descriptor, WTP radio
> > information, WTP reboot statistics.
> > There is no statistics message. 
> > 
> > There is no requirement on how often the statistics related
> > measurement
> > elements must be reported
> > to the AC from the WTP, there is a Statistics timer, see 
> > 7.2.5, which is
> > used by the AC to indicate the
> > timer value to the WTP. (separate question - should the 
> > statistics timer
> > be made general, and indicate the
> > values for the other Section 12 CAPWAP timers too?  Assume that the
> > CAPWAP statistics timer used
> > to determine how often to send the 802.11 specific statistics).
> > 
> > It is not clear that there is a high overhead in keeping the 
> > echo/keep-alive mechanism from the statistics reporting. 
> There is some
> 
> > benefit in keeping the echo messages simple,
> > rather than complicating the processing of those messages.  
> It is true
> > that small messages (echo request, response) have high overhead.
> > In this case, the design choice is to accept the overhead as 
> > the cost of
> > simplicity in design and implementation. 
> > 
> > Recommended resolution: reject the comment, with the
> > explanation in the
> > above paragraph
> > On 4/28/06, Pat Calhoun (pacalhou) < [email-masked]> wrote:
> > I will summarize my thoughts here and not try to inject in 
> > the various 
> > threads, but I agree that the echo remains, does not include any
> > statistics, and MAY only be sent in the absence of any 
> > control packets.
> > I say MAY because an implementation could send them if it 
> wishes, but
> > the receiver must take into account control packets in 
> > addition to the 
> > echo prior to declaring a link dead.
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Scott G Kelly [mailto: [email-masked]]
> > > Sent: Friday, April 21, 2006 5:52 AM
> > > To: Saravanan Govindan
> > > Cc: capwap
> > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 
> > > -Issueoncombiningmessages
> > >
> > > Hi Saravanan,
> > >
> > > Saravanan Govindan wrote:
> > > > Hi Scott,
> > > >
> > > > I think David's note does address the issue on hand.
> > > >
> > > > To formalize;
> > > > 
> > > > The exchange of control messages between a WTP and AC 
> implicitly 
> > > > indicates that the WTP is operational. For the purpose 
> of protocol
> 
> > > > simplicity, I suggest that we focus on statistics messages
> > > alone for
> > > > this purpose, reason being that statistics are periodically
> > > exchanged.
> > > >
> > > > My concern is that by using "any" control message to indicate 
> > > > keepalive (Echo), the AC processing will be 
> complicated. This is 
> > > > because the AC will need to process each control message
> > > for both its own value (e.g.
> > > > Configure Request) and also keepalive value.
> > >
> > > Of course, complexity is a function of many factors, but
> > > there is a straightforward way to implement an echo trigger
> > > with a flag and timer:
> > > when you receive a control message, unconditionally raise 
> the flag.
> > > Periodically (according to your keepalive interval timer) 
> > > check the flag; If it's up, put it down, else send a
> > > keepalive. There are more complicated ways to implement, but
> > > this works just fine.
> > >
> > > On the AC this can easily be implemented by having the
> > > fastpath raise the flag, and having the cp lower it and/or do
> > > whatever it is your AC does if a WTP doesn't report in a
> > > given echo interval (which may be nothing). Pretty basic stuff.
> > >
> > > On the WTP, implementation is similar, except that if the
> > > flag is down, you send the keepalive. Again, very simple 
> and basic.
> > >
> > > > So I suggest keeping it simple - arrival of statistics
> > message from
> > > > WTP means WTP is alive.
> > >
> > > Certainly, a statistics message qualifies as a control
> > > message, so I have no issues with this statement when taken
> > > alone. I'm concerned with the earlier suggestion that the
> > > echo req/reply message be discarded and replaced by the
> > > statistics message. 
> > >
> > > In some cases, the keepalive interval must be *very* 
> brief in order 
> > > to facilitate rapid link loss detection and recovery. I 
> know of one 
> > > vendor who routinely uses a one second interval, and it's 
> > > conceivable that in some scenarios one might choose to use even 
> > > less.
> > >
> > > And keep in mind that WTP and AC requirements are typically 
> > > asymmetric in this regard: the WTP needs to react quickly 
> (maybe try
> 
> > > to find another AC), whereas the AC simply needs to 
> somehow report 
> > > the event. While in some cases reporting might be 
> considered urgent,
> > > this is not the typical (or average) case. 
> > >
> > > The granularity requirements for reporting are typically much 
> > > coarser than those of recovery. That is, the AC may, at 
> it's option,
> 
> > > only check every 10,20,30,... seconds for WTP liveness, 
> and it may 
> > > very well do that via the stats message, rather than the 
> echo, since
> 
> > > this allows echo processing to remain wholly in the AC fastpath.
> > >
> > > But say we eliminate the echo: what happens when, say, 
> 500 WTPs send
> 
> > > stats potentially every second or less?
> > >
> > > I think we still need the echo req/rsp.
> > >
> > > Scott
> > >
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Scott G. Kelly [mailto:[email-masked]]
> > > > Sent: Wednesday, April 19, 2006 1:51 AM
> > > > To: capwap
> > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 
> > > > -Issueoncombiningmessages
> > > >
> > > > Just trying to close the loop: I think David's point (i.e.
> > > that echoes
> > > > should only be sent in the absence of other control
> > > traffic) is dead
> > > > on, and that this effectively closes the question as to
> > > whether echoes
> > > > and stats should be combined in the same messages.
> > > >
> > > > Does anyone disagree?
> > > >
> > > > Scott
> > > >
> > > >
> > > > 
> _________________________________________________________________
> > > > To unsubscribe or modify your subscription options, 
> please visit: 
> > > > http://lists.frascone.com/mailman/listinfo/capwap
> > > >
> > > > Archives: http://lists.frascone.com/pipermail/capwap
> > > >
> > > >
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, please visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap
> > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
> > >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> >  
> > 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: sujay <[email-masked]>
Date: Fri, 05 May 2006 21:17:15 +0530

Correct,.
But could the draft talk about the expected behaviour on reception of 
Messages beyond  the scope of  current state.??
It would be nice to have addition.

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, May 05, 2006 7:46 PM
To: sujay; Saravanan Govindan; Dorothy Stanley
Cc: capwap
Subject: RE: [Capwap] Proposed Resolution to Issue 45

Pat Calhoun

> > A valid point, yet ALL control messages should be monitored for 
> > which are VALID in the RUN state.
> > 
> > Considering an implementation, I see no significant overhead in 
> > assuming  say a Configure Request packet as a keepalive packet from 
> > the peer.
> > 
> > Regds,
> > Sujay
> > 
> > 
> > 
> > Without the text below, the specifications will require an AC to 
> > monitor the arrival of "all" control packet with respect to the
> > EchoInterval and
> > protocol. I'm not sure that it really adds anything since we are
> stating that an
> > -Issueoncombiningmessages Hi Dorothy,
> >  
> > "If another Echo Request or other control message is not received by

> > the AC when the timer expires, the AC
> > "If another Echo Request or Statistics message is not received by 
> > the AC when the timer expires, the AC
> > "If another Echo Request or other control message is not received by

> > the AC when the timer expires, the AC
> > Response message, message, the WTP enters the Reset State." to
> > The CAPWAP protocol specification currently supports the Echo 
> > Request Message and Echo Response Messages, which are used for 
> > measurement elements must be reported
> > that small messages (echo request, response) have high overhead. In 
> > this case, the design choice is to accept the overhead as the cost 
> > of simplicity in design and implementation.
> > 
> > Recommended resolution: reject the comment, with the explanation in 
> > the above paragraph
> > > Of course, complexity is a function of many factors, but there is 
> > > a straightforward way to implement an echo trigger with a flag and

> > > timer: when you receive a control message, unconditionally raise
> the flag.
> > > On the AC this can easily be implemented by having the fastpath 
> > > raise the flag, and having the cp lower it and/or do whatever it 
> > > is your AC does if a WTP doesn't report in a given echo interval 
> > > (which may be nothing). Pretty basic stuff.
> > >
> > > On the WTP, implementation is similar, except that if the flag is 
> > > down, you send the keepalive. Again, very simple
> and basic.
> > >
> > > Certainly, a statistics message qualifies as a control message, so

> > > I have no issues with this statement when taken alone. I'm 
> > > concerned with the earlier suggestion that the echo req/reply 
> > > message be discarded and replaced by the statistics message.
> > >