Subject: [Capwap] question on LWAPP-03 draft

From: "Puneet Agarwal" <[email-masked]>
Date: Sat, 23 Jul 2005 15:43:57 -0700

Hi Pat,
 
I had a couple of question on the "Division of Labor" in Split MAC (section
11.1.1) in draft-ohara-capwap-lwapp-03.txt:
 
(a) In the draft, it is stated that the 802.11i "Encryption/Decryption" can
happen either on the WTP or on the AC. It further states that the
Fragmentation/Defragmentation occurs on the WTP. If one considers the case
when Encryption/Decryption happens on the AC, then for a 802.11 fragment, I
do not see how the defragmentation can happen on the WTP. Each 802.11
fragment (of an MSDU) needs to be decrypted before it can be defragmented.
The one possible way I can see this happening would be Client-->
WTP--->AC(decrypt)----> WTP(defrag)--->AC--->network but I presume that this
is not what you intended.
 
(b) Secondly, who maintains the counter for the "Sequence Number" sub-field
in the "Sequence-Control" field for frames transmitted to the Client? Is it
the AC or the WTP? It would seem that for split MAC, this should really be
maintained at the AC. 
However in your Split MAC model you mention that "Beacon generation" is a WTP
functionality which would imply that this counter must really be maintained
in the WTP. This would imply that the "Sequence Number" sub-field in the
802.11 frames tunneled from the AC to WTP is effectively ignored by the WTP.
Is this the intended behavior?
 
Thanks.
 
-Puneet

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 24 Jul 2005 08:45:22 -0700

Hopefully the following answers the questions to your satisfaction.
Please let me know if you have any additional comments/questions.

(a) That is precisely the problem that I have been raising regarding
encryption in the AC. Fragmentation rarely (if ever) occurs today. Sure,
it's in the 802.11 spec but no one does it. However, with the
introduction of HCCA fragmentation will become commonplace in order to
satisfy a service period. Therefore, fragmentation will have to occur on
the WTP (which has real-time access to RF conditions), and as a
consequence encryption will have to happen on the WTP.

(b)Good question. The Sequence Number subfield is managed by the WTP,
not the AC. I will need to add that clarification to the next rev of the
document. 

Thanks,

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Saturday, July 23, 2005 3:44 PM
To: [email-masked]; Pat Calhoun (pacalhou)
Subject: question on LWAPP-03 draft

	Hi Pat,
	 
	I had a couple of question on the "Division of Labor" in Split
MAC (section 11.1.1) in draft-ohara-capwap-lwapp-03.txt:
	 
	(a) In the draft, it is stated that the 802.11i
"Encryption/Decryption" can happen either on the WTP or on the AC. It
further states that the Fragmentation/Defragmentation occurs on the WTP.
If one considers the case when Encryption/Decryption happens on the AC,
then for a 802.11 fragment, I do not see how the defragmentation can
happen on the WTP. Each 802.11 fragment (of an MSDU) needs to be
decrypted before it can be defragmented. The one possible way I can see
this happening would be Client--> WTP--->AC(decrypt)---->
WTP(defrag)--->AC--->network but I presume that this is not what you
intended. 

	(b) Secondly, who maintains the counter for the "Sequence
Number" sub-field in the "Sequence-Control" field for frames transmitted
to the Client? Is it the AC or the WTP? It would seem that for split
MAC, this should really be maintained at the AC. 
	However in your Split MAC model you mention that "Beacon
generation" is a WTP functionality which would imply that this counter
must really be maintained in the WTP. This would imply that the
"Sequence Number" sub-field in the 802.11 frames tunneled from the AC to
WTP is effectively ignored by the WTP. Is this the intended behavior?
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 25 Jul 2005 16:33:57 -0700

Hi Pat,

Thanks for your clarifications. A few follow-on comments and a couple of new
questions.

(a) I completely agree with you that with the introduction of HCCA, it makes
sense to have the .11 fragmentation and hence .11i encryption at the WTP. By
the symmetry argument, I presume that you are also implying that .11i
decryption and .11 defragmentation should also happen at the WTP (for LWAPP
Split MAC).

(b) Thanks for clarifying this. As a corollary, it would be great if you
could also state what .11 header fields MUST be valid when sending a .11
frame (in LWAPP) from the AC to the WTP. I assume that, at the minimum, the
Address1, Address2 and Address3 fields MUST be valid. If this is a .11e
enabled client, then the TID field MUST be valid. However what is not clear
is that if the client needs .11i encryption, is the AC required to attach the
.11i dummy CCMP header as well as a dummy MIC to the .11 data frame before
sending it to the WTP (in a LWAPP tunnel)?

(c) While LWAPP tunneling, an AC implementation may decide to fragment at the
.11 level to get over network MTU limits and avoid LWAPP/IP fragmentation (it
seems to be legal in LWAPP though there is no explicit mention in the spec
either allowing/disallowing it). In this case, the WTP implementations will
require valid values in the "Sequence number" and "Fragment number" for
correct LWAPP reassembly - though these may be rewritten by the WTP before
transmission to the Client. Hence it would be great if you could specify
which .11 fields MUST be valid and which fields are ignored by the WTP for
data packets received by the WTP from the AC.

(d) For packets from Client to the network, the WTP will reassemble the
fragmented .11 frames. In order to send the MSDU to the AC, the WTP would
need to create a new .11 header (before encapsulation the frame into a LWAPP
tunnel) but without fragments (ie .11 Header.More_Frag = 0). Is this a
correct assumption?
Similarly, if the Client's frame came in with .11i encryption, then will the
WTP send the MSDU to the AC with a dummy .11i CCMP header/MIC or will it
remove the .11i CCMP header. Hence it would be great if you can clarify which
.11 header fields must be valid when .11 data frames are sent from WTP to AC
(in LWAPP).

Thanks.

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Sunday, July 24, 2005 8:45 AM
To: Puneet Agarwal; [email-masked]
Subject: RE: question on LWAPP-03 draft

Hopefully the following answers the questions to your satisfaction. Please
let me know if you have any additional comments/questions.

(a) That is precisely the problem that I have been raising regarding
encryption in the AC. Fragmentation rarely (if ever) occurs today. Sure, it's
in the 802.11 spec but no one does it. However, with the introduction of HCCA
fragmentation will become commonplace in order to satisfy a service period.
Therefore, fragmentation will have to occur on the WTP (which has real-time
access to RF conditions), and as a consequence encryption will have to happen
on the WTP.

(b)Good question. The Sequence Number subfield is managed by the WTP, not the
AC. I will need to add that clarification to the next rev of the document. 

Thanks,

Pat Calhoun

	Hi Pat,
	 
	I had a couple of question on the "Division of Labor" in Split MAC
(section 11.1.1) in draft-ohara-capwap-lwapp-03.txt:
	 
	(a) In the draft, it is stated that the 802.11i
"Encryption/Decryption" can happen either on the WTP or on the AC. It further
states that the Fragmentation/Defragmentation occurs on the WTP. If one
considers the case when Encryption/Decryption happens on the AC, then for a
802.11 fragment, I do not see how the defragmentation can happen on the WTP.
Each 802.11 fragment (of an MSDU) needs to be decrypted before it can be
defragmented. The one possible way I can see this happening would be
Client--> WTP--->AC(decrypt)----> WTP(defrag)--->AC--->network but I presume
that this is not what you intended. 

	(b) Secondly, who maintains the counter for the "Sequence Number"
sub-field in the "Sequence-Control" field for frames transmitted to the
Client? Is it the AC or the WTP? It would seem that for split MAC, this
should really be maintained at the AC. 
	However in your Split MAC model you mention that "Beacon generation"
is a WTP functionality which would imply that this counter must really be
maintained in the WTP. This would imply that the "Sequence Number" sub-field
in the 802.11 frames tunneled from the AC to WTP is effectively ignored by
the WTP. Is this the intended behavior?

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 27 Jul 2005 06:40:16 -0700

See below

Pat Calhoun

> Sent: Monday, July 25, 2005 4:34 PM
> To: Pat Calhoun (pacalhou); [email-masked]
> Thanks for your clarifications. A few follow-on comments and 
> a couple of new questions.
> 
> (a) I completely agree with you that with the introduction of 
> HCCA, it makes sense to have the .11 fragmentation and hence 
> .11i encryption at the WTP. By the symmetry argument, I 
> presume that you are also implying that .11i decryption and 
> .11 defragmentation should also happen at the WTP (for LWAPP 
> Split MAC).
<PRC> That is correct. Note that LWAPP supports the AC providing this
feature, with the restriction that HCCA cannot be used (and this is not
an LWAPP limitation, this is a technology limitation for any protocol
that encrypts in the AC).

> 
> (b) Thanks for clarifying this. As a corollary, it would be 
> great if you could also state what .11 header fields MUST be 
> valid when sending a .11 frame (in LWAPP) from the AC to the 
> WTP. I assume that, at the minimum, the Address1, Address2 
> and Address3 fields MUST be valid. If this is a .11e enabled 
> client, then the TID field MUST be valid. However what is not 
> clear is that if the client needs .11i encryption, is the AC 
> required to attach the .11i dummy CCMP header as well as a 
> dummy MIC to the .11 data frame before sending it to the WTP 
> (in a LWAPP tunnel)?
<PRC> Good point. Today, all of the address and 802.11e TID fields must
be present,
and include the proper values. However, the encryption pad is not
present if encryption
is done in the WTP. I will update the draft to make this explicit.

> .11 level to get over network MTU limits and avoid LWAPP/IP 
> fragmentation (it seems to be legal in LWAPP though there is 
> no explicit mention in the spec either allowing/disallowing 
> it). In this case, the WTP implementations will require valid 
> values in the "Sequence number" and "Fragment number" for 
> correct LWAPP reassembly - though these may be rewritten by 
> the WTP before transmission to the Client. Hence it would be 
> great if you could specify which .11 fields MUST be valid and 
> which fields are ignored by the WTP for data packets received 
> by the WTP from the AC.
<PRC> hmm.... We don't assume this because we cannot control the client
- hence you have this problem in traffic from the station. I believe the
current model the protocol provides is more reliable.

> 
> (d) For packets from Client to the network, the WTP will 
> reassemble the fragmented .11 frames. In order to send the 
> MSDU to the AC, the WTP would need to create a new .11 header 
> (before encapsulation the frame into a LWAPP
> tunnel) but without fragments (ie .11 Header.More_Frag = 0). 
> Is this a correct assumption?
> Similarly, if the Client's frame came in with .11i 
> encryption, then will the WTP send the MSDU to the AC with a 
> dummy .11i CCMP header/MIC or will it remove the .11i CCMP 
> header. Hence it would be great if you can clarify which
> .11 header fields must be valid when .11 data frames are sent 
> from WTP to AC (in LWAPP).
<PRC> Correct, I believe this goes back to your point #2 (above), which
we will address in the next version of the draft.
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap