Subject: RE: [Seamoby] LWAPP

From: [email-masked]
Date: Tue, 8 Apr 2003 10:45:45 -0400

Hi Pat:

A related question on implication of LWAPP draft. With this document in place, can the WG assume in other protocol designs (e.g. CARD) that AR to AP associations and security issues are to be addressed by a dedicated protocol such as LWAPP.

Hemant

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Tuesday, April 08, 2003 8:33 AM
To: Alper Yegin
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Glen Zorn; [email-masked]
Subject: Re: [Seamoby] LWAPP

My apologies for the latency... just catching up to e-mail now.

On Wed, 2003-04-02 at 19:31, Alper Yegin wrote:
> > No, it's does alot more than just configure APs. The information
> > provided in the protocol can provide many additional features, include
> > fast handoffs, creating a secure interface between the AP and the AR,
> > etc.
> 
> I don't see any fast handoffs information carried in the draft.
> 
A foobar on my part. There is a message between the AP and the AR that
is used to communicate a trigger. Used with the signal strength in the
message (which is already in the draft), it can be used by the AR to
determine a mobile's current point of attachment.

I put out the document rather hastily, but will follow up with another
version that includes this (and the formatting problems).

> I'm not sure
> what exactly you mean by "secure interface", but based on my reading of the
> draft the only security is for protecting this protocol's packets between
> the AP and the AR. And this is not an additional feature but a requirement
> on the protocol.

Correct - that is the secure interface I mentioned. It is assumed that
the user will protect his/her own traffic... and that the AR will
enforce whatever policy it has defined. LWAPP was not intended to
replace end-to-end security, but securing that interface *is* a
requirement, not an additional feature. A malicious AP can do very nasty
things to an AR.

> > 
> > Further, the market has made it pretty clear that they no longer want
> > smart APs that have to be managed individually. They want a central
> > point of control, with remote interfaces. But this is a market issue,
> > not a standards one.
> 
> This makes sense. But is there any difference between your proposed protocol
> and SNMP in this context?

Sure, let me explain.

What we've heard from our customers is that they are tired to managing
APs scattered throughout their networks (oh, and it's clear the industry
is moving in this direction, these are not just my own ramblings). The
issue SNMP in the AP is that it does require the administrator to touch
the device. People want a secure plug and play solution. If SNMP is on
the box, you must configure the community string (and user in the case
of v3), and this security relationship is one that must be administered
over the course of the device's lifetime. The market is pretty clear in
the fact that it wants an AP that can auto-discover ARs and establish a
security relationship w/o any administrator involvement. The draft's use
of certificates provides this feature, but I agree that a shared secret
mechanism should probably  be defined as well.

PatC

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

---

From: Pat Calhoun <[email-masked]>
Date: 08 Apr 2003 07:49:14 -0700

> A related question on implication of LWAPP draft. With this document in place, can the WG assume in other protocol designs (e.g. CARD) that AR to AP associations and security issues are to be addre…

No. The draft is an individual contribution. There is nothing in the
charter to cover such work. First we need to focus on our existing
milestones, but if the WG makes progress and determines that something
such as LWAPP makes sense, then we can discuss it at that time. It could
also be that LWAPP really belongs in another area/WG.

The goal of the document is to start discussions in this space. I
believe one of the issues in the market is that there are many WLAN
switches that will become available, and it would be in the market's
best interest to standardize that interface.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: 08 Apr 2003 08:26:05 -0700

<WG chair hat off>

If the designs of current protocols would be simpler with such an
approach, then you could always make an argument for it... but I agree
with the chair in his comments below :)

</WG chair hat on>