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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 20 Dec 2005 13:23:36 -0800

> a) Use of "integer" is not consistent in the document --- most of the
> time it means unsigned, sometimes signed (but marked as signed), but
> sometimes the phrase "unsigned integer" is used and this then makes me
> wonder if the fields marked integer are signed or not.
Unless anyone objects, I will go ahead and make the changes to ensure we
have consistency.

> 
> 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.

Sujay is correct. The text is correct, except that I notice the use of
"an WTP", which really should be "a WTP". I will make the gramatical
changes to the document.

> 
> 
> c) Page 35 -- Radio Type --  no 802.11b (only) -- no 802.11n -- no
> superG -- no superA

I will add 802.11n, because it is a valid IEEE MAC. However,
SuperA/SuperG are proprietary mechanisms, and given that each MAC vendor
had a separate way of supporting "turbo modes". I would recommend that
we not include these modes of operation.

I would also like to remove UWB and 802.16 until such time that we
actually define a CAPWAP extension for these radios. Further, I believe
that 8 bits is too small, so I would propose that this field be changed
to 16 bits.

> 
> 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.

Sujay is correct - load balancing can only happen if there are multiple
addresses on which load can be balanced. A single IP address does not
provide this - only one is possible. That said, I've changed the
sentence to be more specific:

   "In the event that multiple such message elements are
    returned, the WTP is expected to perform load balancing across
    the multiple interfaces."

> 
> 
> e) Page 41 -- Section 6.1  Join Request  -- 3rd paragraph -- Why the
> 1596 MTU limit -- how was this number chosen ? == (RIF routes 
> if vlan ?)
> if I use 802.3 then I have seen h/w do 1522 (4 byte vlan
> tag) -- some number a little bigger than 1522 and h/w do 16K bytes --
> (intel ixp 4xx series) ---  The 16K number is bigger than the 
> 4k SDU for
> wireless medium...  Would it be better to base the discovery 
> on the MTU
> of the wireless media and work down ?

Basically took Ethernet MTU, and then added the LWAPP, UDP, IP and
Ethernet headers. While we could look at wireless media MTUs, such as
802.11 which is 2K+, but the reality is that stations never transmit
greater than Ethernet MTU. That said, if you have a recommendation, I'm
all ears ;-)

> 
> f) Page 52 -- Section 6.5 and Section 6.6 -- Change item that says see
> Figure 2 -- to read see section 2.2
Done.

> 
> g) Page 60 -- REboot Statistics == this requires the WTP maintain
> state to know if the last Failure Type was LWAPP initiated.   Same
> comment for Crash count.  No value defined for state not maintained by
> WTP.  Add cross reference to section where AC tells WTP to reboot.

I've added the cross reference, but I don't quite understand your
comment about maintaining state, other perhaps you wanted me to
specifically state that the WTP needs to maintain this information. Not
sure what you mean about state not maintained by WTP either.

> 
> 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 !

Sujay is once more correct. An AC may interface with some backend
database, such as RADIUS, to detect whether a MAC address is allowed on
the network. However, when a device is considered to malicious (or for
some other reason we want to stop it from trying to associate), the
blacklist is used.

> 
> 
> 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.

Right. Packet loss is detected via the reliable LWAPP transport. We
could use tftp, but then we would have to define how to bootstrap the
security, and figure out how to integrate the state machines. This is a
fairly simplistic transfering approach.

> 
> 
> j) Page 72 -- Section 8.5.1 Decryption Error Report   == add note
> about only useful if split mac.
> 
> Suj> For both local and split Encrytpion / Decryption is done 
> at the WTP
> , so we need to send Error reports
> for both cases.

I have added the following text:
   "Note that this error reporting mechanism is not 
    used if encryption and decryption services are
    provided via the AC."

> 
> 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.

The case being raised is not the same as a duplicate IP address, and in
this case host is any device that is using the same IP address as the
WTP - I can't be specific, because I have no idea what it could be. That
said, a DUP MAC Address is hard to determine on a wireless network and
could be provided via the AC.

> 
> 
> l) General comment -- there is no command to synchronize  
> time (set the
> clocks) in the WTP to a common time base

Good catch - this is missing.

> 
> 
> j) General comment -- why not use the text in the 802.11 MIB 
> definitions
> and the name of the MIB entry where these are used to 
> configure the WTP

See r) below.

> 
> k) Page 94 -- Section 11.3.1 -- WLAN's field -- just do NOT understand
> how setting a bit relates to the WLAN ID's used later in the 
> document --
> can you give an example or two ?  Only 16 WLAN ID's allowed ??/

Well the text specifically states that if the AC wants to send a
broadcast or multicast packet, it sets the BSSIDs that it wishes to
transmit the packets on. This eliminates the need for the AC to have to
replicate the packet n times. In terms of the number of WLAN IDs
allowed, 16 is actually a large number because each BSSID has to
transmit beacons every beacon interval period (typically 100ms), so
that's 16 packets per 100ms of pure overhead.

> 
> l) Page 97 -- WLAN ID -- field is 8 bits -- other places in 
> document 16
> bits
> 
> Suj>It is to be used a 8 bit field only , the 16 bit( 
> status/wlan field
> in header)is just a place holder
> For the 8 bit WLAN ID as well as the 16bit Status combination, subject
> to usage.

This is not a bitfield, whereas the previous comment had to be a
bitfield in order to allow for multiple BSSIDs to be specified.
> 
> 
> m) Page 102 -- IEEE 802.11 stats -- Why not pad out Radio ID with 3
> bytes of "reserved field" so all other fields are 32 bit 
> aligned or move
> it to the end of definition (after decryption errors).

I'm ok with this recommendation and will make the necessary change.

> 
> n) Page 105 -- WLAN ID -- picture is 8 bits -- text is 16 bits
> 
> Suj> See above

Actually, this was a bug and I have corrected the text.

> o) Page 109 WLAN Capability -- can you rename this and ALL 
> other fields
> to use the same terms as the 802.11 base standard or the MIB (very
> confusing) -- or cross reference

Please see r) below.

> 
> p) Page 113 -- Country Code -- reference 802.11d since this is the
> definition

If you insist, but 802.11d will point you to this exact reference and we
would therefore end up creating a double reference just for fun :( 

My personal preference is to keep this.

> 
> q) Page 113 -- Rate Set -- is length wrong ?  should be >= 2 otherwise
> what is definition for rates NOT used

Done

> 
> r) Page 115 -- RTS Threshold etc -- use wording from the MIB 
> definitions
> for all of these entries and reference mib object

Well.... I've opened up 8802-11-1999.pdf, and I see that the text for
RTS Threshold is nearly a replica of the MIB text, as I recall doing in
the first version of this document, except I see that the word Shall is
not present. Is this the main concern? (btw, I recall removing Shall
because it is not IETF language). I've also looked at the next field,
which is Short Retry, and once more it is the same.

As far as using the MIB variable names, it would seem odd to me to have
dot11RTSThreshold, but if the group wants to have its message elements
named after MIB objects, then I'm ok with it. 

I can add references to the 802.11 document for each such field, if the
group feels this is justified.

> 
> s) Page 119 -- IEEE Antenna length -- length sound be >= 5

You are correct

> 
> t) Page 120 -- Supported rates -- length >= 2 and <= 9

Done

> 
> u) Page 122 - WTP Qos -- length is 2 if untagged or 802.1p  -- if dscp
> it is 2 + (10)*dscp entries
> 
> v) Security -- any reason ssl could not be used even for level 2
> encryption?  since the link is PT to PT -- the ip 
> address/header is not
> need -- then almost same code as layer 3 -- and the package is public
> domain so easy to hack

This is being discussed separately.

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: Tue, 20 Dec 2005 15:26:48 -0800

Hi Pat,

Thank you very much.  Some additional comments are below.

regards,

Philip

<snip>

> greater than Ethernet MTU. That said, if you have a recommendation,  

Could you add a note on how the MTU was chosen.  I think this will  
help.  Does the MTU include room for a vlan header at level 2 ?

> sure what you mean about state not maintained by WTP either.

If I have a system that does not count reboots etc then what value is  
used to indicate it does not keep the statistics ?
zero is a bad number  -- since maybe the event did not happen.  Can  
we define all 1's to indicate no statistics kept ?

> some other reason we want to stop it from trying to associate), the

He is correct that this is how I could stop rogue's but suppose I do  
not WANT to have this problem of rogue detection.   If I can define  
what is allowed then there are NO rouges and nothing to manage.  It  
is another way to solve the problem.  I am in FAVOR of the blacklist  
-- just want something for more secure enviroments.

> fairly simplistic transfering approach.

What mechanism is used to load image data ?  I do not understand how  
the API is used to load an image of a few megs ?

> that's 16 packets per 100ms of pure overhead.

Can you give an example showing how this is used for say 3 different  
WLAN ID's.   I am confused.  Can we put the example as an appendix ?

> My personal preference is to keep this.

The words are fine ---
just wanted a note adding "802.11d" so I knew where this defintion  
came from.

> group feels this is justified.

My rationale is that having 1st read the spec I did not  understand  
that the items defined were already defined in a MIB.
I thought they were defined in a different manner than the 802.11  
spec.  BUT I had to go searching to see that this was not true. So,  
what is being set and returned are the MIB objects and a note saying  
that would make life easier for the next person.  If we use the name  
of the object then as an implementor it is more obvious what to do.