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

From: "Randy Chou" <[email-masked]>
Date: Fri, 16 Jul 2004 18:43:55 -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.
 
Now moving to the security implications which I believe should be a
different discussion...
 
> 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.

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.  
 
WEP for example has no replay counters and hence the AP does not have
enough information and the wired network can be flooded with or without
the encryption being done on the AP itself.  So the AP wouldn't be able
to protect even simple data.  With more sophisticated encryption such as
AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by
the backend radius and so the AP does not have enough information to
protect either.   In other networks, VPN over wireless is required and
so unless the AP is doing L3 encryption, this wouldn't work either.  I'm
sure I've left other possible flood attacks out.  So with strong or weak
encryption, flooding is possible and needs to be addressed in a
different way (firewall'd).  But we're going off on a different tangent
and I'd also be advertising a feature rather than discussing the merits
of the draft itself ;).
 
Regards,
 
--
Randy

	 

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

	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: "Randy Chou" <[email-masked]>
Date: Sun, 18 Jul 2004 23:41:29 -0700

Interesting how you cut most of my points out, then ask me where they are.
I've included the thread again for reference below...

><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".

I'm beginning to understand why most choose not to reply to your posts.  My
statement is self-evident.  We're not getting anywhere discussing it further
when it comes to manageability and I'd certainly like to keep your mother
out of this discussion.

Your security statement I refuted (which you also conveniently cut out) was
a misconception I heard elsewhere too and wanted to correct it...The idea
that handling encryption at the AP can prevent flooding the wired network.
Because the authentication portion of 802.11i is based on 802.1x, and the
keys for 802.1x (TLS portion) reside on the authentication server, the AP
cannot prevent EAP flooding.  So flooding must be prevented in other ways
which I've already mentioned below...

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

Again you chose to cut out what I said.  I mentioned both WEP and AES-CCM
where flooding can occur to point out that it is irrelevant what encryption
is used.

On a slightly more humorous note...searching on google for "wep security
airespace", the first hit yields:

"Specifically, the Airespace security framework supports the following
layers of security protocols and ... action • Layer 2 – WEP, WPA, 802.1x"

And I'm the one with contradictory statements???  Sigh...

Regards,

--
Randy

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Pat R. Calhoun
  Sent: Sunday, July 18, 2004 12:22 PM
  To: Randy Chou; [email-masked]
  Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

  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.

  <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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Randy Chou
Sent: Friday, July 16, 2004 6:44 PM
To: [email-masked]
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

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.

> 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.

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.

WEP for example has no replay counters and hence the AP does not have enough
information and the wired network can be flooded with or without the
encryption being done on the AP itself.  So the AP wouldn't be able to
protect even simple data.  With more sophisticated encryption such as
AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by the
backend radius and so the AP does not have enough information to protect
either.   In other networks, VPN over wireless is required and so unless the
AP is doing L3 encryption, this wouldn't work either.  I'm sure I've left
other possible flood attacks out.  So with strong or weak encryption,
flooding is possible and needs to be addressed in a different way
(firewall'd).  But we're going off on a different tangent and I'd also be
advertising a feature rather than discussing the merits of the draft itself
;).

Regards,

--
Randy

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

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
> 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: "James Kempf" <[email-masked]>
Date: Mon, 19 Jul 2004 09:00:43 -0700

Gentlemen,

(At the risk of getting beat up by both sides...)IETF is for people with
competing technical ideas to come to concensus for the purpose of providing
interoperability, something that has time and again proven valuable to
customers of networking equipment (like my current employer). Scoring points
about why one's technical vision is better than one's competitor, or bashing
one's competitor's product offering is, in my opinion, somewhat inconsistent
with this goal.

There's obviously a difference of opinion here about where to locate state
and how that impacts ease of managability. Barring some real hard data about
managability for different products (which I would highly encourage both
sides to seek through some neutral third party), there's probably no way to
objectively assess the two sides of this argument.

Therefore, as an attempt at concensus, I'd suggest modifying the statement
to say something like the following:

    The exact balance of centralized v.s. decentralized state and its impact
    on managability for CAPWAP architectures such as Split  MAC and
    Remote MAC is currently a matter of dispute
    within the technical community.

Sound reasonable?

            jak

----- Original Message ----- 
From: "Randy Chou" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 18, 2004 11:41 PM
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

> layers of security protocols and ... action . Layer 2 - WEP, WPA, 802.1x"
>
the
> First, the manageability side...Clearly the less state there is to
transmit
their
and
AP,
> Traffic policing can be done in many ways.  In this case, even if the AP
can
> WEP for example has no replay counters and hence the AP does not have
enough
> AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by
the
manageability
network,
their
AP,
considering
information
> <PRC> So as a consequence I disagree with the assumption (and statement)

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

---

From: Dan Harkins <[email-masked]>
Date: Mon, 19 Jul 2004 10:07:09 -0700

That is certainly one view of the IETF, sadly it is more of a nostalgic
one. Another view is that the IETF is a place to submit a (portion of a) 
proprietary scheme or protocol with the desire to place the official
imprimatur of the IETF upon it and to then claim compliance to a
"standard". When the points being made include marketing speak (e.g.
"[the AP] cannot firewall (sic) everything as it will not have all possible
keys (sic)") I think it's obvious which IETF this is.

  Also, you mentioned your current employer valuing the output of the
nostalgic IETF, but your current employer has already made up its mind
regarding the issue at hand without waiting for "competing technical ideas
to come to concensus."

  Dan.

On Mon, 19 Jul 2004 09:00:43 PDT you wrote

---

From: "James Kempf" <[email-masked]>
Date: Mon, 19 Jul 2004 10:26:52 -0700

Dan,

> regarding the issue at hand without waiting for "competing technical ideas

Whatever gave you that impression? The fact that I'm author if the problem
statement draft? That just means I think there's a problem, not that I agree
with any particular solution.

Note:  In case you haven't seen, the Docomo co-author was dropped from the
latest LWAPP draft. Turns out this was because his job description changed,
but enough technical disagreement has arisen since he agreed to be co-author
that taking a step backwards and seeing what actually is the case, based on
some hard data, seems prudent. At the time he agreed to co-author, LWAPP was
the only solution being suggested (other than the standard autonomous AP
model).

So, no, neither I nor my current employer (so far as I know,) have made a
decision about the right solution. It's up to IEEE (and not IETF,
incidently) to do that.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 19 Jul 2004 10:30:44 -0700

Dan,

And more to the point, do you or do you not think the text I posted was an
appropriate substitution for the disputed text in the draft?

            jak

----- Original Message ----- 
From: "Dan Harkins" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Randy Chou" <[email-masked]>; <[email-masked]>
Sent: Monday, July 19, 2004 10:07 AM
Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on
draft-ietf-capwap-arch-03.txt)

> > > 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
> > > I'm beginning to understand why most choose not to reply to your
posts.
> > My
> > > Your security statement I refuted (which you also conveniently cut
out)
> > was
> > > 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
> > > between different devices, the easier it is to manage.  So the
statement
> > in
unauthorized
> > > >The advantage of Split MAC is that the AP is being told what it
should
cluttering
> > > either.   In other networks, VPN over wireless is required and so
unless
> > > 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
unauthorized
and
cluttering
disagreed
management
messages
> > > Could I perhaps ask you to provide me with concrete data that proves
this
> > is
approach
terminate
therefore
> > > I'm obviously not arguing that centralization is better... my point
was
> > that
overall
> > > "value added" service could be provided. One simple example is that
the
> > SME
improves
become
> > > extremely light devices.
> > >
> > > <PRC> But one of the "advantages" of a centralized architecture, is
that
statement)

---

From: Dan Harkins <[email-masked]>
Date: Mon, 19 Jul 2004 10:57:32 -0700

James,

  Your email address is at docomolabs-usa.com. According to this

	http://www.80211info.com/publications/page207-515048.asp

docomoolabs-usa has already purchased product that is the basis of
one of these "competing technical ideas". So unless that press release
is not factual-- it wouldn't be the first and definitely won't be the
last-- your current employer has already made up its mind.

  I am not inferring any bias on you, don't misunderstand me. You
mentioned that your current company, as a customer of networking
equipment, values consensus-based standards like the IETF used to
make but it has already acted in its capacity as a customer of
networking equipment without waiting for any consensus-based
standard to arrive. 

  What your company's official view is vis-a-vis CAPWAP is not really
relevant because at the IETF we're all supposed to be individuals
pursuing the best solution (wink-wink) and not representatives with a
corporate ax to grind. I mentioned your company in the same context
you did-- as a customer of networking equipment-- and in that context
it has already decided.

  Dan. 

On Mon, 19 Jul 2004 10:26:52 PDT you wrote

---

From: "James Kempf" <[email-masked]>
Date: Mon, 19 Jul 2004 11:03:32 -0700

Dan,

I partially swallowed the former bait, but I won't take this barbed hook!
:-)

The issue before the WG is what text to put into the draft. I've put out a
suggestion on some compromise text between Pat and Randy. Randy wants to
hear from other WG members. Instead of questioning my motives, how about
putting out an opinion about what you think the text should be (and post an
alternative if you don't like what I posted)?

            jak

---

From: Dan Harkins <[email-masked]>
Date: Mon, 19 Jul 2004 11:18:27 -0700

James,

  A bad day fishing beats a good day working but if no one is biting
then I might as well go back to work :-)

  I actually preferred Pat's suggestion to just kill the text. But your
suggested text is emminently reasonable and including it will enable the
reader who has not followed this thread to be aware of the debate.

  Dan.

On Mon, 19 Jul 2004 11:03:32 PDT you wrote