Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

From: "Pat R. Calhoun" <[email-masked]>
Date: Tue, 13 Jul 2004 09:23:24 -0700

So I think what this thread validates is that there is no clear data to prove that the sentence
stating that remote MAC is more manageable - so I'd like to kill this thread and ask the authors 
of the document to remove the sentence.

PatC
-----Original Message-----
From: Cheng Hong [mailto:[email-masked]]
Sent: Tue 7/13/2004 7:35 AM
To: Pat R. Calhoun; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt
 
I don't object the idea of provide more explanation about the issue at all.
Your reasoning of the edge filtering might serve as the example there.
 
But also one point to note is the difference between the manageability of
the AP and the network. The filtering function to be place at the edge (AP)
could improve the network manageability, but may descrease the manageability
of the AP (function) itself.
 
cheers
 
Cheng Hong 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 1:04 PM
To: Cheng Hong; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

The one round trip "burden" of pushing a rule dow to the AP is minuscule in
comparison with opening up the floodgates for all traffic to be sent to the
AC.

I agree that wired networks have higher bandwidth than the wireless network,
but I would wonder how many IT managers would be pleased to know that their
wired network investment is being used to potentially carry unauthorized
traffic because their wireless solution's APs cannot provide any form of
traffic policing.

The advantage of Split MAC is that the AP is being told what it should and
shouldn't allow onto the wired network, and if encryption is done on the AP,
it will even eliminate invalid (perhaps malicious) traffic from cluttering
the wired network. This enables the AP to protect the AC's resources,
further guaranteeing a well behaved wireless system.

Anyhow, the original point behind this whole thread was that I disagreed
with the statement in the document that stated that remote MAC was more
manageable than split MAC. If we can kill that sentence (or at least provide
some concrete data proving this is true), then I will more than gladly get
off my soap box.

PatC
-----Original Message-----
From: Cheng Hong [mailto:[email-masked]]
Sent: Mon 7/12/2004 9:24 PM
To: Pat R. Calhoun; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Well. That is a valid point. But would that be equally a burden with the
split MAC where you need to put in extra efforts to manage the filter and
the encryption at the edge?  And, with a proper network design (not
management), we don't need to care about the "burden" of traffic considering
that the wireless has much lower bandwidth offered than the wired network.

cheers

-----Original Message-----
From: Pat R. Calhoun [mailto:[email-masked]]
Sent: Tuesday, July 13, 2004 12:14 PM
To: Cheng Hong; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

But I would equally argue that a remote MAC causes *all* traffic to traverse
the network from the AP to the AC (because the AP is really dumb). One of
the benefits of Split MAC is that you have the ability to "protect" network
resources by being able to apply specific filters at the edge. For example,
if you have an encrypted channel, and you are capable of decrypting packets
at the edge, you would further protect the network by ensuring that only
properly encrypted packets enter the wired network.

So if unnecessary burden of the wired network is considered a management
burden, then I would argue that Split MAC increases manageability.

PatC
-----Original Message-----
From: Cheng Hong [mailto:[email-masked]]
Sent: Mon 7/12/2004 9:00 PM
To: Pat R. Calhoun; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

This really depends on how you define MANAGEABILITY. If the decrease in
signaling message is counted as increase in managemeability, it is obivous
that that moving the whole MAC to AC will simplify the protocol messages
used between AC and AP (at least less messags).

cheers

Cheng

-----Original Message-----
From: Pat R. Calhoun [mailto:[email-masked]]
Sent: Tuesday, July 13, 2004 11:55 AM
To: Cheng Hong; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Could I perhaps ask you to provide me with concrete data that proves this is
the case? I have plenty of data that proves that the centralized approach
provides much better manageability. However, there is nothing in my data
that shows that where some of the finer components of the MAC terminate
increase (or decrease) manageability.

PatC

-----Original Message-----
From: Cheng Hong [mailto:[email-masked]]
Sent: Mon 7/12/2004 8:50 PM
To: Pat R. Calhoun; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

As for the remote vs split, when we apply the same logic here, when the
degree of centralization increases, more info will be available at the AC.
Thus, the manageability will be better.

But, of course the centralization also brings other issues, and therefore
the degree of split should be a trade off result of different aspects.

cheers

Cheng Hong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 AM
To: Cheng Hong; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

I'm obviously not arguing that centralization is better... my point was that
the sentence that remote vs. split provides better manageability. I do not
agree with that sentence, and the document also does not provide any
supporting data to prove the point.

PatC
-----Original Message-----
From: Cheng Hong [mailto:[email-masked]]
Sent: Mon 7/12/2004 8:28 PM
To: Pat R. Calhoun; [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point is that with a centralized arch. you have more information
about the network, i.e. at the centralized controller you have a overall
view of the network instead of just the AP point of view. Therefore, more
"value added" service could be provided. One simple example is that the SME
could make better decisions with info from several AP.

cheers

Cheng Hong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 AM
To: [email-masked]; [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

> 7. Section 4.5. Could the authors please explain how they came to the
conclusion that Remote MAC "improves
> WTP manageability"?

If I can proffer an explanation; the characteristics of Remote MAC
follow from those of the Split MAC architecture. The Split MAC improves
manageability over basic autonomous WTPs by centralizing some control
aspects; Remote MAC goes further by centralizing 'all' aspects of the
MAC. So the entire MAC processing is consolidated while the WTPs become
extremely light devices.

<PRC> But one of the "advantages" of a centralized architecture, is that the
WTP look like "local interfaces", and are managed as such. Whether one
implements
remote or split MAC does not really change how one would manage such a
network -
so it's really down to implementation details.

<PRC> So as a consequence I disagree with the assumption (and statement)
made
in the document

PatC

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Sun, 18 Jul 2004 12:22:14 -0700

Sorry, jumping into the thread a bit late.  Some comments to add to the discussion...I don't believe there's justification of removal of a manageability statement based on its security implication.  If there is a flaw in the security, then the flaw needs to be fixed.  In this case however, the security implication itself has not gone through thorough analysis either and I don't agree with some of the conclusions implied.
 
First, the manageability side...Clearly the less state there is to transmit between different devices, the easier it is to manage.  So the statement in current draft is correct IMO.

<PRC> Since you started by implying that you had multiple points to make, perhaps you'd like to also include those? I have made counter arguments that no one else has been able to refute, so at this point the justification made in favor of this sentence seems to be about as good as my mother's old argument "because I said so". 

Traffic policing can be done in many ways.  In this case, even if the AP can do encryption, it cannot firewall everything as it will not have all the possible keys for all the types of authentication and encryption in a wireless network.  There's also a security weakness in keeping the keys at the AP itself, but I'll leave that discussion for another day.  

<PRC> Can you say apples and oranges? The definition of an AP does not even include a firewall function, so trying to introduce this now is irrelevant (unless you plan to introduce a firewall as part of the IEEE's definition of an AP). Hell at that point why don't we also include a web server, traffic shaper, etc.
 
WEP for example has no replay counters [ed: trimmed unnecessary text]

<PRC> The use of WEP and security in the same sentence is contradictory. 

PatC

---

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 23 Jul 2004 10:59:47 -0700

Hi, Pat -

Thanks for your careful review of the documents. The design team is
preparing v04 right now to address your comments and the discussion
lately.

One clarification question for you on item #2 below: Are you referring
to 1.3 "WTP" definition here? We want to be able to use the terminology
of "WTP" in all Centralized architecture discussion, including remote
MAC. So we kind of took the "lowest denominator" approach in defining
"WTP", which is 802.11 PHY. That is why we didn't want to say anything
about MAC layer. 

Does that make sense?

Another clarification on item #7 below: it seems that you read the text
as to say "it improves WTP manageability OVER SPIT and LOCAL MAC". But
what we really intended to convey is a much weaker statement "improves
WTP manageability OVER autonomous architecture". 

But I agree the text isn't explicit and hence confusing. The discussion
later in the mailing list shows that how vague a concept "manageability"
can be, and how hard it is to make a sweeping value judgment statement.
That is why we try to restraint ourselves in the draft to make such
statements. But it is possible that we slip in one or two without
thinking really hard.

We should be sending out our suggestions to resolve these comments in
this mailing list soon.

Thanks again,

Lily

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat R. Calhoun
Sent: Thursday, July 08, 2004 11:08 AM
To: [email-masked]
Subject: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

First, I'd like to applaud the authors on a job well done. It is clear
in reading this spec that there was a significant amount of data to work
with... I am very impressed with the document.

1. Section 1.3. "Typically ," -> "Typically, "

2. This section defines the AP as terminating the 802.11 PHY, but it
should be noted that this device also terminates the
802.11 MAC mgmt layer, which is not specified.

3. The definition of Split MAC implies that all MAC mgmt is handled in
the AC, but in certain implementations this is not true. The MAC mgmt
packets that have very tight timing requirements can be handled in the
WTP.

4. Page 14. The text reads 14 contributions, yet above 16 is mentioned.

5. Section 3.2. Another security issue is the very fact that this device
is most likely not under lock and key, but does contain secret
information in order to communicate with the backend systems, such as
AAA, SNMP, etc. Due to the common management method used by IT personel
of pushing a "template" to all similar devices, theft of such a device
would compromise the wired network.

5. A Network Management Station (NMS) should not be considered as part
of the Access Controller. While most controllers will provide one or
more management interfaces, a system that is used to scale a global
network generally resides on a separate system.

6. Page 25. The list of real-time features should probably include Power
Save handling.

7. Section 4.5. Could the authors please explain how they came to the
conclusion that Remote MAC "improves WTP manageability"?

8. Page 30. The term "Integration Service" is used as a substitute to
bringing function. However, the terminology section called this function
"portal". We should stick to a single term throughout the document.

9. Page 33, second to last paragraph, there is a non traditional
character in the line that starts with "every mesh node..."

10. Section 5.1. If stations (or non-trusted equipment) are allowed to
become part of the mesh backbone, end to end security is required
otherwise users traffic will be compromised.

11. Page 45. The URL for the LWAPP draft has changed and the one listed
has expired. Does it make sense to update it?

12. General comment. I understand that there was a desire to mask the
vendor in the appendices, but I wonder whether this makes sense. The
primary issue moving forward is that this is (and will) be known to
people on the list (or reading he archives)

13. Appendix C. We really should discourage baseless marketing claims
like "secure, scalable, large scale WLAN deployments" unless one intends
to back this up with facts. I'm quite certain that no submittal was
intended for the home user.

14. Appendix D, Page 52. Seems like spelling rogue as "rouge" is a
common mistake. May want to search/replace.

15. Appendix D, question 4. Could the submitter be a tad more specific
than "IP Tunnel". For instance, is there a control protocol to setup the
tunnels, etc.

16. Appendix D, question 5. Probably too late now, but I really question
how these claims can be made given the rather brief data - so we just
have to assume the claims are true.

17. Appendix E. Good write-up!

18. Appendix F. I have a question for the author, but this is purely
asked due to curiosity. In a home environment, you seem to imply that
there is a single set top box, and that you can provide dynamic power
assignment, but I wonder how you can do that with a single antenna - you
need a clear view of the whole space that needs to be covered.

19. Appendix F, section 9. The paragraph states that the PHY and MAC
association services are handled in the STB, and other MAC services are
in the controller. Is it possible to get a breakdown or at least an
understanding of what the other services being provided are?

20. Appendix L. I am curious about the fact that this architecture is
completely agnostic of the PHY, yet it can provide such functions as
centralized RF management (which cannot be performed if one has no idea
what they are dealing with).

PatC

---

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 27 Jul 2004 14:45:02 -0700

Hi, Pat - see below some suggestions for draft change to address your
comments. Let me know if you have further comments and if you don't like
what you read here. 
We plan to get v04 out soon to incorporate the comments from you and
others since v03.
 
Lily

[Lily] Thanks.

2. This section defines the AP as terminating the 802.11 PHY, but it
should be noted that this device also terminates the
802.11 MAC mgmt layer, which is not specified.
[Lily] We would like to use "WTP" in all centralized architecture
instances including remote MAC, so the lowest common denominator is
terminating PHY. So I am inclined to leave it like that.

3. The definition of Split MAC implies that all MAC mgmt is handled in
the AC, but in certain implementations this is not true. The MAC mgmt
packets that have very tight timing requirements can be handled in the
WTP.
[Lily] You are right. Figure 10 shows that most but not all vendors
terminate MAC mgmt packets at AC. So we can change the definition of
"Split MAC" in 1.3 from "...implement the delay sensitive MAC services
(like the control frame processing) for IEEE 802.11, while tunneling all
the management and data frames to AC for centralized processing." to
"...implement the delay sensitive MAC services (including all control
frames and some management frames) for IEEE 802.11, while tunneling all
the remaining management and data frames to AC for centralized
processing."

4. Page 14. The text reads 14 contributions, yet above 16 is mentioned.
[Lily] It should be 16. We will fix 2.4, in the middle of first
paragraph "13 of them are from WLAN vendors" to "15 of them are from
WLAN vendors".
And the second last paragraph: from "11 out of 14" to "11 out of 16".

5. Section 3.2. Another security issue is the very fact that this device
is most likely not under lock and key, but does contain secret
information in order to communicate with the backend systems, such as
AAA, SNMP, etc. Due to the common management method used by IT personel
of pushing a "template" to all similar devices, theft of such a device
would compromise the wired network.
[Lily] Yes, the text in 3.2 alluded to it but I agree that this point
should be made more explicitly. 
 Old text reads "As per problem #4 in [2], the only security issue in
this architecture is mutual authentication between the WTP and the
Ethernet infrastructure to ensure that WTPs cannot be easily stole and
deployed in unprotected networks.  This can be ensured by existing
mechanisms such as, for instance, 802.1x between the WTP and the
Ethernet switch it plugs into." 
Suggested new text: "One of the security issues in this architecture is
the need for mutual authentication between the WTP and the Ethernet
infrastructure.  This can be ensured by existing mechanisms such as,
802.1x between the WTP and the Ethernet switch it plugs into. Another
critical security issue with this architecture is the very fact that the
WTP is most likely not under lock and key, but does contain secret
information in order to communicate with the backend systems, such as
AAA, SNMP, etc. Due to the common management method used by IT personel
of pushing a "template" to all similar devices, theft of such a device
would compromise the wired network. 

5. A Network Management Station (NMS) should not be considered as part
of the Access Controller. While most controllers will provide one or
more management interfaces, a system that is used to scale a global
network generally resides on a separate system.
[Lily] So far , we tend to talk about WLAN "management, control and
configuration" all in one breath, and I think logically and it seems
more natural to include the management functionality in AC.
Architecturally it is also cleaner. Another way to look at this is that
from WTP's point of view, AC is all they need to know to gain access to
all the "management, control and config" functions for the network. So
what it really means is that AC provides interface to all these
services, including SNMP, AAA. It doesn't necessarily mean AC itself has
to implement all these in one physical box. It is very reasonable to
have a separete backend SNMP manager, and another AAA server. Therefore,
SNMP and Radius protocol can co-exist and complement the to-be-developed
CAPWAP protocol. 

6. Page 25. The list of real-time features should probably include Power
Save handling.
[Lily] PS-Poll is included in "Processing of Control Frames:
RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK". Is that what you mean?
Keep in mind that there is no clear definition of what real time
features are exactly, and so what we list here are "examples", not
exhaustive and definitive list.

7. Section 4.5. Could the authors please explain how they came to the
conclusion that Remote MAC "improves WTP manageability"?
[Lily] What we really meant here is that Remote MAC "improves WTP
manageability over autonomous architecture". We didn't intend to state
that it "improves WTP manageability over local or split MAC". Since it
causes lots of confusion here, I suggest we simply delete the ", and
improves WTP manageability" from the first paragraph of 4.5.
As the debate over mailing list shows that manageability is a vague
concept, we have tried very hard to restraint from making sweeping value
judgment statements. There are many factors in play here and it is very
hard to say X is definetely better than Y, without taking into account
the deployment scenarios and specific requirements.   

8. Page 30. The term "Integration Service" is used as a substitute to
bringing function. However, the terminology section called this function
"portal". We should stick to a single term throughout the document.
[Lily] Both terms are used commonly in IEEE and my take is that
"Integration" is a service, while "Portal" is a logical point where that
service gets invoked. So one of them may be more appropriate in certain
sentences than the other. I think that should be ok.

12. General comment. I understand that there was a desire to mask the
vendor in the appendices, but I wonder whether this makes sense. The
primary issue moving forward is that this is (and will) be known to
people on the list (or reading he archives)
[Lily] Yes, this has been public knowledge (on the list). But as a
standalone RFC document which this draft eventually would become, I
think it is more in the vendor-agnostic IETF spirit to leave the
specific vendor info out. As I said in a separate email, we would like
to remove all the survey data out of the draft in this new revision.

20. Appendix L. I am curious about the fact that this architecture is
completely agnostic of the PHY, yet it can provide such functions as
centralized RF management (which cannot be performed if one has no idea
what they are dealing with).
[Lily] I would not be able to address any of the comments for the
individual submissions as these are not part of the draft. We will
remove all these Appendix sections in the final document.