Subject: [Seamoby] LWAPP

From: Pat Calhoun <[email-masked]>
Date: 02 Apr 2003 11:37:00 -0800

All,

Some of us have been working on an AP-AR protocol, which we've called
Light Weight Access Point Protocol. The protocol defines a mechanism
whereby a "remote radio" with limited intelligence (AP) can provide
service through an access router (AR). It became clear at our last
meeting that simply ignoring the AP-AR interface would not lead to
interoperability, so I thought it would be appropriate to submit this
document for comments on this list.

I have sent the draft to the secretariat, but an early version is
available at:
http://www.airespace.com/ftp/draft-calhoun-seamoby-lwapp-00.txt

I do, however, wish to apologize in advance for the formatting. We
started with the word template, and found that there is no way to
convert back to text... I should have known better. I will follow up
with another version that will address the formatting issue, in addition
to any comments received on the list.

Comments are, of course, welcomed.

Thanks,

PatC

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 02 Apr 2003 17:38:45 -0800

As I understand, this protocol should be used for configuring an AP, and
getting stats from it. Isn't SNMP sufficient for that?

Here is another proposed protocol that is needed because of AP-AR
separation:

draft-yegin-l2-triggers-00.txt

alper

---

From: Pat Calhoun <[email-masked]>
Date: 02 Apr 2003 18:09:44 -0800

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.

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.

PatC

---

From: Alper Yegin <[email-masked]>
Date: Wed, 02 Apr 2003 19:31:08 -0800

> fast handoffs, creating a secure interface between the AP and the AR,

I don't see any fast handoffs information carried in the draft. 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.

> point of control, with remote interfaces. But this is a market issue,

This makes sense. But is there any difference between your proposed protocol
and SNMP in this context?

alper

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 07 Apr 2003 14:00:50 +0200

I agree with Alper. It seams that SNMP is just fine for that.
It was designed for small devices, meanwhile it is even secure, was meant 
for a manager )AR in your case) having a number of agents (AP).

Marcus

>> Comments are, of course, welcomed.

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus

---

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

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

On Wed, 2003-04-02 at 19:31, Alper Yegin wrote:
> 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

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.

> 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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 08 Apr 2003 15:58:57 -0700

> version that includes this (and the formatting problems).

If you are talking about carrying L2 event notifications around, please see:

http://ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt

How does what you have in mind compare/relate to the above draft?

> mechanism should probably  be defined as well.

If I'm understanding this right, the problem is that SNMP does not know how
to use certificates for authentication.... I don't know how hard it is to
solve this if it is needed as you described....

alper