Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 18 Jan 2006 12:23:32 -0800

> On Dec 12, 2005, at 11:42 PM, sujay wrote:
> > b) page 32 --  section 5.1 "Discovery requests MUST be sent 
> by an ...
> > AND when no echo responses are received and the WTP"    I think it
> > should say that "Discovery requests MUST be sent by a WTP when the
> > WTP returns to the idle state.   This can occur for example when no
> > echo responses are received for NeibhborDeadInteval. "
> >
> > Suj> IMHO in the Idle State No Discovery requests are sent, once
> > entering
> > the Idle state, the SM moves to Discovery state before sending Disc 
> > Req messages.
> >
> > The section talks about when as you rightly pointed out no echo 
> > responses are Received for NeighborDeadInterval.
> >
> Thanks --  So does idle state wait the random time interval 
> and then move to discovery or is done in the discovery phase ?
> If the initial delay is done in the idle phase then the 
> requirement is after no echo packets -- transition to idle phase.

Does the following text solve the issue, or do you need additional
clarification/changes in the spec?

        Discovery requests MUST be sent by a WTP when no echo responses
are 
        received for NeighborDeadInterval and the WTP returns to the
Idle 
        state.  Discovery requests are sent after NeighborDeadInterval,
they 
        MUST be sent after waiting for a random delay less than 
        MaxDiscoveryInterval.  A WTP MAY send up to a maximum of
MaxDiscoveries 
        discoveries, waiting for a random delay less than
MaxDiscoveryInterval 
        between each successive discovery.
> 
> > d) Page 37 -- Section 5.2.4  WTP manager control IPV4 address -- do 
> > not understand the text --  is there only one ip address ?  
> if so -- 
> > then the ip address is used to return the interface of the AC.  If 
> > only one address -- how is load balancing done ?
> >
> > Suj> If the AC has more than one Interfaces open for the WTP to
> > join, it
> > specifies each of these ip address's with Individual TLV's,
> > - right, for single ip interface load balancing cannot be 
> done ,(given 
> > only one AC) the AC should return its own interface Ip address.
> 
> So the problem is the ip address CAN repeat but this is not 
> reflected in the definition of the length?
An AC would include one such message element per interface it has. So
the length is correct.

> >
> >
> > h) Page 65 -- Blacklist Entry's  -- This whole area is not good  
> > from my
> > point of view.  When I configure a firewall I say what is allowed
> > (explicitly) and forbid everything else -- there is no way I can  
> > give a
> > list of trusted stations and forbid everything else.  This 
> makes live
> > very difficult.  There is room for a blacklist -- but an allowed  
> > list is
> > also needed.
> >
> >
> > Suj> In my opinion blacklisting is to prevent any .11 mgt 
> frames from
> > passing upto the AC for the current WTP-AC session.
> > - to blacklist one MAC address and allow others is more exact and
> > specific rather than knowing ALL those which are
> > Allowed, either way the one which is allowed will is kept 
> the Radius,
> > you could put your 'allowed' list there !
> 
> I think there is a use for BOTH cases.  in a secure environment I do  
> not want control frames from rogue AP's.

Looks like we are still not in complete agreement on this one. Typical
802.11
Devices include an approved list (known as MAC Filter). It is assumed
that this
function is provided w/o CAPWAP involvement, while a blacklist is
provided
by CAPWAP. If I understsand correct, you would like a replicated set of
messages
to serve as the permit list? Do others agree?

> >
> >
> > i) Page 70 -- Image Data -- do not understand how this can work --  
> > only
> > 2 fragments allowed -- no count of what is being sent etc 
> -- no way to
> > detect packet loss ---  why not use data xfer mechanism of 
> tftp ?  --
> > the blocks are numbered == etc BUT define a md5 hash of the whole  
> > image
> > and give its length in the initial request.
> >
> > Suj> LWAPP has the in-band Image transfer mechanism, some 
> protocols  
> > use
> > what you have specified.
> >
> 
> I do not understand how this can work as defined in the text.  I  
> understand I could overlay it but it needs a definition.

Could you help identify what needs a definition?

> > k) Page 72 -- Section 8.5.2   Duplicate IP address == what is a
> > host ?  Is this a mobile station ?  What about the case of a mobile
> > station having the SAME mac address as a already connected mobile
> > station to the WTP.  == only useful if NOT split mac
> >
> > Suj> host here is the WTP itself, MAC address are unique so there  
> > should
> > not be a case of a  mobile station having
> > the same MAC address as another one.
> >
> Can we change text to say WTP -- thanks
> Just like there should not be a duplicate IP address in the network  
> there should not be a duplicate MAC address, but MAC addresses are  
> also soft
> the linux command
> ifconfig hwether allows one to change the mac address

I'm confused here because the text reads fine to me. I did change host
to
IP device, but I don't think this is addressing your original comment.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Philip Rakity <[email-masked]>
Date: Wed, 18 Jan 2006 13:30:06 -0800

Comments belowl

>         between each successive discovery.

TEXT above is fine -- Thank You.

> An AC would include one such message element per interface it has. So

Could you add a note that message element is repeated per interface  
being sent to the WTP.

> to serve as the permit list? Do others agree?

Yes -- My Point.  In a secure environment I want to say what is  
allowed and forbid other things.

> Could you help identify what needs a definition?

I did not understand (and now do) how this mechanism works.  But I do  
not understand how one knows the transfer is finished?

Is there also another end-case to know if the xfer is beginning ?

> IP device, but I don't think this is addressing your original comment.

The change to IP device addresses my concern.

> CTO, Wireless Networking Business Unit

Philip Rakity
[email-masked]

This message is hereby marked U4EA CONFIDENTIAL, is intended only for  
the use of the individual or individuals to which it is addressed and  
shall notbe disclose or made available to any other party except with  
the prior written consent of the sender. If the reader of this  
message is not the intended recipient, you are hereby notified that  
any dissemination, distribution or copying of this message is  
strictly prohibited. If you have received this communication in  
error, please notify us immediately by replying to the sender of this  
E-Mail.

---

From: Philip Rakity <[email-masked]>
Date: Wed, 18 Jan 2006 13:51:05 -0800

We should require MTU discovery and if this is not available then  
require the JOIN request to do this

Change

If the transport used does not provide MTU path discovery, the
    initial Join Request is padded with the Test message element to 1596
    bytes.  If a Join Response is received, the WTP can forward frames
    without requiring any fragmentation.  If no Join Response is
    received, it issues a second Join Request padded with the Test
    payload to a total of 1500 bytes.  The WTP continues to cycle from
    large (1596) to small (1500) packets until a Join Response has been
    received , or until both packets sizes have been retransmitted 3
    times .  If the Join Response is not received after the maximum
    number of retransmissions, the WTP MUST abandon the AC and restart
    the discovery phase.

To
If the transport used does not provide MTU path discovery, the
    initial Join Request is used to perform this function.

The Test message element is used to pad the join request (including  
all headers) to the lesser of the Ethernet MTU and Wireless MTU.

If a Join Response is received, the WTP can forward frames
    without requiring any fragmentation.  If no Join Response is
    received, it issues a second Join Request padded with the Test
    payload to a total of 1500 bytes.  The WTP continues to cycle from
    lesser of the Ethernet MTU and Wireless MTU to small (1500)  
packets until a Join Response has been
    received , or until both packets sizes have been retransmitted 3
    times .  If the Join Response is not received after the maximum
    number of retransmissions, the WTP MUST abandon the AC and restart
    the discovery phase.

---

From: sujay <[email-masked]>
Date: Thu, 19 Jan 2006 17:32:13 +0530

Hi, 
Albeit a late reply;
See SUJ>> below;

-----Original Message-----
From: Philip Rakity [mailto:[email-masked]] 
Sent: Thursday, January 19, 2006 3:00 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Comments on Draft 3 -- LWAPP

Comments belowl

<snipped>

>>>
>>>
>>> h) Page 65 -- Blacklist Entry's  -- This whole area is not good from

>>> my point of view.  When I configure a firewall I say what is allowed
>>> list is also needed.
>>> specific rather than knowing ALL those which are Allowed, either way

>>> the one which is allowed will is kept
>> the Radius,

> 802.11 Devices include an approved list (known as MAC Filter). It is 
> assumed that this

SUJ>> AFAIK it should be best suited on the 'default' mode of 802.11
Device behaviour , if it blocks ALL, use a permit list.
If it allows ALL , use a deny list.

Possibly the default mode is allow ALL !

>>> only 2 fragments allowed -- no count of what is being sent etc
>> -- no way to
>>> image and give its length in the initial request.
>>>

SUJ>> it is by the length of Image Data , iff less than 1024 indicates
operation over, else if the op-code indicates a failure.

Philip Rakity
[email-masked]