From rkp@intotoinc.com Fri Aug 1 05:11:41 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Fri, 01 Aug 2003 09:41:41 +0530 Subject: [Lwapp] where to validate images References: <0D3F1B25E75EE24483A6E69201142C867DA974@paris.synad.com> Message-ID: <3F29E87D.7030209@intotoinc.com> --------------030607090303060304010206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I think signing of code image should be out of the scope of this charter. We can assume that AR administrator securely loads the images of AP in the AR or some management station. Through LWAPP protocol, the image is securely downloaded by AR onto the APs. It is better to leave the code signing and code verification to the AP vendor. Rama Krishna Prasad Intoto Software (India) Pvt Ltd. David Molnar wrote: >On Thu, 31 Jul 2003, Mike Moreton wrote: > > > >>How about a solution where the administrator installs the appropriate >>images on the AR, and the AR downloads them? >> >> > >I agree with this. I do not think the APs need to go out and get new >images; the new images should come from the AR. > > > >>As the format of the boot >>image will be vendor specific (there is absolutely no benefit in making >>it generic) any AP vendor who wants to sign their images can do so >>without any involvement from the AR and check them in the AP. >> >> > >Personally, I tend to agree that images should be checked at the AP. > >The questions is, check them using what public key? The AP manufacturer >can embed its own public key in the AP at manufacture time. Then all >images would have to be signed with that key. This is fine if we believe >all AP images will come from that vendor. In a world where we standardize >an AP-AR protocol and let the AP vendors deal with the implementation, I >believe that is reasonable. > >The world may be more general than that, however. At least if we buy into >Andrew Frame's proposal, it looks like APs may run many different images >written by many different vendors. Is it reasonable to ask for all these >images to be signed by the vendor of the AP? This turns the AP vendor into >a gatekeeper for running images on that AP platform, which may not be >desireable. > >One alternative is to put a global CA public key in the AP instead of a >vendor's public key. Then we all go pay money to the CA, similar to Java >codesigning. Another alternative is to have AP vendors issue certificates >to image vendors allowing them to sign their own images and have them run >on the AP; in effect each AP vendor becomes the root CA for their device. > >These PKI concerns are, IMHO, the best argument against pushing image >validation into the AP. > >I'm still not clear if we all believe that firmware download will be in >spec or not, by the way. This discussion seems a bit premature until we >settle that, although I'm happy to have it. > > > >>I think validation in the AR just protects you from attack by your >>system administrators. I would venture to suggest that that is a pretty >>pointless feature. >> >> > >I respectfully disagree -- validation in the AR gives the system >administrators confidence that they have not downloaded a malicious AP >image masquerading as the real thing. It's the same reason we sign RPMs - >someone might have changed the image on disk after download, or you might >have downloaded it from an untrustworthy source. Even honest system >administrators can fall victim to these problems. > >Validation on AR allows a sysadmin to catch this malicious image before >pushing it to all APs. The AR also will certainly have enough computing >power to perform signature verification. > >Of course, validation on the AR does not help in the case of a rogue AR. >That's why we would want to also consider validation on the AP. > >-David > >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp > > > --------------030607090303060304010206 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi,
    I think signing of code image should be out of the scope of this charter.
    We can assume that AR administrator securely loads the images of AP
    in the AR or some management station. Through LWAPP protocol,
    the image is securely downloaded by AR onto the APs.  It is better to leave
    the code signing and code verification to the AP vendor.


 Rama Krishna Prasad
 Intoto Software (India) Pvt Ltd.


David Molnar wrote:
On Thu, 31 Jul 2003, Mike Moreton wrote:

  
How about a solution where the administrator installs the appropriate
images on the AR, and the AR downloads them?
    

I agree with this. I do not think the APs need to go out and get new
images; the new images should come from the AR.

  
As the format of the boot
image will be vendor specific (there is absolutely no benefit in making
it generic) any AP vendor who wants to sign their images can do so
without any involvement from the AR and check them in the AP.
    

Personally, I tend to agree that images should be checked at the AP.

The questions is, check them using what public key? The AP manufacturer
can embed its own public key in the AP at manufacture time. Then all
images would have to be signed with that key. This is fine if we believe
all AP images will come from that vendor. In a world where we standardize
an AP-AR protocol and let the AP vendors deal with the implementation, I
believe that is reasonable.

The world may be more general than that, however. At least if we buy into
Andrew Frame's proposal, it looks like APs may run many different images
written by many different vendors. Is it reasonable to ask for all these
images to be signed by the vendor of the AP? This turns the AP vendor into
a gatekeeper for running images on that AP platform, which may not be
desireable.

One alternative is to put a global CA public key in the AP instead of a
vendor's public key. Then we all go pay money to the CA, similar to Java
codesigning. Another alternative is to have AP vendors issue certificates
to image vendors allowing them to sign their own images and have them run
on the AP; in effect each AP vendor becomes the root CA for their device.

These PKI concerns are, IMHO, the best argument against pushing image
validation into the AP.

I'm still not clear if we all believe that firmware download will be in
spec or not, by the way. This discussion seems a bit premature until we
settle that, although I'm happy to have it.

  
I think validation in the AR just protects you from attack by your
system administrators.  I would venture to suggest that that is a pretty
pointless feature.
    

I respectfully disagree -- validation in the AR gives the system
administrators confidence that they have not downloaded a malicious AP
image masquerading as the real thing. It's the same reason we sign RPMs -
someone might have changed the image on disk after download, or you might
have downloaded it from an untrustworthy source. Even honest system
administrators can fall victim to these problems.

Validation on AR allows a sysadmin to catch this malicious image before
pushing it to all APs. The AR also will certainly have enough computing
power to perform signature verification.

Of course, validation on the AR does not help in the case of a rogue AR.
That's why we would want to also consider validation on the AP.

-David

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

--------------030607090303060304010206-- From aframe@trapezenetworks.com Fri Aug 1 08:00:01 2003 From: aframe@trapezenetworks.com (Andrew Frame) Date: Fri, 1 Aug 2003 00:00:01 -0700 Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) Message-ID: Tm90IG5lY2Vzc2FyaWx5LiBTaG9ydGN1dHMgc3VjaCBhcyBoYXJkd2FyZSBhYnN0cmFjdGlvbiBp bnRlcmZhY2VzIGNhbiBiZSB1c2VkIGluIG9yZGVyIHRvIGV4cGVkaXRlIGRldmVsb3BtZW50Li4u Lg0KIA0KTm90IGFsbCBBUHMgd2lsbCBiZSAnbGlnaHQnLCBub3QgYWxsIEFQcyB3aWxsIHJ1biB0 aGlzIHByb3Bvc2VkIHByb3RvY29sLi4uLg0KIA0KQW5kcmV3DQoNCgktLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLSANCglGcm9tOiBSYW5keSBCdXNoIFttYWlsdG86cmFuZHlAcHNnLmNvbV0gDQoJ U2VudDogVGh1IDcvMzEvMjAwMyA5OjAwIEFNIA0KCVRvOiBBbmRyZXcgRnJhbWUgDQoJQ2M6IHB1 bmVldGJAbXl3YXkuY29tOyBsd2FwcEBmcmFzY29uZS5jb20gDQoJU3ViamVjdDogUkU6IFNjb3Bl IG9mIENoYXJ0ZXIgRGlzY3Vzc2lvbiAod2FzOiBSZTogW0x3YXBwXSBDZXJ0aWZpY2F0ZXMsIERp c2NvdmVyeSBSZXF1ZXN0L1JlcGx5LCBhbmQgdmFsaWRhdGlvbi4pIA0KCQ0KCQ0KDQoJPiBUaGUg Y29kZSB0aGF0IGRyaXZlcyB0aGUgQVAgaXMgd3JpdHRlbiBieSB0aGUgY29udHJvbGxlciB2ZW5k b3IsIG5vdCB0aGUNCgk+IEFQIHZlbmRvci4NCgkNCglkb2VzIHRoaXMgbm90IGFzc3VtZSB0aGF0 IGFsbCBBUCB2ZW5kb3JzIEEgd2lsbCBoYXZlIHRvIGRpc2Nsb3NlIGFsbA0KCWRldGFpbHMgb2Yg dGhlaXIgaGFyZHdhcmUgdG8gYWxsIENvbnRyb2xsZXIgdmVuZG9ycyBDLCBhbmQgdGhhdCBhbGwN CglDIHdpbGwgaGF2ZSB0byBpbXBsZW1lbnQgaW1hZ2VzIGZvciBhbGwgQT8gIGhvdyBsaWtlbHkg aXMgdGhpcyB0bw0KCWhhcHBlbj8NCgkNCglyYW5keQ0KCQ0KCQ0KDQo= From aframe@trapezenetworks.com Fri Aug 1 08:22:30 2003 From: aframe@trapezenetworks.com (Andrew Frame) Date: Fri, 1 Aug 2003 00:22:30 -0700 Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) Message-ID: VW5mb3J0dW5hdGVseSwgdGhlcmUgaXMgbm8gZWFzeSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0u IEJvdGggTFdBUFAgKyBpbWFnZS10cmFuc3BsYW50IHByb3RvY29sJyBoYXZlIHVwcyBhbmQgZG93 bnMuICBBY2NlcHRlbmNlIG9mIExXQVBQcyBhcmNoaXRlY3R1cmUgaXMgdW5jZXJ0YWluLCBoZXJl IGlzIGEgcXVvdGUgZnJvbSBDaXNjbyB0aGF0IGhpdCB0aGUgcHJlc3MgYSBjb3VwbGUgZGF5cyBh Z28uLi4uLg0KIA0KLS0tLS0tLS0tLQ0KDQpDb25zaWRlciB0aGUgaW50ZXJlc3RzIG9mIHRoZSB2 ZW5kb3JzLiBXTEFODQpoZWF2eXdlaWdodCBDaXNjbyAtIGV2ZXJ5IGVudGVycHJpc2UtY2xhc3Mg V0xBTi1tYWtlcidzIHByaW1hcnkNCmNvbXBldGl0aW9uIC0gdm90ZWQgYWdhaW5zdCBmb3JtaW5n IHRoZSBMV0FQUCBJRVRGIFdvcmtpbmcNCkdyb3VwLCBkZXNwaXRlIHRoZSBmYWN0IHRoYXQgYSBD aXNjbyBlbmdpbmVlciBjby1hdXRob3JlZCB0aGUNCmRyYWZ0J3Mgb3JpZ2luYWwgc3BlYy4NCg0K Q2lzY28gaGFzIG1hZGUgbm8gYm9uZXMgYWJvdXQgaXRzIGRpc2RhaW4gZm9yIHRoZSBzdHJpcHBl ZC1kb3duDQpyYWRpbyBhcHByb2FjaCBhbmQgaW50ZW5kcyB0byByZXRhaW4gaXRzIHJlbm93bmVk IElPUw0Kc29mdHdhcmUtYmFzZWQgaW50ZWxsaWdlbnQgbmV0d29yayBmZWF0dXJlcyBzdXBwb3J0 ZWQgaW4gaXRzDQpBUHMuIE5vdGUsIHRob3VnaCwgdGhhdCBwcm9kdWN0IGxpbmUgbWFuYWdlciBS b24gU2VpZGUgaGFzDQpjb25jZWRlZCB0aGF0LCBvdmVyIHRpbWUsIHRoZSBjb21wYW55J3MgbmV3 bHkgYW5ub3VuY2VkDQpTdHJ1Y3R1cmVkIFdpcmVsZXNzLUF3YXJlIE5ldHdvcmsgZnJhbWV3b3Jr IHdpbGwgZ2l2ZSBjdXN0b21lcnMNCnNvbWUgb3B0aW9ucyB0byBydW4gZmVhdHVyZXMgZWl0aGVy IGluIHRoZWlyIEFQcyBvciBpbiB0aGVpcg0KQ2lzY28gcm91dGVyL3N3aXRjaGVzLg0KDQoiRGlm ZmVyZW50IGVudmlyb25tZW50cyBjYWxsIGZvciBkaWZmZXJlbnQgYXJjaGl0ZWN0dXJhbA0Kc29s dXRpb25zLCIgU2VpZGUgc2F5cy4gIkZvciBleGFtcGxlLCBhIGNhbXB1cyBuZXR3b3JrIG1pZ2h0 DQpoYXZlIGxpdHRsZSB1c2UgZm9yIFJBRElVUyBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlcyBpbiB0 aGUgQVAsDQpiZWNhdXNlIHRoZSBSQURJVVMgc2VydmVyIGl0c2VsZiBpcyBsb2NhbC4gSG93ZXZl ciwgYSBicmFuY2gNCm9mZmljZSBtaWdodCBwdXQgUkFESVVTIHNlcnZpY2VzIGludG8gdGhlIEFQ IGZvciByZWR1bmRhbmN5OyBpbg0KdGhlIGV2ZW50IHRoYXQgYSBXQU4gbGluayB0byB0aGUgY2Vu dHJhbCBSQURJVVMgc2VydmVyIG1pZ2h0IGJlDQpvdXQgb2YgY29tbWlzc2lvbiwgbG9jYWwgdXNl cnMgY291bGQgc3RpbGwgYXV0aGVudGljYXRlIHZpYQ0KdGhlaXIgQVBzLiINCg0KLS0tLS0tDQoN Cg0KVGhlICdpbWFnZS10cmFuc3BsYW50IHByb3RvY29sJyBhbGxvd3MgZm9yIGFueSBjb250cm9s IGRpc3RyaWJ1dGlvbiBtb2RlbCBhbiBBUCBDb250cm9sbGVyIG1pZ2h0IHdhbnQsIGluY2x1ZGlu ZyB0aGUgb25lIG1lbnRpb25lZCBieSBDaXNjby4NCg0KQW5kcmV3DQoNCgktLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLSANCglGcm9tOiBSYW5keSBCdXNoIFttYWlsdG86cmFuZHlAcHNnLmNvbV0g DQoJU2VudDogVGh1IDcvMzEvMjAwMyA5OjAyIEFNIA0KCVRvOiBBbmRyZXcgRnJhbWUgDQoJQ2M6 IFBhdCBSLiBDYWxob3VuOyBwdW5lZXRiQG15d2F5LmNvbTsgbHdhcHBAZnJhc2NvbmUuY29tIA0K CVN1YmplY3Q6IFJFOiBTY29wZSBvZiBDaGFydGVyIERpc2N1c3Npb24gKHdhczogUmU6IFtMd2Fw cF0gQ2VydGlmaWNhdGVzLCBEaXNjb3ZlcnkgUmVxdWVzdC9SZXBseSwgYW5kIHZhbGlkYXRpb24u KQ0KCQ0KCQ0KDQoJPiBPdXQgb2YgY2hhcnRlcjogV2hhdCB0aGUgaW1hZ2UgZG9lcyAoc2Vydmlj ZSBsYXllcikuDQoJDQoJc28sIHdoYXQgdGhlIHVzZXIgbmVlZHMgdG8gcnVuIGEgbXVsdGktdmVu ZG9yIGVudmlyb25tZW50IGlzDQoJb3V0IG9mIHNjb3BlPyAgdWgsIGRvIHdlIGhhdmUgdGhlIHNh bWUgY29uY2VwdCBvZiB0aGUgcHVycG9zZQ0KCW9mIHRoZSBpZXRmPw0KCQ0KCXJhbmR5DQoJDQoJ DQoNCg== From dmolnar@legra.com Fri Aug 1 10:02:47 2003 From: dmolnar@legra.com (David Molnar) Date: Fri, 1 Aug 2003 05:02:47 -0400 (EDT) Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) In-Reply-To: References: Message-ID: <1568.63.191.1.221.1059728567.squirrel@legra-mx-01.legra.com> > Unfortunately, there is no easy solution to this problem. Both LWAPP + > image-transplant protocol' have ups and downs. Acceptence of LWAPPs > architecture is uncertain, here is a quote from Cisco that hit the press > a couple days ago..... Thanks for the quote. Where did it appear? I'd be interested to read the rest of the article. Google isn't helping me out with it yet. In any case, the "light-weight" architecture already has several vendors selling product or about to debut. Many of the people involved are represented here on the mailing list or were at the BOF; I happen to work for one such vendor. We want interoperability between light-weight APs and ARs from different vendors. Therefore it seems that there *is* a current need for a protocol addressing interoperability in the light-weight architecture, regardless of what Cisco's opinion of the architecture is. Whether that protocol turns out to be LWAPP or something else is less of a concern at this point than deciding to tackle this problem. Also, standardizing such a protocol doesn't necessarily mean that every AP vendor in the world needs to rearchitect their APs to run a light-weight AP-AR protocol tomorrow. If you want to stay with all functionality in the AP, that's fine - you don't need a protocol for light-weight APs, so don't implement it. There may still be provisioning and control issues to solve, however, and those might also go into the CAPWAP charter. -David From bhandaru@legra.com Fri Aug 1 15:46:57 2003 From: bhandaru@legra.com (Nehru Bhandaru) Date: Fri, 1 Aug 2003 10:46:57 -0400 Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) In-Reply-To: <1568.63.191.1.221.1059728567.squirrel@legra-mx-01.legra.com> Message-ID: <000601c3583b$c2c8f350$84ccea18@legra.com> Perhaps there is no one solution to all problems :-) However two issues may be relevant for lwapp that the remote access = scenario from the quote brings to mind. -- where does authentication occur AP or AR and is this negotiable? = In an RSN authentiction frames (EAPOL) may be encrypted - so this needs to = be=20 negotiated relative to encryption. -- What does the AP do when the AR is not available? - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of David Molnar Sent: Friday, August 01, 2003 5:03 AM To: aframe@trapezenetworks.com Cc: randy@psg.com; pcalhoun@airespace.com; puneetb@myway.com; lwapp@frascone.com Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) > Unfortunately, there is no easy solution to this problem. Both LWAPP + = > image-transplant protocol' have ups and downs. Acceptence of LWAPPs=20 > architecture is uncertain, here is a quote from Cisco that hit the=20 > press a couple days ago..... Thanks for the quote. Where did it appear? I'd be interested to read the rest of the article. Google isn't helping me out with it yet. In any case, the "light-weight" architecture already has several vendors selling product or about to debut. Many of the people involved are represented here on the mailing list or were at the BOF; I happen to = work for one such vendor. We want interoperability between light-weight APs = and ARs from different vendors. Therefore it seems that there *is* a current need for a protocol addressing interoperability in the light-weight architecture, regardless of what Cisco's opinion of the architecture is. Whether that protocol turns out to be LWAPP or something else is less of = a concern at this point than deciding to tackle this problem. Also, standardizing such a protocol doesn't necessarily mean that every = AP vendor in the world needs to rearchitect their APs to run a light-weight AP-AR protocol tomorrow. If you want to stay with all functionality in = the AP, that's fine - you don't need a protocol for light-weight APs, so = don't implement it. There may still be provisioning and control issues to = solve, however, and those might also go into the CAPWAP charter. -David _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From randy@psg.com Fri Aug 1 16:25:46 2003 From: randy@psg.com (Randy Bush) Date: Fri, 1 Aug 2003 08:25:46 -0700 Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) References: Message-ID: > here is a quote from Cisco that hit the press a couple days ago..... > ... > Consider the interests of the vendors. WLAN > heavyweight Cisco - every enterprise-class WLAN-maker's primary > competition - voted as this is pr, and we don't vote in the ietf, excuse me if i ignore the rest of this offensive message. can we try to focus on providing standards which allow users to deploy multi-vendor solutions, despite some vendors' desires to lock us in? thanks. randy From pcalhoun@airespace.com Fri Aug 1 17:01:33 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 1 Aug 2003 09:01:33 -0700 Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) Message-ID: <40301581B2962B448690A023EF16DFE1DC53C8@bsn-mail-01.bstormnetworks.com> > Are you assuming that all APs manufactured will want to be > 'lightweight'? Or even be 'lightweight capable'? Certainly *all* the ones that I've talked to have express *great* = interest in being able to play in the large enterprise space... PatC From pcalhoun@airespace.com Fri Aug 1 17:17:30 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 1 Aug 2003 09:17:30 -0700 Subject: [Lwapp] LWAPP: AP and AR from different vendors Message-ID: <40301581B2962B448690A023EF16DFE1DC53CA@bsn-mail-01.bstormnetworks.com> > I strongly support that we give provision where AP and AR are > interoperable by protocol, not by downloading image implementing > proprietary protocol between them. This eliminates the requirement > for customer to buy equipment from the same vendor.=20 agreed. As a vendor, I can't imagine the resources required to port our = source code to all platforms, not to mention that many of them may have = completely different underlying MAC hardware. > It is also not advisable for APs to get the images from the AP vendor > website. Think of WLAN deployments where number of APs are in > hundreds and thousands. I feel, AR or something behind this should > provide facility where the Administrator put the latest AP images > (if more than one vendor's AP is deployed which is possible in > multiple divisions of a company spread across cities). APs should > download the images or AR should upload them to the APs. Since AP > and AR communication is secure and they do mutual authentication, = there > may not be any problem of secure image upload.=20 Correct, security is provided from the top down. One must assume that it = is possible to "securely" configure the AR (outside of scope), and the = communication channel from the AR and the AP is secured, so you get = secure download as a consequence. PatC From pcalhoun@airespace.com Fri Aug 1 17:21:20 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 1 Aug 2003 09:21:20 -0700 Subject: [Lwapp] LWAPP: AP and AR from different vendors Message-ID: <40301581B2962B448690A023EF16DFE1DC53CB@bsn-mail-01.bstormnetworks.com> > The downside to such a solution is that a rogue AR can then flash the = AP > with anything it likes. For example, I buy an AR and gain access to = your > AP before your AR does. Then I push my own image to the AP; afterwards > the AP is free to lie about what code it runs, pretend to accept your = AR's > upgrade and not actually upgrade, send duplicate copies of all traffic > somewhere else, etc. It's not clear to me how one would recover from > this scenario, although I can think of some possible architectures = which > might help. If the a malicious AR can coerce an AP to communicate, then we have = bigger problems... > I suggest that if we do decide that > 1) firmware download is in scope and > 2) that we want a solution where the AR validates images but AP > does not perform image validation I think that AP image validation is implementation specific. I think = that requiring that an AR be able to validate an AP image would be = interesting, but could be difficult since many APs already have = proprietary formats.... but maybe this could be done. > When is the AR authorized to push a new image to the AP?=20 When the administrator wants to > What mechanisms are there for clearing the AP image, and do they = survive if > the AP is flashed incorrectly? This is not a standards issue, but an implementation specific one. PatC From pcalhoun@airespace.com Fri Aug 1 17:50:06 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 1 Aug 2003 09:50:06 -0700 Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) Message-ID: <40301581B2962B448690A023EF16DFE1DC53CF@bsn-mail-01.bstormnetworks.com> > Services are the value-add software features that the AP can offer. = QoS, > Rogue detection, etc. How does LWAPP address the fact that multiple > queues might exist on the AP? And that the user might actually want to > take advantage of those queues, and oh wait, did I mention that there > might be a variable number of queues on a per-AP basis? See how easy = it > is to rathole? This is one of many examples why the 'service layer' > needs to be separated and is completely out of charter... >=20 > Again, what I propose: [...] Or even better yet, how about we go down the path of making the AP = relatively simple (aka light weight), and push all functionality that is = not real-time specific (meaning not 802.11 control) in the AR. This way, = value add is provided in the AR, not the AP. So you can use anyone's AP = and get similar functionality (granted some APs will work better than = others). PatC From pcalhoun@airespace.com Sat Aug 2 05:40:02 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 1 Aug 2003 21:40:02 -0700 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: <40301581B2962B448690A023EF16DFE1DC53EE@bsn-mail-01.bstormnetworks.com> QWxsLA0KIA0KQmFzZWQgb24gdGhlIGNvbW1lbnRzIG9uIHRoZSBsaXN0LCBoZXJlIGlzIG15IGF0 dGVtcHQgYXQgYSBwcm9wb3NlZCBjaGFydGVyOg0KLS0tLS0tLS0tLS0tLQ0KIA0KVGhlIENBUFdB UCAocHJvcG9zZWQpIFdHIHdpbGwgZGVzaWduIGEgcHJvdG9jb2wgc3BlY2lmaWNhbGx5IGZvciA4 MDIuMTEsIHdoaWNoIGludHJvZHVjZXMgYSBuZXcgInNwbGl0IE1BQyIgYXJjaGl0ZWN0dXJlLiBU aGlzIGFyY2hpdGVjdHVyZSB3aWxsIGNlbnRyYWxpemUgbW9zdCBvZiB0aGUgaW50ZWxsaWdlbmNl IGluIHRoZSBhY2Nlc3Mgcm91dGVyIChBUiksIHdoaWxlIG1haW50YWluaW5nIHRoZSByZWFsLXRp bWUgZnVuY3Rpb25zIG9mIHRoZSA4MDIuMTEgcHJvdG9jb2wgaW4gdGhlIGFjY2VzcyBwb2ludCAo QVApLiBUaGlzIHdvcmsgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUgSUVFRSdzIGNoYXJ0ZXIg c2luY2UgaXQgZG9lcyBub3QgYWx0ZXIgb3IgY3JlYXRlIGFueSBuZXcgUEhZcyBvciBNQUNzLiBU aGUgV0cgd2lsbCBkZWxpdmVyIHRoZSBmb2xsb3dpbmc6DQogICAgLSBMV0FQUCBTZWN1cml0eSBS ZXF1aXJlbWVudHMsIGRlZmluaW5nIHRoZSBuZWVkcyBmb3Igc2VjdXJpdHkgYmV0d2VlbiB0aGUg QVAgYW5kIHRoZSBBUg0KICAgIC0gTFdBUFAgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiwgd2hpY2gg ZGVmaW5lczoNCiAgICAgICAgLSBEaXNjb3Zlcnkgb2YgQVJzIGJ5IEFQcyAodGhpcyB3b3JrIGNv dWxkIHBvaW50IHRvIGV4aXN0aW5nIElFVEYgc3RhbmRhcmRzLCBpZiBwb3NzaWJsZSkNCiAgICAg ICAgLSBBY3F1aXNpdGlvbiBvZiBBUHMgYnkgQVIsIGluY2x1ZGluZyBBUiBmYWlsLW92ZXIgbWVj aGFuaXNtcw0KICAgICAgICAtIFR1bm5lbGluZyBwcm90b2NvbCAoc2lnbmFsbGluZyBhbmQgZGF0 YSkgb2YgODAyLjExIHRyYWZmaWMgYmV0d2VlbiB0aGUgQVAgYW5kIHRoZSBBUg0KICAgICAgICAt IENvbmZpZ3VyYXRpb24gYW5kIG1vbml0b3Jpbmcgb2Ygd2lyZWxlc3MgbGluayBieSBBUg0KDQpU aGUgaW50ZW50IG9mIHRoZSBDQVBXQVAgV0cgaXMgdG8gY29tcGxldGUgdGhlIHByb3RvY29sIHNw ZWNpZmljYXRpb24gYXMgcXVpY2tseSBhcyBwb3NzaWJsZSBhbmQgdG8gcHJvdmUgaW50ZXJvcGVy YWJpbGl0eSBvZiB0aGUgcHJvdG9jb2wgYmV0d2VlbiBBUCBhbmQgQVJzIGZyb20gZGlmZmVyZW50 IG1hbnVmYWN0dXJlcnMuDQotLS0tLS0tLS0tLS0tDQogDQpUaGFua3MsDQogDQpQYXRDDQo= From pcalhoun@airespace.com Sat Aug 2 20:23:39 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sat, 2 Aug 2003 12:23:39 -0700 Subject: [Lwapp] Another attempt at a proposed charter (again) Message-ID: <40301581B2962B448690A023EF16DFE13F6884@bsn-mail-01.bstormnetworks.com> All, Based on the comments on the list, here is my attempt at a proposed charter: ------------- =20 The CAPWAP (proposed) WG will design a protocol specifically for 802.11, which introduces a "split MAC" architecture. This architecture will centralize most of the intelligence in the access router (AR), while maintaining the real-time functions of the 802.11 protocol in the access point (AP). This work does not conflict with the IEEE's charter since it does not alter or create any new PHYs or MACs. The WG will deliver the following: - LWAPP Security Requirements, defining the needs for security between the AP and=20 the AR - LWAPP Protocol Specification, which defines: 1 Discovery of ARs by APs (this work could point to existing IETF standards,=20 if possible) 2 Acquisition of APs by AR, including AR fail-over mechanisms 3 Tunneling protocol (signaling and data) of 802.11 traffic between the AP=20 and the AR 4 Configuration and monitoring of wireless link by AR 5 A protocol to securely download AP firmware from the AR The intent of the CAPWAP WG is to complete the protocol specification as quickly as possible and to prove interoperability of the protocol between AP and ARs from different manufacturers. ------------- =20 Thanks, =20 PatC From dromasca@avaya.com Sun Aug 3 14:28:09 2003 From: dromasca@avaya.com (Romascanu, Dan (Dan)) Date: Sun, 3 Aug 2003 16:28:09 +0300 Subject: [Lwapp] Another attempt at a proposed charter (again) Message-ID: In general I like the proposed charter. I have one observation however. = The bracketed comment relative to discovery 'this work could point to = existing IETF standards' applies IMO for the whole scope of the work, = and especially to points #4 and #5. In order to make this clear, I would = suggest to add at the end of the protocol specification items list the = following: 'To the possible extent these items will be implemented by = re-using existing IETF standards. The new protocol functionality will = cover the functions not defined by other IETF standards in a = satisfactory manner for the split MAC IEEE 802.11 environment." Regards, Dan > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: 02 August, 2003 10:24 PM > To: lwapp@frascone.com > Subject: [Lwapp] Another attempt at a proposed charter (again) >=20 >=20 > All, >=20 > Based on the comments on the list, here is my attempt at a proposed > charter: > ------------- > =20 > The CAPWAP (proposed) WG will design a protocol specifically=20 > for 802.11, > which introduces a "split MAC" architecture. This architecture will > centralize most of the intelligence in the access router (AR), while > maintaining the real-time functions of the 802.11 protocol in=20 > the access > point (AP). This work does not conflict with the IEEE's=20 > charter since it > does not alter or create any new PHYs or MACs. The WG will deliver the > following: > - LWAPP Security Requirements, defining the needs for security > between the AP and=20 > the AR > - LWAPP Protocol Specification, which defines: > 1 Discovery of ARs by APs (this work could point to existing > IETF standards,=20 > if possible) > 2 Acquisition of APs by AR, including AR fail-over mechanisms > 3 Tunneling protocol (signaling and data) of 802.11 traffic > between the AP=20 > and the AR > 4 Configuration and monitoring of wireless link by AR > 5 A protocol to securely download AP firmware from the AR >=20 > The intent of the CAPWAP WG is to complete the protocol=20 > specification as > quickly as possible and to prove interoperability of the protocol > between AP and ARs from different manufacturers. > ------------- > =20 > Thanks, > =20 > PatC >=20 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp >=20 From isingh@chantrynetworks.com Sun Aug 3 17:13:36 2003 From: isingh@chantrynetworks.com (Inderpreet Singh) Date: Sun, 3 Aug 2003 12:13:36 -0400 Subject: [Lwapp] Another attempt at a proposed charter In-Reply-To: <40301581B2962B448690A023EF16DFE1DC53EE@bsn-mail-01.bstormnetworks.com> Message-ID: <007d01c359da$320ab150$c7ff16ac@toronto.chantrynetworks.com> Finally working towards a charter. I propose that any mention of "split-MAC" architecture be excluded. The = architecture that CAPWAP is working towards is "centralized" = architecture for Control And Provisioning of Wireless Access Points. We can accomplish centralized control and provisioning with splitting as = well as without splitting the MAC in anyway way. Therefore: "Tunneling protocol (signalling and data) of 802.11 traffic = between the AP and the AR" should also exclude 802.11. Something like = "Tunneling protocol of traffic between the AP and the AR" should = suffice. This traffic could be 802.11 or 802.3 <-- the goal of the = proposed WG is to choose one of these as mandatory to implement based on = technical merits. -- Inderpreet Singh=20 Chantry Networks > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf > Of Pat R. Calhoun > Sent: Saturday, August 02, 2003 12:40 AM > To: lwapp@frascone.com > Subject: [Lwapp] Another attempt at a proposed charter >=20 > All, >=20 > Based on the comments on the list, here is my attempt at a proposed > charter: > ------------- >=20 > The CAPWAP (proposed) WG will design a protocol specifically for = 802.11, > which introduces a new "split MAC" architecture. This architecture = will > centralize most of the intelligence in the access router (AR), while > maintaining the real-time functions of the 802.11 protocol in the = access > point (AP). This work does not conflict with the IEEE's charter since = it > does not alter or create any new PHYs or MACs. The WG will deliver the > following: > - LWAPP Security Requirements, defining the needs for security = between > the AP and the AR > - LWAPP Protocol Specification, which defines: > - Discovery of ARs by APs (this work could point to existing = IETF > standards, if possible) > - Acquisition of APs by AR, including AR fail-over mechanisms > - Tunneling protocol (signalling and data) of 802.11 traffic > between the AP and the AR > - Configuration and monitoring of wireless link by AR >=20 > The intent of the CAPWAP WG is to complete the protocol specification = as > quickly as possible and to prove interoperability of the protocol = between > AP and ARs from different manufacturers. > ------------- >=20 > Thanks, >=20 > PatC > /=06f)+/=06 y=CA=86 Wj Y ~j From mmani@avaya.com Sun Aug 3 18:21:39 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Sun, 3 Aug 2003 11:21:39 -0600 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: Q29tbWVudHMgaW4gbGluZS4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFBhdCBSLiBDYWxob3VuIFttYWlsdG86cGNhbGhvdW5AYWlyZXNwYWNlLmNvbV0NCj4gU2Vu dDogRnJpZGF5LCBBdWd1c3QgMDEsIDIwMDMgOTo0MCBQTQ0KPiBUbzogbHdhcHBAZnJhc2NvbmUu Y29tDQo+IFN1YmplY3Q6IFtMd2FwcF0gQW5vdGhlciBhdHRlbXB0IGF0IGEgcHJvcG9zZWQgY2hh cnRlcg0KPiANCj4gQWxsLA0KPiANCj4gQmFzZWQgb24gdGhlIGNvbW1lbnRzIG9uIHRoZSBsaXN0 LCBoZXJlIGlzIG15IGF0dGVtcHQgYXQgYSBwcm9wb3NlZA0KPiBjaGFydGVyOg0KPiAtLS0tLS0t LS0tLS0tDQo+IA0KPiBUaGUgQ0FQV0FQIChwcm9wb3NlZCkgV0cgd2lsbCBkZXNpZ24gYSBwcm90 b2NvbCBzcGVjaWZpY2FsbHkgZm9yIDgwMi4xMSwNCj4gd2hpY2ggaW50cm9kdWNlcyBhIG5ldyAi c3BsaXQgTUFDIiBhcmNoaXRlY3R1cmUuIFRoaXMgYXJjaGl0ZWN0dXJlIHdpbGwNCg0KW01hbmks IE1haGFsaW5nYW0gKE1haGFsaW5nYW0pXSBJIGFtIGluY2xpbmVkIHRvIHRoaW5rIHRoYXQgd2l0 aG91dCBleHBsaWNpdCBtZW50aW9uIG9mICJzcGxpdC1NQUMiIGl0IGlzIHBvc3NpYmxlIHRvIGFj Y29tbW9kYXRlIGJvdGggKHNwbGl0L3Vuc3BsaXQgYW5kIHZhcmlhbnRzIHRoZXJlb2YpIGluIHRo ZSBzY29wZSBvZiBXRyBjaGFydGVyLg0KDQo+IGNlbnRyYWxpemUgbW9zdCBvZiB0aGUgaW50ZWxs aWdlbmNlIGluIHRoZSBhY2Nlc3Mgcm91dGVyIChBUiksIHdoaWxlDQo+IG1haW50YWluaW5nIHRo ZSByZWFsLXRpbWUgZnVuY3Rpb25zIG9mIHRoZSA4MDIuMTEgcHJvdG9jb2wgaW4gdGhlIGFjY2Vz cw0KPiBwb2ludCAoQVApLiBUaGlzIHdvcmsgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUgSUVF RSdzIGNoYXJ0ZXIgc2luY2UgaXQNCj4gZG9lcyBub3QgYWx0ZXIgb3IgY3JlYXRlIGFueSBuZXcg UEhZcyBvciBNQUNzLiBUaGUgV0cgd2lsbCBkZWxpdmVyIHRoZQ0KPiBmb2xsb3dpbmc6DQo+ICAg ICAtIExXQVBQIFNlY3VyaXR5IFJlcXVpcmVtZW50cywgZGVmaW5pbmcgdGhlIG5lZWRzIGZvciBz ZWN1cml0eSBiZXR3ZWVuDQo+IHRoZSBBUCBhbmQgdGhlIEFSDQo+ICAgICAtIExXQVBQIFByb3Rv Y29sIFNwZWNpZmljYXRpb24sIHdoaWNoIGRlZmluZXM6DQo+ICAgICAgICAgLSBEaXNjb3Zlcnkg b2YgQVJzIGJ5IEFQcyAodGhpcyB3b3JrIGNvdWxkIHBvaW50IHRvIGV4aXN0aW5nIElFVEYNCj4g c3RhbmRhcmRzLCBpZiBwb3NzaWJsZSkNCg0KW01hbmksIE1haGFsaW5nYW0gKE1haGFsaW5nYW0p XSANCltNYW5pLCBNYWhhbGluZ2FtIChNYWhhbGluZ2FtKV0gRG9lcyB0aGUgRGlzY292ZXJ5IGlt cGx5IChtdXR1YWwpIGF1dGhlbnRpY2F0aW9uIG9mIEFQICYgQVIgb3IgaXMgaXQgbGVmdCBvdXRz aWRlIHRoZSBzY29wZSBvZiBwcm90b2NvbCAtIGFuZCBiZSBtZXJlbHkgZGVmaW5lZCBpbiB0aGUg U2VjdXJpdHkgcmVxdWlyZW1lbnRzPw0KDQo+ICAgICAgICAgLSBBY3F1aXNpdGlvbiBvZiBBUHMg YnkgQVIsIGluY2x1ZGluZyBBUiBmYWlsLW92ZXIgbWVjaGFuaXNtcw0KPiAgICAgICAgIC0gVHVu bmVsaW5nIHByb3RvY29sIChzaWduYWxsaW5nIGFuZCBkYXRhKSBvZiA4MDIuMTEgdHJhZmZpYw0K PiBiZXR3ZWVuIHRoZSBBUCBhbmQgdGhlIEFSDQo+ICAgICAgICAgLSBDb25maWd1cmF0aW9uIGFu ZCBtb25pdG9yaW5nIG9mIHdpcmVsZXNzIGxpbmsgYnkgQVINCg0KW01hbmksIE1haGFsaW5nYW0g KE1haGFsaW5nYW0pXSAiY29udHJvbCwgY29uZmlndXJhdGlvbiBhbmQgbW9uaXRvcmluZyIgbWF5 IGJlIG1vcmUgYXBwcm9wcmlhdGUgZm9yIHRoZSBpbnRlbnQgb2YgdGhlIFdHLg0KDQpBbHNvLCBy ZWZlcmVuY2UgdG8gdXNlIG9mIEwyIHRyaWdnZXJzIGFuZCBwcmltaXRpdmVzLCBzdWNoIGFzIHRv IGJlIGRlZmluZWQgYnkgSUVFRSBIYW5kb2ZmIGFuZCA4MDIuMTFrIFRHJ3MgcmVzcGVjdGl2ZWx5 LCBmb3IgdGhlIHB1cnBvc2Ugd2lsbCBmYWNpbGl0YXRlIHVzZWZ1bCBpbnRlcndvcmtpbmcgb2Yg dGhlIGxheWVycy4NCg0KPiANCj4gVGhlIGludGVudCBvZiB0aGUgQ0FQV0FQIFdHIGlzIHRvIGNv bXBsZXRlIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGFzDQo+IHF1aWNrbHkgYXMgcG9zc2li bGUgYW5kIHRvIHByb3ZlIGludGVyb3BlcmFiaWxpdHkgb2YgdGhlIHByb3RvY29sIGJldHdlZW4N Cj4gQVAgYW5kIEFScyBmcm9tIGRpZmZlcmVudCBtYW51ZmFjdHVyZXJzLg0KPiAtLS0tLS0tLS0t LS0tDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBQYXRDDQo+IC8GZikrLwZ5yoZXasedWX4NCltNYW5p LCBNYWhhbGluZ2FtIChNYWhhbGluZ2FtKV0gDQotbWFuaQ0K From pcalhoun@airespace.com Sun Aug 3 18:27:42 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sun, 3 Aug 2003 10:27:42 -0700 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: <40301581B2962B448690A023EF16DFE1DC53F6@bsn-mail-01.bstormnetworks.com> > I propose that any mention of "split-MAC" architecture be excluded. The=20 > architecture that CAPWAP is working towards is "centralized" architecture > for Control And Provisioning of Wireless Access Points. But the reality is that if the centralized controller is to be aware of the active session in the AP, which I assume it does, then some form of notification is required from the AP to the AR. So does it make sense to have the AP simply forward messages that are already defined and in use today, or create yet another set of messages to directly map to the 802.11 mac management messages? > We can accomplish centralized control and provisioning with splitting as=20 > well as without splitting the MAC in anyway way. Right, but by creating another protocol... achieving the same goal. BTW, there is no reason that one's AP needs to change. If you terminate the MAC in the AP, then by all means do so. However, the AR needs to be aware of the session in the AP, so it makes sense to simply forward the existing messages to the AR. > Therefore: "Tunneling protocol (signalling and data) of 802.11 traffic > between the AP and the AR" should also exclude 802.11. Something like > "Tunneling protocol of traffic between the AP and the AR" should suffice. > This traffic could be 802.11 or 802.3 <-- the goal of the proposed WG is=20 > to choose one of these as mandatory to implement based on technical=20 > merits. So should we debate the merits of one vs. the other prior to agreeing on a charter, or agree on a charter (with your proposed changes) and then start the debate? PatC From pcalhoun@airespace.com Sun Aug 3 18:32:15 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sun, 3 Aug 2003 10:32:15 -0700 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: <40301581B2962B448690A023EF16DFE1DC53F7@bsn-mail-01.bstormnetworks.com> >> The CAPWAP (proposed) WG will design a protocol specifically for 802.11, >> which introduces a new "split MAC" architecture. This architecture will > > [Mani, Mahalingam (Mahalingam)] I am inclined to think that without=20 > explicit mention of "split-MAC" it is possible to accommodate both=20 > (split/unsplit and variants thereof) in the scope of WG charter. Not if one expects any form of interoperability. See my previous message to Inderpreet regarding the fact that a protocol of some form is required in any case for the AR to maintain an accurate account of active users. So why create another protocol instead of simply forwarding the 802.11 frames to the AR? Again, if you want to terminate the MAC in the AP, that's fine, but forward the frames to the AR. [Mani, Mahalingam (Mahalingam)]=20 > [Mani, Mahalingam (Mahalingam)] Does the Discovery imply (mutual)=20 > authentication of AP & AR or is it left outside the scope of protocol -=20 > and be merely defined in the Security requirements? Good question. Does Discovery need to be authenticated, or does the acquisition phase need to be authenticated (mutually)? I would think the latter, but we can address this in the security requirements specification. >> - Configuration and monitoring of wireless link by AR > [Mani, Mahalingam (Mahalingam)] "control, configuration and monitoring"=20 > may be more appropriate for the intent of the WG. You are correct > Also, reference to use of L2 triggers and primitives, such as to be=20 > defined by IEEE Handoff and 802.11k TG's respectively, for the purpose > will facilitate useful interworking of the layers. Could you provide some examples of what you are thinking? PatC From pcalhoun@airespace.com Sun Aug 3 22:18:59 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sun, 3 Aug 2003 14:18:59 -0700 Subject: [Lwapp] Another attempt at a proposed charter (again) Message-ID: <40301581B2962B448690A023EF16DFE1DC53F8@bsn-mail-01.bstormnetworks.com> My opinion here is that we need to measure the relative complexity that is introduced by requiring a slew of fairly generic protocols on a light weight AP, and understand: 1) How are all these protocols inter-related when the software wants to take action. For instance, what do we gain if the simple task of accepting a user requires that we use SNMP to push a key to the AP, then invoke some protocol to create a tunnel with the AP? Are there any potential race conditions? Etc... 2) The more protocols, the more complex the device and the more susceptible it is to attacks. One cannot simply dismiss the fact that this is an edge device, and can be a great target for attacks, so increasing the number of stacks on the box (or even lines of code) increases the possibility that it become the weak link in the chain (esp when some of these are fairly low cost devices). 3) Does it reduce the number of configuration items in the AP? For instance, I've been hearing recently that one of the key motivations for light weight APs is to reduce the number of security related configuration widgets on the AP. So if the device is stolen, it is not possible to recover any static keying information. Since these device are typically outside the wiring closet, they do not have the same level of physical security that access routers and switches do (hence a big motivator for cert based security). PatC -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Sunday, August 03, 2003 6:28 AM To: Pat R. Calhoun; lwapp@frascone.com Subject: RE: [Lwapp] Another attempt at a proposed charter (again) In general I like the proposed charter. I have one observation however. The bracketed comment relative to discovery 'this work could point to existing IETF standards' applies IMO for the whole scope of the work, and especially to points #4 and #5. In order to make this clear, I would suggest to add at the end of the protocol specification items list the following: 'To the possible extent these items will be implemented by re-using existing IETF standards. The new protocol functionality will cover the functions not defined by other IETF standards in a satisfactory manner for the split MAC IEEE 802.11 environment." Regards, Dan > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: 02 August, 2003 10:24 PM > To: lwapp@frascone.com > Subject: [Lwapp] Another attempt at a proposed charter (again) >=20 >=20 > All, >=20 > Based on the comments on the list, here is my attempt at a proposed > charter: > ------------- > =20 > The CAPWAP (proposed) WG will design a protocol specifically=20 > for 802.11, > which introduces a "split MAC" architecture. This architecture will > centralize most of the intelligence in the access router (AR), while > maintaining the real-time functions of the 802.11 protocol in=20 > the access > point (AP). This work does not conflict with the IEEE's=20 > charter since it > does not alter or create any new PHYs or MACs. The WG will deliver the > following: > - LWAPP Security Requirements, defining the needs for security > between the AP and=20 > the AR > - LWAPP Protocol Specification, which defines: > 1 Discovery of ARs by APs (this work could point to existing > IETF standards,=20 > if possible) > 2 Acquisition of APs by AR, including AR fail-over mechanisms > 3 Tunneling protocol (signaling and data) of 802.11 traffic > between the AP=20 > and the AR > 4 Configuration and monitoring of wireless link by AR > 5 A protocol to securely download AP firmware from the AR >=20 > The intent of the CAPWAP WG is to complete the protocol=20 > specification as > quickly as possible and to prove interoperability of the protocol > between AP and ARs from different manufacturers. > ------------- > =20 > Thanks, > =20 > PatC >=20 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp >=20 From mmani@avaya.com Mon Aug 4 00:40:27 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Sun, 3 Aug 2003 17:40:27 -0600 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: Hi, > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Sunday, August 03, 2003 10:32 AM [...] > > > > [Mani, Mahalingam (Mahalingam)] I am inclined to think that without > > explicit mention of "split-MAC" it is possible to accommodate both > > (split/unsplit and variants thereof) in the scope of WG charter. >=20 > Not if one expects any form of interoperability. See my previous message > to Inderpreet regarding the fact that a protocol of some form is > required in any case for the AR to maintain an accurate account of > active users. So why create another protocol instead of simply > forwarding the 802.11 frames to the AR? Again, if you want to terminate [Mani, Mahalingam (Mahalingam)] that's a no-brainer. [Mani, Mahalingam (Mahalingam)] 802.11 frames will need some encap. To go over 802.3 or in case of pre-processed 802.11 frames (again may be to a varied extent) one still may need 802.3 or other encapsulation. > the MAC in the AP, that's fine, but forward the frames to the AR. >=20 [Mani, Mahalingam (Mahalingam)] I did not mean to imply not to have split-MAC. Nor did I mean to imply not to have the frame forwarded to AR. I just meant that the need to forward is implied in the formation of the WG itself. Perhaps, for this very explanation of yours the "split-MAC" needs to be mentioned after all. [Mani, Mahalingam (Mahalingam)]=20 > [Mani, Mahalingam (Mahalingam)] > > [Mani, Mahalingam (Mahalingam)] Does the Discovery imply (mutual) > > authentication of AP & AR or is it left outside the scope of protocol > - > > and be merely defined in the Security requirements? > Good question. Does Discovery need to be authenticated, or does the > acquisition phase need to be authenticated (mutually)? I would think the > latter, but we can address this in the security requirements > specification. >=20 [Mani, Mahalingam (Mahalingam)] depends on how we scope Discovery. Authentication itself is a discovery (and validation) of (in this case, device) identity. Subsequent capabilities exchange would be facilitated under authenticated (and perhaps protected - if SA can be set up a priori) conditions. However, it also depends on how LW we want preliminary discovery to be as well. [Mani, Mahalingam (Mahalingam)] For example, IEEE LLDP discovery protocol seems to suggest authentication (based, say, on 802.1X) to precede discovery (LLDP is a work in progress). [Not suggesting LLDP for discovery]. > >> - Configuration and monitoring of wireless link by AR > > [Mani, Mahalingam (Mahalingam)] "control, configuration and > monitoring" > > may be more appropriate for the intent of the WG. >=20 > You are correct >=20 > > Also, reference to use of L2 triggers and primitives, such as to be > > defined by IEEE Handoff and 802.11k TG's respectively, for the purpose >=20 > > will facilitate useful interworking of the layers. > Could you provide some examples of what you are thinking? >=20 [Mani, Mahalingam (Mahalingam)] Briefly - IEEE 802.11k (Radio Resource Measurements) provides L2 API's for state information (of clients and AP's): higher layers are expected to use this information to make control / (re)configuration decisions. Depending on how MAC is split - this may come partly from AP and part from AR (consulting the AP). Likewise, Handoff is expected to L2 API triggers (alarms - if you will) on state of association of clients to AP's - which higher layer functions (resident in AR more likely) are expected to use for handoff decisions. Coordinating with the two will help make the WG work quicker. Even if CAPWAP is not going to be in the business of defining their use; the proposed protocol should provide for channeling these flows (between AP & AR). I feel this is important to note given the 'C' in CAPWAP. To that end - "- Configuration and monitoring of wireless link by AR" should be qualified to reflect that. > PatC [Mani, Mahalingam (Mahalingam)]=20 regards, -mani From pcalhoun@airespace.com Mon Aug 4 02:15:02 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sun, 3 Aug 2003 18:15:02 -0700 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: <40301581B2962B448690A023EF16DFE13F6892@bsn-mail-01.bstormnetworks.com> > [Mani, Mahalingam (Mahalingam)] depends on how we scope Discovery. > > Authentication itself is a discovery (and validation) of (in this case, > device) identity. Subsequent capabilities exchange would be facilitated > under authenticated (and perhaps protected - if SA can be set up a > priori) conditions. However, it also depends on how LW we want > preliminary discovery to be as well. > > [Mani, Mahalingam (Mahalingam)] For example, IEEE LLDP discovery > protocol seems to suggest authentication (based, say, on 802.1X) to > precede discovery (LLDP is a work in progress). [Not suggesting LLDP for > discovery]. But if the protocol is to run at L3 (and perhaps L2) then I view discovery as simply a means of acquiring the address of the peer. After this point, acquisition occurs, and this needs to be authenticated. Perhaps you are considering a different form of discovery than I am. > [Mani, Mahalingam (Mahalingam)] Briefly - IEEE 802.11k (Radio Resource > Measurements) provides L2 API's for state information (of clients and > AP's): higher layers are expected to use this information to make > control / (re)configuration decisions. Depending on how MAC is split - > this may come partly from AP and part from AR (consulting the AP). > > Likewise, Handoff is expected to L2 API triggers (alarms - if you will) > on state of association of clients to AP's - which higher layer > functions (resident in AR more likely) are expected to use for handoff > decisions. So are these functions purely L2? I thought that 802.11k was considering creating a MIB for these. > Coordinating with the two will help make the WG work quicker. > Even if CAPWAP is not going to be in the business of defining their use; > the proposed protocol should provide for channeling these flows (between > AP & AR). > > I feel this is important to note given the 'C' in CAPWAP. > > To that end - "- Configuration and monitoring of wireless link by AR" > should be qualified to reflect that. Anything that can help provide interoperability, and help speed up the standards process is a good thing. Actually, I would appreciate if you could help provide some text that could go into the LWAPP draft that explains how the interactions between these new task groups can work with LWAPP. PatC From rkp@intotoinc.com Mon Aug 4 05:00:30 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Mon, 04 Aug 2003 09:30:30 +0530 Subject: [Lwapp] lwapp AP configuration Message-ID: <3F2DDA5E.2@intotoinc.com> Hi, I am trying to understand the one time configuration information that needs to be put in, before it is installed to operate with the AR. Please validate and also I have some comments on message elements. - Location data (Where the AP going to be installed - logical location string ) I guess it is only useful to locate the AP. - Preshared key OR CA Certificate + Self certificate signed by CA Needed for mutual authentication and also to create the session keys for confidentiality and per packet authentication between AP and AR. - AP Image location (path name) I feel it is better to represent 'hardware version', 'software version' and 'boot version' as character strings. Most of the hardware vendors tend to keep these in string format. I think, 'image location' in 'Image download' is not required. Hardware version of the AP itself can be key to find the location of AP Image in the AR. Certificate message element should be sent in Discovery phase, not in Join phase. Please comment. Thanks Rama Krishna Prasad Intoto Software (India) Pvt Ltd. From Marcus Brunner Mon Aug 4 10:45:47 2003 From: Marcus Brunner (Marcus Brunner) Date: Mon, 04 Aug 2003 11:45:47 +0200 Subject: [Lwapp] Another attempt at a proposed charter (again) In-Reply-To: <40301581B2962B448690A023EF16DFE13F6884@bsn-mail-01.bstormnetworks.com> References: <40301581B2962B448690A023EF16DFE13F6884@bsn-mail-01.bstormnetwor ks.com> Message-ID: <2403786.1059997547@[10.1.1.130]> > 5 A protocol to securely download AP firmware from the AR So far this looks like a rathole. Do you really want to go down that path? Marcus From Mike.Moreton@Synad.com Mon Aug 4 11:45:13 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Mon, 4 Aug 2003 11:45:13 +0100 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: <0D3F1B25E75EE24483A6E69201142C868B0BDA@paris.synad.com> > So should we debate the merits of one vs. the other prior to agreeing on > a charter, or agree on a charter (with your proposed changes) and then > start the debate? I would have thought it's outside the scope of the IETF to discuss how the 802.11 MAC should be split, especially as that MAC evolves. But your work doesn't make any sense without a definition of such a split. (How can you have a protocol to implement a split if you don't know what that split is?) So if you don't want to get the IEEE involved, then the charter should say something like "which introduces a new "split MAC" architecture as defined in Airespace document XXX". Mike Moreton Synad Technologies Ltd. =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: 03 August 2003 18:28 To: Inderpreet Singh; lwapp@frascone.com Subject: RE: [Lwapp] Another attempt at a proposed charter > I propose that any mention of "split-MAC" architecture be excluded. The=20 > architecture that CAPWAP is working towards is "centralized" architecture > for Control And Provisioning of Wireless Access Points. But the reality is that if the centralized controller is to be aware of the active session in the AP, which I assume it does, then some form of notification is required from the AP to the AR. So does it make sense to have the AP simply forward messages that are already defined and in use today, or create yet another set of messages to directly map to the 802.11 mac management messages? > We can accomplish centralized control and provisioning with splitting as=20 > well as without splitting the MAC in anyway way. Right, but by creating another protocol... achieving the same goal. BTW, there is no reason that one's AP needs to change. If you terminate the MAC in the AP, then by all means do so. However, the AR needs to be aware of the session in the AP, so it makes sense to simply forward the existing messages to the AR. > Therefore: "Tunneling protocol (signalling and data) of 802.11 traffic > between the AP and the AR" should also exclude 802.11. Something like > "Tunneling protocol of traffic between the AP and the AR" should suffice. > This traffic could be 802.11 or 802.3 <-- the goal of the proposed WG is=20 > to choose one of these as mandatory to implement based on technical=20 > merits. So should we debate the merits of one vs. the other prior to agreeing on a charter, or agree on a charter (with your proposed changes) and then start the debate? PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Tue Aug 5 05:30:30 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 4 Aug 2003 21:30:30 -0700 Subject: [Lwapp] Another attempt at a proposed charter (again) Message-ID: <40301581B2962B448690A023EF16DFE1DC5400@bsn-mail-01.bstormnetworks.com> Yes, I think it is necessary. From my discussions with IT managers of = various forms of enterprises, they all state that they like to be able = to abstract their view of wireless areas via a single AR. Further, they = like that the AR makes sure that the APs are running the "approved" = firmware. So we need a way for the AR to be able to push the firmware = down to the AP. If that interface is secured, then you get authenticated = firmware transfers too :) PatC -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Mon 8/4/2003 2:45 AM To: Pat R. Calhoun Cc: lwapp@frascone.com Subject: Re: [Lwapp] Another attempt at a proposed charter (again) > 5 A protocol to securely download AP firmware from the AR So far this looks like a rathole. Do you really want to go down that = path? Marcus From mark.jones@bridgewatersystems.com Tue Aug 5 17:02:34 2003 From: mark.jones@bridgewatersystems.com (Mark Jones) Date: Tue, 5 Aug 2003 12:02:34 -0400 Subject: [Lwapp] Another attempt at a proposed charter (again) Message-ID: > So far this looks like a rathole. Do you really want to go > down that path? > I agree with Pat. We've also been hearing that firmware management is an issue for any sizable 802.1x deployment. If the 'control and provisioning of access points' is to be the focus of the proposed WG then I think it should address this problem. However, we need to consider whether the AR is always the most suitable element to host the firmware management functions. It would be a shame if we just moved this problem to the AR rather than solve it, i.e. network administrators will now have to manage the AP firmware repositories on the ARs in addition to the AR firmware. Thanks Mark From kempf@docomolabs-usa.com Wed Aug 6 06:08:19 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Tue, 5 Aug 2003 22:08:19 -0700 Subject: [Lwapp] Another attempt at a proposed charter (again) References: <40301581B2962B448690A023EF16DFE13F6884@bsn-mail-01.bstormnetworks.com> Message-ID: <045e01c35bd8$c0cfc010$616015ac@dclkempt40> Pat, Charter looks good. W.r.t. making the protocol specific to 802.11, I believe this would simplify the design considerably and thus make the standardization process go faster. It would cause a loss of generality and applicability to other radio protocols, but perhaps the generalization could be done somewhere down the line when we've got more experience with a design based on one protocol. It is usually easier to generalize and abstract if one specific example is available. W.r.t. point 5, Steve Bellovin suggested looking at the Cablelabs protocol for securely downloading an image in a very hostile environment. No sense in re-inventing something if it is already covered adequately elsewhere. jak ----- Original Message ----- From: "Pat R. Calhoun" To: Sent: Saturday, August 02, 2003 12:23 PM Subject: [Lwapp] Another attempt at a proposed charter (again) > All, > > Based on the comments on the list, here is my attempt at a proposed > charter: > ------------- > > The CAPWAP (proposed) WG will design a protocol specifically for 802.11, > which introduces a "split MAC" architecture. This architecture will > centralize most of the intelligence in the access router (AR), while > maintaining the real-time functions of the 802.11 protocol in the access > point (AP). This work does not conflict with the IEEE's charter since it > does not alter or create any new PHYs or MACs. The WG will deliver the > following: > - LWAPP Security Requirements, defining the needs for security > between the AP and > the AR > - LWAPP Protocol Specification, which defines: > 1 Discovery of ARs by APs (this work could point to existing > IETF standards, > if possible) > 2 Acquisition of APs by AR, including AR fail-over mechanisms > 3 Tunneling protocol (signaling and data) of 802.11 traffic > between the AP > and the AR > 4 Configuration and monitoring of wireless link by AR > 5 A protocol to securely download AP firmware from the AR > > The intent of the CAPWAP WG is to complete the protocol specification as > quickly as possible and to prove interoperability of the protocol > between AP and ARs from different manufacturers. > ------------- > > Thanks, > > PatC > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > From avi@bridgewatersystems.com Wed Aug 6 15:40:24 2003 From: avi@bridgewatersystems.com (Avi Lior) Date: Wed, 6 Aug 2003 10:40:24 -0400 Subject: [Lwapp] Is AR a one box solution Message-ID: Hi, It seems from reading the proposed charter that the AR is "one box" solution. That is, all functionality resides on one machine. Is that the intent? Avi. From cchaplin@sj.symbol.com Wed Aug 6 18:57:47 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Wed, 06 Aug 2003 10:57:47 -0700 Subject: [Lwapp] RE: [802-11Technical] Security of PMK, PTK, etc. Message-ID: Having thought on the matter some more, I need to expand on a point you = touched on in your reply. You said: "FH -- The STA needs to be designed for weakest multiple AP/AS topology because the same STA must be able to communciate securely with both the weaker as well as the stronger topologies. An example of a stronger = topology is the single AP with multiple radios, a secure link between the AP & the radios, and a single secure path between the AP and the AS. An example of = a weaker topology consists of multiple APs(with internal radios) each with a path between the AP and the AS. This assessment of these two examples assumes that the security mechanism between the AP and the radios in the first example is superior to that between the AP and the AS in both = cases." And this is where I start riffing. When I talked about APs with multiple radios, I was trying to make the = cateogry as broad as possible, covering cases where the radios are = physically within the AP, as well as cases where the radios are physically = seperate from the AP with a communication path in between. The former = cases are the traditional legacy AP architecture, including APs with mixed = a/g modes. The latter cases are systems that fall under the "Wireless = Switch" banner. There are a lot of possible architectures that fit within the "Wireless = Switch" category, depending on how the functionality of the traditional AP = is split between the central unit and the leaves. I've heard of implementa= tions that put almost the entire functionality in the central unit, and = the leaves are pretty close to dumb radios (Symbol's architecture falls at = this extreme, in that all security, including encryption/decryption, takes = place in the central unit, and in fact we call the leaves Access Ports = instead of Points). I've also heard of implementations where the AP = functionality is almost entirely in the leaves, while the central unit = takes care of administrative tasks. Of course, anybody is free to design = a system which falls in between these two extremes. Given the above, there are four possibilities for placement of the EAP = authenticator and the 4 Way Handshake/Group Key Handshake, which I will = explore below. 1) The central unit has both the EAP authenticator and the 4 Way = Handshake/Group Key Handshake. In this case, the PMK will stay within the = central unit, and will not be pushed out to the leaves. What happens to = the PTK, GTK, and the derivatives of them is unknown, and is outside the = discussion of PMK issues. I believe that in this case, the central unit, = for purposes of this threat analysis, is the AP. 2) The leaves have both the EAP authenticator and the 4 Way Handshake/Grou= p Key Handshake. In this case, the leaf itself has the PMK, and I would = maintain that the leaves are full blown APs unto themselves, and the = central unit is relegated to only being in the communication path between = the AP and the AS "blob", which means that the threat of PMK compromise is = only slightly increased. There is one possible wrinkle; for some reason, = a designer of this sort of architecture may let the central unit know the = RADIUS shared secret, in order to allow the central unit to get the PMK = from the conversation so that the central unit can pass the PMK somewhere = else. This possibility raises a whole new set of possible threats, = including compromise of the central switch. 3) The central unit has the EAP authenticator and the leaf has the 4 Way = Handshake/Group Key Handshake. This means that the PMK must be passed = from the central unit to the leaf, and that handoff had better be secure. = Architectures in this category add two possible ways that the PMK may be = compromised: the central switch or the leaf can be compromised, or the = communication path between the central switch and the leaf can be = compromised. Devices that use this architecture, I think, are as secure = sharing the PMK between the leaves as not; the PMK has to be pushed to the = original leaf in a secure manner anyway, and that same mechanism can be = used to push the PMK to other leaves with the same security (or insecurity)= . 4) The leaf has the EAP authenticator and the central unit has the 4 Way = Handshake/Group Key Handshake. This choice in architecture makes no sense = to me at all, and seems pretty counterproductive. Any thoughts? Clint (JOATMON) Chaplin >>> Fred Haisch 8/4/03 14:19:16 >>> Clint, See my comment below. Fred -----Original Message----- From: Clint Chaplin [mailto:cchaplin@sj.symbol.com]=20 Sent: Monday, August 04, 2003 4:20 PM To: stds-802-11@ieee.org; ieee-802-11-tgi@majordomo.rsasecurity.com; housley@vigilsec.com=20 Subject: Re: [802-11Technical] Security of PMK, PTK, etc. Ooh, ooh, teacher, call on me! I know the answer! (Well, I know I'm answering my own question, but I've had the rest of the weekend to mull it over....) From what I can tell, allowing PMK sharing is more a case of lowered security by degree rather than kind. First of all, how can the PMK become compromised under the existing = system? There are a few ways: 1) Attacker guesses the PMK. Yeah, and pigs will fly. 2) Attacker works out the PMK from traffic. This means cracking the PRF, or something similar. Right now, there is no known attack against the = PRF, but that isn't to mean that there may be one in the future. 3) The station is compromised. 4) The AP is compromised. 5) The AS "blob" is compromised. By "blob", I mean whatever shape the AS may take: single combined server, or separate Radius, EAP, and EAP method servers, with the communication links in between. 6) The communication path between the AS and the AP is compromised. FH -- 6) is one of the more likely approaches but requires access to the wired network to collect RADIUS messages for an attack on the shared = secret and thus the PMK. Access to the wireline network requires only a hub, a cheap AP, and a power outlet and 802.1X on authentication of the AP does = not help. However once the shard secret is compromised, all the PMKs are available! Once the PMK is compromised, what can an attacker do? Under the existing system, any and all of the following: 1) The attacker can eavesdrop on the traffic between the AP and the STA, including broadcast/multicast traffic. With PMK caching, the attacker can do this even when the STA roams away and then comes back. 2) The attacker can inject traffic into the AP or the STA. However, = replay detection will be triggered. 3) If the STA physically moves out of range of the legitimate AP, the attacker can spoof the AP and cause the STA to associate with it. The ultimate success of this tactic depends on what upper level services = (IPSec, etc.) the STA may be expecting. 4) If the STA disappears completely, the attacker can spoof the STA and successfully associate with the legitimate AP (if the STA is elsewhere on the network, the two instances of the MAC address will collide). Again, = the ultimate success of this tactic will depend on the upper level services (IPSec, etc.) the network may be expecting from the STA. Great. That's the stae of the world today. Now, what happens if we allow PMK sharing? The PMK may be compromised in the following additional ways: 1) AP compromisation is not limited to a single AP: any AP that knows the PMK could compromise it. This isn't as much of a problem if we're really talking about a single "AP" with multiple radio interfaces, but still... 2) Whatever mechanism that shares the PMK is compromised. Again, if = we're talking about a single "AP" with multiple radio interfaces, it's not as = much of a problem. HFH -- The problem is that the STA has to be designed for = the weakest AP With PMK sharing, the attacker can do the following, in addition to the attacks listed above: 1) The attacker can listen to traffic between the STA and any AP that = knows the PMK, not just a single AP. A security decrease in degree, not in = kind. 2) The attacker can spoof a "new" AP with an entirely new MAC address and cause the STA to associate with it, even if the STA is within range of legitimate APs. A security decrease in kind. 3) The attacker can eavesdrop on broadcast/multicast traffic for all APs the STA has associated with, even when the STA has lost association. This condition will persist for each AP until the AP changes the broadcast key after the STA has roamed away. I think this is a security decrease in degree, but I'm willing to accept an argument that it's a decrease in = kind. In addition, once it has been detected that a PMK has been compromised, revocation of that PMK will take more effort. FH -- It will also take more effort to find out where the PMK was compromised so that additional attacks using the same approach can be prevented. FH -- The STA needs to be designed for weakest multiple AP/AS topology because the same STA must be able to communciate securely with both the weaker as well as the stronger topologies. An example of a stronger = topology is the single AP with multiple radios, a secure link between the AP & the radios, and a single secure path between the AP and the AS. An example of = a weaker topology consists of multiple APs(with internal radios) each with a path between the AP and the AS. This assessment of these two examples assumes that the security mechanism between the AP and the radios in the first example is superior to that between the AP and the AS in both cases. And, well, that's all I can think of. Are there any others? I'm going to write all this up, expanding and explaining as I go, into a submission to TGi entitled "PMK Sharing Considered Harmful". That way, = when the subject comes up in the future, we can just point the person towards = the submission. Clint (JOATMON) Chaplin >>> "Clint Chaplin" 8/2/03 12:22:23 >>> Well, perhaps I'm not. In order to better focus on my concerns, let's do some postulations. Let's postulate the existence of a company called Fubar, Inc. Fubar has among many other products) a product that consists of a single physical AP with two radios built in (e.g. A/G modes, or two narrowly focused radio beams for narrow coverage). Each radio has a separate MAC address. So = far as I can tell, this company description fits just about every AP manufactirer out there. In this company is a bright, skeptical, highly placed senior engineer, J. Random, who knows something about security, but is not a security expert. One day, J. Random gets the bright idea that since PMK caching within an = AP is allowed, why not allow the same PMK to be valid on both radio interfaces= ? The PMK has >not< been transferred between APs, so there is no security = risk during the transfer. You >know< this is going to happen, and more than once. In fact, I would like to suggest that this problem and solution will become just about as contentious as the 60 second countermeasure. OK, >I< believe that this should not be done, because a lot of really = bright crypto folks (Jesse Walker, Russ Housley, Bob Moskowitz, et. al.) have = told me that this is not a good thing to do, and I believe them. However, J. Random doesn't have that same faith that I have; he doesn't know who these people are. I'm willing to make a deal here. I feel that a lot of real embodiments of J. Random are going to come out of the woodwork, and each one will raise = the same question, and we'll have to go over this over and over again. If you can help me convince J. Random of why this is a bad idea, I'm willing to then be the person that has to explain it to all the others who ask the = same question. Possible new attacks because of this idea would be great (if the attack already exists in the present setup, that doesn't count). J. Random understands attacks. Clint (JOATMON) Chaplin >>> Greg Chesson 8/1/03 09:13:17 >>> Clint is really asking for consensus on the trust model for roaming. "who do you trust, and why." If an attacker knows the PMK, then any trust model fails. But that is not a logical reason for distributing PMKs. PMKs should not be distributed because that is considered to vastly = increase the probability of an attacker compromising the key system. It's an odd argument to say if the attacker already has the PMK then it=20 won't hurt to make it easier for an attacker to get the PMK. duh? Apologies to Clint, but it bothers me to go through all the trouble of=20 certificates and 4-way handshakes and related mechanism to have a strong front gate,=20 and then leave the back door unlocked. g Clint Chaplin wrote: >As part of the roaming discussions within TGi, the idea has been advanced to allow the PMK to be transferred from one AP to another one, as a method of doing fast roaming. When this idea has been brought up, it has been dismissed by the crypto protocol folks as being extremely dangerous, in = that the STA has no secure way of knowing that the AP is a legitimate possessor of the PMK. > >Fair enough. However, that brings up another security problem of an attacker knowing the PMK. If an attacker knows the PMK, it can always set itself up as a mimic of the AP the station is currently associated with = and that is the legitimate owner of the PMK, including the same MAC address, = and the station will never know the difference. The attacking AP can always insert traffic to the station, using the compromised PMK and the MAC = address of the legitimate AP, and none will be the wiser..... > >If this security hole exists, then allowing the PMK to be transferred doesn't open up any bigger hole than what already exists. The PMK must be protected, and the station has to assume that the PMK has not been compromised; otherwise it couldn't trust >any< traffic from >any< AP. > >Clint (JOATMON) Chaplin > > >This message came from the IEEE 802.11 Technical Reflector List >Info at http://www.ieee802.org/11=20 > =20 > ________________________________________________________________________ This email has been scanned for computer viruses. This message came from the IEEE 802.11 Technical Reflector List Info at http://www.ieee802.org/11=20 ________________________________________________________________________ This email has been scanned for computer viruses. ________________________________________________________________________ This email has been scanned for computer viruses. This message came from the IEEE 802.11 Technical Reflector List Info at http://www.ieee802.org/11=20 ________________________________________________________________________ This email has been scanned for computer viruses. From Marcus Brunner Thu Aug 7 10:43:40 2003 From: Marcus Brunner (Marcus Brunner) Date: Thu, 07 Aug 2003 11:43:40 +0200 Subject: [Lwapp] Another attempt at a proposed charter (again) In-Reply-To: References: Message-ID: <5924629.1060256620@[10.1.1.130]> I fully understand that firmware management is an issue. But I also see the complexity in a multi-vendor deployment (and only for these multi-vendor deployments a standard make sense. ) IMHO the AR is not the best place for that function anyway, because I assume also a high number of ARs in a deployment. Firmeware management seams to be a very centralized function. Marcus --On Dienstag, 5. August 2003 12:02 -0400 Mark Jones wrote: >> So far this looks like a rathole. Do you really want to go >> down that path? >> > > I agree with Pat. We've also been hearing that firmware management is an > issue for any sizable 802.1x deployment. If the 'control and provisioning > of access points' is to be the focus of the proposed WG then I think it > should address this problem. > > However, we need to consider whether the AR is always the most suitable > element to host the firmware management functions. It would be a shame if > we just moved this problem to the AR rather than solve it, i.e. network > administrators will now have to manage the AP firmware repositories on the > ARs in addition to the AR firmware. > > Thanks > Mark > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From pcalhoun@airespace.com Thu Aug 7 16:41:57 2003 From: pcalhoun@airespace.com (Pat Calhoun) Date: 07 Aug 2003 08:41:57 -0700 Subject: [Lwapp] Is AR a one box solution In-Reply-To: References: Message-ID: <1060270916.2632.33.camel@localhost.localdomain> On Wed, 2003-08-06 at 07:40, Avi Lior wrote: > Hi, > It seems from reading the proposed charter that the AR is "one box" > solution. That is, all functionality resides on one machine. Is that the > intent? I believe that the current document does allow for the signaling and data plane to terminate on two separate devices (when IP is used as the transport). PatC From lefko@trapezenetworks.com Thu Aug 7 18:18:38 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Thu, 07 Aug 2003 10:18:38 -0700 Subject: [Lwapp-external] RE: [Lwapp] Another attempt at a proposed charter (again) In-Reply-To: <5924629.1060256620@[10.1.1.130]> References: Message-ID: <5.1.0.14.2.20030807100038.035e52a8@mail.trpz.com> At 11:43 AM 8/7/2003 +0200, Marcus Brunner wrote: >IMHO the AR is not the best place for that function anyway, because I >assume also a high number of ARs in a deployment. Firmeware management >seams to be a very centralized function. It seems to me that the AR is the best place to do the firmware download. This is because there is a discovery state. It seems very logical to me that during the discovery state that the firmware object code can be identified and downloaded, if necessary. It seems more complicated to me for the device to have to deal with different entities for config/operation and code download, or have to create more unnecessary requirements for other protocols. In a way I view the code download part of this as something very similar to what an OS has to do to load a device driver. Having a standard way for the right executable to be downloaded into a device seems to me to be within the scope of what we are trying to do, but describing how AR's receive/distribute these executables seems to me to be outside the scope. Marty From avi@bridgewatersystems.com Thu Aug 7 18:54:15 2003 From: avi@bridgewatersystems.com (Avi Lior) Date: Thu, 7 Aug 2003 13:54:15 -0400 Subject: [Lwapp] Is AR a one box solution Message-ID: > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@airespace.com] > Sent: Thursday, August 07, 2003 11:42 AM > To: Avi Lior > Cc: lwapp@frascone.com > Subject: Re: [Lwapp] Is AR a one box solution > > > On Wed, 2003-08-06 at 07:40, Avi Lior wrote: > > Hi, > > It seems from reading the proposed charter that the AR is "one box" > > solution. That is, all functionality resides on one > machine. Is that > > the intent? > I believe that the current document does allow for the > signaling and data plane to terminate on two separate devices > (when IP is used as the transport). > > PatC The current document *may* elude to this possiblity but the charter *should* be explicit about it. We should be dealing with a set of functions - not an entity called an AR which makes one belive that the solution is a one box solution. The issues I have with a specification that mandates a one box solution are: 1) Only a certain number of companies have the capability to deliver a product that is in the data path. The management function does not have to be in the data path. Let those companies build the hardware required to switch packets rapidly and other companies can worry about building the management functions. 2) Because the AR is in the data path you have to have lots of them in large deployments. The Management Functions do not have to be distributed (because of bandwidth restrictions or network restrictions) can these functions can be centralized. We should be defining protocols and these protocols should allow for various implementations. Regarding your statement that it is only possible to have the signaling and data plane to terminate on two separate devices but only when IP is the transport; is it not possible to allow for this when the transport is not IP? From pcalhoun@airespace.com Thu Aug 7 19:03:59 2003 From: pcalhoun@airespace.com (Pat Calhoun) Date: 07 Aug 2003 11:03:59 -0700 Subject: [Lwapp-external] RE: [Lwapp] Another attempt at a proposed charter (again) In-Reply-To: <5.1.0.14.2.20030807100038.035e52a8@mail.trpz.com> References: <5.1.0.14.2.20030807100038.035e52a8@mail.trpz.com> Message-ID: <1060279439.2621.46.camel@localhost.localdomain> > Having a standard way for the right executable to be downloaded into a > device seems to me to be within the scope of what we are trying to do, but > describing how AR's receive/distribute these executables seems to me to be > outside the scope. I agree with this statement. PatC From pcalhoun@airespace.com Thu Aug 7 19:37:56 2003 From: pcalhoun@airespace.com (Pat Calhoun) Date: 07 Aug 2003 11:37:56 -0700 Subject: [Lwapp] Is AR a one box solution In-Reply-To: References: Message-ID: <1060281475.2621.51.camel@localhost.localdomain> But the issue I have with this architecture of having both the data and the control components separate, is that now we require yet another protocol so you get interoperability between these devices :( I don't think we want to go down this path. It may be fine to allow the protocol to do it, but not get into opening up this interface for interoperability. Thoughts? PatC On Thu, 2003-08-07 at 10:54, Avi Lior wrote: > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@airespace.com] > > Sent: Thursday, August 07, 2003 11:42 AM > > To: Avi Lior > > Cc: lwapp@frascone.com > > Subject: Re: [Lwapp] Is AR a one box solution > > > > > > On Wed, 2003-08-06 at 07:40, Avi Lior wrote: > > > Hi, > > > It seems from reading the proposed charter that the AR is "one box" > > > solution. That is, all functionality resides on one > > machine. Is that > > > the intent? > > I believe that the current document does allow for the > > signaling and data plane to terminate on two separate devices > > (when IP is used as the transport). > > > > PatC > > The current document *may* elude to this possiblity but the charter *should* > be explicit about it. > > We should be dealing with a set of functions - not an entity called an AR > which makes one belive that the solution is a one box solution. > > The issues I have with a specification that mandates a one box solution are: > > 1) Only a certain number of companies have the capability to deliver a > product that is in the data path. The management function does not have to > be in the data path. Let those companies build the hardware required to > switch packets rapidly and other companies can worry about building the > management functions. > > 2) Because the AR is in the data path you have to have lots of them in large > deployments. The Management Functions do not have to be distributed > (because of bandwidth restrictions or network restrictions) can these > functions can be centralized. > > We should be defining protocols and these protocols should allow for various > implementations. > > Regarding your statement that it is only possible to have the signaling and > data plane to terminate on two separate devices but only when IP is the > transport; is it not possible to allow for this when the transport is not > IP? From mark.jones@bridgewatersystems.com Thu Aug 7 19:45:57 2003 From: mark.jones@bridgewatersystems.com (Mark Jones) Date: Thu, 7 Aug 2003 14:45:57 -0400 Subject: [Lwapp-external] RE: [Lwapp] Another attempt at a proposed ch arter (again) Message-ID: > Having a standard way for the right executable to be > downloaded into a > device seems to me to be within the scope of what we are > trying to do, but > describing how AR's receive/distribute these executables > seems to me to be > outside the scope. > This restricts the WG to solving just the 'last hop' of the firmware management problem. The WG could solve the whole problem by allowing the firmware repository to reside on a different network element than the AR. This does not prevent a vendor from co-locating the AR with the firmware repository just as a DHCP server could be co-located with a boot server. Mark From pcalhoun@airespace.com Thu Aug 7 19:50:31 2003 From: pcalhoun@airespace.com (Pat Calhoun) Date: 07 Aug 2003 11:50:31 -0700 Subject: [Lwapp-external] RE: [Lwapp] Another attempt at a proposed ch arter (again) In-Reply-To: References: Message-ID: <1060282231.2632.55.camel@localhost.localdomain> > This restricts the WG to solving just the 'last hop' of the firmware > management problem. The WG could solve the whole problem by allowing the > firmware repository to reside on a different network element than the AR. > > This does not prevent a vendor from co-locating the AR with the firmware > repository just as a DHCP server could be co-located with a boot server. I'm not stating that this isn't a problem that doesn't need to be solved, but I think it is a fairly generic problem that should be addressed outside of this (proposed) WG. PatC From kempf@docomolabs-usa.com Thu Aug 7 20:39:38 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 7 Aug 2003 12:39:38 -0700 Subject: [Lwapp] Is AR a one box solution References: <1060281475.2621.51.camel@localhost.localdomain> Message-ID: <027001c35d1b$a3d1ed50$2b6015ac@dclkempt40> > But the issue I have with this architecture of having both the data and > the control components separate, is that now we require yet another > protocol so you get interoperability between these devices :( > Right, that would be MEGACO or SIP. These were designed for separated data and control plane applications. > I don't think we want to go down this path. It may be fine to allow the > protocol to do it, but not get into opening up this interface for > interoperability. > For simplicity, I think it might make sense to keep this interface closed for the moment. This will make the design process go faster. Like using CAPWAP for radio protocols other than 802.11, separation of data and control plane could be introduced down the line, when we've got some experience with the initial protocol. jak From pcalhoun@airespace.com Thu Aug 7 23:02:41 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 7 Aug 2003 15:02:41 -0700 Subject: [Lwapp] Another attempt at a proposedcharter (again) Message-ID: <40301581B2962B448690A023EF16DFE1DC5428@bsn-mail-01.bstormnetworks.com> Duh! I read too fast. I disagree with my own comment. I think we need to = specify how the AR gets the image to the AP. From re-reading Marty's = comment below, it's not clear that's what he was saying. Whether or not we create or specify a protocol for this task is another = matter. PatC -----Original Message----- From: Pat R. Calhoun=20 Sent: Thursday, August 07, 2003 11:04 AM To: Martin Lefkowitz Cc: 'lwapp@frascone.com' Subject: Re: [Lwapp] Another attempt at a proposedcharter (again) > Having a standard way for the right executable to be downloaded into a = > device seems to me to be within the scope of what we are trying to do, = but=20 > describing how AR's receive/distribute these executables seems to me = to be=20 > outside the scope. I agree with this statement. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From lefko@trapezenetworks.com Thu Aug 7 23:51:21 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Thu, 07 Aug 2003 15:51:21 -0700 Subject: [Lwapp] Another attempt at a proposedcharter (again) In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5428@bsn-mail-01.bstormn etworks.com> Message-ID: <5.1.0.14.2.20030807154656.03628f20@mail.trpz.com> No Pat, I am agreeing with you. We need to specify how the AR gets the image to the AP. I'm unclear on how my comment can be construed otherwise, especially within the scope of the whole message, but that is beside the point. Marty At 03:02 PM 8/7/2003 -0700, Pat R. Calhoun wrote: >Duh! I read too fast. I disagree with my own comment. I think we need to >specify how the AR gets the image to the AP. From re-reading Marty's >comment below, it's not clear that's what he was saying. > >Whether or not we create or specify a protocol for this task is another >matter. > >PatC >-----Original Message----- >From: Pat R. Calhoun >Sent: Thursday, August 07, 2003 11:04 AM >To: Martin Lefkowitz >Cc: 'lwapp@frascone.com' >Subject: Re: [Lwapp] Another attempt at a proposedcharter (again) > > > > Having a standard way for the right executable to be downloaded into a > > device seems to me to be within the scope of what we are trying to do, but > > describing how AR's receive/distribute these executables seems to me to be > > outside the scope. > >I agree with this statement. > >PatC > > >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp > > >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Mon Aug 11 02:43:28 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sun, 10 Aug 2003 18:43:28 -0700 Subject: [Lwapp] Another attempt at a proposedcharter (again) Message-ID: <40301581B2962B448690A023EF16DFE1DC547B@bsn-mail-01.bstormnetworks.com> Probably sleep deprivation on my part :( PatC -----Original Message----- From: Martin Lefkowitz [mailto:lefko@trapezenetworks.com] Sent: Thu 8/7/2003 3:51 PM To: lwapp@frascone.com Cc:=09 Subject: RE: [Lwapp] Another attempt at a proposedcharter (again) No Pat, I am agreeing with you. We need to specify how the AR gets the=20 image to the AP. I'm unclear on how my comment can be construed otherwise, especially = within=20 the scope of the whole message, but that is beside the point. Marty At 03:02 PM 8/7/2003 -0700, Pat R. Calhoun wrote: >Duh! I read too fast. I disagree with my own comment. I think we need = to=20 >specify how the AR gets the image to the AP. From re-reading Marty's=20 >comment below, it's not clear that's what he was saying. > >Whether or not we create or specify a protocol for this task is another = >matter. > >PatC >-----Original Message----- >From: Pat R. Calhoun >Sent: Thursday, August 07, 2003 11:04 AM >To: Martin Lefkowitz >Cc: 'lwapp@frascone.com' >Subject: Re: [Lwapp] Another attempt at a proposedcharter (again) > > > > Having a standard way for the right executable to be downloaded into = a > > device seems to me to be within the scope of what we are trying to = do, but > > describing how AR's receive/distribute these executables seems to me = to be > > outside the scope. > >I agree with this statement. > >PatC > > >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp > > >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From mmani@avaya.com Mon Aug 11 19:20:25 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Mon, 11 Aug 2003 12:20:25 -0600 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: Sorry about the long pause in responding... > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Sunday, August 03, 2003 6:15 PM > To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com > Subject: RE: [Lwapp] Another attempt at a proposed charter >=20 >=20 > > [Mani, Mahalingam (Mahalingam)] depends on how we scope Discovery. > > > > Authentication itself is a discovery (and validation) of (in this > case, > > device) identity. Subsequent capabilities exchange would be > facilitated > > under authenticated (and perhaps protected - if SA can be set up a > > priori) conditions. However, it also depends on how LW we want > > preliminary discovery to be as well. > > > > [Mani, Mahalingam (Mahalingam)] For example, IEEE LLDP discovery > > protocol seems to suggest authentication (based, say, on 802.1X) to > > precede discovery (LLDP is a work in progress). [Not suggesting LLDP > for > > discovery]. >=20 > But if the protocol is to run at L3 (and perhaps L2) then I view > discovery as simply a means of acquiring the address of the peer. After > this point, acquisition occurs, and this needs to be authenticated. > Perhaps you are considering a different form of discovery than I am. >=20 [Mani, Mahalingam (Mahalingam)] at L3 - that's alternate approach to - authenticating after the discovery. One may also view discovery as realizing the basic capabilities announced by the peer (not merely the address issued). If address acquisition is all, there's no way authentication can precede discovery - as you say. > > [Mani, Mahalingam (Mahalingam)] Briefly - IEEE 802.11k (Radio > Resource > > Measurements) provides L2 API's for state information (of clients and > > AP's): higher layers are expected to use this information to make > > control / (re)configuration decisions. Depending on how MAC is split - > > this may come partly from AP and part from AR (consulting the AP). > > > > Likewise, Handoff is expected to L2 API triggers (alarms - if you > will) > > on state of association of clients to AP's - which higher layer > > functions (resident in AR more likely) are expected to use for handoff > > decisions. >=20 > So are these functions purely L2? I thought that 802.11k was considering > creating a MIB for these. >=20 [Mani, Mahalingam (Mahalingam)] not as far as I can tell by the latest 802.11k draft. > > Coordinating with the two will help make the WG work quicker. > > Even if CAPWAP is not going to be in the business of defining their > use; > > the proposed protocol should provide for channeling these flows > (between > > AP & AR). > > > > I feel this is important to note given the 'C' in CAPWAP. > > > > To that end - "- Configuration and monitoring of wireless link by AR" > > should be qualified to reflect that. >=20 > Anything that can help provide interoperability, and help speed up the > standards process is a good thing. Actually, I would appreciate if you > could help provide some text that could go into the LWAPP draft that > explains how the interactions between these new task groups can work > with LWAPP. >=20 > PatC [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] here's an attempt (with room to tweak choice of terminologies): "- Configuration and Monitoring of Wireless links by AR" to "- Control, Configuration and Monitoring of wireless links by AR leveraging=20 and consistent with available/evolving Link/MAC-layer interfaces exported to=20 IP and higher layers." While a quick resolution towards 802.11-specific LWAPP is the objective - it is worthwhile to atleast encourage not to preclude possible future WLAN=20 extensibility to, say, mesh networks. -mani From bob@airespace.com Mon Aug 11 19:47:35 2003 From: bob@airespace.com (Bob O'Hara) Date: Mon, 11 Aug 2003 11:47:35 -0700 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: <40301581B2962B448690A023EF16DFE1C8F963@bsn-mail-01.bstormnetworks.com> Regarding what will, or won't, be in the 802.11k draft, I think it is a bit premature to nail that down. The 802.11k working group has not completed its first draft, yet. We (the folks participating in this dialogue) can have an influence on what goes into 802.11k, if we believe it is overlooking something. Dorothy can represent the IETF, as liaison, and any individual is able to make a submission to 802.11k. -Bob O'Hara =20 -----Original Message----- From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com]=20 Sent: Monday, August 11, 2003 11:20 AM To: Pat R. Calhoun; lwapp@frascone.com Subject: RE: [Lwapp] Another attempt at a proposed charter [snip - Bob O'Hara] > So are these functions purely L2? I thought that 802.11k was considering > creating a MIB for these. >=20 [Mani, Mahalingam (Mahalingam)] not as far as I can tell by the latest 802.11k draft. [snip the rest - Bob O'Hara] From pcalhoun@airespace.com Mon Aug 11 20:04:14 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 11 Aug 2003 12:04:14 -0700 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: <40301581B2962B448690A023EF16DFE1DC5492@bsn-mail-01.bstormnetworks.com> [Mani, Mahalingam (Mahalingam)] at L3 - that's alternate approach to - authenticating after the discovery. One may also view discovery as realizing the basic capabilities announced by the peer (not merely the address issued). If address acquisition is all, there's no way authentication can precede discovery - as you say. Correct. Capabilities occurs after the discovery process, and as = you say, it is authenticated. [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] here's an attempt (with room to tweak choice of terminologies): "- Configuration and Monitoring of Wireless links by AR" to "- Control, Configuration and Monitoring of wireless links by AR leveraging=20 and consistent with available/evolving Link/MAC-layer interfaces exported to=20 IP and higher layers." I'm not sure that I follow you here. While a quick resolution towards 802.11-specific LWAPP is the objective - it is worthwhile to atleast encourage not to preclude possible future WLAN=20 extensibility to, say, mesh networks. I think the goal is to restrict to 802.11, as we know it, then = find out whether the protocol is widely deployed. If so, and there is = demand for extensions outside of the current scope, then the (proposed) = WG can be rechartered (or a new WG formed). PatC From pcalhoun@airespace.com Wed Aug 13 17:21:00 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 13 Aug 2003 09:21:00 -0700 Subject: [Lwapp] CAPWAP Problem Statement Message-ID: <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C361B6.E2827C4B Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We just sent this document to the secretariat. Comments welcomed, PatC ------_=_NextPart_001_01C361B6.E2827C4B Content-Type: text/plain; name="draft-calhoun-capwap-problem-statement-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-calhoun-capwap-problem-statement-00.txt Content-Disposition: attachment; filename="draft-calhoun-capwap-problem-statement-00.txt" CgpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFAuIENhbGhvdW4KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQi4gTydIYXJhCkV4cGlyZXM6IEZlYnJ1YXJ5IDExLCAy MDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFpcmVzcGFjZQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Si4gS2VtcGYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRG9jb21vIExhYnMgVVNBCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAxMywgMjAwMwoKCiAgICAgICAgICAgICAg ICAgICAgICAgIENBUFdBUCBQcm9ibGVtIFN0YXRlbWVudAogICAgICAgICAgICAgICBkcmFmdC1j YWxob3VuLWNhcHdhcC1wcm9ibGVtLXN0YXRlbWVudC0wMAoKU3RhdHVzIG9mIHRoaXMgTWVtbwoK ICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25m b3JtYW5jZSB3aXRoCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29y a2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1 dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1v bnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50 IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgaHR0cDovLwogICB3d3cuaWV0Zi5v cmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4KCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbC4KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g RmVicnVhcnkgMTEsIDIwMDQuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKEMpIFRo ZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAzKS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCgpBYnN0cmFj dAoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIENvbmZpZ3VyYXRpb24gYW5kIFByb3Zp c2lvbmluZyBmb3IKICAgV2lyZWxlc3MgQWNjZXNzIFBvaW50cyAoQ0FQV0FQKSBwcm9ibGVtIHN0 YXRlbWVudC4KCgoKCgoKCgoKCkNhbGhvdW4sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMTEsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgIENBUFdBUCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICBBdWd1c3QgMjAwMwoKClRh YmxlIG9mIENvbnRlbnRzCgogICAxLiBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgMi4gUHJvYmxlbSBTdGF0ZW1lbnQg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0CiAgIDMuIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNgogICAgICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcKICAgICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3CiAgICAgIEZ1bGwgQ29weXJp Z2h0IFN0YXRlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOAoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKQ2FsaG91biwgZXQgYWwu ICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxMSwgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDJd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgQ0FQV0FQIFByb2JsZW0gU3RhdGVtZW50ICAgICAg ICAgICAgIEF1Z3VzdCAyMDAzCgoKMS4gSW50cm9kdWN0aW9uCgogICBIaXN0b3JpY2FsbHksIHdp cmVsZXNzIExBTiAoV0xBTikgZGVwbG95bWVudHMgaGF2ZSBiZWVuIGRvbmUgdXNpbmcKICAgc3Rh bmQtYWxvbmUgODAyLjExIGFjY2VzcyBwb2ludHMgKEFQcykgdGhhdCBwZXJmb3JtIGxheWVyIDIg YnJpZGdpbmcsCiAgIGNvbm5lY3RlZCB0byBhIGxheWVyIDIgbmV0d29yayBmb3IgZGlzdHJpYnV0 aW9uIG9mIHRoZSBwYWNrZXRzIGZyb20KICAgODAyLjExIG1vYmlsZSBjbGllbnQgZGV2aWNlcyB0 byBvdGhlciBkZXZpY2VzLCBib3RoIHdpcmVkIGFuZAogICB3aXJlbGVzcy4gIFRoaXMgbmV0d29y ayBhcmNoaXRlY3R1cmUgc3VmZmljZWQgZm9yIHRoZSBsaW1pdGVkIHNpemUgb2YKICAgODAyLjEx IG5ldHdvcmtzLCB1bnRpbCByZWNlbnRseS4gIEFzIHRoZSBsaW1pdGF0aW9ucyB0aGF0IGhhdmUg aGVsZAogICBiYWNrIHRoZSBncm93dGggb2YgdGhlIHNpemUgb2YgODAyLjExIG5ldHdvcmtzIGhh dmUgYmVlbiBhZGRyZXNzZWQsCiAgIHRob3NlIG5ldHdvcmtzIGhhdmUgYmVndW4gdG8gaW5jcmVh c2UgaW4gc2l6ZS4gIFNvbWUgODAyLjExIG5ldHdvcmtzCiAgIGhhdmUgZ3Jvd24gdG8gaW5jbHVk ZSB0aG91c2FuZHMgb2YgQVBzLiAgVGhpcyBncm93dGggb2YgaW5kaXZpZHVhbAogICA4MDIuMTEg bmV0d29yayBzaXplIGhhcyBpbnRyb2R1Y2VkIGZvdXIgcHJvYmxlbXMgdGhhdCBuZWVkIHRvIGJl CiAgIGFkZHJlc3NlZC4KCiAgIE5vdGUgdGhhdCB0aGUgbGltaXRhdGlvbnMgb24gdGhlIHNjYWxh YmlsaXR5IG9mIGJyaWRnaW5nIHNob3VsZCBjb21lCiAgIGFzIG5vIHN1cHJpc2UgdG8gdGhlIG5l dHdvcmtpbmcgY29tbXVuaXR5LCBzaW5jZSBzaW1pbGFyIGxpbWl0YXRpb25zCiAgIGFyb3NlIGlu IHRoZSBlYXJseSAxOTgwJ3MgZm9yIHdpcmVkIG5ldHdvcmsgYnJpZGdpbmcgZHVyaW5nIHRoZQog ICBleHBhbnNpb24gYW5kIGludGVyY29ubmVjdGlvbiBvZiB3aXJlZCBsb2NhbCBhcmVhIG5ldHdv cmtzLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDYWxob3VuLCBldCBhbC4gICAg ICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDExLCAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAg ICAgQXVndXN0IDIwMDMKCgoyLiBQcm9ibGVtIFN0YXRlbWVudAoKICAgVGhlIGZpcnN0IHByb2Js ZW0gY3JlYXRlZCBieSBpbmNyZWFzZWQgc2l6ZSBvZiBhbiA4MDIuMTEgbmV0d29yayBpcwogICB0 aGF0IHRoZSBpbmRpdmlkdWFsIEFQcyBhcmUgZWFjaCBJUCBhZGRyZXNzYWJsZSBkZXZpY2VzIHRo YXQgcmVxdWlyZQogICBtYW5hZ2VtZW50LCBtb25pdG9yaW5nLCBhbmQgY29udHJvbC4gIFR5cGlj YWwgODAyLjExIG5ldHdvcmtzIHRoYXQKICAgcHJvdmlkZSB3aXJlbGVzcyBjb3ZlcmFnZSBmb3Ig YWxsIHRoZSBvZmZpY2Ugc3BhY2Ugb2YgYW4gaW5zdGFsbGF0aW9uCiAgIHVzdWFsbHkgZG91Ymxl IHRoZSBudW1iZXIgb2YgZGV2aWNlcyByZXF1aXJpbmcgbWFuYWdlbWVudCBpbiB0aGF0CiAgIGlu c3RhbGxhdGlvbiwgb3ZlciB0aGUgd2lyZWQgZGV2aWNlcyB0aGF0IGFyZSBhbHJlYWR5IHByZXNl bnQuICBUaGlzCiAgIHByZXNlbnRzIGEgc2lnbmlmaWNhbnQgYWRkaXRpb25hbCBidXJkZW4gdG8g dGhlIG5ldHdvcmsKICAgYWRtaW5pc3RyYXRpb24gcmVzb3VyY2VzIGFuZCBpcyBvZnRlbiBhIGh1 cmRsZSB0byBhZG9wdGlvbiBvZgogICB3aXJlbGVzcyB0ZWNobm9sb2dpZXMuICBDZW50cmFsaXpp bmcgdGhlIG1hbmFnZW1lbnQsIG1vbml0b3JpbmcsIGFuZAogICBjb250cm9sIG9mIHRoZSBBUHMg aW4gYSBzZWN1cmUgbWFubmVyIHdpbGwgcmVkdWNlIHRoZSBidXJkZW4gb2YKICAgZGVwbG95aW5n IGFuZCBvcGVyYXRpbmcgbGFyZ2UgODAyLjExIG5ldHdvcmtzLgoKICAgVGhlIHNlY29uZCBwcm9i bGVtIGNyZWF0ZWQgYnkgaW5jcmVhc2VkIHNpemUgb2YgYW4gODAyLjExIG5ldHdvcmsgaXMKICAg ZGlzdHJpYnV0aW5nIGFuZCBtYWludGFpbmluZyBhIGNvbnNpc3RlbnQgY29uZmlndXJhdGlvbiBp biB0aGUgbWFueQogICBBUHMuICBEZXNpZ25pbmcgYW4gODAyLjExIG5ldHdvcmsgY2FuIGludm9s dmUgYSBzaWduaWZpY2FudCBhbW91bnQgb2YKICAgbWFudWFsIHN1cnZleWluZyBhbmQgY29uZmln dXJhdGlvbiBvZiB0aGUgQVBzLiAgS2VlcGluZyB0cmFjayBvZiB0aGUKICAgQVBzJyBjb25maWd1 cmF0aW9uIGlzIGFuIGFyZHVvdXMgdGFzaywgYXMgaXMgbW9kaWZ5aW5nIHRoZQogICBjb25maWd1 cmF0aW9uIG9mIHRoZSA4MDIuMTEgbmV0d29yayAoYmVjYXVzZSB0aGUgY29uZmlndXJhdGlvbiBv ZiBhCiAgIHNpbmdsZSBBUCBjYW4gYWZmZWN0IHRoZSBvcGVyYXRpb24gb2Ygb25lIG9yIG1vcmUg b2YgaXRzIG5laWdoYm9yCiAgIEFQcywgYW5kIHNvIG9uKS4gIEFuIGFkZGl0aW9uYWwgcGFydCBv ZiB0aGUgQVAgY29uZmlndXJhdGlvbiBpcwogICBtYWludGFpbmluZyBhIGNvbnNpc3RlbnQgY29k ZSBiYXNlIHRoYXQgaXMgcnVubmluZyBpbiB0aGUgQVBzCiAgIHRocm91Z2hvdXQgdGhlIG5ldHdv cmsuICBUbyBtaW5pbWl6ZSB0aGUgdmFyaWF0aW9uIG9mIGZ1bmN0aW9uYWxpdHkKICAgYWNyb3Nz IHRoZSA4MDIuMTEgbmV0d29yayBhbmQgdG8gbWF4aW1pemUgdGhlIGludGVyb3BlcmFiaWxpdHkK ICAgYmV0d2VlbiB0aGUgQVBzIGFuZCB0aGUgbW9iaWxlIHdpcmVsZXNzIGNsaWVudHMsIGFsbCBv ZiB0aGUgQVBzCiAgIHNob3VsZCBiZSBvcGVyYXRpbmcgb24gdGhlIHNhbWUgY29kZSBiYXNlLiAg RGlzdHJpYnV0aW5nIHRoaXMgY29kZQogICBiYXNlIHRvIHRoZSBBUHMgc2VjdXJlbHksIHVuZGVy IHRoZSBjb250cm9sIG9mIHRoZSBuZXR3b3JrCiAgIGFkbWluaXN0cmF0b3IsIGluIGEgY29uc2lz dGVudCBmYXNoaW9uLCBhbmQgaW4gYSB0aW1lbHkgZmFzaGlvbiwgaXMKICAgY3VycmVudGx5IGFk ZHJlc3NlZCBvbmx5IGluIHByb3ByaWV0YXJ5IHNvbHV0aW9ucy4KCiAgIFRoZSB0aGlyZCBwcm9i bGVtIHdpdGggdGhlIHRyYWRpdGlvbmFsIGFyY2hpdGVjdHVyZSBpcyB0aGF0IGVhY2ggQVAKICAg b25seSBoYXMgdmlzaWJpbGl0eSBpbnRvIGl0cyBvd24gY2VsbC4gIFRoZSB0eXBpY2FsIEFQIGlz IGEgZGV2aWNlCiAgIHRoYXQgc3RhbmRzIGFsb25lLCB3aXRob3V0IG11Y2ggcmVnYXJkIGZvciBu ZWlnaGJvcmluZyBBUHMsIGl0cwogICBlZmZlY3Qgb24gdGhvc2UgbmVpZ2hib3JzLCBvciB0aGUg bmVpZ2hib3JzIGVmZmVjdHMgb24gaXRzZWxmLiAgVGhpcwogICBhcmNoaXRlY3R1cmUgbWFrZXMg aXQgdmlydHVhbGx5IGltcG9zc2libGUgdG8gYmUgYWJsZSB0byBsb29rIGF0CiAgIHBvdGVudGlh bCBhdHRhY2tzIChvciBwYXR0ZXJucyksIGFuZCBjb3JyZWxhdGUgdGhpcyBpbmZvcm1hdGlvbiB3 aXRoCiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gZnJvbSB2YXJpb3VzIG90aGVyIG5laWdoYm9y aW5nIGNlbGxzLgogICBDZW50cmFsaXppbmcgdGhlIDgwMi4xMSBwb2xpY3kgbWFuYWdlbWVudCBw cm92aWRlcyBhIG11Y2ggZ3JlYXRlcgogICB2aWV3IGludG8gdGhlIFJGIG5ldHdvcmssIGFuZCBh bGxvd3MgdmVuZG9ycyB0byBhZGQgbWFueSB2YWx1ZSBhZGRlZAogICBmZWF0dXJlcyB0aGF0IGRp cmVjdGx5IGFkZHJlc3Mgc2VjdXJpdHksIHdoaWNoIGlzIG9uZSBvZiB0aGUgYmlnZ2VzdAogICBp bXBlZGVtZW50cyBoaW5kZXJpbmcgbGFyZ2Ugc2NhbGUgZGVwbG95bWVudHMuCgogICBJdCBpcyBm ZWx0IHRoYXQgdGhpcyBuZXcgY2VudHJhbGl6ZWQgYXJjaGl0ZWN0dXJlIGFsbG93cyB2ZW5kb3Jz IHRvCiAgIHByb3ZpZGUgc2lnbmlmaWNhbnQgdmFsdWUgYWRkZWQgZmVhdHVyZXMsIHN1Y2ggYXMg UkYgbWFuYWdlbWVudCwKICAgd2hpY2ggYXJlIG91dCBvZiBzY29wZSBvZiB0aGlzIHByb2JsZW0g c3RhdGVtZW50LgoKICAgQSBmb3VydGggcHJvYmxlbSBoYXMgdG8gZG8gd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBvZiBhY2Nlc3MgcG9pbnRzIG9uCgoKCkNhbGhvdW4sIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMTEsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgIENBUFdBUCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICBBdWd1 c3QgMjAwMwoKCiAgIHRoZSBuZXR3b3JrLiAgVGhlcmUgaXMgYSBncm93aW5nIGNvbmNlcm4gYW1v bmcgSVQgbWFuYWdlcnMgcmVnYXJkaW5nCiAgIHRoZSB1bmF1dGhvcml6ZWQgdXNlIG9mIEFjY2Vz cyBQb2ludHMgaW4gdGhlaXIgbmV0d29yaywgY3JlYXRpbmcgYQogICBzZXJpb3VzIHNlY3VyaXR5 IHRocmVhdC4gIEl0IGlzIHRoZXJlZm9yZSBuZWNlc3NhcnkgZm9yIGFjY2VzcyBwb2ludHMKICAg dG8gYmUgYXV0aG9yaXplZCBwcmlvciB0byBkZWxpdmVyaW5nIHdpcmVsZXNzIHNlcnZpY2UuCgog ICBSZWNlbnRseSwgbXVsdGlwbGUgdmVuZG9ycyBoYXZlIGJlZ3VuIG9mZmVyaW5nIHByb3ByaWV0 YXJ5IHNvbHV0aW9ucwogICB0aGF0IGNvbWJpbmUgYXNwZWN0cyBvZiBuZXR3b3JrIHN3aXRjaGlu ZywgY2VudHJhbGl6ZWQgY29udHJvbCBhbmQKICAgbWFuYWdlbWVudCwgYW5kIGRpc3RyaWJ1dGVk IHdpcmVsZXNzIGFjY2VzcyB0byBzb2x2ZSB0aGUgYWJvdmUKICAgbWVudGlvbmVkIHByb2JsZW1z LiAgU2luY2UgaW50ZXJvcGVyYWJsZSBzb2x1dGlvbnMgYWxsb3cgc2VydmljZQogICBwcm92aWRl cnMgYSBicm9hZGVyIGNob2ljZSwgYSBzdGFuZGFyZGl6ZWQsIGludGVyb3BlcmFibGUgaW50ZXJm YWNlCiAgIGJldHdlZW4gYWNjZXNzIHBvaW50cyBhbmQgYSBjZW50cmFsaXplZCBjb250cm9sbGVy IGFkZHJlc3NpbmcgdGhlCiAgIGFib3ZlIG1lbnRpb25lZCBwcm9ibGVtcyBzZWVtcyBkZXNpcmFi bGUuCgogICBUaGUgcGh5c2ljYWwgcG9ydGlvbnMgb2YgdGhpcyBuZXR3b3JrIHN5c3RlbSwgaW4g Y3VycmVudGx5IGZpZWxkZWQKICAgZGV2aWNlcywgYXJlIG9uZSBvciBtb3JlIDgwMi4xMSBhY2Nl c3MgcG9pbnRzIChBUHMpIGFuZCBvbmUgb3IgbW9yZQogICBjZW50cmFsIGNvbnRyb2wgZGV2aWNl cywgYWx0ZXJuYXRpdmVseSBkZXNjcmliZWQgYXMgY29udHJvbGxlcnMgKG9yCiAgIEFScykuICBJ ZGVhbGx5LCBhIG5ldHdvcmsgZGVzaWduZXIgd291bGQgYmUgYWJsZSB0byBjaG9vc2Ugb25lIG9y CiAgIG1vcmUgdmVuZG9ycyBmb3IgdGhlIEFQcyBhbmQgb25lIG9yIG1vcmUgdmVuZG9ycyBmb3Ig dGhlIGNlbnRyYWwKICAgY29udHJvbCBkZXZpY2VzIGluIHN1ZmZpY2llbnQgbnVtYmVycyB0byBk ZXNpZ24gYSBuZXR3b3JrIHdpdGggODAyLjExCiAgIHdpcmVsZXNzIGFjY2VzcyB0byBtZWV0IHRo ZSBkZXNpZ25lcidzIHJlcXVpcmVtZW50cy4gIEN1cnJlbnQKICAgaW1wbGVtZW50YXRpb25zIGFy ZSBwcm9wcmlldGFyeSBhbmQgbm90IGludGVyb3BlcmFibGUuICBEZWZpbmluZyBhbgogICBpbnRl cmZhY2UgYmV0d2VlbiB0aGVzZSB0d28gbGF5ZXJzIG9mIHRoZSBoaWVyYXJjaHksIGlkZW50aWZ5 aW5nCiAgIGV4aXN0aW5nIHN0YW5kYXJkIHByb3RvY29scyB0aGF0IGNhbiBiZSB1c2VkIHRvIHBy b3ZpZGUgdGhlIG5lY2Vzc2FyeQogICBmdW5jdGlvbnMgdG8gc29sdmUgdGhlIHByb2JsZW1zIGRl c2NyaWJlZCBhYm92ZSwgYW5kIGRldmVsb3Bpbmcgb25lCiAgIG9yIG1vcmUgbmV3IHByb3RvY29s cyB0byBwcm92aWRlIGZ1bmN0aW9ucyBub3QgbWV0IGJ5IGV4aXN0aW5nCiAgIHByb3RvY29scyBp cyBuZWNlc3NhcnkgdG8gZW5hYmxlIG11bHRpLXZlbmRvciBpbnRlcm9wZXJhYmlsaXR5IGluCiAg IHRoaXMgbmV3IGFyY2hpdGVjdHVyZSBmb3Igd2lyZWxlc3MgYWNjZXNzLgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgpDYWxob3VuLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDExLCAy MDA0ICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBDQVBX QVAgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgQXVndXN0IDIwMDMKCgozLiBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucwoKICAgVG8gdGhlIGV4dGVudCBvZiBvdXIga25vd2xlZGdlLCB0aGlz IHByb2JsZW0gc3RhdGVtZW50IGRvZXMgbm90CiAgIGNyZWF0ZSBhbnkgc2VjdXJpdHkgaXNzdWVz IHRvIHRoZSBJbnRlcm5ldC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgpDYWxob3VuLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDExLCAyMDA0 ICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBDQVBXQVAg UHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgQXVndXN0IDIwMDMKCgpSZWZlcmVuY2VzCgog ICBbMV0gICJNb2JpbGl0eSBSZWxhdGVkIFRlcm1pbm9sb2d5IiwgQXByaWwgMjAwMywgPGZ0cDov L2Z0cC5pc2kuZWR1LwogICAgICAgIGludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNlYW1vYnkt dGVybWlub2xvZ3ktMDQudHh0Pi4KCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIFBhdCBSLiBDYWxo b3VuCiAgIEFpcmVzcGFjZQogICAxMTAgTm9ydGVjaCBQYXJrd2F5CiAgIFNhbiBKb3NlLCBDQSAg OTUxMzQKCiAgIFBob25lOiArMSA0MDgtNjM1LTIwMDAKICAgRU1haWw6IHBjYWxob3VuQGFpcmVz cGFjZS5jb20KCgogICBCb2IgTydIYXJhCiAgIEFpcmVzcGFjZQogICAxMTAgTm9ydGVjaCBQYXJr d2F5CiAgIFNhbiBKb3NlLCBDQSAgOTUxMzQKCiAgIFBob25lOiArMSA0MDgtNjM1LTIwMjUKICAg RU1haWw6IGJvYkBhaXJlc3BhY2UuY29tCgoKICAgSmFtZXMgS2VtcGYKICAgRG9jb21vIExhYnMg VVNBCiAgIDE4MSBNZXRybyBEcml2ZSwgU3VpdGUgMzAwCiAgIFNhbiBKb3NlLCBDQSAgOTUxMTAK CiAgIFBob25lOiArMSA0MDggNDUxIDQ3MTEKICAgRU1haWw6IGtlbXBmQGRvY29tb2xhYnMtdXNh LmNvbQoKCgoKCgoKCgoKCgoKCgoKCgpDYWxob3VuLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDExLCAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgQXVndXN0IDIwMDMK CgpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0 IFNvY2lldHkgKDIwMDMpLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQg YW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8KICAg b3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNl IGV4cGxhaW4gaXQKICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJl cGFyZWQsIGNvcGllZCwgcHVibGlzaGVkCiAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3Ig aW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkKICAga2luZCwgcHJvdmlkZWQgdGhh dCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlCiAgIGlu Y2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gIEhvd2V2ZXIs IHRoaXMKICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwg c3VjaCBhcyBieSByZW1vdmluZwogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2Vz IHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyCiAgIEludGVybmV0IG9yZ2FuaXphdGlv bnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3NlIG9mCiAgIGRldmVsb3BpbmcgSW50 ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yCiAgIGNvcHly aWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZQog ICBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2Vz IG90aGVyIHRoYW4KICAgRW5nbGlzaC4KCiAgIFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50 ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3QgYmUKICAgcmV2b2tlZCBieSB0aGUg SW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25zLgoKICAgVGhpcyBk b2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQg b24gYW4KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJ TlRFUk5FVCBFTkdJTkVFUklORwogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElF UywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcKICAgQlVUIE5PVCBMSU1JVEVEIFRPIEFO WSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OCiAgIEhFUkVJTiBXSUxM IE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YKICAg TUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoKQWNr bm93bGVkZ2VtZW50CgogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBj dXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlCiAgIEludGVybmV0IFNvY2lldHkuCgoKCgoKCgoKCgoK CgoKCgoKCgpDYWxob3VuLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDExLCAyMDA0 ICAgICAgICAgICAgICAgW1BhZ2UgOF0KDAo= ------_=_NextPart_001_01C361B6.E2827C4B-- From mmani@avaya.com Thu Aug 14 12:11:36 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 14 Aug 2003 05:11:36 -0600 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Monday, August 11, 2003 12:04 PM > To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com > Subject: RE: [Lwapp] Another attempt at a proposed charter >=20 > [Mani, Mahalingam (Mahalingam)] at L3 - that's alternate approach to - > authenticating after the discovery. >=20 > One may also view discovery as realizing the basic capabilities > announced by the peer (not merely the address issued). If address > acquisition is all, there's no way authentication can precede discovery > - as you say. >=20 > Correct. Capabilities occurs after the discovery process, and as you > say, it is authenticated. >=20 > [Mani, Mahalingam (Mahalingam)] > [Mani, Mahalingam (Mahalingam)] here's an attempt (with room to tweak > choice of terminologies): >=20 > "- Configuration and Monitoring of Wireless links by AR" >=20 > to >=20 > "- Control, Configuration and Monitoring of wireless links by AR > leveraging > and consistent with available/evolving Link/MAC-layer interfaces > exported to > IP and higher layers." >=20 > I'm not sure that I follow you here. >=20 [Mani, Mahalingam (Mahalingam)] I will simplify it: "- Control, Configuration and Monitoring of wireless links by AR leveraging, where relevant, evolving link-layer standards such as=20 802.11k." [...] > PatC [Mani, Mahalingam (Mahalingam)] -mani From pcalhoun@airespace.com Thu Aug 14 14:05:16 2003 From: pcalhoun@airespace.com (Pat Calhoun) Date: Thu, 14 Aug 2003 06:05:16 -0700 Subject: [Lwapp] Another attempt at a proposed charter In-Reply-To: References: Message-ID: <1060866316.1871.20.camel@pc-laptop.airespace.com> > [Mani, Mahalingam (Mahalingam)] I will simplify it: > "- Control, Configuration and Monitoring of wireless links by AR > leveraging, where relevant, evolving link-layer standards such as > 802.11k." > [...] So basically, you are stating that the protocol should poll 802.11k statistics from the AP? I think the primary issue here is that 802.11k is not done (yet), and althought I agree with your statement, I'd hate to tie our protocol design based on unfinished work at the IEEE. Ideally, the protocol would have to be "extended" to be able to retrieve new statistics from the AP, and 802.11k is one such example. PatC From mmani@avaya.com Thu Aug 14 14:20:11 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 14 Aug 2003 07:20:11 -0600 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: While I agree that 802.11k is not the same scope as LWAPP; my point is that=20 Inasmuch as we have a LWAPP that serves to configure and monitor just the AP's that they also make available the stats. that it helps retrieve from AP and clients (and not limited to 802.11k). I am not suggesting we tie LWAPP down to 802.11k. I am pointing out the relevance of such to be available through LWAPP. For sure, depending on how MAC is split, this may be getting done differently - between AP and AR. My concern is we will end up having more exchanges between AP & AR outside LWAPP scope than LWAPP aims for now. In my opinion that sort of dampens the purpose of LWAPP. -mani > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@airespace.com] > Sent: Thursday, August 14, 2003 6:05 AM > To: Mani, Mahalingam (Mahalingam) > Cc: lwapp@frascone.com > Subject: RE: [Lwapp] Another attempt at a proposed charter >=20 >=20 > > [Mani, Mahalingam (Mahalingam)] I will simplify it: > > "- Control, Configuration and Monitoring of wireless links by AR > > leveraging, where relevant, evolving link-layer standards such as > > 802.11k." > > [...] > So basically, you are stating that the protocol should poll 802.11k > statistics from the AP? I think the primary issue here is that 802.11k > is not done (yet), and althought I agree with your statement, I'd hate > to tie our protocol design based on unfinished work at the IEEE. > Ideally, the protocol would have to be "extended" to be able to retrieve > new statistics from the AP, and 802.11k is one such example. >=20 > PatC From pcalhoun@airespace.com Thu Aug 14 14:25:33 2003 From: pcalhoun@airespace.com (Pat Calhoun) Date: Thu, 14 Aug 2003 06:25:33 -0700 Subject: [Lwapp] Another attempt at a proposed charter In-Reply-To: References: Message-ID: <1060867533.1871.25.camel@pc-laptop.airespace.com> On Thu, 2003-08-14 at 06:20, Mani, Mahalingam (Mahalingam) wrote: > While I agree that 802.11k is not the same scope as LWAPP; my point is > that > Inasmuch as we have a LWAPP that serves to configure and monitor just > the AP's that they also make available the stats. that it helps retrieve > from AP and clients (and not limited to 802.11k). Given the split, the end result is simply that the 802.11k stack resides in the AR, and 802.11k exchanges are done between the AP and the AR. > I am not suggesting we > tie LWAPP down to 802.11k. I am pointing out the relevance of such to be > available through LWAPP. For sure, depending on how MAC is split, this > may be getting done differently - between AP and AR. My concern is we > will end up having more exchanges between AP & AR outside LWAPP scope > than LWAPP aims for now. > In my opinion that sort of dampens the purpose of LWAPP. Agreed, this would be a bad thing, but other than having new statistics to poll from the AP once 802.11k is available, it isn't clear that I see how we'd end up with additional exchanges. Could you help clarify this for me? PatC From mmani@avaya.com Thu Aug 14 20:12:08 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 14 Aug 2003 13:12:08 -0600 Subject: [Lwapp] Another attempt at a proposed charter Message-ID: Pat, > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@airespace.com] > Sent: Thursday, August 14, 2003 6:26 AM > To: Mani, Mahalingam (Mahalingam) > Cc: lwapp@frascone.com > Subject: RE: [Lwapp] Another attempt at a proposed charter >=20 > On Thu, 2003-08-14 at 06:20, Mani, Mahalingam (Mahalingam) wrote: > > While I agree that 802.11k is not the same scope as LWAPP; my point is > > that > > Inasmuch as we have a LWAPP that serves to configure and monitor just > > the AP's that they also make available the stats. that it helps retrieve > > from AP and clients (and not limited to 802.11k). > Given the split, the end result is simply that the 802.11k stack resides > in the AR, and 802.11k exchanges are done between the AP and the AR. >=20 [Mani, Mahalingam (Mahalingam)] if this is applicable to all splits I see no issues. > > I am not suggesting we > > tie LWAPP down to 802.11k. I am pointing out the relevance of such to be > > available through LWAPP. For sure, depending on how MAC is split, this > > may be getting done differently - between AP and AR. My concern is we > > will end up having more exchanges between AP & AR outside LWAPP scope > > than LWAPP aims for now. > > In my opinion that sort of dampens the purpose of LWAPP. > Agreed, this would be a bad thing, but other than having new statistics > to poll from the AP once 802.11k is available, it isn't clear that I see > how we'd end up with additional exchanges. Could you help clarify this [Mani, Mahalingam (Mahalingam)] People have raised on this list the varied approaches to MAC-split. If this is so - based on where the (802.11k or other) work gets done - LWAPP may be used to get the information over from AP->AR. The nature of MAC-split will determine how such LWAPP exchanges get defined. Unless LWAPP allows for extensions accommodating all such splits. I will leave the clarification at that. > for me? >=20 > PatC >=20 [Mani, Mahalingam (Mahalingam)] -mani From Marcus Brunner Mon Aug 18 15:13:09 2003 From: Marcus Brunner (Marcus Brunner) Date: Mon, 18 Aug 2003 16:13:09 +0200 Subject: [Lwapp] CAPWAP Problem Statement In-Reply-To: <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetworks.com> References: <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> Message-ID: <25096186.1061223189@[10.1.1.130]> Problem 1: managing large networks is a common problem. Centralization of management for large networks is a problem not a solution. Problem 2: updating fireware of all the network element at once is somehting nobody likes to do, because a failure in the new fireware has catastrophic implication for your network. Why should this be different for 802.11 networks? Additionally, do you regard configuration as parameters or as code? Marcus --On Mittwoch, 13. August 2003 09:21 -0700 "Pat R. Calhoun" wrote: > We just sent this document to the secretariat. > > Comments welcomed, > > PatC > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From kempf@docomolabs-usa.com Mon Aug 18 17:27:15 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 18 Aug 2003 09:27:15 -0700 Subject: [Lwapp] CAPWAP Problem Statement References: <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> <25096186.1061223189@[10.1.1.130]> Message-ID: <01bf01c365a5$962740f0$0a6015ac@dclkempt40> Marcus, > Problem 1: managing large networks is a common problem. Centralization of > management for large networks is a problem not a solution. > Whatever leads you to this conclusion? Having a single point from which a a single person acting as an administrator can monitor and update configuration on many different networks elements (routers, firewalls, whatever), seems like a much more cost effective solution than having to send one or a bunch of people around to each individual machine to monitor and update. Or am I missing something? jak From lefko@trapezenetworks.com Mon Aug 18 18:05:05 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Mon, 18 Aug 2003 10:05:05 -0700 Subject: [Lwapp] CAPWAP Problem Statement In-Reply-To: <25096186.1061223189@[10.1.1.130]> References: <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetworks.com> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> Message-ID: <5.1.0.14.2.20030818094659.01c7b828@mail.trpz.com> At 04:13 PM 8/18/2003 +0200, Marcus Brunner wrote: >Problem 1: managing large networks is a common problem. Centralization of >management for large networks is a problem not a solution. > >Problem 2: updating fireware of all the network element at once is >somehting nobody likes to do, because a failure in the new fireware has >catastrophic implication for your network. Why should this be different >for 802.11 networks? I think the CAPWAP document may need some different wording in this area. When I reread it in light of this question, I can see where you would think this. My understanding is that CAPWAP would be handing the downloading of code, not the updating of firmware. My understanding was that an AP would identify itself, and then the AR would download it's code in a way that both would be able to interpret the results. This is different than upgrading. But the process of upgrading requires that code be downloaded. >Additionally, do you regard configuration as parameters or as code? After developing a number of these devices I think the AP would have 3 states. Init: This would be everything needed to get the code operational. This includes EEPROM, or messages from the AP and AR in the boot state (e.g. identification messages). Code download is optional. Configuration: Everything needed to enable the radio in the system Operational: Radio's on data is flowing back and forth. There will however be messages that flow back and forth that happen both in the configuration and operational state. The difference is whether the radio needs to be off or on. Marty From lefko@trapezenetworks.com Mon Aug 18 18:45:27 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Mon, 18 Aug 2003 10:45:27 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) In-Reply-To: <5.1.0.14.2.20030818094659.01c7b828@mail.trpz.com> References: <25096186.1061223189@[10.1.1.130]> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetworks.com> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> Message-ID: <5.1.0.14.2.20030818104002.03ce2900@mail.trpz.com> I also am wondering why we need a secure download? Given TGi's basic linchpin of mutual authentication I wonder what good it would do to have rogue code in an AP that can not authenticate itself to the AR in it's operational state, or authenticate itself of the STA in it's operational state. However, I do see significant danger in putting something like a certificate in a physically insecure device (like in a hotspot) where it could be broken into and have the certificate compromised. Seems to me that the CAPWAP doc should concentrate of getting the image downloaded reliably, not securely. The security part come in play in the operational state. Marty From kempf@docomolabs-usa.com Mon Aug 18 18:48:33 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 18 Aug 2003 10:48:33 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) References: <25096186.1061223189@[10.1.1.130]> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetworks.com> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> <5.1.0.14.2.20030818104002.03ce2900@mail.trpz.com> Message-ID: <02dc01c365b0$f19020f0$0a6015ac@dclkempt40> How about rogue code that causes the AP to increase its power to the maximum and start broadcasting white noise across all channels? jak ----- Original Message ----- From: "Martin Lefkowitz" To: Sent: Monday, August 18, 2003 10:45 AM Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > I also am wondering why we need a secure download? > > Given TGi's basic linchpin of mutual authentication I wonder what good it > would do to have rogue code in an AP that can not authenticate itself to > the AR in it's operational state, or authenticate itself of the STA in it's > operational state. However, I do see significant danger in putting > something like a certificate in a physically insecure device (like in a > hotspot) where it could be broken into and have the certificate compromised. > > Seems to me that the CAPWAP doc should concentrate of getting the image > downloaded reliably, not securely. The security part come in play in the > operational state. > > Marty > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From pcalhoun@airespace.com Mon Aug 18 18:51:37 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 18 Aug 2003 10:51:37 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) Message-ID: <40301581B2962B448690A023EF16DFE1DC5520@bsn-mail-01.bstormnetworks.com> SSBjYW4gY2VydGFpbmx5IGltYWdlIGEgc2NlbmFyaW8gd2hlcmUgc29tZW9uZSBwdXRzIG1hbGlj aW91cyBjb2RlIG9uIGFuIEFQLCBieSBnYWluaW5nIGFjY2VzcyB0byBpdCdzIHNjaGVtYXRpY3Mu IEl0IGNhbiByZWFkIGV4aXN0aW5nIGZsYXNoIGZvcm1hdHMgKHdoaWNoIGNhbiBiZSByZXZlcnNl IGVuZ2luZWVyZWQpLCBhbmQgY2F1c2Ugc29tZSByYXRoZXIgc2VyaW91cyBzZWN1cml0eSB0aHJl YXRzLiBIb3dldmVyLCBpZiB0aGUgY29uY2Vuc3VzIG9mIHRoZSAocHJvcG9zZWQpIFdHIGlzIHRv IGlnbm9yZSBzZWN1cmUgZG93bmxvYWQsIGFuZCBqdXN0IGZvY3VzIG9uIGRvd25sb2FkIGl0c2Vs ZiwgdGhlbiBJICpjb3VsZCogYmUgc3dheWVkIDopDQogDQpQYXRDDQoNCgktLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLSANCglGcm9tOiBKYW1lcyBLZW1wZiBbbWFpbHRvOmtlbXBmQGRvY29tb2xh YnMtdXNhLmNvbV0gDQoJU2VudDogTW9uIDgvMTgvMjAwMyAxMDo0OCBBTSANCglUbzogbHdhcHBA ZnJhc2NvbmUuY29tOyBNYXJ0aW4gTGVma293aXR6IA0KCUNjOiANCglTdWJqZWN0OiBSZTogW0x3 YXBwXSBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQgKHNlY3VyZSBkb3dubG9hZD8pDQoJDQoJDQoN CglIb3cgYWJvdXQgcm9ndWUgY29kZSB0aGF0IGNhdXNlcyB0aGUgQVAgdG8gaW5jcmVhc2UgaXRz IHBvd2VyIHRvIHRoZSBtYXhpbXVtDQoJYW5kIHN0YXJ0IGJyb2FkY2FzdGluZyB3aGl0ZSBub2lz ZSBhY3Jvc3MgYWxsIGNoYW5uZWxzPw0KCQ0KCSAgICAgICAgICAgIGphaw0KCQ0KCS0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCglGcm9tOiAiTWFydGluIExlZmtvd2l0eiIgPGxlZmtvQHRy YXBlemVuZXR3b3Jrcy5jb20+DQoJVG86IDxsd2FwcEBmcmFzY29uZS5jb20+DQoJU2VudDogTW9u ZGF5LCBBdWd1c3QgMTgsIDIwMDMgMTA6NDUgQU0NCglTdWJqZWN0OiBSZTogW0x3YXBwXSBDQVBX QVAgUHJvYmxlbSBTdGF0ZW1lbnQgKHNlY3VyZSBkb3dubG9hZD8pDQoJDQoJDQoJPiBJIGFsc28g YW0gd29uZGVyaW5nIHdoeSB3ZSBuZWVkIGEgc2VjdXJlIGRvd25sb2FkPw0KCT4NCgk+IEdpdmVu IFRHaSdzIGJhc2ljIGxpbmNocGluIG9mIG11dHVhbCBhdXRoZW50aWNhdGlvbiBJIHdvbmRlciB3 aGF0IGdvb2QgaXQNCgk+IHdvdWxkIGRvIHRvIGhhdmUgcm9ndWUgY29kZSBpbiBhbiBBUCB0aGF0 IGNhbiBub3QgYXV0aGVudGljYXRlIGl0c2VsZiB0bw0KCT4gdGhlIEFSIGluIGl0J3Mgb3BlcmF0 aW9uYWwgc3RhdGUsIG9yIGF1dGhlbnRpY2F0ZSBpdHNlbGYgb2YgdGhlIFNUQSBpbg0KCWl0J3MN Cgk+IG9wZXJhdGlvbmFsIHN0YXRlLiAgSG93ZXZlciwgSSBkbyBzZWUgc2lnbmlmaWNhbnQgZGFu Z2VyIGluIHB1dHRpbmcNCgk+IHNvbWV0aGluZyBsaWtlIGEgY2VydGlmaWNhdGUgaW4gYSBwaHlz aWNhbGx5IGluc2VjdXJlIGRldmljZSAobGlrZSBpbiBhDQoJPiBob3RzcG90KSB3aGVyZSBpdCBj b3VsZCBiZSBicm9rZW4gaW50byBhbmQgaGF2ZSB0aGUgY2VydGlmaWNhdGUNCgljb21wcm9taXNl ZC4NCgk+DQoJPiBTZWVtcyB0byBtZSB0aGF0IHRoZSBDQVBXQVAgZG9jIHNob3VsZCBjb25jZW50 cmF0ZSBvZiBnZXR0aW5nIHRoZSBpbWFnZQ0KCT4gZG93bmxvYWRlZCByZWxpYWJseSwgbm90IHNl Y3VyZWx5LiAgVGhlIHNlY3VyaXR5IHBhcnQgY29tZSBpbiBwbGF5IGluIHRoZQ0KCT4gb3BlcmF0 aW9uYWwgc3RhdGUuDQoJPg0KCT4gTWFydHkNCgk+DQoJPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4gTHdhcHAgbWFpbGluZyBsaXN0DQoJPiBMd2Fw cEBmcmFzY29uZS5jb20NCgk+IGh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3Rp bmZvL2x3YXBwDQoJPg0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoJTHdhcHAgbWFpbGluZyBsaXN0DQoJTHdhcHBAZnJhc2NvbmUuY29tDQoJaHR0 cDovL21haWwuZnJhc2NvbmUuY29tL21haWxtYW4vbGlzdGluZm8vbHdhcHANCgkNCg0K From lefko@trapezenetworks.com Mon Aug 18 19:05:10 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Mon, 18 Aug 2003 11:05:10 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) In-Reply-To: <02dc01c365b0$f19020f0$0a6015ac@dclkempt40> References: <25096186.1061223189@[10.1.1.130]> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetworks.com> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> <5.1.0.14.2.20030818104002.03ce2900@mail.trpz.com> Message-ID: <5.1.0.14.2.20030818110218.01e03a20@mail.trpz.com> Yes, but you could just as easily put a $100 2.4g spread spectrum phone in the physical area and do pretty much the same thing. In 802.11 it has always been assumed that you really can't protect the air from a DOS attack. The only exception would be if a very few packets from easily obtainable equipment could shut down the whole network. So far the only example of this is TKIP countermeasures. Marty At 10:48 AM 8/18/2003 -0700, James Kempf wrote: >How about rogue code that causes the AP to increase its power to the maximum >and start broadcasting white noise across all channels? > > jak > >----- Original Message ----- >From: "Martin Lefkowitz" >To: >Sent: Monday, August 18, 2003 10:45 AM >Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > > > > I also am wondering why we need a secure download? > > > > Given TGi's basic linchpin of mutual authentication I wonder what good it > > would do to have rogue code in an AP that can not authenticate itself to > > the AR in it's operational state, or authenticate itself of the STA in >it's > > operational state. However, I do see significant danger in putting > > something like a certificate in a physically insecure device (like in a > > hotspot) where it could be broken into and have the certificate >compromised. > > > > Seems to me that the CAPWAP doc should concentrate of getting the image > > downloaded reliably, not securely. The security part come in play in the > > operational state. > > > > Marty > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > From bob@airespace.com Mon Aug 18 19:08:38 2003 From: bob@airespace.com (Bob O'Hara) Date: Mon, 18 Aug 2003 11:08:38 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) Message-ID: <40301581B2962B448690A023EF16DFE10139A81F@bsn-mail-01.bstormnetworks.com> TGi (802.11i task group) has nothing at all to do with the security of the code in the AP, or of its download and installation. Without some method to secure and authenticate the code, the possibility exists (and some script kiddie will exploit it) to download code to the AP that plays "Oh Suzanna" in the key of 2.4 GHz. -Bob =20 -----Original Message----- From: Martin Lefkowitz [mailto:lefko@trapezenetworks.com]=20 Sent: Monday, August 18, 2003 10:45 AM To: lwapp@frascone.com Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) I also am wondering why we need a secure download? Given TGi's basic linchpin of mutual authentication I wonder what good it=20 would do to have rogue code in an AP that can not authenticate itself to the AR in it's operational state, or authenticate itself of the STA in it's=20 operational state. However, I do see significant danger in putting=20 something like a certificate in a physically insecure device (like in a=20 hotspot) where it could be broken into and have the certificate compromised. Seems to me that the CAPWAP doc should concentrate of getting the image=20 downloaded reliably, not securely. The security part come in play in the=20 operational state. Marty _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From bob@airespace.com Mon Aug 18 19:10:11 2003 From: bob@airespace.com (Bob O'Hara) Date: Mon, 18 Aug 2003 11:10:11 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) Message-ID: <40301581B2962B448690A023EF16DFE10139A820@bsn-mail-01.bstormnetworks.com> Protecting the air from DoS attacks is entirely different than enabling NEW DoS attacks. -Bob =20 -----Original Message----- From: Martin Lefkowitz [mailto:lefko@trapezenetworks.com]=20 Sent: Monday, August 18, 2003 11:05 AM To: James Kempf; lwapp@frascone.com Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) Yes, but you could just as easily put a $100 2.4g spread spectrum phone in=20 the physical area and do pretty much the same thing. In 802.11 it has always been assumed that you really can't protect the air=20 from a DOS attack. The only exception would be if a very few packets from=20 easily obtainable equipment could shut down the whole network. So far the=20 only example of this is TKIP countermeasures. Marty At 10:48 AM 8/18/2003 -0700, James Kempf wrote: >How about rogue code that causes the AP to increase its power to the maximum >and start broadcasting white noise across all channels? > > jak > >----- Original Message ----- >From: "Martin Lefkowitz" >To: >Sent: Monday, August 18, 2003 10:45 AM >Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > > > > I also am wondering why we need a secure download? > > > > Given TGi's basic linchpin of mutual authentication I wonder what good it > > would do to have rogue code in an AP that can not authenticate itself to > > the AR in it's operational state, or authenticate itself of the STA in >it's > > operational state. However, I do see significant danger in putting > > something like a certificate in a physically insecure device (like in a > > hotspot) where it could be broken into and have the certificate >compromised. > > > > Seems to me that the CAPWAP doc should concentrate of getting the image > > downloaded reliably, not securely. The security part come in play in the > > operational state. > > > > Marty > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From lefko@trapezenetworks.com Mon Aug 18 19:14:54 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Mon, 18 Aug 2003 11:14:54 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5520@bsn-mail-01.bstormn etworks.com> Message-ID: <5.1.0.14.2.20030818110526.01d7c128@mail.trpz.com> I think we need to be careful about putting protections into a device that is physically insecure. Somebody could steal, or disconnect the device for a short amount of time and do the same thing. I'm also not saying I know the answer to this, I'm assuming that protecting download frames in the boot state will be cumbersome to do. I could be wrong in that it's no more cumbersome than protecting management, and data frames in the operational state. Especially if it requires new hardware to do it at line rate... Marty At 10:51 AM 8/18/2003 -0700, Pat R. Calhoun wrote: >I can certainly image a scenario where someone puts malicious code on an >AP, by gaining access to it's schematics. It can read existing flash >formats (which can be reverse engineered), and cause some rather serious >security threats. However, if the concensus of the (proposed) WG is to >ignore secure download, and just focus on download itself, then I *could* >be swayed :) > >PatC > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Mon 8/18/2003 10:48 AM > To: lwapp@frascone.com; Martin Lefkowitz > Cc: > Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > > > > How about rogue code that causes the AP to increase its power to > the maximum > and start broadcasting white noise across all channels? > > jak > > ----- Original Message ----- > From: "Martin Lefkowitz" > To: > Sent: Monday, August 18, 2003 10:45 AM > Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > > > > I also am wondering why we need a secure download? > > > > Given TGi's basic linchpin of mutual authentication I wonder > what good it > > would do to have rogue code in an AP that can not authenticate > itself to > > the AR in it's operational state, or authenticate itself of the > STA in > it's > > operational state. However, I do see significant danger in putting > > something like a certificate in a physically insecure device > (like in a > > hotspot) where it could be broken into and have the certificate > compromised. > > > > Seems to me that the CAPWAP doc should concentrate of getting > the image > > downloaded reliably, not securely. The security part come in > play in the > > operational state. > > > > Marty > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From kempf@docomolabs-usa.com Mon Aug 18 19:19:27 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 18 Aug 2003 11:19:27 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) References: <5.1.0.14.2.20030818110526.01d7c128@mail.trpz.com> Message-ID: <034701c365b5$424a5700$0a6015ac@dclkempt40> Suggest taking a look at what Cablelabs did. I'm told they have a fairly nice solution to the problem which has very similar security/hardware constraints. jak ----- Original Message ----- From: "Martin Lefkowitz" To: Sent: Monday, August 18, 2003 11:14 AM Subject: RE: [Lwapp] CAPWAP Problem Statement (secure download?) > I think we need to be careful about putting protections into a device that > is physically insecure. Somebody could steal, or disconnect the device for > a short amount of time and do the same thing. > > I'm also not saying I know the answer to this, I'm assuming that protecting > download frames in the boot state will be cumbersome to do. I could be > wrong in that it's no more cumbersome than protecting management, and data > frames in the operational state. Especially if it requires new hardware to > do it at line rate... > > Marty > > > At 10:51 AM 8/18/2003 -0700, Pat R. Calhoun wrote: > >I can certainly image a scenario where someone puts malicious code on an > >AP, by gaining access to it's schematics. It can read existing flash > >formats (which can be reverse engineered), and cause some rather serious > >security threats. However, if the concensus of the (proposed) WG is to > >ignore secure download, and just focus on download itself, then I *could* > >be swayed :) > > > >PatC > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Mon 8/18/2003 10:48 AM > > To: lwapp@frascone.com; Martin Lefkowitz > > Cc: > > Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > > > > > > > > How about rogue code that causes the AP to increase its power to > > the maximum > > and start broadcasting white noise across all channels? > > > > jak > > > > ----- Original Message ----- > > From: "Martin Lefkowitz" > > To: > > Sent: Monday, August 18, 2003 10:45 AM > > Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > > > > > > > I also am wondering why we need a secure download? > > > > > > Given TGi's basic linchpin of mutual authentication I wonder > > what good it > > > would do to have rogue code in an AP that can not authenticate > > itself to > > > the AR in it's operational state, or authenticate itself of the > > STA in > > it's > > > operational state. However, I do see significant danger in putting > > > something like a certificate in a physically insecure device > > (like in a > > > hotspot) where it could be broken into and have the certificate > > compromised. > > > > > > Seems to me that the CAPWAP doc should concentrate of getting > > the image > > > downloaded reliably, not securely. The security part come in > > play in the > > > operational state. > > > > > > Marty > > > > > > _______________________________________________ > > > Lwapp mailing list > > > Lwapp@frascone.com > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From waa@cs.umd.edu Mon Aug 18 19:31:52 2003 From: waa@cs.umd.edu (William Arbaugh) Date: Mon, 18 Aug 2003 14:31:52 -0400 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) In-Reply-To: <5.1.0.14.2.20030818110526.01d7c128@mail.trpz.com> Message-ID: <3C7C73D0-D1AA-11D7-A221-000A957E8894@cs.umd.edu> The best way to handle this is to look at the threat. In this case, the threat is from a user (or abuser) on the wired network maliciously downloading a bad image to an AP. The probability that every organization has a malicious insider at this moment is high. The probability that every organization will have a malicious insider at some point in the future (perhaps for a limited time) is 100%. Thus, I would argue that this is a high risk threat and should be countered. So how do we counter it? Easy- some form of one-way authentication. Their are many ways to do this such that a physical compromise of the AP doesn't cause a entire system re-key. Yes- a physical compromise of the AP makes this protection moot, but a physical compromise requires significantly greater skills and requires the attacker to take a much greater risk. Providing protection for images is a no brainer to me. It can be done easily, and it pushes the attacker to touch the equipment, i.e. physical presence instead of reprogramming the device from the middle of the atlantic some place. On Monday, August 18, 2003, at 02:14 PM, Martin Lefkowitz wrote: > I think we need to be careful about putting protections into a device > that is physically insecure. Somebody could steal, or disconnect the > device for a short amount of time and do the same thing. > > I'm also not saying I know the answer to this, I'm assuming that > protecting download frames in the boot state will be cumbersome to do. > I could be wrong in that it's no more cumbersome than protecting > management, and data frames in the operational state. Especially if > it requires new hardware to do it at line rate... > > Marty > > > At 10:51 AM 8/18/2003 -0700, Pat R. Calhoun wrote: >> I can certainly image a scenario where someone puts malicious code on >> an AP, by gaining access to it's schematics. It can read existing >> flash formats (which can be reverse engineered), and cause some >> rather serious security threats. However, if the concensus of the >> (proposed) WG is to ignore secure download, and just focus on >> download itself, then I *could* be swayed :) >> >> PatC >> >> -----Original Message----- >> From: James Kempf [mailto:kempf@docomolabs-usa.com] >> Sent: Mon 8/18/2003 10:48 AM >> To: lwapp@frascone.com; Martin Lefkowitz >> Cc: >> Subject: Re: [Lwapp] CAPWAP Problem Statement (secure >> download?) >> >> >> >> How about rogue code that causes the AP to increase its power >> to the maximum >> and start broadcasting white noise across all channels? >> >> jak >> >> ----- Original Message ----- >> From: "Martin Lefkowitz" >> To: >> Sent: Monday, August 18, 2003 10:45 AM >> Subject: Re: [Lwapp] CAPWAP Problem Statement (secure >> download?) >> >> >> > I also am wondering why we need a secure download? >> > >> > Given TGi's basic linchpin of mutual authentication I >> wonder what good it >> > would do to have rogue code in an AP that can not >> authenticate itself to >> > the AR in it's operational state, or authenticate itself of >> the STA in >> it's >> > operational state. However, I do see significant danger in >> putting >> > something like a certificate in a physically insecure >> device (like in a >> > hotspot) where it could be broken into and have the >> certificate >> compromised. >> > >> > Seems to me that the CAPWAP doc should concentrate of >> getting the image >> > downloaded reliably, not securely. The security part come >> in play in the >> > operational state. >> > >> > Marty >> > >> > _______________________________________________ >> > Lwapp mailing list >> > Lwapp@frascone.com >> > http://mail.frascone.com/mailman/listinfo/lwapp >> > >> >> _______________________________________________ >> Lwapp mailing list >> Lwapp@frascone.com >> http://mail.frascone.com/mailman/listinfo/lwapp >> > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From Marcus Brunner Mon Aug 18 19:52:49 2003 From: Marcus Brunner (Marcus Brunner) Date: Mon, 18 Aug 2003 20:52:49 +0200 Subject: [Lwapp] CAPWAP Problem Statement In-Reply-To: <01bf01c365a5$962740f0$0a6015ac@dclkempt40> References: <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> <25096186.1061223189@[10.1.1.130]> <01bf01c365a5$962740f0$0a6015ac@dclkempt40> Message-ID: <41877857.1061239969@[10.1.1.130]> James, Depending on how large your network is, the central management system is the bottleneck. E.g., a rule of dumb for SNMP networks is that a single management station can manage something in the range of 500 nodes. (please no discussion on the number). In the 802.11 case that's why the layer split issue came up, because it seams to be to expensive to handle a number of the functions centrally. That a network administrator wants to sit at a single location is more than natural, but that is not the issue. Given the 2 topologies A) one AR AP ---\ \ AP -----\ \ AP -------\ \ AP --------- AR / AP -------/ / AP -----/ / AP ---/ B)several ARs AP -------\ \ AP --------- AR -\ / \ AP -------/ \ management system AP -------\ / \ / AP --------- AR- / AP -------/ So I think the question is are we assuming A) or B)? Note that B) naturally only makes sense again for a reasonably large number of ARs. Marcus --On Montag, 18. August 2003 09:27 -0700 James Kempf wrote: > Marcus, > >> Problem 1: managing large networks is a common problem. Centralization of >> management for large networks is a problem not a solution. >> > > Whatever leads you to this conclusion? > > Having a single point from which a a single person acting as an > administrator can monitor and update configuration on many different > networks elements (routers, firewalls, whatever), seems like a much more > cost effective solution than having to send one or a bunch of people > around to each individual machine to monitor and update. > > Or am I missing something? > > jak > > > From Marcus Brunner Mon Aug 18 20:00:04 2003 From: Marcus Brunner (Marcus Brunner) Date: Mon, 18 Aug 2003 21:00:04 +0200 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5520@bsn-mail-01.bstormnetworks.com> References: <40301581B2962B448690A023EF16DFE1DC5520@bsn-mail-01.bstormnetwor ks.com> Message-ID: <42312081.1061240404@[10.1.1.130]> Actually, the main motivation, why we did a similar solution some time ago was to terminate the 802.11 security association (with some tweaks to overcome the security problem) in a secured physical location. So we don't care what happens to the access point non-secure download is fine for that particular scenario. Marcus --On Montag, 18. August 2003 10:51 -0700 "Pat R. Calhoun" wrote: > I can certainly image a scenario where someone puts malicious code on an > AP, by gaining access to it's schematics. It can read existing flash > formats (which can be reverse engineered), and cause some rather serious > security threats. However, if the concensus of the (proposed) WG is to > ignore secure download, and just focus on download itself, then I *could* > be swayed :) > PatC > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Mon 8/18/2003 10:48 AM > To: lwapp@frascone.com; Martin Lefkowitz > Cc: > Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > > > > How about rogue code that causes the AP to increase its power to the > maximum and start broadcasting white noise across all channels? > > jak > > ----- Original Message ----- > From: "Martin Lefkowitz" > To: > Sent: Monday, August 18, 2003 10:45 AM > Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > > > > I also am wondering why we need a secure download? > > > > Given TGi's basic linchpin of mutual authentication I wonder what good > it > would do to have rogue code in an AP that can not authenticate > itself to > the AR in it's operational state, or authenticate itself of > the STA in it's > > operational state. However, I do see significant danger in putting > > something like a certificate in a physically insecure device (like in a > > hotspot) where it could be broken into and have the certificate > compromised. > > > > Seems to me that the CAPWAP doc should concentrate of getting the image > > downloaded reliably, not securely. The security part come in play in > the > operational state. > > > > Marty > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > > ?*i~f")?,4<&?+"w?r !6?y > _?+"w?r ?(%)+- > w?& -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From Marcus Brunner Mon Aug 18 20:00:58 2003 From: Marcus Brunner (Marcus Brunner) Date: Mon, 18 Aug 2003 21:00:58 +0200 Subject: [Lwapp] CAPWAP Problem Statement In-Reply-To: <5.1.0.14.2.20030818094659.01c7b828@mail.trpz.com> References: <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwork s.com> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> <5.1.0.14.2.20030818094659.01c7b828@mail.trpz.com> Message-ID: <42366159.1061240458@[10.1.1.130]> sorry what do you underatand with "code" Marcus --On Montag, 18. August 2003 10:05 -0700 Martin Lefkowitz wrote: > At 04:13 PM 8/18/2003 +0200, Marcus Brunner wrote: >> Problem 1: managing large networks is a common problem. Centralization >> of management for large networks is a problem not a solution. >> >> Problem 2: updating fireware of all the network element at once is >> somehting nobody likes to do, because a failure in the new fireware has >> catastrophic implication for your network. Why should this be different >> for 802.11 networks? > > I think the CAPWAP document may need some different wording in this area. > When I reread it in light of this question, I can see where you would > think this. My understanding is that CAPWAP would be handing the > downloading of code, not the updating of firmware. My understanding was > that an AP would identify itself, and then the AR would download it's > code in a way that both would be able to interpret the results. This is > different than upgrading. But the process of upgrading requires that > code be downloaded. > > > >> Additionally, do you regard configuration as parameters or as code? > > After developing a number of these devices I think the AP would have 3 > states. > > Init: > This would be everything needed to get the code operational. This > includes EEPROM, or messages from the AP and AR in the boot state (e.g. > identification messages). Code download is optional. > > Configuration: > Everything needed to enable the radio in the system > > Operational: > Radio's on data is flowing back and forth. > > There will however be messages that flow back and forth that happen both > in the configuration and operational state. The difference is whether > the radio needs to be off or on. > > Marty > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From Marcus Brunner Mon Aug 18 20:05:21 2003 From: Marcus Brunner (Marcus Brunner) Date: Mon, 18 Aug 2003 21:05:21 +0200 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) In-Reply-To: <3C7C73D0-D1AA-11D7-A221-000A957E8894@cs.umd.edu> References: <3C7C73D0-D1AA-11D7-A221-000A957E8894@cs.umd.edu> Message-ID: <42629217.1061240721@[10.1.1.130]> Easier don't standardize the image download at all. Marcus --On Montag, 18. August 2003 14:31 -0400 William Arbaugh wrote: > The best way to handle this is to look at the threat. > > In this case, the threat is from a user (or abuser) on the wired network > maliciously downloading a bad image to an AP. The probability that every > organization has a malicious insider at this moment is high. The > probability that every organization will have a malicious insider at some > point in the future (perhaps for a limited time) is 100%. Thus, I would > argue that this is a high risk threat and should be countered. So how do > we counter it? > > Easy- some form of one-way authentication. Their are many ways to do this > such that a physical compromise of the AP doesn't cause a entire system > re-key. Yes- a physical compromise of the AP makes this protection moot, > but a physical compromise requires significantly greater skills and > requires the attacker to take a much greater risk. > > Providing protection for images is a no brainer to me. It can be done > easily, and it pushes the attacker to touch the equipment, i.e. physical > presence instead of reprogramming the device from the middle of the > atlantic some place. > > On Monday, August 18, 2003, at 02:14 PM, Martin Lefkowitz wrote: > >> I think we need to be careful about putting protections into a device >> that is physically insecure. Somebody could steal, or disconnect the >> device for a short amount of time and do the same thing. >> >> I'm also not saying I know the answer to this, I'm assuming that >> protecting download frames in the boot state will be cumbersome to do. >> I could be wrong in that it's no more cumbersome than protecting >> management, and data frames in the operational state. Especially if >> it requires new hardware to do it at line rate... >> >> Marty >> >> >> At 10:51 AM 8/18/2003 -0700, Pat R. Calhoun wrote: >>> I can certainly image a scenario where someone puts malicious code on >>> an AP, by gaining access to it's schematics. It can read existing >>> flash formats (which can be reverse engineered), and cause some >>> rather serious security threats. However, if the concensus of the >>> (proposed) WG is to ignore secure download, and just focus on >>> download itself, then I *could* be swayed :) >>> >>> PatC >>> >>> -----Original Message----- >>> From: James Kempf [mailto:kempf@docomolabs-usa.com] >>> Sent: Mon 8/18/2003 10:48 AM >>> To: lwapp@frascone.com; Martin Lefkowitz >>> Cc: >>> Subject: Re: [Lwapp] CAPWAP Problem Statement (secure >>> download?) >>> >>> >>> >>> How about rogue code that causes the AP to increase its power >>> to the maximum >>> and start broadcasting white noise across all channels? >>> >>> jak >>> >>> ----- Original Message ----- >>> From: "Martin Lefkowitz" >>> To: >>> Sent: Monday, August 18, 2003 10:45 AM >>> Subject: Re: [Lwapp] CAPWAP Problem Statement (secure >>> download?) >>> >>> >>> > I also am wondering why we need a secure download? >>> > >>> > Given TGi's basic linchpin of mutual authentication I >>> wonder what good it >>> > would do to have rogue code in an AP that can not >>> authenticate itself to >>> > the AR in it's operational state, or authenticate itself of >>> the STA in >>> it's >>> > operational state. However, I do see significant danger in >>> putting >>> > something like a certificate in a physically insecure >>> device (like in a >>> > hotspot) where it could be broken into and have the >>> certificate >>> compromised. >>> > >>> > Seems to me that the CAPWAP doc should concentrate of >>> getting the image >>> > downloaded reliably, not securely. The security part come >>> in play in the >>> > operational state. >>> > >>> > Marty >>> > >>> > _______________________________________________ >>> > Lwapp mailing list >>> > Lwapp@frascone.com >>> > http://mail.frascone.com/mailman/listinfo/lwapp >>> > >>> >>> _______________________________________________ >>> Lwapp mailing list >>> Lwapp@frascone.com >>> http://mail.frascone.com/mailman/listinfo/lwapp >>> >> >> _______________________________________________ >> Lwapp mailing list >> Lwapp@frascone.com >> http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From lefko@trapezenetworks.com Mon Aug 18 21:16:23 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Mon, 18 Aug 2003 13:16:23 -0700 Subject: [Lwapp] CAPWAP Problem Statement In-Reply-To: <42366159.1061240458@[10.1.1.130]> References: <5.1.0.14.2.20030818094659.01c7b828@mail.trpz.com> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwork s.com> <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> <5.1.0.14.2.20030818094659.01c7b828@mail.trpz.com> Message-ID: <5.1.0.14.2.20030818131532.01d071c8@mail.trpz.com> Code means executable, whether it is downloaded or not. Marty At 09:00 PM 8/18/2003 +0200, Marcus Brunner wrote: >sorry what do you underatand with "code" >Marcus > >--On Montag, 18. August 2003 10:05 -0700 Martin Lefkowitz > wrote: > >>At 04:13 PM 8/18/2003 +0200, Marcus Brunner wrote: >>>Problem 1: managing large networks is a common problem. Centralization >>>of management for large networks is a problem not a solution. >>> >>>Problem 2: updating fireware of all the network element at once is >>>somehting nobody likes to do, because a failure in the new fireware has >>>catastrophic implication for your network. Why should this be different >>>for 802.11 networks? >> >>I think the CAPWAP document may need some different wording in this area. >>When I reread it in light of this question, I can see where you would >>think this. My understanding is that CAPWAP would be handing the >>downloading of code, not the updating of firmware. My understanding was >>that an AP would identify itself, and then the AR would download it's >>code in a way that both would be able to interpret the results. This is >>different than upgrading. But the process of upgrading requires that >>code be downloaded. >> >> >> >>>Additionally, do you regard configuration as parameters or as code? >> >>After developing a number of these devices I think the AP would have 3 >>states. >> >>Init: >>This would be everything needed to get the code operational. This >>includes EEPROM, or messages from the AP and AR in the boot state (e.g. >>identification messages). Code download is optional. >> >>Configuration: >>Everything needed to enable the radio in the system >> >>Operational: >>Radio's on data is flowing back and forth. >> >>There will however be messages that flow back and forth that happen both >>in the configuration and operational state. The difference is whether >>the radio needs to be off or on. >> >>Marty >> >> >>_______________________________________________ >>Lwapp mailing list >>Lwapp@frascone.com >>http://mail.frascone.com/mailman/listinfo/lwapp > > > >-------------------------------------- >Dr. Marcus Brunner >Network Laboratories >NEC Europe Ltd. > >E-Mail: brunner@ccrle.nec.de >WWW: http://www.ccrle.nec.de/ >Phone: +49 (0) 6221 905 11 29 >Mobile: +49 (0) 163 275 17 43 >personal home page: http://www.brubers.org/marcus > > > From kempf@docomolabs-usa.com Mon Aug 18 21:29:50 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 18 Aug 2003 13:29:50 -0700 Subject: [Lwapp] CAPWAP Problem Statement References: <40301581B2962B448690A023EF16DFE1DC54B9@bsn-mail-01.bstormnetwor ks.com> <25096186.1061223189@[10.1.1.130]> <01bf01c365a5$962740f0$0a6015ac@dclkempt40> <41877857.1061239969@[10.1.1.130]> Message-ID: <003e01c365c7$796cda20$0a6015ac@dclkempt40> I've been assuming B, that is, I'm not assuming that all APs for a particular network are under a single AR. The value of CAPWAP would be to go from a case where each individual AP is managed to B, where the routers/switches are managed, thereby increasing the fanout and decreasing the number of devices requiring management. So taking your number of 500, managing 500 routers/switches with CAPWAP would cover a lot larger geographic/topological area than managing 500 individual APs. jak > Depending on how large your network is, the central management system is > the bottleneck. E.g., a rule of dumb for SNMP networks is that a single > management station can manage something in the range of 500 nodes. (please > no discussion on the number). > > In the 802.11 case that's why the layer split issue came up, because it > seams to be to expensive to handle a number of the functions centrally. > That a network administrator wants to sit at a single location is more than > natural, but that is not the issue. > > Given the 2 topologies > A) one AR > > AP ---\ > \ > AP -----\ > \ > AP -------\ > \ > AP --------- AR > / > AP -------/ > / > AP -----/ > / > AP ---/ > > B)several ARs > > AP -------\ > \ > AP --------- AR -\ > / \ > AP -------/ \ > management system > AP -------\ / > \ / > AP --------- AR- > / > AP -------/ > > So I think the question is are we assuming A) or B)? Note that B) naturally > only makes sense again for a reasonably large number of ARs. > > > > Marcus > > > --On Montag, 18. August 2003 09:27 -0700 James Kempf > wrote: > > > Marcus, > > > >> Problem 1: managing large networks is a common problem. Centralization of > >> management for large networks is a problem not a solution. > >> > > > > Whatever leads you to this conclusion? > > > > Having a single point from which a a single person acting as an > > administrator can monitor and update configuration on many different > > networks elements (routers, firewalls, whatever), seems like a much more > > cost effective solution than having to send one or a bunch of people > > around to each individual machine to monitor and update. > > > > Or am I missing something? > > > > jak > > > > > > > > > > > > > > From hunter@timefactor.com Tue Aug 19 04:40:05 2003 From: hunter@timefactor.com (hunter) Date: Mon, 18 Aug 2003 20:40:05 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) In-Reply-To: <3C7C73D0-D1AA-11D7-A221-000A957E8894@cs.umd.edu> References: <5.1.0.14.2.20030818110526.01d7c128@mail.trpz.com> Message-ID: <5.1.0.14.0.20030818195907.00bc7f40@mail.impulse.net> Marty, If someone plugs in a microwave oven or a 2.4 mobile phone, they (1) can easily be found and eliminated (choose your favorite method) and (2) can only affect a few APs at a time (then they have to buy another oven or mobile phone to attack the APs on the next block). That is: the "inherently vulnerable wireless" argument is very limited. On the other hand, if someone can download rogue code to the 10,000 APs in your coffeehype network, they can steal from your customers' credit cards for a very long time. Frankly, you shouldn't be worried about the former threat -- you know how to deal with that. But the only feasible way of dealing with the latter is to increase the cost enough to make it very unlikely (which is the definition of "protection"). If CAPWAP specifies a standard way to download code, then it has the responsibility to specify a way for protecting that transaction. But protection of the transaction is not protection of the device. The limit of CAPWAP's responsibility is the minimization of any additional vulnerabilities created by the transactions it specifies. Hunter At 02:31 PM 8/18/2003 -0400, William Arbaugh wrote: >The best way to handle this is to look at the threat. > >In this case, the threat is from a user (or abuser) on the wired network >maliciously downloading a bad image to an AP. The probability that every >organization has a malicious insider at this moment is high. The >probability that every organization will have a malicious insider at some >point in the future (perhaps for a limited time) is 100%. Thus, I would >argue that this is a high risk threat and should be countered. So how do >we counter it? > >Easy- some form of one-way authentication. Their are many ways to do this >such that a physical compromise of the AP doesn't cause a entire system >re-key. Yes- a physical compromise of the AP makes this protection moot, >but a physical compromise requires significantly greater skills and >requires the attacker to take a much greater risk. > >Providing protection for images is a no brainer to me. It can be done >easily, and it pushes the attacker to touch the equipment, i.e. physical >presence instead of reprogramming the device from the middle of the >atlantic some place. > >On Monday, August 18, 2003, at 02:14 PM, Martin Lefkowitz wrote: > >>I think we need to be careful about putting protections into a device >>that is physically insecure. Somebody could steal, or disconnect the >>device for a short amount of time and do the same thing. >> >>I'm also not saying I know the answer to this, I'm assuming that >>protecting download frames in the boot state will be cumbersome to do. I >>could be wrong in that it's no more cumbersome than protecting >>management, and data frames in the operational state. Especially if it >>requires new hardware to do it at line rate... >> >>Marty >> >> >>At 10:51 AM 8/18/2003 -0700, Pat R. Calhoun wrote: >>>I can certainly image a scenario where someone puts malicious code on an >>>AP, by gaining access to it's schematics. It can read existing flash >>>formats (which can be reverse engineered), and cause some rather serious >>>security threats. However, if the concensus of the (proposed) WG is to >>>ignore secure download, and just focus on download itself, then I >>>*could* be swayed :) >>> >>>PatC >>> >>> -----Original Message----- >>> From: James Kempf [mailto:kempf@docomolabs-usa.com] >>> Sent: Mon 8/18/2003 10:48 AM >>> To: lwapp@frascone.com; Martin Lefkowitz >>> Cc: >>> Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) >>> >>> >>> >>> How about rogue code that causes the AP to increase its power >>> to the maximum >>> and start broadcasting white noise across all channels? >>> >>> jak >>> >>> ----- Original Message ----- >>> From: "Martin Lefkowitz" >>> To: >>> Sent: Monday, August 18, 2003 10:45 AM >>> Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) >>> >>> >>> > I also am wondering why we need a secure download? >>> > >>> > Given TGi's basic linchpin of mutual authentication I wonder >>> what good it >>> > would do to have rogue code in an AP that can not >>> authenticate itself to >>> > the AR in it's operational state, or authenticate itself of >>> the STA in >>> it's >>> > operational state. However, I do see significant danger in >>> putting >>> > something like a certificate in a physically insecure device >>> (like in a >>> > hotspot) where it could be broken into and have the certificate >>> compromised. >>> > >>> > Seems to me that the CAPWAP doc should concentrate of getting >>> the image >>> > downloaded reliably, not securely. The security part come in >>> play in the >>> > operational state. >>> > >>> > Marty >>> > >>> > _______________________________________________ >>> > Lwapp mailing list >>> > Lwapp@frascone.com >>> > http://mail.frascone.com/mailman/listinfo/lwapp >>> > >>> >>> _______________________________________________ >>> Lwapp mailing list >>> Lwapp@frascone.com >>> http://mail.frascone.com/mailman/listinfo/lwapp >> >>_______________________________________________ >>Lwapp mailing list >>Lwapp@frascone.com >>http://mail.frascone.com/mailman/listinfo/lwapp > >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp From Mike.Moreton@Synad.com Tue Aug 19 09:49:35 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Tue, 19 Aug 2003 09:49:35 +0100 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) Message-ID: <0D3F1B25E75EE24483A6E69201142C868B0F82@paris.synad.com> Marcus, I think what you comment exposes is that the threat model is largely different depending on where you terminate the 802.11 security association. =20 I think the group will save itself a lot of work in the long-run if it decides up front where that association is going to be terminated. I know that's a difficult question, but it's not going to get any easier with time. Mike Moreton Synad Technologies Ltd. =20 -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de]=20 Sent: 18 August 2003 20:00 To: Pat R. Calhoun; James Kempf; lwapp@frascone.com; Martin Lefkowitz Subject: RE: [Lwapp] CAPWAP Problem Statement (secure download?) Actually, the main motivation, why we did a similar solution some time ago=20 was to terminate the 802.11 security association (with some tweaks to=20 overcome the security problem) in a secured physical location. So we don't=20 care what happens to the access point non-secure download is fine for that=20 particular scenario. Marcus --On Montag, 18. August 2003 10:51 -0700 "Pat R. Calhoun"=20 wrote: > I can certainly image a scenario where someone puts malicious code on an > AP, by gaining access to it's schematics. It can read existing flash > formats (which can be reverse engineered), and cause some rather serious > security threats. However, if the concensus of the (proposed) WG is to > ignore secure download, and just focus on download itself, then I *could* > be swayed :) > PatC > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Mon 8/18/2003 10:48 AM > To: lwapp@frascone.com; Martin Lefkowitz > Cc: > Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > =09 > =09 > > How about rogue code that causes the AP to increase its power to the > maximum and start broadcasting white noise across all channels? > =09 > jak > =09 > ----- Original Message ----- > From: "Martin Lefkowitz" > To: > Sent: Monday, August 18, 2003 10:45 AM > Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) > =09 > =09 > > I also am wondering why we need a secure download? > > > > Given TGi's basic linchpin of mutual authentication I wonder what good > it > would do to have rogue code in an AP that can not authenticate > itself to > the AR in it's operational state, or authenticate itself of > the STA in it's > > operational state. However, I do see significant danger in putting > > something like a certificate in a physically insecure device (like in a > > hotspot) where it could be broken into and have the certificate > compromised. > > > > Seems to me that the CAPWAP doc should concentrate of getting the image > > downloaded reliably, not securely. The security part come in play in > the > operational state. > > > > Marty > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > =09 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > =09 > > = =7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F=7F= =7F=7F=7F=7F=7F=7F=7F=7F=7F=7F?*i~f"=16)?,4<=1A&?+=1C"w?r !6?=7Fy=1A > _?+=1C"w?r ?=19(%=19)=7F=16+- > w?=1A& -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From Mike.Moreton@Synad.com Tue Aug 19 09:57:39 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Tue, 19 Aug 2003 09:57:39 +0100 Subject: [Lwapp] CAPWAP Problem Statement Message-ID: <0D3F1B25E75EE24483A6E69201142C868B0F83@paris.synad.com> It strikes me there's a related question: Is the idea to allow more than one AR per broadcast domain? The way 802.11 works there's some benefit in having all the 802.11 LANs on a site in the same broadcast domain. Mike Moreton Synad Technologies Ltd. =20 -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: 18 August 2003 21:30 To: Marcus Brunner; Pat R. Calhoun; lwapp@frascone.com Subject: Re: [Lwapp] CAPWAP Problem Statement I've been assuming B, that is, I'm not assuming that all APs for a particular network are under a single AR. The value of CAPWAP would be to go from a case where each individual AP is managed to B, where the routers/switches are managed, thereby increasing the fanout and decreasing the number of devices requiring management. So taking your number of 500, managing 500 routers/switches with CAPWAP would cover a lot larger geographic/topological area than managing 500 individual APs. jak > Depending on how large your network is, the central management system is > the bottleneck. E.g., a rule of dumb for SNMP networks is that a single > management station can manage something in the range of 500 nodes. (please > no discussion on the number). > > In the 802.11 case that's why the layer split issue came up, because it > seams to be to expensive to handle a number of the functions centrally. > That a network administrator wants to sit at a single location is more than > natural, but that is not the issue. > > Given the 2 topologies > A) one AR > > AP ---\ > \ > AP -----\ > \ > AP -------\ > \ > AP --------- AR > / > AP -------/ > / > AP -----/ > / > AP ---/ > > B)several ARs > > AP -------\ > \ > AP --------- AR -\ > / \ > AP -------/ \ > management system > AP -------\ / > \ / > AP --------- AR- > / > AP -------/ > > So I think the question is are we assuming A) or B)? Note that B) naturally > only makes sense again for a reasonably large number of ARs. > > > > Marcus > > > --On Montag, 18. August 2003 09:27 -0700 James Kempf > wrote: > > > Marcus, > > > >> Problem 1: managing large networks is a common problem. Centralization of > >> management for large networks is a problem not a solution. > >> > > > > Whatever leads you to this conclusion? > > > > Having a single point from which a a single person acting as an > > administrator can monitor and update configuration on many different > > networks elements (routers, firewalls, whatever), seems like a much more > > cost effective solution than having to send one or a bunch of people > > around to each individual machine to monitor and update. > > > > Or am I missing something? > > > > jak > > > > > > > > > > > > > > _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From esadot@avaya.com Tue Aug 19 14:31:40 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Tue, 19 Aug 2003 16:31:40 +0300 Subject: [Lwapp] CAPWAP Problem Statement Message-ID: We must avoid limiting the solution to single AR. The issue of multiple = AR per broadcast domain must be addressed, or at least not to be = prevented by the standard. To start with AR failure must be backup by ARs in the same broadcast = domain. Also, we should pursue an architecture, which will uniformly = distributes APs among ARs in the same broadcast domain. Allowing AP to = register and join the "best" AR within its broadcast domain (or AR to = redirect/reject AP if it's loaded). Furthermore, it may be advisable to = allow an AP to register to two AR - active AR and dormant AR, and to = switch to the dormant when the active cannot be reached.=20 Limiting the solution to a single AR per a broadcast domain seems also = as an installation hurdle. Furthermore, in case AR is simply and = upgradeable image code to an existent router/switch (versus dedicated = appliance) it would be impossible to force the customer, with an = installation based, to change its network infrastructure to met the = "single AR per broadcast domain" demand. Emek -----Original Message----- From: Mike Moreton [mailto:Mike.Moreton@Synad.com] Sent: Tuesday, 19 August, 2003 11:58 AM To: lwapp@frascone.com Subject: RE: [Lwapp] CAPWAP Problem Statement It strikes me there's a related question: Is the idea to allow more than one AR per broadcast domain? The way 802.11 works there's some benefit in having all the 802.11 LANs on a site in the same broadcast domain. Mike Moreton Synad Technologies Ltd. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 18 August 2003 21:30 To: Marcus Brunner; Pat R. Calhoun; lwapp@frascone.com Subject: Re: [Lwapp] CAPWAP Problem Statement I've been assuming B, that is, I'm not assuming that all APs for a particular network are under a single AR. The value of CAPWAP would be to go from a case where each individual AP is managed to B, where the routers/switches are managed, thereby increasing the fanout and decreasing the number of devices requiring management. So taking your number of 500, managing 500 routers/switches with CAPWAP would cover a lot larger geographic/topological area than managing 500 individual APs. jak > Depending on how large your network is, the central management system is > the bottleneck. E.g., a rule of dumb for SNMP networks is that a single > management station can manage something in the range of 500 nodes. (please > no discussion on the number). > > In the 802.11 case that's why the layer split issue came up, because it > seams to be to expensive to handle a number of the functions centrally. > That a network administrator wants to sit at a single location is more than > natural, but that is not the issue. > > Given the 2 topologies > A) one AR > > AP ---\ > \ > AP -----\ > \ > AP -------\ > \ > AP --------- AR > / > AP -------/ > / > AP -----/ > / > AP ---/ > > B)several ARs > > AP -------\ > \ > AP --------- AR -\ > / \ > AP -------/ \ > management system > AP -------\ / > \ / > AP --------- AR- > / > AP -------/ > > So I think the question is are we assuming A) or B)? Note that B) naturally > only makes sense again for a reasonably large number of ARs. > > > > Marcus > > > --On Montag, 18. August 2003 09:27 -0700 James Kempf > wrote: > > > Marcus, > > > >> Problem 1: managing large networks is a common problem. Centralization of > >> management for large networks is a problem not a solution. > >> > > > > Whatever leads you to this conclusion? > > > > Having a single point from which a a single person acting as an > > administrator can monitor and update configuration on many different > > networks elements (routers, firewalls, whatever), seems like a much more > > cost effective solution than having to send one or a bunch of people > > around to each individual machine to monitor and update. > > > > Or am I missing something? > > > > jak > > > > > > > > > > > > > > _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From bhandaru@legra.com Tue Aug 19 14:48:43 2003 From: bhandaru@legra.com (Nehru Bhandaru) Date: Tue, 19 Aug 2003 09:48:43 -0400 Subject: [Lwapp] CAPWAP Problem Statement In-Reply-To: Message-ID: <000201c36658$9b50b9e0$a30ba8c0@legra.com> I agree - aside from reliability and installation issues, transparent roaming support would require an AR to be in and/or service multiple broadcast domains. IMO it might be sufficient to have AP <-> AR communication restricted to a single broadcast domain, but the architecture should allow an AR to place associated end-stations into multiple/different broadcast domains. my two cents... - Nehru >-----Original Message----- >From: lwapp-admin@frascone.com >[mailto:lwapp-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) >Sent: Tuesday, August 19, 2003 9:32 AM >To: Mike Moreton; lwapp@frascone.com >Subject: RE: [Lwapp] CAPWAP Problem Statement > > >We must avoid limiting the solution to single AR. The issue of >multiple AR per broadcast domain must be addressed, or at >least not to be prevented by the standard. > >To start with AR failure must be backup by ARs in the same >broadcast domain. Also, we should pursue an architecture, >which will uniformly distributes APs among ARs in the same >broadcast domain. Allowing AP to register and join the "best" >AR within its broadcast domain (or AR to redirect/reject AP if >it's loaded). Furthermore, it may be advisable to allow an AP >to register to two AR - active AR and dormant AR, and to >switch to the dormant when the active cannot be reached. > >Limiting the solution to a single AR per a broadcast domain >seems also as an installation hurdle. Furthermore, in case AR >is simply and upgradeable image code to an existent >router/switch (versus dedicated appliance) it would be >impossible to force the customer, with an installation based, >to change its network infrastructure to met the "single AR per >broadcast domain" demand. > >Emek > > >-----Original Message----- >From: Mike Moreton [mailto:Mike.Moreton@Synad.com] >Sent: Tuesday, 19 August, 2003 11:58 AM >To: lwapp@frascone.com >Subject: RE: [Lwapp] CAPWAP Problem Statement > >It strikes me there's a related question: Is the idea to >allow more than one AR per broadcast domain? The way 802.11 >works there's some benefit in having all the 802.11 LANs on a >site in the same broadcast domain. > >Mike Moreton >Synad Technologies Ltd. > > >-----Original Message----- >From: James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: 18 August 2003 21:30 >To: Marcus Brunner; Pat R. Calhoun; lwapp@frascone.com >Subject: Re: [Lwapp] CAPWAP Problem Statement > >I've been assuming B, that is, I'm not assuming that all APs >for a particular network are under a single AR. The value of >CAPWAP would be to go from a case where each individual AP is >managed to B, where the routers/switches are managed, thereby >increasing the fanout and decreasing the number of devices >requiring management. So taking your number of 500, managing >500 routers/switches with CAPWAP would cover a lot larger >geographic/topological area than managing 500 individual APs. > > jak > > >> Depending on how large your network is, the central management system >is >> the bottleneck. E.g., a rule of dumb for SNMP networks is that a >single >> management station can manage something in the range of 500 nodes. >(please >> no discussion on the number). >> >> In the 802.11 case that's why the layer split issue came up, because >it >> seams to be to expensive to handle a number of the functions >centrally. >> That a network administrator wants to sit at a single >location is more >than >> natural, but that is not the issue. >> >> Given the 2 topologies >> A) one AR >> >> AP ---\ >> \ >> AP -----\ >> \ >> AP -------\ >> \ >> AP --------- AR >> / >> AP -------/ >> / >> AP -----/ >> / >> AP ---/ >> >> B)several ARs >> >> AP -------\ >> \ >> AP --------- AR -\ >> / \ >> AP -------/ \ >> management system >> AP -------\ / >> \ / >> AP --------- AR- >> / >> AP -------/ >> >> So I think the question is are we assuming A) or B)? Note that B) >naturally >> only makes sense again for a reasonably large number of ARs. >> >> >> >> Marcus >> >> >> --On Montag, 18. August 2003 09:27 -0700 James Kempf >> wrote: >> >> > Marcus, >> > >> >> Problem 1: managing large networks is a common problem. >Centralization >of >> >> management for large networks is a problem not a solution. >> >> >> > >> > Whatever leads you to this conclusion? >> > >> > Having a single point from which a a single person acting as an >> > administrator can monitor and update configuration on many >different >> > networks elements (routers, firewalls, whatever), seems like a much >more >> > cost effective solution than having to send one or a bunch >of people >> > around to each individual machine to monitor and update. >> > >> > Or am I missing something? >> > >> > jak >> > >> > >> > >> >> >> >> >> >> >> >> > >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp > From pcalhoun@airespace.com Tue Aug 19 16:03:50 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 19 Aug 2003 08:03:50 -0700 Subject: [Lwapp] CAPWAP Problem Statement Message-ID: <40301581B2962B448690A023EF16DFE1DC5540@bsn-mail-01.bstormnetworks.com> WWVzLCBJIGFtIGFsc28gYXNzdW1pbmcgQi4gRm9yIHNtYWxsZXIgODAyLjExIGRlcGxveW1lbnRz LCB0aGUgY3VycmVudCBtb2RlbCBtYXkgYmUgZmluZS4gSG93ZXZlciwgSSd2ZSBoZWFyZCBmcm9t IHZhcmlvdXMgSVQgbWFuYWdlcnMgdGhhdCB3aGVuIHRoZXkgZGVwbG95ZWQgODAyLjExLCB0aGV5 IG5lYXJseSBkb3VibGVkIHRoZSBudW1iZXIgb2YgbWFuYWdlZCBkZXZpY2VzIGluIHRoZWlyIG5l dHdvcmtzLg0KIA0KUGF0Qw0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTog SmFtZXMgS2VtcGYgW21haWx0bzprZW1wZkBkb2NvbW9sYWJzLXVzYS5jb21dIA0KCVNlbnQ6IE1v biA4LzE4LzIwMDMgMToyOSBQTSANCglUbzogTWFyY3VzIEJydW5uZXI7IFBhdCBSLiBDYWxob3Vu OyBsd2FwcEBmcmFzY29uZS5jb20gDQoJQ2M6IA0KCVN1YmplY3Q6IFJlOiBbTHdhcHBdIENBUFdB UCBQcm9ibGVtIFN0YXRlbWVudA0KCQ0KCQ0KDQoJSSd2ZSBiZWVuIGFzc3VtaW5nIEIsIHRoYXQg aXMsIEknbSBub3QgYXNzdW1pbmcgdGhhdCBhbGwgQVBzIGZvciBhDQoJcGFydGljdWxhciBuZXR3 b3JrIGFyZSB1bmRlciBhIHNpbmdsZSBBUi4gVGhlIHZhbHVlIG9mIENBUFdBUCB3b3VsZCBiZSB0 byBnbw0KCWZyb20gYSBjYXNlIHdoZXJlIGVhY2ggaW5kaXZpZHVhbCBBUCBpcyBtYW5hZ2VkIHRv IEIsIHdoZXJlIHRoZQ0KCXJvdXRlcnMvc3dpdGNoZXMgYXJlIG1hbmFnZWQsIHRoZXJlYnkgaW5j cmVhc2luZyB0aGUgZmFub3V0IGFuZCBkZWNyZWFzaW5nDQoJdGhlIG51bWJlciBvZiBkZXZpY2Vz IHJlcXVpcmluZyBtYW5hZ2VtZW50LiBTbyB0YWtpbmcgeW91ciBudW1iZXIgb2YgNTAwLA0KCW1h bmFnaW5nIDUwMCByb3V0ZXJzL3N3aXRjaGVzIHdpdGggQ0FQV0FQIHdvdWxkIGNvdmVyIGEgbG90 IGxhcmdlcg0KCWdlb2dyYXBoaWMvdG9wb2xvZ2ljYWwgYXJlYSB0aGFuIG1hbmFnaW5nIDUwMCBp bmRpdmlkdWFsIEFQcy4NCgkNCgkgICAgICAgICAgICBqYWsNCgkNCgkNCgk+IERlcGVuZGluZyBv biBob3cgbGFyZ2UgeW91ciBuZXR3b3JrIGlzLCB0aGUgY2VudHJhbCBtYW5hZ2VtZW50IHN5c3Rl bSBpcw0KCT4gdGhlIGJvdHRsZW5lY2suIEUuZy4sIGEgcnVsZSBvZiBkdW1iIGZvciBTTk1QIG5l dHdvcmtzIGlzIHRoYXQgYSBzaW5nbGUNCgk+IG1hbmFnZW1lbnQgc3RhdGlvbiBjYW4gbWFuYWdl IHNvbWV0aGluZyBpbiB0aGUgcmFuZ2Ugb2YgNTAwIG5vZGVzLiAocGxlYXNlDQoJPiBubyBkaXNj dXNzaW9uIG9uIHRoZSBudW1iZXIpLg0KCT4NCgk+IEluIHRoZSA4MDIuMTEgY2FzZSB0aGF0J3Mg d2h5IHRoZSBsYXllciBzcGxpdCBpc3N1ZSBjYW1lIHVwLCBiZWNhdXNlIGl0DQoJPiBzZWFtcyB0 byBiZSB0byBleHBlbnNpdmUgdG8gaGFuZGxlIGEgbnVtYmVyIG9mIHRoZSBmdW5jdGlvbnMgY2Vu dHJhbGx5Lg0KCT4gVGhhdCBhIG5ldHdvcmsgYWRtaW5pc3RyYXRvciB3YW50cyB0byBzaXQgYXQg YSBzaW5nbGUgbG9jYXRpb24gaXMgbW9yZQ0KCXRoYW4NCgk+IG5hdHVyYWwsIGJ1dCB0aGF0IGlz IG5vdCB0aGUgaXNzdWUuDQoJPg0KCT4gR2l2ZW4gdGhlIDIgdG9wb2xvZ2llcw0KCT4gQSkgb25l IEFSDQoJPg0KCT4gQVAgLS0tXA0KCT4gICAgICAgIFwNCgk+IEFQIC0tLS0tXA0KCT4gICAgICAg ICAgXA0KCT4gQVAgLS0tLS0tLVwNCgk+ICAgICAgICAgICAgXA0KCT4gQVAgLS0tLS0tLS0tIEFS DQoJPiAgICAgICAgICAgIC8NCgk+IEFQIC0tLS0tLS0vDQoJPiAgICAgICAgICAvDQoJPiBBUCAt LS0tLS8NCgk+ICAgICAgICAvDQoJPiBBUCAtLS0vDQoJPg0KCT4gQilzZXZlcmFsIEFScw0KCT4N Cgk+IEFQIC0tLS0tLS1cDQoJPiAgICAgICAgICAgIFwNCgk+IEFQIC0tLS0tLS0tLSBBUiAtXA0K CT4gICAgICAgICAgICAvICAgICAgXA0KCT4gQVAgLS0tLS0tLS8gICAgICAgIFwNCgk+ICAgICAg ICAgICAgICAgICAgICBtYW5hZ2VtZW50IHN5c3RlbQ0KCT4gQVAgLS0tLS0tLVwgICAgICAgLw0K CT4gICAgICAgICAgICBcICAgICAvDQoJPiBBUCAtLS0tLS0tLS0gQVItDQoJPiAgICAgICAgICAg IC8NCgk+IEFQIC0tLS0tLS0vDQoJPg0KCT4gU28gSSB0aGluayB0aGUgcXVlc3Rpb24gaXMgYXJl IHdlIGFzc3VtaW5nIEEpIG9yIEIpPyBOb3RlIHRoYXQgQikNCgluYXR1cmFsbHkNCgk+IG9ubHkg bWFrZXMgc2Vuc2UgYWdhaW4gZm9yIGEgcmVhc29uYWJseSBsYXJnZSBudW1iZXIgb2YgQVJzLg0K CT4NCgk+DQoJPg0KCT4gTWFyY3VzDQoJPg0KCT4NCgk+IC0tT24gTW9udGFnLCAxOC4gQXVndXN0 IDIwMDMgMDk6MjcgLTA3MDAgSmFtZXMgS2VtcGYNCgk+IDxrZW1wZkBkb2NvbW9sYWJzLXVzYS5j b20+IHdyb3RlOg0KCT4NCgk+ID4gTWFyY3VzLA0KCT4gPg0KCT4gPj4gUHJvYmxlbSAxOiBtYW5h Z2luZyBsYXJnZSBuZXR3b3JrcyBpcyBhIGNvbW1vbiBwcm9ibGVtLiBDZW50cmFsaXphdGlvbg0K CW9mDQoJPiA+PiBtYW5hZ2VtZW50IGZvciBsYXJnZSBuZXR3b3JrcyBpcyBhIHByb2JsZW0gbm90 IGEgc29sdXRpb24uDQoJPiA+Pg0KCT4gPg0KCT4gPiBXaGF0ZXZlciBsZWFkcyB5b3UgdG8gdGhp cyBjb25jbHVzaW9uPw0KCT4gPg0KCT4gPiBIYXZpbmcgYSBzaW5nbGUgcG9pbnQgZnJvbSB3aGlj aCBhIGEgc2luZ2xlIHBlcnNvbiBhY3RpbmcgYXMgYW4NCgk+ID4gYWRtaW5pc3RyYXRvciBjYW4g bW9uaXRvciBhbmQgdXBkYXRlIGNvbmZpZ3VyYXRpb24gb24gbWFueSBkaWZmZXJlbnQNCgk+ID4g bmV0d29ya3MgZWxlbWVudHMgKHJvdXRlcnMsIGZpcmV3YWxscywgd2hhdGV2ZXIpLCBzZWVtcyBs aWtlIGEgbXVjaCBtb3JlDQoJPiA+IGNvc3QgZWZmZWN0aXZlIHNvbHV0aW9uIHRoYW4gaGF2aW5n IHRvIHNlbmQgb25lIG9yIGEgYnVuY2ggb2YgcGVvcGxlDQoJPiA+IGFyb3VuZCB0byBlYWNoIGlu ZGl2aWR1YWwgbWFjaGluZSB0byBtb25pdG9yIGFuZCB1cGRhdGUuDQoJPiA+DQoJPiA+IE9yIGFt IEkgbWlzc2luZyBzb21ldGhpbmc/DQoJPiA+DQoJPiA+ICAgICAgICAgICAgIGphaw0KCT4gPg0K CT4gPg0KCT4gPg0KCT4NCgk+DQoJPg0KCT4NCgk+DQoJPg0KCT4NCgk+DQoJDQoJDQoNCg== From pcalhoun@airespace.com Tue Aug 19 16:05:55 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 19 Aug 2003 08:05:55 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) Message-ID: <40301581B2962B448690A023EF16DFE1DC5541@bsn-mail-01.bstormnetworks.com> SWYgeW91IGFyZSB0YWxraW5nIGFib3V0IDgwMi4xeC9XUEEsIHRoZW4gdGhlIEFSIGlzIHdoZXJl IGl0IGJlbG9uZ3MuIEhvd2V2ZXIsIHRoZSBhY3R1YWwgZW5jcnlwdGlvbiByZWFsbHkgbXVzdCBv Y2N1ciBpbiB0aGUgQVAgaW4gb3JkZXIgZm9yIHRoaXMgdG8gd29yayB3aXRoIDgwMi4xMWUuDQog DQpQYXRDDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBNaWtlIE1vcmV0 b24gW21haWx0bzpNaWtlLk1vcmV0b25AU3luYWQuY29tXSANCglTZW50OiBUdWUgOC8xOS8yMDAz IDE6NDkgQU0gDQoJVG86IGx3YXBwQGZyYXNjb25lLmNvbSANCglDYzogDQoJU3ViamVjdDogUkU6 IFtMd2FwcF0gQ0FQV0FQIFByb2JsZW0gU3RhdGVtZW50IChzZWN1cmUgZG93bmxvYWQ/KQ0KCQ0K CQ0KDQoJTWFyY3VzLA0KCQ0KCUkgdGhpbmsgd2hhdCB5b3UgY29tbWVudCBleHBvc2VzIGlzIHRo YXQgdGhlIHRocmVhdCBtb2RlbCBpcyBsYXJnZWx5DQoJZGlmZmVyZW50IGRlcGVuZGluZyBvbiB3 aGVyZSB5b3UgdGVybWluYXRlIHRoZSA4MDIuMTEgc2VjdXJpdHkNCglhc3NvY2lhdGlvbi4gDQoJ DQoJSSB0aGluayB0aGUgZ3JvdXAgd2lsbCBzYXZlIGl0c2VsZiBhIGxvdCBvZiB3b3JrIGluIHRo ZSBsb25nLXJ1biBpZiBpdA0KCWRlY2lkZXMgdXAgZnJvbnQgd2hlcmUgdGhhdCBhc3NvY2lhdGlv biBpcyBnb2luZyB0byBiZSB0ZXJtaW5hdGVkLiAgSQ0KCWtub3cgdGhhdCdzIGEgZGlmZmljdWx0 IHF1ZXN0aW9uLCBidXQgaXQncyBub3QgZ29pbmcgdG8gZ2V0IGFueSBlYXNpZXINCgl3aXRoIHRp bWUuDQoJDQoJTWlrZSBNb3JldG9uDQoJU3luYWQgVGVjaG5vbG9naWVzIEx0ZC4NCgkNCgkNCgkt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCUZyb206IE1hcmN1cyBCcnVubmVyIFttYWlsdG86 YnJ1bm5lckBjY3JsZS5uZWMuZGVdDQoJU2VudDogMTggQXVndXN0IDIwMDMgMjA6MDANCglUbzog UGF0IFIuIENhbGhvdW47IEphbWVzIEtlbXBmOyBsd2FwcEBmcmFzY29uZS5jb207IE1hcnRpbiBM ZWZrb3dpdHoNCglTdWJqZWN0OiBSRTogW0x3YXBwXSBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQg KHNlY3VyZSBkb3dubG9hZD8pDQoJDQoJQWN0dWFsbHksIHRoZSBtYWluIG1vdGl2YXRpb24sIHdo eSB3ZSBkaWQgYSBzaW1pbGFyIHNvbHV0aW9uIHNvbWUgdGltZQ0KCWFnbw0KCXdhcyB0byB0ZXJt aW5hdGUgdGhlIDgwMi4xMSBzZWN1cml0eSBhc3NvY2lhdGlvbiAod2l0aCBzb21lIHR3ZWFrcyB0 bw0KCW92ZXJjb21lIHRoZSBzZWN1cml0eSBwcm9ibGVtKSBpbiBhIHNlY3VyZWQgcGh5c2ljYWwg bG9jYXRpb24uIFNvIHdlDQoJZG9uJ3QNCgljYXJlIHdoYXQgaGFwcGVucyB0byB0aGUgYWNjZXNz IHBvaW50IG5vbi1zZWN1cmUgZG93bmxvYWQgaXMgZmluZSBmb3INCgl0aGF0DQoJcGFydGljdWxh ciBzY2VuYXJpby4NCgkNCglNYXJjdXMNCgkNCgktLU9uIE1vbnRhZywgMTguIEF1Z3VzdCAyMDAz IDEwOjUxIC0wNzAwICJQYXQgUi4gQ2FsaG91biINCgk8cGNhbGhvdW5AYWlyZXNwYWNlLmNvbT4g d3JvdGU6DQoJDQoJPiBJIGNhbiBjZXJ0YWlubHkgaW1hZ2UgYSBzY2VuYXJpbyB3aGVyZSBzb21l b25lIHB1dHMgbWFsaWNpb3VzIGNvZGUgb24NCglhbg0KCT4gQVAsIGJ5IGdhaW5pbmcgYWNjZXNz IHRvIGl0J3Mgc2NoZW1hdGljcy4gSXQgY2FuIHJlYWQgZXhpc3RpbmcgZmxhc2gNCgk+IGZvcm1h dHMgKHdoaWNoIGNhbiBiZSByZXZlcnNlIGVuZ2luZWVyZWQpLCBhbmQgY2F1c2Ugc29tZSByYXRo ZXINCglzZXJpb3VzDQoJPiBzZWN1cml0eSB0aHJlYXRzLiBIb3dldmVyLCBpZiB0aGUgY29uY2Vu c3VzIG9mIHRoZSAocHJvcG9zZWQpIFdHIGlzIHRvDQoJPiBpZ25vcmUgc2VjdXJlIGRvd25sb2Fk LCBhbmQganVzdCBmb2N1cyBvbiBkb3dubG9hZCBpdHNlbGYsIHRoZW4gSQ0KCSpjb3VsZCoNCgk+ IGJlIHN3YXllZCA6KQ0KCT4gUGF0Qw0KCT4NCgk+ICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQoJPiAgICAgICBGcm9tOiBKYW1lcyBLZW1wZiBbbWFpbHRvOmtlbXBmQGRvY29tb2xh YnMtdXNhLmNvbV0NCgk+ICAgICAgIFNlbnQ6IE1vbiA4LzE4LzIwMDMgMTA6NDggQU0NCgk+ICAg ICAgIFRvOiBsd2FwcEBmcmFzY29uZS5jb207IE1hcnRpbiBMZWZrb3dpdHoNCgk+ICAgICAgIENj Og0KCT4gICAgICAgU3ViamVjdDogUmU6IFtMd2FwcF0gQ0FQV0FQIFByb2JsZW0gU3RhdGVtZW50 IChzZWN1cmUgZG93bmxvYWQ/KQ0KCT4gICAgICANCgk+ICAgICAgDQoJPg0KCT4gICAgICAgSG93 IGFib3V0IHJvZ3VlIGNvZGUgdGhhdCBjYXVzZXMgdGhlIEFQIHRvIGluY3JlYXNlIGl0cyBwb3dl ciB0bw0KCXRoZQ0KCT4gbWF4aW11bSAgICAgICBhbmQgc3RhcnQgYnJvYWRjYXN0aW5nIHdoaXRl IG5vaXNlIGFjcm9zcyBhbGwgY2hhbm5lbHM/DQoJPiAgICAgIA0KCT4gICAgICAgICAgICAgICAg ICAgamFrDQoJPiAgICAgIA0KCT4gICAgICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K CT4gICAgICAgRnJvbTogIk1hcnRpbiBMZWZrb3dpdHoiIDxsZWZrb0B0cmFwZXplbmV0d29ya3Mu Y29tPg0KCT4gICAgICAgVG86IDxsd2FwcEBmcmFzY29uZS5jb20+DQoJPiAgICAgICBTZW50OiBN b25kYXksIEF1Z3VzdCAxOCwgMjAwMyAxMDo0NSBBTQ0KCT4gICAgICAgU3ViamVjdDogUmU6IFtM d2FwcF0gQ0FQV0FQIFByb2JsZW0gU3RhdGVtZW50IChzZWN1cmUgZG93bmxvYWQ/KQ0KCT4gICAg ICANCgk+ICAgICAgDQoJPiAgICAgICA+IEkgYWxzbyBhbSB3b25kZXJpbmcgd2h5IHdlIG5lZWQg YSBzZWN1cmUgZG93bmxvYWQ/DQoJPiAgICAgICA+DQoJPiAgICAgICA+IEdpdmVuIFRHaSdzIGJh c2ljIGxpbmNocGluIG9mIG11dHVhbCBhdXRoZW50aWNhdGlvbiBJIHdvbmRlcg0KCXdoYXQgZ29v ZA0KCT4gaXQgICAgPiB3b3VsZCBkbyB0byBoYXZlIHJvZ3VlIGNvZGUgaW4gYW4gQVAgdGhhdCBj YW4gbm90IGF1dGhlbnRpY2F0ZQ0KCT4gaXRzZWxmIHRvICAgICA+IHRoZSBBUiBpbiBpdCdzIG9w ZXJhdGlvbmFsIHN0YXRlLCBvciBhdXRoZW50aWNhdGUNCglpdHNlbGYgb2YNCgk+IHRoZSBTVEEg aW4gICAgaXQncw0KCT4gICAgICAgPiBvcGVyYXRpb25hbCBzdGF0ZS4gIEhvd2V2ZXIsIEkgZG8g c2VlIHNpZ25pZmljYW50IGRhbmdlciBpbg0KCXB1dHRpbmcNCgk+ICAgICAgID4gc29tZXRoaW5n IGxpa2UgYSBjZXJ0aWZpY2F0ZSBpbiBhIHBoeXNpY2FsbHkgaW5zZWN1cmUgZGV2aWNlDQoJKGxp a2UgaW4gYQ0KCT4gICAgICAgPiBob3RzcG90KSB3aGVyZSBpdCBjb3VsZCBiZSBicm9rZW4gaW50 byBhbmQgaGF2ZSB0aGUNCgljZXJ0aWZpY2F0ZQ0KCT4gICAgICAgY29tcHJvbWlzZWQuDQoJPiAg ICAgICA+DQoJPiAgICAgICA+IFNlZW1zIHRvIG1lIHRoYXQgdGhlIENBUFdBUCBkb2Mgc2hvdWxk IGNvbmNlbnRyYXRlIG9mIGdldHRpbmcNCgl0aGUgaW1hZ2UNCgk+ICAgICAgID4gZG93bmxvYWRl ZCByZWxpYWJseSwgbm90IHNlY3VyZWx5LiAgVGhlIHNlY3VyaXR5IHBhcnQgY29tZSBpbg0KCXBs YXkgaW4NCgk+IHRoZSAgID4gb3BlcmF0aW9uYWwgc3RhdGUuDQoJPiAgICAgICA+DQoJPiAgICAg ICA+IE1hcnR5DQoJPiAgICAgICA+DQoJPiAgICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoJPiAgICAgICA+IEx3YXBwIG1haWxpbmcgbGlzdA0K CT4gICAgICAgPiBMd2FwcEBmcmFzY29uZS5jb20NCgk+ICAgICAgID4gaHR0cDovL21haWwuZnJh c2NvbmUuY29tL21haWxtYW4vbGlzdGluZm8vbHdhcHANCgk+ICAgICAgID4NCgk+ICAgICAgDQoJ PiAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K CT4gICAgICAgTHdhcHAgbWFpbGluZyBsaXN0DQoJPiAgICAgICBMd2FwcEBmcmFzY29uZS5jb20N Cgk+ICAgICAgIGh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2x3YXBw DQoJPiAgICAgIA0KCT4NCgk+IH9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/Pypp fmYiFik/LDQ8GiY/Kxwidz9yICAgICAgITY/f3kaDQoJPiBfPyscInc/ciAgICAgID8ZKCUZKX8W Ky0NCgk+IHc/GiYNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KCURyLiBNYXJjdXMgQnJ1bm5lcg0KCU5ldHdvcmsgTGFib3JhdG9yaWVzDQoJTkVDIEV1 cm9wZSBMdGQuDQoJDQoJRS1NYWlsOiBicnVubmVyQGNjcmxlLm5lYy5kZQ0KCVdXVzogICAgaHR0 cDovL3d3dy5jY3JsZS5uZWMuZGUvDQoJUGhvbmU6ICs0OSAoMCkgNjIyMSA5MDUgMTEgMjkNCglN b2JpbGU6ICs0OSAoMCkgMTYzIDI3NSAxNyA0Mw0KCXBlcnNvbmFsIGhvbWUgcGFnZTogaHR0cDov L3d3dy5icnViZXJzLm9yZy9tYXJjdXMNCgkNCgkNCgkNCgkNCglfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCUx3YXBwIG1haWxpbmcgbGlzdA0KCUx3YXBw QGZyYXNjb25lLmNvbQ0KCWh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3RpbmZv L2x3YXBwDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CglMd2FwcCBtYWlsaW5nIGxpc3QNCglMd2FwcEBmcmFzY29uZS5jb20NCglodHRwOi8vbWFpbC5m cmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9sd2FwcA0KCQ0KDQo= From pcalhoun@airespace.com Tue Aug 19 16:06:48 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 19 Aug 2003 08:06:48 -0700 Subject: [Lwapp] CAPWAP Problem Statement Message-ID: <40301581B2962B448690A023EF16DFE1DC5542@bsn-mail-01.bstormnetworks.com> UmlnaHQsIGJ1dCB0aGVzZSB3aXJlZCBneW1uYXN0aWNzIGFyZSB3aGF0IElUIG1hbmFnZXJzIHdh bnQgdG8gbW92ZSBhd2F5IGZyb20NCiANClBhdEMNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tIA0KCUZyb206IE1pa2UgTW9yZXRvbiBbbWFpbHRvOk1pa2UuTW9yZXRvbkBTeW5hZC5jb21d IA0KCVNlbnQ6IFR1ZSA4LzE5LzIwMDMgMTo1NyBBTSANCglUbzogbHdhcHBAZnJhc2NvbmUuY29t IA0KCUNjOiANCglTdWJqZWN0OiBSRTogW0x3YXBwXSBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQN CgkNCgkNCg0KCUl0IHN0cmlrZXMgbWUgdGhlcmUncyBhIHJlbGF0ZWQgcXVlc3Rpb246ICBJcyB0 aGUgaWRlYSB0byBhbGxvdyBtb3JlDQoJdGhhbiBvbmUgQVIgcGVyIGJyb2FkY2FzdCBkb21haW4/ ICBUaGUgd2F5IDgwMi4xMSB3b3JrcyB0aGVyZSdzIHNvbWUNCgliZW5lZml0IGluIGhhdmluZyBh bGwgdGhlIDgwMi4xMSBMQU5zIG9uIGEgc2l0ZSBpbiB0aGUgc2FtZSBicm9hZGNhc3QNCglkb21h aW4uDQoJDQoJTWlrZSBNb3JldG9uDQoJU3luYWQgVGVjaG5vbG9naWVzIEx0ZC4NCgkNCgkNCgkt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCUZyb206IEphbWVzIEtlbXBmIFttYWlsdG86a2Vt cGZAZG9jb21vbGFicy11c2EuY29tXQ0KCVNlbnQ6IDE4IEF1Z3VzdCAyMDAzIDIxOjMwDQoJVG86 IE1hcmN1cyBCcnVubmVyOyBQYXQgUi4gQ2FsaG91bjsgbHdhcHBAZnJhc2NvbmUuY29tDQoJU3Vi amVjdDogUmU6IFtMd2FwcF0gQ0FQV0FQIFByb2JsZW0gU3RhdGVtZW50DQoJDQoJSSd2ZSBiZWVu IGFzc3VtaW5nIEIsIHRoYXQgaXMsIEknbSBub3QgYXNzdW1pbmcgdGhhdCBhbGwgQVBzIGZvciBh DQoJcGFydGljdWxhciBuZXR3b3JrIGFyZSB1bmRlciBhIHNpbmdsZSBBUi4gVGhlIHZhbHVlIG9m IENBUFdBUCB3b3VsZCBiZQ0KCXRvIGdvDQoJZnJvbSBhIGNhc2Ugd2hlcmUgZWFjaCBpbmRpdmlk dWFsIEFQIGlzIG1hbmFnZWQgdG8gQiwgd2hlcmUgdGhlDQoJcm91dGVycy9zd2l0Y2hlcyBhcmUg bWFuYWdlZCwgdGhlcmVieSBpbmNyZWFzaW5nIHRoZSBmYW5vdXQgYW5kDQoJZGVjcmVhc2luZw0K CXRoZSBudW1iZXIgb2YgZGV2aWNlcyByZXF1aXJpbmcgbWFuYWdlbWVudC4gU28gdGFraW5nIHlv dXIgbnVtYmVyIG9mDQoJNTAwLA0KCW1hbmFnaW5nIDUwMCByb3V0ZXJzL3N3aXRjaGVzIHdpdGgg Q0FQV0FQIHdvdWxkIGNvdmVyIGEgbG90IGxhcmdlcg0KCWdlb2dyYXBoaWMvdG9wb2xvZ2ljYWwg YXJlYSB0aGFuIG1hbmFnaW5nIDUwMCBpbmRpdmlkdWFsIEFQcy4NCgkNCgkgICAgICAgICAgICBq YWsNCgkNCgkNCgk+IERlcGVuZGluZyBvbiBob3cgbGFyZ2UgeW91ciBuZXR3b3JrIGlzLCB0aGUg Y2VudHJhbCBtYW5hZ2VtZW50IHN5c3RlbQ0KCWlzDQoJPiB0aGUgYm90dGxlbmVjay4gRS5nLiwg YSBydWxlIG9mIGR1bWIgZm9yIFNOTVAgbmV0d29ya3MgaXMgdGhhdCBhDQoJc2luZ2xlDQoJPiBt YW5hZ2VtZW50IHN0YXRpb24gY2FuIG1hbmFnZSBzb21ldGhpbmcgaW4gdGhlIHJhbmdlIG9mIDUw MCBub2Rlcy4NCgkocGxlYXNlDQoJPiBubyBkaXNjdXNzaW9uIG9uIHRoZSBudW1iZXIpLg0KCT4N Cgk+IEluIHRoZSA4MDIuMTEgY2FzZSB0aGF0J3Mgd2h5IHRoZSBsYXllciBzcGxpdCBpc3N1ZSBj YW1lIHVwLCBiZWNhdXNlDQoJaXQNCgk+IHNlYW1zIHRvIGJlIHRvIGV4cGVuc2l2ZSB0byBoYW5k bGUgYSBudW1iZXIgb2YgdGhlIGZ1bmN0aW9ucw0KCWNlbnRyYWxseS4NCgk+IFRoYXQgYSBuZXR3 b3JrIGFkbWluaXN0cmF0b3Igd2FudHMgdG8gc2l0IGF0IGEgc2luZ2xlIGxvY2F0aW9uIGlzIG1v cmUNCgl0aGFuDQoJPiBuYXR1cmFsLCBidXQgdGhhdCBpcyBub3QgdGhlIGlzc3VlLg0KCT4NCgk+ IEdpdmVuIHRoZSAyIHRvcG9sb2dpZXMNCgk+IEEpIG9uZSBBUg0KCT4NCgk+IEFQIC0tLVwNCgk+ ICAgICAgICBcDQoJPiBBUCAtLS0tLVwNCgk+ICAgICAgICAgIFwNCgk+IEFQIC0tLS0tLS1cDQoJ PiAgICAgICAgICAgIFwNCgk+IEFQIC0tLS0tLS0tLSBBUg0KCT4gICAgICAgICAgICAvDQoJPiBB UCAtLS0tLS0tLw0KCT4gICAgICAgICAgLw0KCT4gQVAgLS0tLS0vDQoJPiAgICAgICAgLw0KCT4g QVAgLS0tLw0KCT4NCgk+IEIpc2V2ZXJhbCBBUnMNCgk+DQoJPiBBUCAtLS0tLS0tXA0KCT4gICAg ICAgICAgICBcDQoJPiBBUCAtLS0tLS0tLS0gQVIgLVwNCgk+ICAgICAgICAgICAgLyAgICAgIFwN Cgk+IEFQIC0tLS0tLS0vICAgICAgICBcDQoJPiAgICAgICAgICAgICAgICAgICAgbWFuYWdlbWVu dCBzeXN0ZW0NCgk+IEFQIC0tLS0tLS1cICAgICAgIC8NCgk+ICAgICAgICAgICAgXCAgICAgLw0K CT4gQVAgLS0tLS0tLS0tIEFSLQ0KCT4gICAgICAgICAgICAvDQoJPiBBUCAtLS0tLS0tLw0KCT4N Cgk+IFNvIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIGlzIGFyZSB3ZSBhc3N1bWluZyBBKSBvciBCKT8g Tm90ZSB0aGF0IEIpDQoJbmF0dXJhbGx5DQoJPiBvbmx5IG1ha2VzIHNlbnNlIGFnYWluIGZvciBh IHJlYXNvbmFibHkgbGFyZ2UgbnVtYmVyIG9mIEFScy4NCgk+DQoJPg0KCT4NCgk+IE1hcmN1cw0K CT4NCgk+DQoJPiAtLU9uIE1vbnRhZywgMTguIEF1Z3VzdCAyMDAzIDA5OjI3IC0wNzAwIEphbWVz IEtlbXBmDQoJPiA8a2VtcGZAZG9jb21vbGFicy11c2EuY29tPiB3cm90ZToNCgk+DQoJPiA+IE1h cmN1cywNCgk+ID4NCgk+ID4+IFByb2JsZW0gMTogbWFuYWdpbmcgbGFyZ2UgbmV0d29ya3MgaXMg YSBjb21tb24gcHJvYmxlbS4NCglDZW50cmFsaXphdGlvbg0KCW9mDQoJPiA+PiBtYW5hZ2VtZW50 IGZvciBsYXJnZSBuZXR3b3JrcyBpcyBhIHByb2JsZW0gbm90IGEgc29sdXRpb24uDQoJPiA+Pg0K CT4gPg0KCT4gPiBXaGF0ZXZlciBsZWFkcyB5b3UgdG8gdGhpcyBjb25jbHVzaW9uPw0KCT4gPg0K CT4gPiBIYXZpbmcgYSBzaW5nbGUgcG9pbnQgZnJvbSB3aGljaCBhIGEgc2luZ2xlIHBlcnNvbiBh Y3RpbmcgYXMgYW4NCgk+ID4gYWRtaW5pc3RyYXRvciBjYW4gbW9uaXRvciBhbmQgdXBkYXRlIGNv bmZpZ3VyYXRpb24gb24gbWFueSBkaWZmZXJlbnQNCgk+ID4gbmV0d29ya3MgZWxlbWVudHMgKHJv dXRlcnMsIGZpcmV3YWxscywgd2hhdGV2ZXIpLCBzZWVtcyBsaWtlIGEgbXVjaA0KCW1vcmUNCgk+ ID4gY29zdCBlZmZlY3RpdmUgc29sdXRpb24gdGhhbiBoYXZpbmcgdG8gc2VuZCBvbmUgb3IgYSBi dW5jaCBvZiBwZW9wbGUNCgk+ID4gYXJvdW5kIHRvIGVhY2ggaW5kaXZpZHVhbCBtYWNoaW5lIHRv IG1vbml0b3IgYW5kIHVwZGF0ZS4NCgk+ID4NCgk+ID4gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGlu Zz8NCgk+ID4NCgk+ID4gICAgICAgICAgICAgamFrDQoJPiA+DQoJPiA+DQoJPiA+DQoJPg0KCT4N Cgk+DQoJPg0KCT4NCgk+DQoJPg0KCT4NCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KCUx3YXBwIG1haWxpbmcgbGlzdA0KCUx3YXBwQGZyYXNjb25l LmNvbQ0KCWh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2x3YXBwDQoJ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglMd2FwcCBt YWlsaW5nIGxpc3QNCglMd2FwcEBmcmFzY29uZS5jb20NCglodHRwOi8vbWFpbC5mcmFzY29uZS5j b20vbWFpbG1hbi9saXN0aW5mby9sd2FwcA0KCQ0KDQo= From kempf@docomolabs-usa.com Tue Aug 19 16:52:13 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Tue, 19 Aug 2003 08:52:13 -0700 Subject: [Lwapp] CAPWAP Problem Statement References: <0D3F1B25E75EE24483A6E69201142C868B0F83@paris.synad.com> Message-ID: <00cc01c36669$dbb5a660$0a6015ac@dclkempt40> I'm not quite sure what you mean by "broadcast domain" but I think the proposed architecture doesn't necessarily tie the MAC termination point to a router, though terminating at a router makes a certain amount of sense from an implementation standpoint in certain cases IMHO. For example, most of the new products (Airespace, Aruba, Trapeze, etc.) terminate at switches. I've been calling the termination point the "CAPWAP manager" for want of a better word, to keep my thinking about the functional element independent of implementation. If the termination point is independent of the subnet structure, the network operator is free to arrange the subnet to WLAN mapping to their liking. If the termination point is tied to a router through the implementation, then there are more constraints on how the operator arranges the WLAN to subnet mapping. I agree that having a single router per subnet (not sure about "broadcast domain") for 802.11 is probably best from a movement detection standpont, though there is an issue of failover capacity. jak ----- Original Message ----- From: "Mike Moreton" To: Sent: Tuesday, August 19, 2003 1:57 AM Subject: RE: [Lwapp] CAPWAP Problem Statement > It strikes me there's a related question: Is the idea to allow more > than one AR per broadcast domain? The way 802.11 works there's some > benefit in having all the 802.11 LANs on a site in the same broadcast > domain. > > Mike Moreton > Synad Technologies Ltd. > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 18 August 2003 21:30 > To: Marcus Brunner; Pat R. Calhoun; lwapp@frascone.com > Subject: Re: [Lwapp] CAPWAP Problem Statement > > I've been assuming B, that is, I'm not assuming that all APs for a > particular network are under a single AR. The value of CAPWAP would be > to go > from a case where each individual AP is managed to B, where the > routers/switches are managed, thereby increasing the fanout and > decreasing > the number of devices requiring management. So taking your number of > 500, > managing 500 routers/switches with CAPWAP would cover a lot larger > geographic/topological area than managing 500 individual APs. > > jak > > > > Depending on how large your network is, the central management system > is > > the bottleneck. E.g., a rule of dumb for SNMP networks is that a > single > > management station can manage something in the range of 500 nodes. > (please > > no discussion on the number). > > > > In the 802.11 case that's why the layer split issue came up, because > it > > seams to be to expensive to handle a number of the functions > centrally. > > That a network administrator wants to sit at a single location is more > than > > natural, but that is not the issue. > > > > Given the 2 topologies > > A) one AR > > > > AP ---\ > > \ > > AP -----\ > > \ > > AP -------\ > > \ > > AP --------- AR > > / > > AP -------/ > > / > > AP -----/ > > / > > AP ---/ > > > > B)several ARs > > > > AP -------\ > > \ > > AP --------- AR -\ > > / \ > > AP -------/ \ > > management system > > AP -------\ / > > \ / > > AP --------- AR- > > / > > AP -------/ > > > > So I think the question is are we assuming A) or B)? Note that B) > naturally > > only makes sense again for a reasonably large number of ARs. > > > > > > > > Marcus > > > > > > --On Montag, 18. August 2003 09:27 -0700 James Kempf > > wrote: > > > > > Marcus, > > > > > >> Problem 1: managing large networks is a common problem. > Centralization > of > > >> management for large networks is a problem not a solution. > > >> > > > > > > Whatever leads you to this conclusion? > > > > > > Having a single point from which a a single person acting as an > > > administrator can monitor and update configuration on many different > > > networks elements (routers, firewalls, whatever), seems like a much > more > > > cost effective solution than having to send one or a bunch of people > > > around to each individual machine to monitor and update. > > > > > > Or am I missing something? > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > From pcalhoun@airespace.com Tue Aug 19 16:58:59 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 19 Aug 2003 08:58:59 -0700 Subject: [Lwapp] CAPWAP Problem Statement Message-ID: <40301581B2962B448690A023EF16DFE1DC5544@bsn-mail-01.bstormnetworks.com> SSBiZWxpZXZlIHdlIG5lZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSBDQVBXQVAgbWFuYWdlcnMsIG9y IEFScyBwZXIgYnJvYWRjYXN0IGRvbWFpbiwgYnV0IG5vdCAqcmVxdWlyZSogdGhhdCB0aGV5IGFs bCBiZSBvbiB0aGUgc2FtZSBzdWJuZXQuDQogDQpQYXRDDQoNCgktLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLSANCglGcm9tOiBKYW1lcyBLZW1wZiBbbWFpbHRvOmtlbXBmQGRvY29tb2xhYnMtdXNh LmNvbV0gDQoJU2VudDogVHVlIDgvMTkvMjAwMyA4OjUyIEFNIA0KCVRvOiBNaWtlIE1vcmV0b247 IGx3YXBwQGZyYXNjb25lLmNvbSANCglDYzogDQoJU3ViamVjdDogUmU6IFtMd2FwcF0gQ0FQV0FQ IFByb2JsZW0gU3RhdGVtZW50DQoJDQoJDQoNCglJJ20gbm90IHF1aXRlIHN1cmUgd2hhdCB5b3Ug bWVhbiBieSAiYnJvYWRjYXN0IGRvbWFpbiIgYnV0IEkgdGhpbmsgdGhlDQoJcHJvcG9zZWQgYXJj aGl0ZWN0dXJlIGRvZXNuJ3QgbmVjZXNzYXJpbHkgdGllIHRoZSBNQUMgdGVybWluYXRpb24gcG9p bnQgdG8gYQ0KCXJvdXRlciwgdGhvdWdoIHRlcm1pbmF0aW5nIGF0IGEgcm91dGVyIG1ha2VzIGEg Y2VydGFpbiBhbW91bnQgb2Ygc2Vuc2UgZnJvbQ0KCWFuIGltcGxlbWVudGF0aW9uIHN0YW5kcG9p bnQgaW4gY2VydGFpbiBjYXNlcyBJTUhPLiBGb3IgZXhhbXBsZSwgbW9zdCBvZiB0aGUNCgluZXcg cHJvZHVjdHMgKEFpcmVzcGFjZSwgQXJ1YmEsIFRyYXBlemUsIGV0Yy4pIHRlcm1pbmF0ZSBhdCBz d2l0Y2hlcy4gSSd2ZQ0KCWJlZW4gY2FsbGluZyB0aGUgdGVybWluYXRpb24gcG9pbnQgdGhlICJD QVBXQVAgbWFuYWdlciIgZm9yIHdhbnQgb2YgYSBiZXR0ZXINCgl3b3JkLCB0byBrZWVwIG15IHRo aW5raW5nIGFib3V0IHRoZSBmdW5jdGlvbmFsIGVsZW1lbnQgaW5kZXBlbmRlbnQgb2YNCglpbXBs ZW1lbnRhdGlvbi4NCgkNCglJZiB0aGUgdGVybWluYXRpb24gcG9pbnQgaXMgaW5kZXBlbmRlbnQg b2YgdGhlIHN1Ym5ldCBzdHJ1Y3R1cmUsIHRoZSBuZXR3b3JrDQoJb3BlcmF0b3IgaXMgZnJlZSB0 byBhcnJhbmdlIHRoZSBzdWJuZXQgdG8gV0xBTiBtYXBwaW5nIHRvIHRoZWlyIGxpa2luZy4gSWYN Cgl0aGUgdGVybWluYXRpb24gcG9pbnQgaXMgdGllZCB0byBhIHJvdXRlciB0aHJvdWdoIHRoZSBp bXBsZW1lbnRhdGlvbiwgdGhlbg0KCXRoZXJlIGFyZSBtb3JlIGNvbnN0cmFpbnRzIG9uIGhvdyB0 aGUgb3BlcmF0b3IgYXJyYW5nZXMgdGhlIFdMQU4gdG8gc3VibmV0DQoJbWFwcGluZy4NCgkNCglJ IGFncmVlIHRoYXQgaGF2aW5nIGEgc2luZ2xlIHJvdXRlciBwZXIgc3VibmV0IChub3Qgc3VyZSBh Ym91dCAiYnJvYWRjYXN0DQoJZG9tYWluIikgZm9yIDgwMi4xMSBpcyBwcm9iYWJseSBiZXN0IGZy b20gYSBtb3ZlbWVudCBkZXRlY3Rpb24gc3RhbmRwb250LA0KCXRob3VnaCB0aGVyZSBpcyBhbiBp c3N1ZSBvZiBmYWlsb3ZlciBjYXBhY2l0eS4NCgkNCgkgICAgICAgICAgICBqYWsNCgkNCgktLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQoJRnJvbTogIk1pa2UgTW9yZXRvbiIgPE1pa2UuTW9y ZXRvbkBTeW5hZC5jb20+DQoJVG86IDxsd2FwcEBmcmFzY29uZS5jb20+DQoJU2VudDogVHVlc2Rh eSwgQXVndXN0IDE5LCAyMDAzIDE6NTcgQU0NCglTdWJqZWN0OiBSRTogW0x3YXBwXSBDQVBXQVAg UHJvYmxlbSBTdGF0ZW1lbnQNCgkNCgkNCgk+IEl0IHN0cmlrZXMgbWUgdGhlcmUncyBhIHJlbGF0 ZWQgcXVlc3Rpb246ICBJcyB0aGUgaWRlYSB0byBhbGxvdyBtb3JlDQoJPiB0aGFuIG9uZSBBUiBw ZXIgYnJvYWRjYXN0IGRvbWFpbj8gIFRoZSB3YXkgODAyLjExIHdvcmtzIHRoZXJlJ3Mgc29tZQ0K CT4gYmVuZWZpdCBpbiBoYXZpbmcgYWxsIHRoZSA4MDIuMTEgTEFOcyBvbiBhIHNpdGUgaW4gdGhl IHNhbWUgYnJvYWRjYXN0DQoJPiBkb21haW4uDQoJPg0KCT4gTWlrZSBNb3JldG9uDQoJPiBTeW5h ZCBUZWNobm9sb2dpZXMgTHRkLg0KCT4NCgk+DQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KCT4gRnJvbTogSmFtZXMgS2VtcGYgW21haWx0bzprZW1wZkBkb2NvbW9sYWJzLXVzYS5jb21d DQoJPiBTZW50OiAxOCBBdWd1c3QgMjAwMyAyMTozMA0KCT4gVG86IE1hcmN1cyBCcnVubmVyOyBQ YXQgUi4gQ2FsaG91bjsgbHdhcHBAZnJhc2NvbmUuY29tDQoJPiBTdWJqZWN0OiBSZTogW0x3YXBw XSBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQNCgk+DQoJPiBJJ3ZlIGJlZW4gYXNzdW1pbmcgQiwg dGhhdCBpcywgSSdtIG5vdCBhc3N1bWluZyB0aGF0IGFsbCBBUHMgZm9yIGENCgk+IHBhcnRpY3Vs YXIgbmV0d29yayBhcmUgdW5kZXIgYSBzaW5nbGUgQVIuIFRoZSB2YWx1ZSBvZiBDQVBXQVAgd291 bGQgYmUNCgk+IHRvIGdvDQoJPiBmcm9tIGEgY2FzZSB3aGVyZSBlYWNoIGluZGl2aWR1YWwgQVAg aXMgbWFuYWdlZCB0byBCLCB3aGVyZSB0aGUNCgk+IHJvdXRlcnMvc3dpdGNoZXMgYXJlIG1hbmFn ZWQsIHRoZXJlYnkgaW5jcmVhc2luZyB0aGUgZmFub3V0IGFuZA0KCT4gZGVjcmVhc2luZw0KCT4g dGhlIG51bWJlciBvZiBkZXZpY2VzIHJlcXVpcmluZyBtYW5hZ2VtZW50LiBTbyB0YWtpbmcgeW91 ciBudW1iZXIgb2YNCgk+IDUwMCwNCgk+IG1hbmFnaW5nIDUwMCByb3V0ZXJzL3N3aXRjaGVzIHdp dGggQ0FQV0FQIHdvdWxkIGNvdmVyIGEgbG90IGxhcmdlcg0KCT4gZ2VvZ3JhcGhpYy90b3BvbG9n aWNhbCBhcmVhIHRoYW4gbWFuYWdpbmcgNTAwIGluZGl2aWR1YWwgQVBzLg0KCT4NCgk+ICAgICAg ICAgICAgIGphaw0KCT4NCgk+DQoJPiA+IERlcGVuZGluZyBvbiBob3cgbGFyZ2UgeW91ciBuZXR3 b3JrIGlzLCB0aGUgY2VudHJhbCBtYW5hZ2VtZW50IHN5c3RlbQ0KCT4gaXMNCgk+ID4gdGhlIGJv dHRsZW5lY2suIEUuZy4sIGEgcnVsZSBvZiBkdW1iIGZvciBTTk1QIG5ldHdvcmtzIGlzIHRoYXQg YQ0KCT4gc2luZ2xlDQoJPiA+IG1hbmFnZW1lbnQgc3RhdGlvbiBjYW4gbWFuYWdlIHNvbWV0aGlu ZyBpbiB0aGUgcmFuZ2Ugb2YgNTAwIG5vZGVzLg0KCT4gKHBsZWFzZQ0KCT4gPiBubyBkaXNjdXNz aW9uIG9uIHRoZSBudW1iZXIpLg0KCT4gPg0KCT4gPiBJbiB0aGUgODAyLjExIGNhc2UgdGhhdCdz IHdoeSB0aGUgbGF5ZXIgc3BsaXQgaXNzdWUgY2FtZSB1cCwgYmVjYXVzZQ0KCT4gaXQNCgk+ID4g c2VhbXMgdG8gYmUgdG8gZXhwZW5zaXZlIHRvIGhhbmRsZSBhIG51bWJlciBvZiB0aGUgZnVuY3Rp b25zDQoJPiBjZW50cmFsbHkuDQoJPiA+IFRoYXQgYSBuZXR3b3JrIGFkbWluaXN0cmF0b3Igd2Fu dHMgdG8gc2l0IGF0IGEgc2luZ2xlIGxvY2F0aW9uIGlzIG1vcmUNCgk+IHRoYW4NCgk+ID4gbmF0 dXJhbCwgYnV0IHRoYXQgaXMgbm90IHRoZSBpc3N1ZS4NCgk+ID4NCgk+ID4gR2l2ZW4gdGhlIDIg dG9wb2xvZ2llcw0KCT4gPiBBKSBvbmUgQVINCgk+ID4NCgk+ID4gQVAgLS0tXA0KCT4gPiAgICAg ICAgXA0KCT4gPiBBUCAtLS0tLVwNCgk+ID4gICAgICAgICAgXA0KCT4gPiBBUCAtLS0tLS0tXA0K CT4gPiAgICAgICAgICAgIFwNCgk+ID4gQVAgLS0tLS0tLS0tIEFSDQoJPiA+ICAgICAgICAgICAg Lw0KCT4gPiBBUCAtLS0tLS0tLw0KCT4gPiAgICAgICAgICAvDQoJPiA+IEFQIC0tLS0tLw0KCT4g PiAgICAgICAgLw0KCT4gPiBBUCAtLS0vDQoJPiA+DQoJPiA+IEIpc2V2ZXJhbCBBUnMNCgk+ID4N Cgk+ID4gQVAgLS0tLS0tLVwNCgk+ID4gICAgICAgICAgICBcDQoJPiA+IEFQIC0tLS0tLS0tLSBB UiAtXA0KCT4gPiAgICAgICAgICAgIC8gICAgICBcDQoJPiA+IEFQIC0tLS0tLS0vICAgICAgICBc DQoJPiA+ICAgICAgICAgICAgICAgICAgICBtYW5hZ2VtZW50IHN5c3RlbQ0KCT4gPiBBUCAtLS0t LS0tXCAgICAgICAvDQoJPiA+ICAgICAgICAgICAgXCAgICAgLw0KCT4gPiBBUCAtLS0tLS0tLS0g QVItDQoJPiA+ICAgICAgICAgICAgLw0KCT4gPiBBUCAtLS0tLS0tLw0KCT4gPg0KCT4gPiBTbyBJ IHRoaW5rIHRoZSBxdWVzdGlvbiBpcyBhcmUgd2UgYXNzdW1pbmcgQSkgb3IgQik/IE5vdGUgdGhh dCBCKQ0KCT4gbmF0dXJhbGx5DQoJPiA+IG9ubHkgbWFrZXMgc2Vuc2UgYWdhaW4gZm9yIGEgcmVh c29uYWJseSBsYXJnZSBudW1iZXIgb2YgQVJzLg0KCT4gPg0KCT4gPg0KCT4gPg0KCT4gPiBNYXJj dXMNCgk+ID4NCgk+ID4NCgk+ID4gLS1PbiBNb250YWcsIDE4LiBBdWd1c3QgMjAwMyAwOToyNyAt MDcwMCBKYW1lcyBLZW1wZg0KCT4gPiA8a2VtcGZAZG9jb21vbGFicy11c2EuY29tPiB3cm90ZToN Cgk+ID4NCgk+ID4gPiBNYXJjdXMsDQoJPiA+ID4NCgk+ID4gPj4gUHJvYmxlbSAxOiBtYW5hZ2lu ZyBsYXJnZSBuZXR3b3JrcyBpcyBhIGNvbW1vbiBwcm9ibGVtLg0KCT4gQ2VudHJhbGl6YXRpb24N Cgk+IG9mDQoJPiA+ID4+IG1hbmFnZW1lbnQgZm9yIGxhcmdlIG5ldHdvcmtzIGlzIGEgcHJvYmxl bSBub3QgYSBzb2x1dGlvbi4NCgk+ID4gPj4NCgk+ID4gPg0KCT4gPiA+IFdoYXRldmVyIGxlYWRz IHlvdSB0byB0aGlzIGNvbmNsdXNpb24/DQoJPiA+ID4NCgk+ID4gPiBIYXZpbmcgYSBzaW5nbGUg cG9pbnQgZnJvbSB3aGljaCBhIGEgc2luZ2xlIHBlcnNvbiBhY3RpbmcgYXMgYW4NCgk+ID4gPiBh ZG1pbmlzdHJhdG9yIGNhbiBtb25pdG9yIGFuZCB1cGRhdGUgY29uZmlndXJhdGlvbiBvbiBtYW55 IGRpZmZlcmVudA0KCT4gPiA+IG5ldHdvcmtzIGVsZW1lbnRzIChyb3V0ZXJzLCBmaXJld2FsbHMs IHdoYXRldmVyKSwgc2VlbXMgbGlrZSBhIG11Y2gNCgk+IG1vcmUNCgk+ID4gPiBjb3N0IGVmZmVj dGl2ZSBzb2x1dGlvbiB0aGFuIGhhdmluZyB0byBzZW5kIG9uZSBvciBhIGJ1bmNoIG9mIHBlb3Bs ZQ0KCT4gPiA+IGFyb3VuZCB0byBlYWNoIGluZGl2aWR1YWwgbWFjaGluZSB0byBtb25pdG9yIGFu ZCB1cGRhdGUuDQoJPiA+ID4NCgk+ID4gPiBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KCT4g PiA+DQoJPiA+ID4gICAgICAgICAgICAgamFrDQoJPiA+ID4NCgk+ID4gPg0KCT4gPiA+DQoJPiA+ DQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+DQoJPg0KCT4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+IEx3YXBwIG1haWxp bmcgbGlzdA0KCT4gTHdhcHBAZnJhc2NvbmUuY29tDQoJPiBodHRwOi8vbWFpbC5mcmFzY29uZS5j b20vbWFpbG1hbi9saXN0aW5mby9sd2FwcA0KCT4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCgk+IEx3YXBwIG1haWxpbmcgbGlzdA0KCT4gTHdhcHBAZnJh c2NvbmUuY29tDQoJPiBodHRwOi8vbWFpbC5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9s d2FwcA0KCT4NCgk+DQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCglMd2FwcCBtYWlsaW5nIGxpc3QNCglMd2FwcEBmcmFzY29uZS5jb20NCglodHRw Oi8vbWFpbC5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9sd2FwcA0KCQ0KDQo= From lefko@trapezenetworks.com Tue Aug 19 17:19:49 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Tue, 19 Aug 2003 09:19:49 -0700 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) In-Reply-To: <5.1.0.14.0.20030818195907.00bc7f40@mail.impulse.net> References: <3C7C73D0-D1AA-11D7-A221-000A957E8894@cs.umd.edu> <5.1.0.14.2.20030818110526.01d7c128@mail.trpz.com> Message-ID: <5.1.0.14.2.20030819090908.01ca32d0@mail.trpz.com> At 08:40 PM 8/18/2003 -0700, hunter wrote: >Marty, > >If someone plugs in a microwave oven or a 2.4 mobile phone, they (1) can >easily be found and eliminated (choose your favorite method) and (2) can >only affect a few APs at a time (then they have to buy another oven or >mobile phone to attack the APs on the next block). That is: the >"inherently vulnerable wireless" argument is very limited. > >On the other hand, if someone can download rogue code to the 10,000 APs in >your coffeehype network, they can steal from your customers' credit cards >for a very long time. Actually they can't if they are using TGi or WPA. The basic premise is mutual authentication. The question is whether there is enough inside the device during the boot stage to gain the secret. If there is then the device should be physically secure. >Frankly, you shouldn't be worried about the former threat -- you know how >to deal with that. But the only feasible way of dealing with the latter >is to increase the cost enough to make it very unlikely (which is the >definition of "protection"). > >If CAPWAP specifies a standard way to download code, then it has the >responsibility to specify a way for protecting that transaction. > >But protection of the transaction is not protection of the >device. The limit of CAPWAP's responsibility is the minimization of any >additional vulnerabilities created by the transactions it specifies. I agree, but if there is nothing to be gained by downloading rogue code then it's pointless other than yet another DOS attack. On the other hand if it really is cheap and easy to do for a physically unsecure device, that does not open up more problems, then it's not an issue. Marty >Hunter > > >At 02:31 PM 8/18/2003 -0400, William Arbaugh wrote: >>The best way to handle this is to look at the threat. >> >>In this case, the threat is from a user (or abuser) on the wired network >>maliciously downloading a bad image to an AP. The probability that every >>organization has a malicious insider at this moment is high. The >>probability that every organization will have a malicious insider at some >>point in the future (perhaps for a limited time) is 100%. Thus, I would >>argue that this is a high risk threat and should be countered. So how do >>we counter it? >> >>Easy- some form of one-way authentication. Their are many ways to do this >>such that a physical compromise of the AP doesn't cause a entire system >>re-key. Yes- a physical compromise of the AP makes this protection moot, >>but a physical compromise requires significantly greater skills and >>requires the attacker to take a much greater risk. >> >>Providing protection for images is a no brainer to me. It can be done >>easily, and it pushes the attacker to touch the equipment, i.e. physical >>presence instead of reprogramming the device from the middle of the >>atlantic some place. >> >>On Monday, August 18, 2003, at 02:14 PM, Martin Lefkowitz wrote: >> >>>I think we need to be careful about putting protections into a device >>>that is physically insecure. Somebody could steal, or disconnect the >>>device for a short amount of time and do the same thing. >>> >>>I'm also not saying I know the answer to this, I'm assuming that >>>protecting download frames in the boot state will be cumbersome to >>>do. I could be wrong in that it's no more cumbersome than protecting >>>management, and data frames in the operational state. Especially if it >>>requires new hardware to do it at line rate... >>> >>>Marty >>> >>> >>>At 10:51 AM 8/18/2003 -0700, Pat R. Calhoun wrote: >>>>I can certainly image a scenario where someone puts malicious code on >>>>an AP, by gaining access to it's schematics. It can read existing flash >>>>formats (which can be reverse engineered), and cause some rather >>>>serious security threats. However, if the concensus of the (proposed) >>>>WG is to ignore secure download, and just focus on download itself, >>>>then I *could* be swayed :) >>>> >>>>PatC >>>> >>>> -----Original Message----- >>>> From: James Kempf [mailto:kempf@docomolabs-usa.com] >>>> Sent: Mon 8/18/2003 10:48 AM >>>> To: lwapp@frascone.com; Martin Lefkowitz >>>> Cc: >>>> Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) >>>> >>>> >>>> >>>> How about rogue code that causes the AP to increase its power >>>> to the maximum >>>> and start broadcasting white noise across all channels? >>>> >>>> jak >>>> >>>> ----- Original Message ----- >>>> From: "Martin Lefkowitz" >>>> To: >>>> Sent: Monday, August 18, 2003 10:45 AM >>>> Subject: Re: [Lwapp] CAPWAP Problem Statement (secure download?) >>>> >>>> >>>> > I also am wondering why we need a secure download? >>>> > >>>> > Given TGi's basic linchpin of mutual authentication I wonder >>>> what good it >>>> > would do to have rogue code in an AP that can not >>>> authenticate itself to >>>> > the AR in it's operational state, or authenticate itself of >>>> the STA in >>>> it's >>>> > operational state. However, I do see significant danger in >>>> putting >>>> > something like a certificate in a physically insecure device >>>> (like in a >>>> > hotspot) where it could be broken into and have the certificate >>>> compromised. >>>> > >>>> > Seems to me that the CAPWAP doc should concentrate of >>>> getting the image >>>> > downloaded reliably, not securely. The security part come >>>> in play in the >>>> > operational state. >>>> > >>>> > Marty >>>> > >>>> > _______________________________________________ >>>> > Lwapp mailing list >>>> > Lwapp@frascone.com >>>> > http://mail.frascone.com/mailman/listinfo/lwapp >>>> > >>>> >>>> _______________________________________________ >>>> Lwapp mailing list >>>> Lwapp@frascone.com >>>> http://mail.frascone.com/mailman/listinfo/lwapp >>> >>>_______________________________________________ >>>Lwapp mailing list >>>Lwapp@frascone.com >>>http://mail.frascone.com/mailman/listinfo/lwapp >> >>_______________________________________________ >>Lwapp mailing list >>Lwapp@frascone.com >>http://mail.frascone.com/mailman/listinfo/lwapp > From Mike.Moreton@Synad.com Wed Aug 20 12:08:49 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Wed, 20 Aug 2003 12:08:49 +0100 Subject: [Lwapp] CAPWAP Problem Statement (secure download?) Message-ID: <0D3F1B25E75EE24483A6E69201142C867A5150@paris.synad.com> --{3A06FFD2-3D61-484E-8A1A-1BFCE197DB7F} Content-Type: text/plain; charset="UTF-8" ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. synad.com ********************************************************************** --{3A06FFD2-3D61-484E-8A1A-1BFCE197DB7F} Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF0LA0KDQpJIGRvbid0IHRoaW5rIHRoYXQgaXMgYWN0dWFsbHkgdHJ1ZS4gIEFsbCBvZiBUR2kg d2lsbCB3b3JrIHdpdGggZW5jcnlwdGlvbi9kZWNyeXB0aW9uICYgYXV0aGVudGljYXRpb24gcnVu bmluZyBpbiB0aGUgaG9zdCBPUy4gIFRoZSByZWFzb24gaXQgaXNuJ3QgZ2VuZXJhbGx5IHRoZXJl IGlzIHRvIHJlZHVjZSB0aGUgbG9hZCBvbiB0aGUgaG9zdCBDUFUsIG5vdCBmb3IgYXJjaGl0ZWN0 dXJhbCByZWFzb25zLg0KDQpPSywgdGhlcmUgaXMgb25lIGV4Y2VwdGlvbi4gIFRoZSBuZXcgZHlu YW1pYyBmcmFnbWVudGF0aW9uIGZlYXR1cmUgYmVpbmcgaW50cm9kdWNlZCBieSBUR2UgbWFrZXMg YW55dGhpbmcgYnV0IG9uIHRoZSBmbHkgZW5jcnlwdGlvbiBpbXBvc3NpYmxlLiAgSG93ZXZlciB0 aGF0IGZlYXR1cmUgaXMgb3B0aW9uYWwsIHdvbid0IGJlIGltcGxlbWVudGVkIGJ5IG1hbnkgbWFu dWZhY3R1cmVycywgYW5kIGlzIGluIGFueSBjYXNlIGxhcmdlbHkgcG9pbnRsZXNzLiAgKElmIHlv dXIgbmV0d29yayBpcyBzbyBoZWF2aWx5IGxvYWRlZCB0aGF0IHlvdSBuZWVkIGR5bmFtaWMgZnJh Z21lbnRhdGlvbiB0byBtYWtlIGl0IHdvcmssIHlvdXIgUW9TIGlzIHNvIGJyb2tlbiBhIGxpdHRs ZSBiaXQgb2YgZXh0cmEgdGltZSB3b24ndCBtYWtlIGFueSBkaWZmZXJlbmNlKQ0KDQpNaWtlIE1v cmV0b24NClN5bmFkIFRlY2hub2xvZ2llcyBMdGQuDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBQYXQgUi4gQ2FsaG91biBbbWFpbHRvOnBjYWxob3VuQGFpcmVzcGFjZS5j b21dIA0KU2VudDogMTkgQXVndXN0IDIwMDMgMTY6MDYNClRvOiBNaWtlIE1vcmV0b247IGx3YXBw QGZyYXNjb25lLmNvbQ0KU3ViamVjdDogUkU6IFtMd2FwcF0gQ0FQV0FQIFByb2JsZW0gU3RhdGVt ZW50IChzZWN1cmUgZG93bmxvYWQ/KQ0KDQpJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgODAyLjF4 L1dQQSwgdGhlbiB0aGUgQVIgaXMgd2hlcmUgaXQgYmVsb25ncy4gSG93ZXZlciwgdGhlIGFjdHVh bCBlbmNyeXB0aW9uIHJlYWxseSBtdXN0IG9jY3VyIGluIHRoZSBBUCBpbiBvcmRlciBmb3IgdGhp cyB0byB3b3JrIHdpdGggODAyLjExZS4NCiANClBhdEMNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIA0KCUZyb206IE1pa2UgTW9yZXRvbiBbbWFpbHRvOk1pa2UuTW9yZXRvbkBTeW5hZC5j b21dIA0KCVNlbnQ6IFR1ZSA4LzE5LzIwMDMgMTo0OSBBTSANCglUbzogbHdhcHBAZnJhc2NvbmUu Y29tIA0KCUNjOiANCglTdWJqZWN0OiBSRTogW0x3YXBwXSBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1l bnQgKHNlY3VyZSBkb3dubG9hZD8pDQoJDQoJDQoNCglNYXJjdXMsDQoJDQoJSSB0aGluayB3aGF0 IHlvdSBjb21tZW50IGV4cG9zZXMgaXMgdGhhdCB0aGUgdGhyZWF0IG1vZGVsIGlzIGxhcmdlbHkN CglkaWZmZXJlbnQgZGVwZW5kaW5nIG9uIHdoZXJlIHlvdSB0ZXJtaW5hdGUgdGhlIDgwMi4xMSBz ZWN1cml0eQ0KCWFzc29jaWF0aW9uLiANCgkNCglJIHRoaW5rIHRoZSBncm91cCB3aWxsIHNhdmUg aXRzZWxmIGEgbG90IG9mIHdvcmsgaW4gdGhlIGxvbmctcnVuIGlmIGl0DQoJZGVjaWRlcyB1cCBm cm9udCB3aGVyZSB0aGF0IGFzc29jaWF0aW9uIGlzIGdvaW5nIHRvIGJlIHRlcm1pbmF0ZWQuICBJ DQoJa25vdyB0aGF0J3MgYSBkaWZmaWN1bHQgcXVlc3Rpb24sIGJ1dCBpdCdzIG5vdCBnb2luZyB0 byBnZXQgYW55IGVhc2llcg0KCXdpdGggdGltZS4NCgkNCglNaWtlIE1vcmV0b24NCglTeW5hZCBU ZWNobm9sb2dpZXMgTHRkLg0KCQ0KCQ0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJRnJv bTogTWFyY3VzIEJydW5uZXIgW21haWx0bzpicnVubmVyQGNjcmxlLm5lYy5kZV0NCglTZW50OiAx OCBBdWd1c3QgMjAwMyAyMDowMA0KCVRvOiBQYXQgUi4gQ2FsaG91bjsgSmFtZXMgS2VtcGY7IGx3 YXBwQGZyYXNjb25lLmNvbTsgTWFydGluIExlZmtvd2l0eg0KCVN1YmplY3Q6IFJFOiBbTHdhcHBd IENBUFdBUCBQcm9ibGVtIFN0YXRlbWVudCAoc2VjdXJlIGRvd25sb2FkPykNCgkNCglBY3R1YWxs eSwgdGhlIG1haW4gbW90aXZhdGlvbiwgd2h5IHdlIGRpZCBhIHNpbWlsYXIgc29sdXRpb24gc29t ZSB0aW1lDQoJYWdvDQoJd2FzIHRvIHRlcm1pbmF0ZSB0aGUgODAyLjExIHNlY3VyaXR5IGFzc29j aWF0aW9uICh3aXRoIHNvbWUgdHdlYWtzIHRvDQoJb3ZlcmNvbWUgdGhlIHNlY3VyaXR5IHByb2Js ZW0pIGluIGEgc2VjdXJlZCBwaHlzaWNhbCBsb2NhdGlvbi4gU28gd2UNCglkb24ndA0KCWNhcmUg d2hhdCBoYXBwZW5zIHRvIHRoZSBhY2Nlc3MgcG9pbnQgbm9uLXNlY3VyZSBkb3dubG9hZCBpcyBm aW5lIGZvcg0KCXRoYXQNCglwYXJ0aWN1bGFyIHNjZW5hcmlvLg0KCQ0KCU1hcmN1cw0KCQ0KCS0t T24gTW9udGFnLCAxOC4gQXVndXN0IDIwMDMgMTA6NTEgLTA3MDAgIlBhdCBSLiBDYWxob3VuIg0K CTxwY2FsaG91bkBhaXJlc3BhY2UuY29tPiB3cm90ZToNCgkNCgk+IEkgY2FuIGNlcnRhaW5seSBp bWFnZSBhIHNjZW5hcmlvIHdoZXJlIHNvbWVvbmUgcHV0cyBtYWxpY2lvdXMgY29kZSBvbg0KCWFu DQoJPiBBUCwgYnkgZ2FpbmluZyBhY2Nlc3MgdG8gaXQncyBzY2hlbWF0aWNzLiBJdCBjYW4gcmVh ZCBleGlzdGluZyBmbGFzaA0KCT4gZm9ybWF0cyAod2hpY2ggY2FuIGJlIHJldmVyc2UgZW5naW5l ZXJlZCksIGFuZCBjYXVzZSBzb21lIHJhdGhlcg0KCXNlcmlvdXMNCgk+IHNlY3VyaXR5IHRocmVh dHMuIEhvd2V2ZXIsIGlmIHRoZSBjb25jZW5zdXMgb2YgdGhlIChwcm9wb3NlZCkgV0cgaXMgdG8N Cgk+IGlnbm9yZSBzZWN1cmUgZG93bmxvYWQsIGFuZCBqdXN0IGZvY3VzIG9uIGRvd25sb2FkIGl0 c2VsZiwgdGhlbiBJDQoJKmNvdWxkKg0KCT4gYmUgc3dheWVkIDopDQoJPiBQYXRDDQoJPg0KCT4g ICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+ICAgICAgIEZyb206IEphbWVzIEtl bXBmIFttYWlsdG86a2VtcGZAZG9jb21vbGFicy11c2EuY29tXQ0KCT4gICAgICAgU2VudDogTW9u IDgvMTgvMjAwMyAxMDo0OCBBTQ0KCT4gICAgICAgVG86IGx3YXBwQGZyYXNjb25lLmNvbTsgTWFy dGluIExlZmtvd2l0eg0KCT4gICAgICAgQ2M6DQoJPiAgICAgICBTdWJqZWN0OiBSZTogW0x3YXBw XSBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQgKHNlY3VyZSBkb3dubG9hZD8pDQoJPiAgICAgIA0K CT4gICAgICANCgk+DQoJPiAgICAgICBIb3cgYWJvdXQgcm9ndWUgY29kZSB0aGF0IGNhdXNlcyB0 aGUgQVAgdG8gaW5jcmVhc2UgaXRzIHBvd2VyIHRvDQoJdGhlDQoJPiBtYXhpbXVtICAgICAgIGFu ZCBzdGFydCBicm9hZGNhc3Rpbmcgd2hpdGUgbm9pc2UgYWNyb3NzIGFsbCBjaGFubmVscz8NCgk+ ICAgICAgDQoJPiAgICAgICAgICAgICAgICAgICBqYWsNCgk+ICAgICAgDQoJPiAgICAgICAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQoJPiAgICAgICBGcm9tOiAiTWFydGluIExlZmtvd2l0 eiIgPGxlZmtvQHRyYXBlemVuZXR3b3Jrcy5jb20+DQoJPiAgICAgICBUbzogPGx3YXBwQGZyYXNj b25lLmNvbT4NCgk+ICAgICAgIFNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAyMDAzIDEwOjQ1IEFN DQoJPiAgICAgICBTdWJqZWN0OiBSZTogW0x3YXBwXSBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQg KHNlY3VyZSBkb3dubG9hZD8pDQoJPiAgICAgIA0KCT4gICAgICANCgk+ICAgICAgID4gSSBhbHNv IGFtIHdvbmRlcmluZyB3aHkgd2UgbmVlZCBhIHNlY3VyZSBkb3dubG9hZD8NCgk+ICAgICAgID4N Cgk+ICAgICAgID4gR2l2ZW4gVEdpJ3MgYmFzaWMgbGluY2hwaW4gb2YgbXV0dWFsIGF1dGhlbnRp Y2F0aW9uIEkgd29uZGVyDQoJd2hhdCBnb29kDQoJPiBpdCAgICA+IHdvdWxkIGRvIHRvIGhhdmUg cm9ndWUgY29kZSBpbiBhbiBBUCB0aGF0IGNhbiBub3QgYXV0aGVudGljYXRlDQoJPiBpdHNlbGYg dG8gICAgID4gdGhlIEFSIGluIGl0J3Mgb3BlcmF0aW9uYWwgc3RhdGUsIG9yIGF1dGhlbnRpY2F0 ZQ0KCWl0c2VsZiBvZg0KCT4gdGhlIFNUQSBpbiAgICBpdCdzDQoJPiAgICAgICA+IG9wZXJhdGlv bmFsIHN0YXRlLiAgSG93ZXZlciwgSSBkbyBzZWUgc2lnbmlmaWNhbnQgZGFuZ2VyIGluDQoJcHV0 dGluZw0KCT4gICAgICAgPiBzb21ldGhpbmcgbGlrZSBhIGNlcnRpZmljYXRlIGluIGEgcGh5c2lj YWxseSBpbnNlY3VyZSBkZXZpY2UNCgkobGlrZSBpbiBhDQoJPiAgICAgICA+IGhvdHNwb3QpIHdo ZXJlIGl0IGNvdWxkIGJlIGJyb2tlbiBpbnRvIGFuZCBoYXZlIHRoZQ0KCWNlcnRpZmljYXRlDQoJ PiAgICAgICBjb21wcm9taXNlZC4NCgk+ICAgICAgID4NCgk+ICAgICAgID4gU2VlbXMgdG8gbWUg dGhhdCB0aGUgQ0FQV0FQIGRvYyBzaG91bGQgY29uY2VudHJhdGUgb2YgZ2V0dGluZw0KCXRoZSBp bWFnZQ0KCT4gICAgICAgPiBkb3dubG9hZGVkIHJlbGlhYmx5LCBub3Qgc2VjdXJlbHkuICBUaGUg c2VjdXJpdHkgcGFydCBjb21lIGluDQoJcGxheSBpbg0KCT4gdGhlICAgPiBvcGVyYXRpb25hbCBz dGF0ZS4NCgk+ICAgICAgID4NCgk+ICAgICAgID4gTWFydHkNCgk+ICAgICAgID4NCgk+ICAgICAg ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ICAg ICAgID4gTHdhcHAgbWFpbGluZyBsaXN0DQoJPiAgICAgICA+IEx3YXBwQGZyYXNjb25lLmNvbQ0K CT4gICAgICAgPiBodHRwOi8vbWFpbC5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9sd2Fw cA0KCT4gICAgICAgPg0KCT4gICAgICANCgk+ICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoJPiAgICAgICBMd2FwcCBtYWlsaW5nIGxpc3QNCgk+ ICAgICAgIEx3YXBwQGZyYXNjb25lLmNvbQ0KCT4gICAgICAgaHR0cDovL21haWwuZnJhc2NvbmUu Y29tL21haWxtYW4vbGlzdGluZm8vbHdhcHANCgk+ICAgICAgDQoJPg0KCT4gf39/f39/f39/f39/ f39/f39/f39/f39/f39/f39/f39/f38/Kml+ZiIWKT8sNDwaJj8rHCJ3P3IgICAgICAhNj9/eRoN Cgk+IF8/Kxwidz9yICAgICAgPxkoJRkpfxYrLQ0KCT4gdz8aJg0KCQ0KCQ0KCQ0KCS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJRHIuIE1hcmN1cyBCcnVubmVyDQoJTmV0 d29yayBMYWJvcmF0b3JpZXMNCglORUMgRXVyb3BlIEx0ZC4NCgkNCglFLU1haWw6IGJydW5uZXJA Y2NybGUubmVjLmRlDQoJV1dXOiAgICBodHRwOi8vd3d3LmNjcmxlLm5lYy5kZS8NCglQaG9uZTog KzQ5ICgwKSA2MjIxIDkwNSAxMSAyOQ0KCU1vYmlsZTogKzQ5ICgwKSAxNjMgMjc1IDE3IDQzDQoJ cGVyc29uYWwgaG9tZSBwYWdlOiBodHRwOi8vd3d3LmJydWJlcnMub3JnL21hcmN1cw0KCQ0KCQ0K CQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJ THdhcHAgbWFpbGluZyBsaXN0DQoJTHdhcHBAZnJhc2NvbmUuY29tDQoJaHR0cDovL21haWwuZnJh c2NvbmUuY29tL21haWxtYW4vbGlzdGluZm8vbHdhcHANCglfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCUx3YXBwIG1haWxpbmcgbGlzdA0KCUx3YXBwQGZy YXNjb25lLmNvbQ0KCWh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2x3 YXBwDQoJDQoNCi8GZikrLwZ5yoZXasedWX4NCg== --{3A06FFD2-3D61-484E-8A1A-1BFCE197DB7F}-- From scott@airespace.com Fri Aug 22 17:31:11 2003 From: scott@airespace.com (Scott G. Kelly) Date: Fri, 22 Aug 2003 09:31:11 -0700 Subject: [Lwapp] lwapp security requirements draft Message-ID: <3F46454F.10501@airespace.com> This is a multi-part message in MIME format. --------------060408000206030406020803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attached is a first pass at a security requirements draft for lwapp. This has been submitted to the ID editor, but I'm also posting it to this list for convenience. Comments welcome. --Scott --------------060408000206030406020803 Content-Type: text/plain; name="draft-kelly-ietf-lwapp-sec-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-kelly-ietf-lwapp-sec-00.txt" Network Working Group S. Kelly Internet-Draft Airespace Expires: February 19, 2004 D. Molnar Legra Systems August 21, 2003 Security Requirements for a Light Weight Access Point Protocol draft-kelly-ietf-lwapp-sec-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 19, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract LWAPP defines the interactions of wireless lan infrastructure components, including access points (APs) and access routers (ARs). The AR represents a centralized point of management control in such infrastructures, implying critical control signalling between APs and ARs. Given the open nature of WLANs, a careful analysis of security threats is required, and appropriate security countermeasures must be defined. This document provides a security analysis and makes recommendations for securing LWAPP Kelly & Molnar Expires February 19, 2004 [Page 1] Internet-Draft LWAPP Security Requirements August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. LWAPP Architecture and Topology . . . . . . . . . . . . . 4 3. WLAN Security Termination . . . . . . . . . . . . . . . . 4 4. WLAN Security Architecture Naming Convention . . . . . . . 5 5. Topological Assumptions . . . . . . . . . . . . . . . . . 5 5.1 Directly Connected . . . . . . . . . . . . . . . . . . . . 6 5.2 Switched Connections . . . . . . . . . . . . . . . . . . . 7 5.3 Routed Connections . . . . . . . . . . . . . . . . . . . . 8 6. Capabilities of Adversary . . . . . . . . . . . . . . . . 10 6.1 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Packet Modification . . . . . . . . . . . . . . . . . . . 10 6.2.1 Packet Injection . . . . . . . . . . . . . . . . . . . . . 10 6.2.2 Packet Deletion . . . . . . . . . . . . . . . . . . . . . 10 6.2.3 Packet Reordering . . . . . . . . . . . . . . . . . . . . 10 6.2.4 Packet Redirection . . . . . . . . . . . . . . . . . . . . 10 6.2.5 Packet Reflection . . . . . . . . . . . . . . . . . . . . 10 6.2.6 Session Replay . . . . . . . . . . . . . . . . . . . . . . 11 6.3 Address Spoofing . . . . . . . . . . . . . . . . . . . . . 11 6.4 MiM Attack . . . . . . . . . . . . . . . . . . . . . . . . 11 6.5 Password Guessing/Dictionary Attacks . . . . . . . . . . . 11 6.6 Corruption of Auxiliary Network Services . . . . . . . . . 11 6.6.1 DCHP Takeover . . . . . . . . . . . . . . . . . . . . . . 11 6.6.2 DNS Takeover . . . . . . . . . . . . . . . . . . . . . . . 11 7. Adversary Goals . . . . . . . . . . . . . . . . . . . . . 11 7.1 Associate Unauthorized AP with Legitimate AR . . . . . . . 12 7.2 Associate Unauthorized AR with Legitimate AP . . . . . . . 12 7.3 De-associate authorized AP and AR . . . . . . . . . . . . 12 7.4 DoS attacks . . . . . . . . . . . . . . . . . . . . . . . 12 7.5 Eavesdropping on AP Control Data . . . . . . . . . . . . . 12 7.6 Modification of AP Control Data . . . . . . . . . . . . . 12 7.7 Eavesdropping on AR Control Data . . . . . . . . . . . . . 12 7.8 Modification of AR Control Data . . . . . . . . . . . . . 13 8. Adversary Scenarios . . . . . . . . . . . . . . . . . . . 13 8.1 Rogue AP . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2 Rogue AR . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3 AP Takeover . . . . . . . . . . . . . . . . . . . . . . . 13 8.4 AR Takeover . . . . . . . . . . . . . . . . . . . . . . . 13 8.5 Passive Adversary between AR and AP . . . . . . . . . . . 13 8.6 Active Adversary between AR and AP . . . . . . . . . . . . 14 9. Countermeasures . . . . . . . . . . . . . . . . . . . . . 14 9.1 Secure Association . . . . . . . . . . . . . . . . . . . . 14 9.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 14 9.3 Secure Discovery . . . . . . . . . . . . . . . . . . . . . 15 9.4 Integrity Verification . . . . . . . . . . . . . . . . . . 15 9.4.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 16 9.4.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 16 Kelly & Molnar Expires February 19, 2004 [Page 2] Internet-Draft LWAPP Security Requirements August 2003 9.5 Anti-replay . . . . . . . . . . . . . . . . . . . . . . . 16 9.5.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 17 9.5.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 17 9.6 Confidentiality . . . . . . . . . . . . . . . . . . . . . 17 9.6.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 17 9.6.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 18 10. Additional Security Requirements . . . . . . . . . . . . . 18 10.1 Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 18 10.1.1 Key Establishment . . . . . . . . . . . . . . . . . . . . 18 10.1.2 Key Naming . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1.3 Key Freshness . . . . . . . . . . . . . . . . . . . . . . 18 10.2 Privilege Separation . . . . . . . . . . . . . . . . . . . 18 10.3 Firewall/NAT Considerations . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . 19 12. Intellectual Property . . . . . . . . . . . . . . . . . . 19 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 19 Full Copyright Statement . . . . . . . . . . . . . . . . . 21 Kelly & Molnar Expires February 19, 2004 [Page 3] Internet-Draft LWAPP Security Requirements August 2003 1. Introduction LWAPP defines the interactions of wireless lan infrastructure components, including access points (APs) and access routers (ARs). For a complete description of this protocol, see [LWAPP]. The primary goal of LWAPP is to centralize much of the non-PHY WLAN processing at the AR, thereby enabling scalable, manageable deployments of lightweight APs. The AR represents a centralized point of management control in such infrastructures, implying critical control signalling between APs and ARs. All WLAN data traffic must transit between ARs and APs as well. Given the security concerns surrounding wireless access, it seems prudent to consider the associated security vulnerabilities and threats, and to define appropriate countermeasures. This document provides a security analysis and makes recommendations for securing LWAPP. 2. LWAPP Architecture and Topology For a complete definition of the LWAPP architecture, see [LWAPP]. For convenience, the following figure is copied from that document: --------------------------------------------------------------------- +-+ 802.11frames +-+ | |--------------------------------| | | | +-+ | | | |--------------| |---------------| | | | 802.11 PHY/ | | LWAPP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA AP AR Figure 1: LWAPP Architecture --------------------------------------------------------------------- LWAPP encompasses control and data traffic flowing bidirectionally between the AP and the AR. Note that some topological subtleties exist which are not called out by the above diagram. These are discussed in the following sections. 3. WLAN Security Termination The IEEE 802.11 specification family [802.11] defines multiple security mechanisms, including WEP, 802.1x, and 802.11i. In Kelly & Molnar Expires February 19, 2004 [Page 4] Internet-Draft LWAPP Security Requirements August 2003 addition, the WiFi consortium defines WPA as an interim step between WEP and 802.11i. In non-LWAPP deployments, these protocols interact with the mobile station (STA) and the AP, and also with an Authentication Server (AS) in the case of 802.1x. LWAPP entails delegation of some or all of the AP's roles in these mechanisms to the AR. For example, WEP associations are historically between STA and AP, but with LWAPP, the association may be between STA and AR if desired. 802.1x associations are historically a 3-way conversation between STA, AP, and AS, but with LWAPP, these are more typically between STA, AR and AS. Hence, the introduction of LWAPP entails modifications to security termination points which may introduce new security concerns. 4. WLAN Security Architecture Naming Convention For convenience, we now define names for some possible WLAN security architectures. This naming is not meant to be exhaustive; we only give a few possible architectures that can help illustrate the security impact of MAC-splitting decisions. These architectures are: SAAP - standalone AP terminates all L2 security ARCH1 - terminate WEP/WPA/802.11i/802.1x at the AR ARCH2 - terminate WEP/WPA/802.11i at the AP, 802.1x at the AR ARCH3 - terminate WEP/WPA/802.11i/802.1x at the AP Note that we could also define an architecture wherein WEP/WPA/ 802.11i are terminated at the AR, and 802.1x is terminated at the AP, but this seems nonsensical, and so it is not defined. Note that LWAPP is irrelevant for the SAAP architecture, but that architecture is included for completeness. 5. Topological Assumptions LWAPP assumes that the AR and AP are within the same administrative domain, i.e. they are owned/controlled by the same entity. LWAPP makes no topological assumptions beyond these, meaning there are several topologies which must be considered for our purposes. These are discussed below, along with the interactions between each topology and different WLAN security architectures Kelly & Molnar Expires February 19, 2004 [Page 5] Internet-Draft LWAPP Security Requirements August 2003 5.1 Directly Connected The first topology we consider is one in which APs are directly connected to an AR: --------------------------------------------------------------------- -------+------ LAN | +-------+-------+ | + + AR + + | +----+-----+----+ | | +---+ +---+ | | +--+--+ +--+--+ | AP | | AP | +--+--+ +--+--+ Figure 2: Directly Connected --------------------------------------------------------------------- In this case, a direct layer 2 connection exists between the AP and AR, and an adversary must penetrate the direct connection in order to access the AP-AR traffic. While such physical access is possible, the risk of such access may be low enough to be acceptable in specific situations. In the case of ARCH1, security for STA-AR data traffic is provided by the WPA/802.11i MAC functionality in addition to physical access control. Note that this effectively provides security for AP-AR data traffic. Security for AP-AR control traffic is not provided by any MAC layer functionality; additional mechanisms must be employed if assurances beyond physical security are desired In the case of ARCH2, security provided by 802.11i/WPA MAC functionality for data traffic is strictly between STA and AP; data and control traffic between AP and AR rely primarily on physical access control. If assurances beyond physical security are desired for this region, additional mechanisms must be employed for both data and control traffic. For example, IPsec may be used between STA and AR to secure AP-AR data traffic, but the issue remains for control traffic. Because 802.1x traffic terminates at the AR, security of this traffic depends on the EAP method used; if a method such as EAP- TLS is employed, then access to the AP-AR traffic is less of a concern Kelly & Molnar Expires February 19, 2004 [Page 6] Internet-Draft LWAPP Security Requirements August 2003 The case of ARCH3 is similar to the case of ARCH2, except now all 802.1x traffic terminates at the AP. This may imply that 802.1x provisioning information is pushed from the AR to the AP, or it may imply that the AP will form separate connections with back-end AAA servers. In any case, physical security provides the primary assurance for communications between AP and the rest of the network. 5.2 Switched Connections --------------------------------------------------------------------- -------+------ LAN | +-------+-------+ | + + AR + + | +----+-----+----+ | | +---+ +---+ | | +--+--+ +-----+-----+ | AP | | Switch | +--+--+ +---+-----+-+ | | +--+--+ +----+ | AP | | +--+--+ +--+---+ | host | +------+ Figure 3: Switched Connections --------------------------------------------------------------------- This case is (almost) functionally identical to the directly connected case. For all practical purposes, a direct layer 2 connection exists between the AP and AR. The primary difference is that other systems may also be "directly" connected to the AR, and intermingling traffic with the AP on that medium. In this case, there are additional security considerations because these systems potentially have access to the AP-AR traffic, and may be indistinguishable from a valid AP or AR In the case of ARCH1, security for STA-AR data traffic is provided by the 802.11i MAC functionality in addition to physical access control. Security for AP-AR control traffic is not provided by any MAC layer functionality; additional mechanisms must be employed if assurances beyond physical security are desired. Note that in this case, Kelly & Molnar Expires February 19, 2004 [Page 7] Internet-Draft LWAPP Security Requirements August 2003 security of control traffic relies on the security of all systems with access to AP-AR traffic In the case of ARCH2, security for the STA-AR data traffic relies on the security of AP-AR data traffic,and both AP-AR data and control traffic rely primarily on physical access control. If assurances beyond physical security are desired, additional mechanisms must be employed for both data and control traffic. For example, IPsec may be used between STA and AR to secure user data traffic, but this does nothing to secure AP-AR control traffic. Because 802.1x traffic terminates at the AR, security of his traffic depends on the EAP method used; if a secure method such as EAP-TLS is employed, then access to the AP-AR traffic is perhaps less of a concern The case of ARCH3 is similar to the case of ARCH2, except now all 802.1x traffic terminates at the AP. This may imply that 802.1x provisioning information is pushed from the AR to the AP, or it may imply that the AP will form separate connections with back-end AAA servers. In any case, physical security provides the primary assurance for communications between AP and the rest of the network; if switches on the subnet are considered untrustworthy, additional mechanisms will be required 5.3 Routed Connections Kelly & Molnar Expires February 19, 2004 [Page 8] Internet-Draft LWAPP Security Requirements August 2003 --------------------------------------------------------------------- +-------+-------+ | + + AR + + | +-------+-------+ | --------+------ LAN | +-------+-------+ | router | +-------+-------+ | -----+--+--+--- LAN | | +---+ +---+ | | +--+--+ +--+--+ | AP | | AP | +--+--+ +--+--+ Figure 4: Routed Connections --------------------------------------------------------------------- This case is considerably different than the direct and switched cases. Routed connections imply a layer 3 connection between the AP and AR. Additionally, there may be other systems on either LAN segment. If there are, this introduces additional security considerations, because these systems have access to AP-AR traffic, and may be indistinguishable from APs/ARs. It is also possible for a mix of links with different security properties to be employed between the AP and AR; some links may even be wireless. Under such circumstances, it may be appropriate to treat the connection between AP and AR as untrusted In the case of ARCH1, security for STA-AR data traffic is provided by the 802.11i MAC functionality. Security for AP-AR control traffic is not provided by any MAC layer functionality; additional mechanisms must be employed if security is desired In the case of ARCH2, security for the STA-AR data traffic relies on the security of AP-AR data traffic. If security is desired, additional mechanisms must be employed for both control and data traffic between the AP and AR. For example, IPsec may be used to secure user data between STA and AR. In the case of 802.1x traffic passing from STA to AR, protection depends on the EAP method used; unencrypted methods such as EAP-MD5 should not be used under these Kelly & Molnar Expires February 19, 2004 [Page 9] Internet-Draft LWAPP Security Requirements August 2003 circumstances The case of ARCH3 is similar to the case of ARCH2, except now all 802.1x traffic terminates at the AP. This may imply that 802.1x provisioning information is pushed from the AR to the AP, or it may imply that the AP will form separate connections with back-end AAA servers. Additional mechanisms beyond physical security should then provide the primary assurance for communications between AP and the rest of the network. 6. Capabilities of Adversary We now enumerate capabilities of adversaries in this setting. Different adversaries may have different mixes of capabilities. When specifying security mechanisms, it is important to state precisely which adversaries are defended against 6.1 Eavesdropping An adversary may read traffic on a link. 6.2 Packet Modification An adversary may modify packets on a link. There are several special cases of this capability 6.2.1 Packet Injection The adversary may add arbitrary packets to the link. These packets are not constrained to follow any particular standard format. 6.2.2 Packet Deletion The adversary may delete a packet from the link; the packet is dropped and never reaches its destination 6.2.3 Packet Reordering The adversary may reorder packets or delay packets indefinitely. 6.2.4 Packet Redirection The adversary may send a packet intended for one recipient to another recipien 6.2.5 Packet Reflection The adversary may re-address a packet to its original sender. Kelly & Molnar Expires February 19, 2004 [Page 10] Internet-Draft LWAPP Security Requirements August 2003 6.2.6 Session Replay The adversary may record messages on a link between two parties and then replay half the conversation later to one of the parties. 6.3 Address Spoofing The adversary may change its network address (e.g. IP or MAC address) arbitraril 6.4 MiM Attack The adversary may pose as an AP or an AR and negotiate a connection that "passes through" the adversary. This adversary may be situated between a legitimate AP-AR pair, or it may terminate one end of the AP-AR connection itself 6.5 Password Guessing/Dictionary Attacks In scenarios where passwords are used, the adversary may attempt to guess passwords and employ password dictionaries. 6.6 Corruption of Auxiliary Network Services 6.6.1 DCHP Takeover The adversary may take over a DHCP server on any subnet it likes. Alternatively, the adversary sets up its own DHCP server and responds more quickly than the "real" DHCP server 6.6.2 DNS Takeover The adversary may take over a DNS server or respond more quickly than the real DNS server 7. Adversary Goals This section contains an overview of some likely goals of an adversary. While we cannot always know with certainty all the ways in which an adversary might behave, we can anticipate certain actions based on a knowledge of higher-level objectives in conjunction with the constraints of the problem space. We should note that it is sometimes difficult to anticipate precisely how exploits might be combined to compromise a system, and so we must exercise caution when considering dismissal of some goal which, taken by itself, might seem trivial and uninteresting. With this in mind, we review the following list of likely adversarial objectives Kelly & Molnar Expires February 19, 2004 [Page 11] Internet-Draft LWAPP Security Requirements August 2003 7.1 Associate Unauthorized AP with Legitimate AR Such APs may be used in MiM attacks, or to facilitate unauthorized network access 7.2 Associate Unauthorized AR with Legitimate AP Unauthorized ARs may be used in MiM attacks on 802.1x, or may be used to associate stations with unauthorized networks 7.3 De-associate authorized AP and AR This attack could be used as part of a MiM scheme (de-associate authorized device, re-associate with unauthorized device), or as a DoS 7.4 DoS attacks For this category, we concentrate on DoS attacks which are LWAPP- specific, such as de-associating an AP-AR pair, corrupting LWAPP protocol setup packets, and other actions which disrupt AP-AR (and by extension, STA-AR) communications. This class does not include general DoS attacks such as LAN saturation, ping floods, etc. which LWAPP cannot address 7.5 Eavesdropping on AP Control Data AP control data includes AP configuration, which might contain credentials, security parameters, firmware, or RF parameters, to name a few things. Knowledge of such values could provide an attacker with facilitating information. 7.6 Modification of AP Control Data Modification of AP control data may permit an attacker to take control of the AP to varying degrees. This might be used to facilitate DoS or MiM attacks, or takeover of an AP (if control data includes AP firmware) 7.7 Eavesdropping on AR Control Data AR control data includes AR configuration, which might contain credentials, security parameters, and various other things. Knowledge of such values could provide an attacker with facilitating information Kelly & Molnar Expires February 19, 2004 [Page 12] Internet-Draft LWAPP Security Requirements August 2003 7.8 Modification of AR Control Data Modification of AR control data may permit an attacker to take control of the AR to varying degrees. This might be used to facilitate DoS or MiM attacks 8. Adversary Scenarios We now define specific adversary scenarios in which a network is attacked. Documents defining LWAPP security mechanisms should be able to "walk through" how the mechanism interacts with each of these scenarios. In particular, adversary goals that the mechanism does and does not permit in each scenario should be spelled out. 8.1 Rogue AP The adversary obtains a "clean" AP and connects to the network without being authorized by the network administrator 8.2 Rogue AR The adversary obtains a "clean" AR and connects to the network without being authorized by the network administrator. 8.3 AP Takeover In the Rogue AP scenario, the AP has no preexisting relationship with any STA or AR on the network. In the AP Takeover scenario, an adversary gains control of an AP with existing security relationships. This takeover may occur due to password leakage, buffer overflow in the AP software, compromise or injection of an AP firmware download, or other reasons 8.4 AR Takeover In the Rogue AR scenario, the AR had no preexisting relationship with any STA or AR on the network. In the AR Takeover scenario, an adversary gains control of an AP with existing security relationships. This takeover may occur due to password leakage, buffer overflow in the AR software, or other reasons 8.5 Passive Adversary between AR and AP In this scenario, an adversary has the capability of eavesdropping on any link between AR and AP, but does not have the capability to modify packets Kelly & Molnar Expires February 19, 2004 [Page 13] Internet-Draft LWAPP Security Requirements August 2003 8.6 Active Adversary between AR and AP In this scenario, an adversary may eavesdrop and/or modify packets on any link between AR and AP. Such modification may include injection, deletion, reflection, reordering, or replay. The attacker may effect a MiM attack or a DoS attack 9. Countermeasures 9.1 Secure Association Just as strong authentication is a precursor for integrity verification, a secure association mechanism is a precursor to authentication. Assuming that an AR is always situated between an AP and the wired network, prevention of Rogue AP/AR deployment comes down to a single question: how do an AR and AP determine that they should associate with each other? There must be a mechanism for forming a "secure association" between AR and AP that has these properties 1) Association between an AR and AP occurs only when intended by the network administrator 2) Once formed, the secure association can only be torn down if the administrator authorizes it, the AP fails, or the AR fails; no third party can cause disassociation of the AR and AP There are numerous ways in which a secure association might be created, and a detailed discussion of such mechanisms is beyond the scope of this document. However, such a mechanism is a prerequisite to AP-AR authentication 9.2 Authentication Strong AP-AR authentication is a precursor to per-packet integrity verification, so to fully understand its impact, we must examine its benefits alone and in conjunction with integrity verification. In this section, we review it as a stand-alone mechanism only - integrity verification is reviewed fully in section 6.4 - Associate Unauthorized AP with Legitimate AR (7.1) - Associate Unauthorized AR with Legitimate AP (7.2) - De-associate authorized AP and AR (7.3) This provides protection against the following adversary scenarios: Kelly & Molnar Expires February 19, 2004 [Page 14] Internet-Draft LWAPP Security Requirements August 2003 - Rogue AP (8.1); if an AP-AR association is strongly authenticated, the rogue AP cannot form an unauthorized association. - Rogue AR (8.2); if an AP-AR association is strongly authenticated, the rogue AR cannot form an unauthorized association. Again, we must emphasize that due to the fact that it is required for per-packet integrity verification and reliable cryptographic key exchange, strong authentication has significant consequences beyond these, and it must be considered in that context. Integrity verification is reviewed below in section 6.x. 9.3 Secure Discovery In addition to methods for creating a secure association, AP's and AR's must have some method for dynamically discovering such associations. An AP deployed in a network must discover at least one AR with which it has established a secure association. The mechanisms for this discovery should not return information concerning ARs that cannot form a secure association with the AP. An adversary should also be unable to use discovery to switch one AR with another AR that also can securely associate with the AP. 9.4 Integrity Verification At minimum, integrity verification mechanisms assure us that the data has not been modified in transit. There are simple integrity verification mechanisms which require no prior relationship between the endpoints, e.g. a CRC checksum. While such mechanisms are helpful in detecting transmission errors and the like in a non- hostile environment, they are of little use in the face of an adversary. This is because the adversary can modify the data and then simple recompute the Integrity Check Value (ICV) In order to protect against such malicious tampering, we must have a mechanism for ICV computation which is not available to the attacker. Typically, this is accomplished by adding some sort of secret which is shared only by the authorized endpoints into the ICV computation. An example of such a ICV method using a shared secret is HMAC-SHA1 HMAC [3] Regardless of whether integrity-related secrets are manually configured or dynamically created, associated integrity mechanisms have an added benefit: they provide data origin authentication. This means that when we verify the ICV associated with the data, not only are we sure that the data was not modified in transit, but we also Kelly & Molnar Expires February 19, 2004 [Page 15] Internet-Draft LWAPP Security Requirements August 2003 have some assurance regarding its origin Per-packet integrity verification may be applied to all traffic, or it may be selectively applied to control traffic or data traffic. Different attacker goals and scenarios are affected, depending on our choice in this regard. These are treated separately below. 9.4.1 Control Traffic Integrity protection for LWAPP signalling interferes with the following adversary goals - DoS attacks (7.4); some DoS attacks are prevented due to the data origination verification provided as a benefit of integrity verification - Modification of AP Control Data (7.8); the ICV prevents modification of in-transit packets, and also prevents injection of invalid packets. This provides protection against the following adversary scenarios: - Rogue AP (8.1); this is prevented due to the data origination verification provided as a benefit of integrity verification. - Rogue AR (8.2); this is prevented due to the data origination verification provided as a benefit of integrity verification. 9.4.2 Data Traffic Integrity protection for LWAPP data traffic interferes with the following adversary goals: - Modification of user Data (7.6); the ICV prevents modification of in-transit packets, and also prevents injection of invalid packets This provides protection against the following adversary scenarios: - Active Adversary Between AR and AP (8.6); this is prevented due to the data origination verification provided as a benefit of integrity verification. 9.5 Anti-replay This feature entails a mechanism for preventing the replay of valid traffic. It is typically implemented through inclusion of an Kelly & Molnar Expires February 19, 2004 [Page 16] Internet-Draft LWAPP Security Requirements August 2003 authenticated sequence number in each packet. 9.5.1 Control Traffic Integrity-protected anti-replay protection for LWAPP control traffic interferes with the following adversary goals: - Replay of AP Control Data (7.8); replayed control data could be used to cause the AP to revert to a previous (exploitable) state This provides protection against the following adversary scenarios: - Rogue AP (8.1); if an adversary can replay discovery and association packets, it may be able to impersonate a valid AP. - Active Adversary Between AR and AP (8.6) 9.5.2 Data Traffic Integrity-protected anti-replay protection for LWAPP data traffic interferes with the following adversary goals - Replay of AP Control Data (7.8); replayed control data could be used to cause the AP to revert to a previous (exploitable) state This provides protection against the following adversary scenarios: - Active Adversary Between AR and AP (8.6) 9.6 Confidentiality Data confidentiality involves rendering the data unreadable to all but the authorized parties. It should be noted that data confidentiality cannot be effectively provided without also providing a data integrity function. 9.6.1 Control Traffic Confidentiality protection for LWAPP control traffic interferes with the following adversary goals - Eavesdropping on user data (7.5); an adversary could use knowledge gained from control data to facilitate an attack on the AP/AR This provides protection against the following adversary scenarios: Kelly & Molnar Expires February 19, 2004 [Page 17] Internet-Draft LWAPP Security Requirements August 2003 - Passive Adversary Between AR and AP (8.5) - Active Adversary Between AR and AP (8.6) 9.6.2 Data Traffic Confidentiality protection for LWAPP data traffic interferes with the following adversary goals - Eavesdropping on user data (7.5); an adversary could use knowledge gained from control data to facilitate an attack on the AP/AR This provides protection against the following adversary scenarios: - Passive Adversary Between AR and AP (8.5); - Active Adversary Between AR and AP (8.6) 10. Additional Security Requirements 10.1 Cryptographic Keys 10.1.1 Key Establishment Confidentiality and integrity verification mechanisms require cryptographic keys. It is possible to establish such keys via manual configuration or dynamic key exchange. Given that some deployments may be very large, scalability issues associated with manual configuration imply the need to support dynamic key establishment mechanisms along with manual mechanisms 10.1.2 Key Naming Each key in a security mechanism must be explicitly named. This name facilitates the management and revocation of keys 10.1.3 Key Freshness Keys in a security mechanism should be refreshed. The exact details of when to refresh may depend on adminstrator policy and the specific security mechanisms used 10.2 Privilege Separation Takeover of any component of the system (STA, AP, or AR) should Kelly & Molnar Expires February 19, 2004 [Page 18] Internet-Draft LWAPP Security Requirements August 2003 compromise the minimum possible number of additional components. In particular, compromise of an AP should yield no key material or other data protecting the control or data transport of any other AP 10.3 Firewall/NAT Considerations Security mechanisms should strive to avoid bad interactions with firewall and NAT techniques. When interactions exist, they should be clearly documented 11. Security Considerations The topic of this document is LWAPP security requirements, so no separate security considerations discussion is required 12. Intellectual Property Since this is strictly an informational requirements document, there are no associated intellectual property rights 13. Acknowledgements We thank Russ Housley for useful discussions about security protocol requirements. Of course any shortcomings are our own. [DM] References [1] "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [2] "IEEE Std 802.11i/3.0: Specification for Enhanced Security", November 2003. [3] "HMAC: Keyed-Hashing for Message Authentication", February 1997, . Authors' Addresses Scott Kelly Airespace 110 Nortech Parkway San Jose, CA 95134 Phone: +1 408-635-2022 EMail: skelly@airespace.com Kelly & Molnar Expires February 19, 2004 [Page 19] Internet-Draft LWAPP Security Requirements August 2003 David Molnar Legra Systems 3 Burlington Woods Dr Burlington, MA 01803 Phone: +1 781-272-8400 EMail: dmolnar@legra.com Kelly & Molnar Expires February 19, 2004 [Page 20] Internet-Draft LWAPP Security Requirements August 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kelly & Molnar Expires February 19, 2004 [Page 21] --------------060408000206030406020803-- From alper@docomolabs-usa.com Mon Aug 25 05:25:34 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Sun, 24 Aug 2003 21:25:34 -0700 Subject: [Lwapp] lwapp security requirements draft In-Reply-To: <3F46454F.10501@airespace.com> Message-ID: Hello, > Attached is a first pass at a security requirements draft for lwapp. > This has been submitted to the ID editor, but I'm also posting it to > this list for convenience. Comments welcome. This is a good document listing potential security threats related to AP-AR separation and carrying any protocol signaling between the two. I presume these are architectural requirements, not specifically for LWAPP protocol to solve. For handling these threats, isn't relying on physical security or using cryptographic security (e.g., at L2 by 802.11i, or at L3 by IPsec) sufficient? Alper From scott@airespace.com Mon Aug 25 17:18:04 2003 From: scott@airespace.com (Scott G. Kelly) Date: Mon, 25 Aug 2003 09:18:04 -0700 Subject: [Lwapp] lwapp security requirements draft In-Reply-To: References: Message-ID: <3F4A36BC.5050808@airespace.com> Hi Alper, Alper Yegin wrote: > Hello, > > >>Attached is a first pass at a security requirements draft for lwapp. >>This has been submitted to the ID editor, but I'm also posting it to >>this list for convenience. Comments welcome. > > > This is a good document listing potential security threats related to AP-AR > separation and carrying any protocol signaling between the two. > > I presume these are architectural requirements, not specifically for LWAPP > protocol to solve. For handling these threats, isn't relying on physical > security or using cryptographic security (e.g., at L2 by 802.11i, or at L3 > by IPsec) sufficient? The purpose of the document is to clearly elucidate the security issues/requirements that result from the deployment of lwapp-like architectures. On this basis, we can evaluate potential solutions, such as the ones you suggest. It is up to the interested participants to decide if what you suggest is sufficient or not. In my view, running IPsec between the AP and AR would solve nearly all the security problems one might encounter in lwapp deployments. One problem with this approach is that IPsec is anything but lightweight, though, so it will likely not be acceptable to some. That is why we need to have this discussion. Scott From kempf@docomolabs-usa.com Tue Aug 26 19:31:46 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Tue, 26 Aug 2003 11:31:46 -0700 Subject: [Lwapp] CAPWAP BOF Minutes Message-ID: <025301c36c00$4e750ec0$806015ac@dclkempt40> Control and provisioning of the Wireless (CAPWAP) BoF ====================================================== Session: Friday, July 18, 2003 at 0900-1130 BoF Chairs: Dorothy Stanley (dstanley@agere.com) James Kempf (kempf@docomolabs-usa.com) Agenda Discussion: Chairs Accepted with no comment from the room. Topic 1: Overview by James Kempf Problem statement discussion focused mainly on the 802.11 network installation and management. It was mentioned that currently installation of the 802.11 is very expensive and complex. Also, the management of 802.11 access points is difficult especially the interactions between the Access Routers (ARs) and Access Points (APs). Also, there are no tools available today for the same. The primary reason for chartering this BoF was difficulties in large deployments. Currently there is no standard way for establishing the trust relation between the APs and ARs and also no mechanism for centrally managing configuration of APs. There is no mechanism available for the prediction of potential problems until they are encountered. Radio resources are unmanaged and lead AP overload unlike in cellular systems. Handovers become very complicated because of security reasons. In past also, there were a few attempts on this subject. Draft on IAPP never became BoF. It is really an IP protocol to carry state information between APs after handover (1995). The CRAPS BoF in 2000 covered many areas including AP control which resulted in to Seamoby WG, but AP control was dropped because it was perceived to be a Layer 2 issue. The main reason on taking CAPWAP work in IETF now is growing interest in 802.11 and the need for IP protocols to provide the support. The access point was discussed in brief and the architectural difference between the AP as a Layer 2 and Layer 3(L3) device was given. ======================================================================= Topic 2: LWAPP Architecture by Pat Calhoun The intent of having this work in the IETF was discussed in brief. The LWAPP architecture includes mainly two components, AR and AP. The LWAPP reflects interface between the APs and ARs. Currently there is no standard protocol between the ARs and APs. So standardizing LWAPP would benefit for ensuring interoperability. The goal is to reduce the amount of code and have light APs. Centralized security functions in AR seems preferable. The protocol should be extensible to access points other than 802.11 as well. Division of the functionality for the AP and AR was discussed wrt to 802.11 architecture. The AR basically handles the data and management of the 802.11 while the AP is mainly responsible for control of the host. The LWAPP assumes that the MAC is split between the AP and the AR, reducing the functions required on the AP. The following components of the LWAPP were discussed: 1. Control channel management: Includes discovery and AR-AP session establishment, heartbeat and key updates. Plug and Play type of interface and extra provisioning are required. Failover mechanism is another important factor to be considered. 2. AP Configuration: Configure response, configure updates, statistics update and the reset request were discussed. 3. Mobile session Management: Pushes a specific rule to the AP. Operations like authentication etc. are defined, allowing to add and delete the host. 4. Firmware management: During the AP-AR session establishment phase, the peers exchange firmware versions. In case of unmatched version at the AP, the AR can securely download the image to the AP. 5. Transport Services: Ethernet and IP (future non-IP support) are options for LWAPP transports. For each transport, discovery, frame of packets are considered. It is assumed that all LWAPP peers have a certificate. During the AP-AR session establishment phase, a session key is exchanged and all control packets are subsequently encrypted using AES-CCM. A rekey message exists in order to allow the AP (or AR) to create a new session key. Points raised on the mailing list included: - Where does encryption occur - LWAPP discovery at L3 - LW data message be secured - Used certificates or shared key Comments: - Asked clarification on the IPR statement mentioned in the draft. Free license has been issued to the IETF related to LWAPP work in addition to three other IPRs specific for LWAPP. ======================================================================= Topic 3: Use of SNMP or DHCP for AP Control by Marcus Brunner Marcus Brunner argued there are two major issues in the CAPWAP scenario, which are AP control/management and 802.11 frame tunneling. The tunneling part makes sense because of security and multiplexing issues. But, since the current draft doesn't have IP transport, he was not sure the tunneling part is an IETF issue. For control/management part, SNMP is just fine. But AP needs IP address in this case. DHCP is also fine, but it doesn't have functions for coniguration information read back and statistics report from AP. He agreed on the significance of the proposed work (LWAPP) itself, and recommended to include a work on IP transport. It was recommended in the end that DHCP and/or SNMP works fine for the configuration, control, and management. No WG discussion took place on this topic. ======================================================================= Topic 4: Access point Discovery by Inderpreet Singh The applicability of this talk is specific to L3 only. Per AR, there may be 100s of access points. Goal is to have plug and play type of interface. AR may or may not matter but light APs are desirable. Discovery comes in to the picture when the AP needs to find its AR from the available list of ARs. It can be either at bootup or dynamic discovery. Potential solution could be - SLP based discovery: Unicast, multicast SLP based discovery scenarios were discussed along with the pros and cons. - DHCP based discovery: This option was discussed with some pros and cons. - Static configuration Next step should include security and authentication options in addition to the discovery. Comments: - DHCP database is not dynamically updated that may be an issue. - Is there any support for IPv6 since current work seems like for IPv4 only. The reply was that IETF work should cover IPv6 as well but as a starting point, the focus is just IPv4 because that's what the vendors want. ======================================================================= Topic 5: Security Issues by David Molnar David Molnar introduced three parts, radio control, session management, and data tunneling, which need to be protected from attacks. Especially for data tunneling, he pointed out the choice we need to make carefully is MAC termination point. Then, he stated the constraints and types of attacks clearly for discussion. He explained the issues in secure associations between AP and AR. After the association, secure transport is used to prevent attacks. For the secure transport, he argued pros. and cons. of several schemes including IPSec, TLS, CMS, and a custom scheme for this purpose. Then, he presented four scenario for provisioning associations. He also pointed out those security scheme might lead AP to heavyweight, which contradict the initial purpose of this work. Finally he suggested future directions and possible solutions. Comments: - This presentation is not specific to wireless and may be very generic. It should be common to all types of devices. Reply is that the main focus is what has been done so far but it is agreed that the scope may be larger than expected. - Work in SEND WG may be also related. It was clarified that it is mainly for the host. But the cryptographic work can be reused. - What is really light-weight AP? It was mentioned that most likely vendors will split the functionality between the hardware, software or combination of both. Mobility and security demands vertical solutions which can't be met by a single standards body. Light weight APs are desired and they can be cheap and dumb devices. Reference to draft-irtf-aaaarch-handoff-02 and draft-mistra-seamoby-context drafts were given related to this subject. - It seems the problem targeted to solve is focused toward basic configuration for cheap (other) Ethernet devices. What is really different here from what has been expected for other devices. It was clarified that the current AP has a narrow view. This BoF is expected to make AP having broader view. This is lot more than just configuration. - Taking away burden of the management and config from the AP is useful for the lightweightness. It was clarified that the perspective of a functionality for light vs heavy might be different everywhere. - Since the focus is on the provisioning and more toward real-time support, opinion on QoS was asked. One of the BOF co-chairs pointed toward the current mailing list discussion on this topic. - Question was asked on the overlap between the IAPP and this work. It was mentioned that there is very minimal overlap. Focus on provisioning and managing is completely different from the IAPP. It's a different problem and this is completely outside of the IEEE. - Is there any formal liaison between the IEEE and IETF? It was clarified that Dorothy Stanley (co-chair) is the current liaison. The request is basically coming from the vendors to work on this problem statement. ====================================================================== Topic 6 - AAA, James Kempf for Bill Arbaugh James Kempf presented AAA issues on behalf of Bill Arbaugh. He pointed out mobility and security demand vertical solutions which can't be met by single (IEEE or IETF) standards body. An example of the objectives is secure movement of STA security associations considering 802.11f (IAPP) and 802.11k. - Question: Is IAPP IPR-encumbered? Answer: Check IEEE. ======================================================================= Topic 6: Charter Discussion by all The rationale was given by one of the co-chairs on why IETF should take on this particular work item. Lightweight AP model could simplify deployment, security, and maintenance of 802.11 networks. Multiple vendors are interested in a standardized, secure protocol for lightweight access points so their routers, switches, and access points interoperate. It was mentioned that APs have enough L3 characteristics and hence this work may be suitable for the IETF. The following items are discussed as a part of the proposed charter: 1. Independent of wireless link protocol 2. Discovery of a CAPWAP manager (AR, IP addressable switch) 3. Acquisition of APs by CAPWAP manager 4. Configuration and monitoring of wireless link by CAPWAP manager 5. Partially or fully terminate the wireless MAC layer at the CAPWAP manager 6. Control of AP host load 7. Security for CAPWAP signaling Next Step: As a part of finalize charter topic, the following comments were received from the WG: - Light weight v.s. heavy weight? - Architecture issue should be addressed - The same thing happened in ethernet hub 8-10 years ago - The goal is centralized control of APs - It's not just light weight AP problem - That's why CAPWAP named, LWAPP is one solution - Trying to specify interfaces between AP and AR, splitting MAC - The purpose of the protocol is simple configuration, centralized AP management. Vendors want interoperability solutions. - 2 node architecture (AP,AR) or 3 node architecture (+other node)? Chair: 2 node architecture - The Ops AD questioned whether this work is well aligned with the IEEE work. Dorothy indicated that she thought this work is currently in the alignment with the IEEE expectations. - The recommendation was that since the security of the signalling be discussed here. It is good to have input from the Security AD as well. - Asked the clarification of point 1 (Independent of wireless link protocol). It was clarified that the current intent is to have a protocol which is basically independent of the radio network and includes support of non-IEEE links as well. - If the current focus is on provided L3 solution, why the emphasize on only IEEE at this time. The reply was that 802.11 is of more interest today. This is just viewed as a near term requirements on this. - The question raised whether there is any potential interest from the 3GPP2 as well. The co-chair mentioned that 3GPP2 input on this work would be of interest. - Clarify point 3 and 4. Any real time function will be in the AP. Other wireless technology may not be that simple to fit in here. - In the clarification of point 6 above, it was mentioned that CAPWAP requires mobility as well. It was agreed in the sense of the definite overlap for the context transfer. - It was clarified that although the security of the signaling is mentioned in the charter, it is also applicable to the data traffic for the network leg in question. Also, both, IPv4 and IPv6 are included in the scope and this BoF will cover only L3 related work. - It seems it is not clear why the split of MAC layer at the CAPWAP manager is in the items list since it is basically Layer 2 issue. No clarification was given on this point. - Ops AD basically compared this problem domain with the AAA/Diameter as an example and suggested that this BoF needs to identify exactly what should be done vs what everyone else think what this BoF/WG should be doing. Hence, it is essential to understand this difference well. BoF Conclusion 1. Should a WG be formed in order to look at design protocol for CAPWAP? This was agreed by the group. 2. Should above bullets (items) become the basis of the charter discussion on the list. There was 60/40 split on the agreement (mostly agreed) The conclusion of this BoF was to continue work as a BoF and have further mailing list discussion. If there is an enough interest, it will be a meeting in the next IETF meeting (IETF-58). From kempf@docomolabs-usa.com Fri Aug 29 20:21:32 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Fri, 29 Aug 2003 12:21:32 -0700 Subject: [Lwapp] Proposed WG Charter Message-ID: <035501c36e62$c1622170$956015ac@dclkempt40> Folks, Below is a charter for the WG that Dorothy and I would like to propose to Randy. Please send comments if you have any. jak +++++++++++++++++++++++++++++++++++++++++++++++ Control and Provisioning of Wireless Access Points (CAPWAP) =============================================== Area: ----- OPS Chairs: ------- TBD Mailing List: ------------- List: lwapp@frascone.com Subscribe: lwapp-request@frascone.com Body: subscribe in Subject line Archive: http://mail.frascone.com/pipermail/public/lwapp/ Description of Working Group: ----------------------------- As the size and complexity of IEEE 802.11 wireless networks has increased, problems in the deployment, management, and usability of these networks have become evident. draft-calhoun-capwap-problem-statement-00.txt describes some of those problems. In addition, security considerations have become increasingly important as IEEE 802.11 networks have been deployed in situations where their use in accessing sensitive data must be restricted for business or other reasons. While there are many possible approaches to solving these problems, most of them involve IP-level protocols in some fashion. To the extent changes to existing IETF protocols are necessary or new IP-level protocols must be standardized to facilitate interoperability, this work is an appropriate topic for the IETF. The charter of the CAPWAP Working Group is to investigate and design a protocol for the purpose of simplifying the deployment, management, and usability of IEEE 802.11 wireless networks. The Working Group will attempt to utilize existing IETF protocols where possible, but will engage in new design if necessary. The Working Group's designs will focus on the "split AP" architecture. The split AP architecture centralizes processing of access point (AP) management functions, such as inter-AP configuration and control, and non-realtime host functions, such as data transport and host authentication, in a management entity, typically an access router (AR). The IEEE 802.11 APs continue to perform real-time host functions. The split AP architecture does not involve any changes in IEEE 802.11 standards, since the IEEE 802.11 specification says nothing about the architecture of the IEEE 802.11 access point. This new architecture has been adopted by many manufacturers, each with some variation. Creating an interoperable protocol between the AP and the AR will benefit the network operator community by allowing operators to build networks with equipment from a collection of vendors. Specific Working Group work items are: - Clear problem statement and description of the split AP architecture, - CAPWAP security requirements, defining the needs for security between the AP and the AR, both for host data transport and for AP-AR signalling and control, - A protocol for implementing the split AP architecture, including the following functionality: . Discovery of ARs by APs (this work should point to existing IETF standards, if possible) . Auto-organization of APs and ARs into a managed wireless access network, including failover if an AR should fail, . A tunneling protocol for IEEE 802.11 non-realtime host-related signalling and data between the AP and the AR, . Support for configuration of the AP by the AR, including secure download and booting of code to the AP (some aspects of this task may involve existing IETF standards), . Security for both tunneled host data and AR-AP signaling, as necessary to address the requirements (this work may involve utilizing existing IETF standards). The intent of the CAPWAP Working Group is to complete the protocol specification as quickly as possible and to serve as a forum for facilitating the testing of interoperability, in typical IETF fashion. While not specifically a work item, the Working Group will attempt to make all designs as independent of the IEEE 802.11 radio protocol as possible, so that the protocol might, in the future be used with other radio protocols. However, in any situation where a tradeoff between simplicity/speed of design completion and extensibility is required, the Working Group will opt for the former. The Working Group will also co-ordinate closely with the IEEE 802.11 WG. Specific nongoals of this work are: - Support for general, inter-subnet micromobility, - Interoperable APIs for downloaded AP code images, - Any IP-layer work that would require changes to the IEEE 802.11 MAC layer, - Dependence on yet to be approved IEEE 802.11 work or drafts, - Support for an inter-AP communication protocol, like IEEE 802.11f, - Direct joint development of protocols with the IEEE 802.11 WG. Working Group protocol documents and the security requirements will be sent to the Security Area Advisory Group (SAAG) for review prior to submission to the IESG. Goals and Milestones: --------------------- Mar. 2004 Complete problem statement draft and architecture description and submit to IESG for publication as Informational. Mar. 2004 Complete security requirements and submit to SAAG for review. Submit to IESG for publication as Informational when SAAG review is complete. Nov. 2004 First draft of CAPWAP protocol complete and ready for review. Mar. 2005 Complete CAPWAP protocol and submit to SAAG for review. Submit to IESG for publication as Proposed Standard when SAAG review is complete.