Subject: [Capwap] Taxonomy doc

From: "Malini Raghavendra" <[email-masked]>
Date: Thu, 15 Apr 2004 12:49:11 +0530

Hello All,
I would like to get clarification on the below statement [Reference: Page
23 v01].
The document extract is given below.
"In most cases, since WTP devices are IP-addressable,
 any of the direct connection, L2-switched, or
   L3-routed topologies of Section 2.2 can be used."

With respect to the above statement,I would like to know,
When i implement AC to support all the 3 modes(direct connection,
L2-switched, or
   L3-routed), is it possible that same AC is connected by L2 with one WTP
and L3 connected with another WTP?

Because in Page 16, Figure 4 direct connection as well as switch connection
is shown whereas the Figure 5 does not have such combination of topology in
a single AC.

Thanks
Malini Raghavendra

                      capwap-request@fr                                                                    
                      ascone.com               To:       [email-masked]                               
                      Sent by:                 cc:                                                         
                      capwap-admin@fras        Subject:  Capwap digest, Vol 1 #204 - 5 msgs                
                      cone.com                                                                             

                      04/14/2004 09:30                                                                     
                      PM                                                                                   
                      Please respond to                                                                    
                      capwap                                                                               

Send Capwap mailing list submissions to
             [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
             http://mail.frascone.com/mailman/listinfo/capwap
or, via email, send a message with subject or body 'help' to
             [email-masked]

You can reach the person managing the list at
             [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Capwap digest..."

Today's Topics:

   1. test - pls ignore (Wijnen, Bert (Bert))
   2. Design Team conference minutes (Yang, Lily L)
   3. RE: Taxonomy doc (Yang, Lily L)
   4. Re: Taxonomy doc (Shankar Narayanaswamy)
   5. RE: About LWAPP's security (Michael Cheng)

--__--__--

Message: 1
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Capwap (E-mail)" <[email-masked]>
Date: Wed, 14 Apr 2004 00:09:09 +0200
Subject: [Capwap] test - pls ignore

checking if archive works

Thanks,
Bert

--__--__--

Message: 2
Date: Tue, 13 Apr 2004 15:25:18 -0700
From: "Yang, Lily L" <[email-masked]>
To: <[email-masked]>
Subject: [Capwap] Design Team conference minutes

This is a multi-part message in MIME format.

------_=_NextPart_001_01C421A6.3391B95F
Content-Type: text/plain;
             charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

CAPWAP Design Team teleconference minutes

April 13, 2004  8-10am

=20

Attendees (11):

Victor, Inderpreet, Partha, Jim, Petros, Ajit, Dave, Peyush, Matt, Lily,
Mani

=20

**** Short term milestone: Revise to v02 according to comments received,
submit by end of day April 14, ready for IEEE Review on April 15.

=20

***** Draft review: we went through the April 7 version of the draft
page by page, section by section to collect comments and feedback.
Nothing major came up but the team did provide a list of good comments
and had good discussion to reach consensus on the necessary changes.
Will send out the new revision with list of changes by tomorrow to the
CAPWAP list. Ideally we would like the CAPWAP WG to have some internal
review time before submitting for external IEEE review. However, the
tight schedule prohibits us from doing that. So we will be doing IETF
and IEEE review in parallel. It is expected that the draft will continue
to be revised and advanced for the next several months.

=20

=20

Lily

------_=_NextPart_001_01C421A6.3391B95F
Content-Type: text/html;
             charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
 {font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
      {font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal,
li.MsoNormal, div.MsoNormal
  {margin:0in;
     margin-bottom:.0001pt;
font-size:12.0pt;
      font-family:"Times New Roman";}
a:link,
span.MsoHyperlink
      {color:blue;
     text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
     {color:purple;
text-decoration:underline;}
span.EmailStyle17
  {font-family:Arial;
color:windowtext;}
@page Section1
  {size:8.5in 11.0in;
    margin:1.0in
1.25in 1.0in 1.25in;}
div.Section1
 {page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>CAPWAP Design Team teleconference =
minutes</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
 font-family:Arial'>April 13, 2004</span></font><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp; </span></font><font =
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>8-10am</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Attendees (11):</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Victor, Inderpreet, Partha, Jim, Petros, Ajit, Dave, =
Peyush,
Matt, Lily, Mani</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>**** Short term milestone: Revise to v02 according to
comments received, submit by end of day April 14, ready for IEEE Review =
on
April 15.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>***** Draft review: we went through the April 7 =
version of
the draft page by page, section by section to collect comments and =
feedback. Nothing
major came up but the team did provide a list of good comments and had =
good
discussion to reach consensus on the necessary changes. Will send out =
the new
revision with list of changes by tomorrow to the CAPWAP list. Ideally we =
would
like the CAPWAP WG to have some internal review time before submitting =
for
external IEEE review. However, the tight schedule prohibits us from =
doing that.
So we will be doing IETF and IEEE review in parallel. It is expected =
that the
draft will continue to be revised and advanced for the next several =
months.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Lily</span></font></p>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C421A6.3391B95F--

--__--__--

Message: 3
Subject: RE: [Capwap] Taxonomy doc
Date: Tue, 13 Apr 2004 13:41:09 -0700
From: "Yang, Lily L" <[email-masked]>
To: "Shankar Narayanaswamy" <[email-masked]>
Cc: <[email-masked]>

Hi, Shankar --

It appears that what you are referring to here is an older version of =
our docemnt. There is a newer version that we are still working on, and =
this version can be found at=20
http://www.capwap.org/draft-ietf-capwap-arch-01.txt=20
In this newer version, you will see that we do move the =
encryption/decryption from the real time list to the non-real time list. =

We also added content to 4.6 security. Please review and if you feel =
there are more you can add on top of that, please don't hesitate to send =
to us. We are trying to revise this version by end of tomorrow so that =
we can provide to IEEE for their review. So early comments would be =
appreciated.

Thanks,
Lily

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Shankar Narayanaswamy
> Sent: Monday, April 12, 2004 2:03 AM
> To: [email-masked]
> Subject: [Capwap] Taxonomy doc
>=20
>=20
> All,
>=20
> Some thoughts:
>=20
> 1.  Section 4.2: This section states that the reasoning=20
> behind the Split=20
> MAC architecture is to "offload to the WTP(s) functionality that is=20
> specific and relevant only to the locality of each BSS in=20
> order to allow=20
> the AC to scale to a large number of 'lightweight' WTP devices". The=20
> section also mentions 802.11 encryption/decryption as being a=20
> real-time=20
> service implemented on the WTP.
>=20
>      This is not always true. For example, at Instant802 (and some=20
> others: Symbol, Aruba?) we perform 802.11=20
> encryption/decryption at the=20
> AC rather than the WTP. 802.11 frames in WEP/TKIP/WPA are transported=20
> using a GRE or some other encapsulation between the WTP and the AC.
>=20
>      This is driven by two considerations. The first is cost=20
> reduction=20
> in the WTP. We want it to be as cheap and simple as possible=20
> so taking=20
> out encryption/decryption is useful, especially since this=20
> may otherwise=20
> have to be done twice (decrypt the 802.11 packet, then encrypt the IP=20
> packet to tunnel it to the AC). The second is security. We=20
> want to avoid=20
> any risk from a compromised WTP, and therefore not have user=20
> encryption=20
> keys on the AP at all. Since the entire encrypted 802.11 frame is=20
> carried over the wired LAN between WTP and AC, the user's=20
> security level=20
> (WEP, TKIP, WPA, 802.11i) is preserved.
>=20
>      A side effect of this architecture is that progress in security=20
> protocols and algorithm does not obsolete the WTPs; the ACs implement=20
> the new security schemes instead and the management problem=20
> is therefore=20
> simplified. It can also protect from LAN-side eavesdropping.
>=20
>      This architecture is susceptible to MIM attack in the=20
> sense that a=20
> MIM on the wired LAN could prevent PDUs from getting to their=20
> destinations, but privacy and message integrity are not lost.
>=20
> 2.  Section 4.6: This section on security is blank. May I offer the=20
> following prose:
>=20
>     "There are different kinds of traffic passing between the WTP and=20
> the AC, and each one warrants different considerations.
>=20
>     "For user traffic, there are several choices. Some=20
> vendors choose to=20
> encrypt/decrypt user traffic at the WTP and send user data in=20
> the clear=20
> between the WTP and the AC. Other vendors choose to=20
> encrypt/decrypt user=20
> traffic at the WTP and then aggregate this traffic into a single=20
> encrypted tunnel to the AC. Yet others transport the=20
> WEP/TKIP/WPA-encrypted 802.11 MAC PDU between the AC and the WTP,=20
> thereby avoiding user encryption keys being stored at the WTP. The=20
> tradeoffs are between complexity at the AC versus the WTP,=20
> and also in=20
> security versus simplicity in the WTP.
>=20
>     "Most vendors choose to encrypt management traffic=20
> between WTPs and=20
> APs. Most vendors use mutual authentication between WTP and AC to=20
> protect against rogue APs.
>=20
>     "Some vendors support IPSec VPN termination on ACs; this allows=20
> greater security since wireless clients can use an IPSec VPN over the=20
> air and over the wired network, all the way to the AC. Some=20
> vendors use=20
> Access Control Lists (ACLs) at the WTP or the AC to prevent=20
> unauthorized=20
> clients from using the wireless network."
>=20
> 3.  I did not see any section on roaming, redundancy, WTP/AC=20
> handoff; do=20
> we need sections on this? If so, I would be happy to write=20
> them. These=20
> are all important issues and some of the taxonomy submissions=20
> do mention=20
> how those vendors approach them.
>=20
> Regards,
> Shankar
> --=20
> Shankar Narayanaswamy, Ph.D.
> [email-masked]            Mobile: +1 650-387-4593
> http://www.shankar.org          E-Fax: +1 253-498-8372
>=20
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
>=20

--__--__--

Message: 4
Date: Wed, 14 Apr 2004 02:55:12 -0700
From: Shankar Narayanaswamy <[email-masked]>
To: "Yang, Lily L" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Capwap] Taxonomy doc

Lily,

Since the newer version was not distributed before (and the feedback
deadline was April 12) it is very difficult for someone who is not on
the design team to contribute: we are chasing a moving target! It would
be more efficient to freeze the document in between feedback cycles. And
to change the filename for each draft so we know which one we are
talking about.

Anyway, my original comment (1) still stands. Section 4.4 (Split MAC)
states that the reasoning behind the split MAC architecture is scaling.
But cost reduction in the WTP and security are just as important, if not
more so. I could even argue the converse: moving functionality away from
the WTP and centralizing it introduces massive complexity in the AC as
the system scales, and it is easy to reach a level of complexity in the
AC that is impractical (from a CPU and I/O processing perspective) with
just a couple of dozen access points. This would argue for moving
everything except centralized management into the WTPs.

So my argument is that cost reduction in the WTP and security are the
real reasons behind the split MAC architecture; their importance
outweighs the scaling disadvantage.

My original comment (3) also still stands: we have not addressed
roaming, redundancy and AC/WTP handoff (due to AC failure or
load-balancing). This is important because it affects the protocol
between ACs and between AC and WTP. Does anyone else see a need to
capture this as part of the architecture taxonomy?

Thanks,
Shankar

Yang, Lily L wrote:
> Hi, Shankar --
>
> It appears that what you are referring to here is an older version of our
docemnt. There is a newer version that we are still working on, and this
version can be found at
> http://www.capwap.org/draft-ietf-capwap-arch-01.txt
> In this newer version, you will see that we do move the
encryption/decryption from the real time list to the non-real time list.
> We also added content to 4.6 security. Please review and if you feel
there are more you can add on top of that, please don't hesitate to send to
us. We are trying to revise this version by end of tomorrow so that we can
provide to IEEE for their review. So early comments would be appreciated.
>
> Thanks,
> Lily
>
>
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of Shankar Narayanaswamy
>>Sent: Monday, April 12, 2004 2:03 AM
>>To: [email-masked]
>>Subject: [Capwap] Taxonomy doc
>>
>>
>>All,
>>
>>Some thoughts:
>>
>>1.  Section 4.2: This section states that the reasoning
>>behind the Split
>>MAC architecture is to "offload to the WTP(s) functionality that is
>>specific and relevant only to the locality of each BSS in
>>order to allow
>>the AC to scale to a large number of 'lightweight' WTP devices". The
>>section also mentions 802.11 encryption/decryption as being a
>>real-time
>>service implemented on the WTP.
>>
>>     This is not always true. For example, at Instant802 (and some
>>others: Symbol, Aruba?) we perform 802.11
>>encryption/decryption at the
>>AC rather than the WTP. 802.11 frames in WEP/TKIP/WPA are transported
>>using a GRE or some other encapsulation between the WTP and the AC.
>>
>>     This is driven by two considerations. The first is cost
>>reduction
>>in the WTP. We want it to be as cheap and simple as possible
>>so taking
>>out encryption/decryption is useful, especially since this
>>may otherwise
>>have to be done twice (decrypt the 802.11 packet, then encrypt the IP
>>packet to tunnel it to the AC). The second is security. We
>>want to avoid
>>any risk from a compromised WTP, and therefore not have user
>>encryption
>>keys on the AP at all. Since the entire encrypted 802.11 frame is
>>carried over the wired LAN between WTP and AC, the user's
>>security level
>>(WEP, TKIP, WPA, 802.11i) is preserved.
>>
>>     A side effect of this architecture is that progress in security
>>protocols and algorithm does not obsolete the WTPs; the ACs implement
>>the new security schemes instead and the management problem
>>is therefore
>>simplified. It can also protect from LAN-side eavesdropping.
>>
>>     This architecture is susceptible to MIM attack in the
>>sense that a
>>MIM on the wired LAN could prevent PDUs from getting to their
>>destinations, but privacy and message integrity are not lost.
>>
>>2.  Section 4.6: This section on security is blank. May I offer the
>>following prose:
>>
>>    "There are different kinds of traffic passing between the WTP and
>>the AC, and each one warrants different considerations.
>>
>>    "For user traffic, there are several choices. Some
>>vendors choose to
>>encrypt/decrypt user traffic at the WTP and send user data in
>>the clear
>>between the WTP and the AC. Other vendors choose to
>>encrypt/decrypt user
>>traffic at the WTP and then aggregate this traffic into a single
>>encrypted tunnel to the AC. Yet others transport the
>>WEP/TKIP/WPA-encrypted 802.11 MAC PDU between the AC and the WTP,
>>thereby avoiding user encryption keys being stored at the WTP. The
>>tradeoffs are between complexity at the AC versus the WTP,
>>and also in
>>security versus simplicity in the WTP.
>>
>>    "Most vendors choose to encrypt management traffic
>>between WTPs and
>>APs. Most vendors use mutual authentication between WTP and AC to
>>protect against rogue APs.
>>
>>    "Some vendors support IPSec VPN termination on ACs; this allows
>>greater security since wireless clients can use an IPSec VPN over the
>>air and over the wired network, all the way to the AC. Some
>>vendors use
>>Access Control Lists (ACLs) at the WTP or the AC to prevent
>>unauthorized
>>clients from using the wireless network."
>>
>>3.  I did not see any section on roaming, redundancy, WTP/AC
>>handoff; do
>>we need sections on this? If so, I would be happy to write
>>them. These
>>are all important issues and some of the taxonomy submissions
>>do mention
>>how those vendors approach them.
>>
>>Regards,
>>Shankar
>>--
>>Shankar Narayanaswamy, Ph.D.
>>[email-masked]            Mobile: +1 650-387-4593
>>http://www.shankar.org          E-Fax: +1 253-498-8372
>>
>>_______________________________________________
>>Capwap mailing list
>>[email-masked]
>>http://mail.frascone.com/mailman/listinfo/capwap
>>
>
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap

--
Shankar Narayanaswamy, Ph.D.
[email-masked]             Mobile: +1 650-387-4593
http://www.shankar.org          E-Fax: +1 253-498-8372

--__--__--

Message: 5
Date: Wed, 14 Apr 2004 11:09:14 +0100
From: Michael Cheng <[email-masked]>
Subject: RE: [Capwap] About LWAPP's security
To: "[email-masked]'" <[email-masked]>

Hi Scott,

Thank you very much for your quick response. Sorry to reply late. I was
off for a few days.

We wrote the paper purely for our own research interest and  did not
plan to attack one particular design. We noticed the problem last June(
maybe you still can find my email in  the group) and wrote the paper under
a
request for academic reason last December. Because we believed that the
lwapp team would release new version after the old draft expired, we didn't
post the paper. However, it seems that the LWAPP team becomes inactive
after
establishing CAPWAP or am I wrong?
We think we should post the paper purely for academic reason.

Only a few comments on your response.
Moreover, I updated the paper with some minor corrections.

Scott G. Kelly wrote:

> Hi Michael,
>
> Michael Cheng wrote:
>
> > Hi,
> >
> > We wrote a paper to briefly analyze the security aspect of LWAPP.
> > If anyone is still interested in LWAPP, the paper is avaible
> > on http://www.cs.mdx.ac.uk/staffpages/m_cheng/link/lwapp_g.pdf
>
> Thanks for posting this paper. After giving it a quick review, I have a
few comments. I'd like to preface this by saying that this is not currently
a working group item, and so this discussion is purely academic, and it may
be terminatated by the wg chairs at any time. Nonetheless, I think it
should
hold some interest for wg members, and the paper deserves some response.
>
> In order to properly analyze the security properties of the protocol
discussed in the draft, you must understand the assumptions under which the
protocol operates. These were described in an internal document here, but
not in detail in the lwapp draft, so you are at a disadvantage in that
regard.
>
> One primary architectural assumption in the original lwapp security
design
was that the AP's have a direct layer 2 connection to the AR, which in our
case is a switch. It is also assumed that this connection is relatively
protected with regard to physical security (e.g. runs through the ceiling
of
your office building to your lockable server room). That is, the security
protocol discussed in the draft was not designed to operate over a hostile
network. I believe this was made clear in subsequent discussions on this
list.

I totally agree with you that when designing a security protocol we
should consider the protocol application environment and evaluate the
potentional threats.

However, I believe all of us agree with that we can not just design a
protocol to cope with the threats we found.

A general way to design a protocol is
first to analyze the available cryptography primitives( enc: AES, RSA,
ECC, ..., hash: ..., sometimes patents are concerned)

second to decide the acceptable protocol complexity (computation,
bandwith, implementation)

third to decide the general protocol type (symmetric or aymmetric-based,
password-based, key agreement or  key transport, AK or AKC)

four to design a protocol (or some) as rigerous as possible (formally
provable with some general properties: known-key attack, key-comprise
impersonation...)

fifth to evaluate the protocol's ability to counter the potential threats.
(Some attacks in networks can not be defended by only designing a
generally good protocol.
Some protocol security properties are undesireable in the application
environment.)

sixth to make a choice based on the balance between complexity and
security.

Of cz sometime we also should consider whether the parameter negotiation
is necessary.

I believe a rigerous protocol with tolerable complexity is NEVER a bad
choice.

For example protocol 3 in our paper,  to provide explicit key-confirmation,
AR only needs to perform one more hash operation.
Maybe one will argue that the opening  key attack is  not feasible in
LWAPP.
However when we tell customers that there is a bug, but the attack is
extremely unlikely, customers maybe will not be convinced.
On the other hand,  why not  use a small cost to remove the potential
bug with an explicity key confirmation?

Moreover, we cannot forcast the future. If we can design a protocol with
acceptable complexity which is secure in the hotile environment, why don't
we  do it ?

>
> In our internal analysis we concluded, as do you, that there is no
significant security benefit inherent in encrypting the wep keys, since
anyone who can see the encrypted lwapp channel can see the unencrypted data
traffic. But try telling a customer that you're sending encryption keys
over
the network in the clear, but that they shouldn't worry about this. Also,
in
the case where an attacker can't insert himself as a MiM, there is a small
security benefit: in these cases he can only eavesdrop; he cannot modify
the
traffic flow, whereas with compromised wep keys he could inject traffic.
But
this is an admittedly small benefit.
>
> There is some additional benefit in the encrypted/authenticated command
channel: the AP control API is protected (including firmware downloads).
This prevents the introduction of hostile firmware and/or configuration
into
the AP which might be used as building blocks in an attack.
>
> After related discussions on this list and the subsequent publication of
the lwapp security requirements draft (expired, but still available at
http://www.legra.com/downloads/IETF_Internet_Draft_LWAPP_Security.pdf ), it
should be clear that the mechanism discussed in the original lwapp draft
was
quite limited, and is not viewed as sufficient solution for generalized
lwapp security.
>
> Regarding various discussions about the authentication mechanism, you
guys
are mistaken in some of your assumptions. Both sides are supposed to be
authenticated (not just the AR), and clearly you want to look at the IDs in
the certs as part of the verification. We did not publish that level of
detail in the 00 draft, but this does not mean it has not been considered.

That is great. However we didnot see any new publication in the last few
months. Is LWAPP still alive?
I  can't quite understand why LWAPP runs out of steam. or am I wrong? (
I did not follow the progress tightly.)

In fact, ID and validality of certifications are problems out of the
scope of designing secure protocols. Two problems are faced by any
certification-based protocol. However, these two problems are particularly
important in LWAPP-like  protocols and should be addressed in the proposal
if certification-based protocol is used.
Password-based protocol has no such problem because AR's ID and password
must be preconfigured in AP.

For certification revocation, commonly there are two solutions.
A: after establishing the channel, AP checks the CRL. (for example
EAP-TLS uses this method)
B: AR relays the request and response. (We proposed this way)
Both methods have advantages and disadvantages.

About ID, I agree with that this is more likely about implementation and
deployment.

>
> Verifying IDs implies some preconfiguration during the initial staging,
but this should come as no surprise to someone experienced at deploying
this
sort of gear. Discussion of these points was beyond the scope of the draft,
and I'm sure these issues will be addressed if this wg moves forward with
an
lwapp-like protocol.
> Scott
Michael

--__--__--

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

End of Capwap Digest

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Yang, Lily L" <[email-masked]>
Date: Thu, 15 Apr 2004 08:40:54 -0700

I think 2 and 3 are not specific to Split MAC but are benefits by a
standard WTP/AC protocol.

-----Original Message-----
From: Shankar Narayanaswamy [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2004 11:32 PM
To: Yang, Lily L
Cc: [email-masked]
Subject: Re: [Capwap] Taxonomy doc

More thoughts on reasoning for the split MAC architecture:

1. Security - extend the wireless security back to the AC.

2. To allow switch vendors to independently innovate products and 
protocols from WTP vendors (given a standard WTP/AC protocol)

3. To allow WTP vendors to innovate products independently from switch 
vendors - e.g. different form factors, higher speeds, etc.

Thanks,
Shankar

Yang, Lily L wrote:
> Hi, Shankar --
> 
> Sorry about the versioning problem. I agree that it has been a moving
> target because of the tight schedule and our desire to improve on the
> draft as much as possible. 
> I agree with your comments (1) and (3). I probably can incorporate (1)
> into v02 today, but (3) needs more discussion and work and so I would
> like to defer that into later version. Is that ok with you?
> 
> Lily
> 
> From: Shankar Narayanaswamy [mailto:[email-masked]] 
> Sent: Wednesday, April 14, 2004 2:55 AM
> To: Yang, Lily L
> Cc: [email-masked]

>>It appears that what you are referring to here is an older version of
> 
> our docemnt. There is a newer version that we are still working on,
and
> this version can be found at 
> 
> there are more you can add on top of that, please don't hesitate to
send
> to us. We are trying to revise this version by end of tomorrow so that
> we can provide to IEEE for their review. So early comments would be
> appreciated.
> 
>>Thanks,
>>Lily
>>
>>
>>
>>

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 16 Apr 2004 09:12:12 -0600

Malini,

> -----Original Message-----
[...]
> and L3 connected with another WTP?
[Mani, Mahalingam (Mahalingam)] it appears to me to be more of a
configuration / implementation question than an architectural one. I
will leave it to the contributing configurations to state if they allow
it.

-mani
> is shown whereas the Figure 5 does not have such combination of
topology
> Malini Raghavendra
[...]

---

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 21 Apr 2004 16:39:40 -0700

Shankar --

Within the category of CAPWAP Functions (2.2), we included:
   o  Network-wide STA state information database, including the
      information needed to support value-added services, such as
      mobility, load balancing etc.
Hopefully this network wide database can support some of the services you mentioned, like roaming. It does not cover AC failover/redundancy/load-balancing, because most of the discussions focus around the interaction between WTP and AC, not between multiple AC. But we did mention in one place that multiple AC should be part of the architecture. 
The DT had some discussion around VoIP, and believed that it boils down to QoS support like WME and 11e -- so that is covered in 802.11 Functions.

We decided to focus primarily on the low level (MAC) functions because we need to understand the mapping there first before we can discuss higher level support like VoIP, etc. Ultimately we need to break these service support down to the required functions at MAC level.

Lily

> Sent: Wednesday, April 14, 2004 11:23 PM
> To: Yang, Lily L
> Cc: [email-masked]
> We probably have no option but to defer (3) because they were not 
> addressed in the original taxonomy survey (although I would 
> be happy to 
> write a section on how we do it at Instant802). A new survey will be 
> needed to capture how each of the three items is addressed by the 
> participating vendors. Also VoIP support and any other architectural 
> facets that must eventually be captured by the LWAPP to allow true 
> interoperability between WTPs and ACs.
> 
> Regards,
> Shankar
> 
> 
> Yang, Lily L wrote:
> > Hi, Shankar --
> > 
> > our docemnt. There is a newer version that we are still 
> working on, and
> > there are more you can add on top of that, please don't 
> hesitate to send