From alper@docomolabs-usa.com Tue Jul 1 02:45:31 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Mon, 30 Jun 2003 18:45:31 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: <40301581B2962B448690A023EF16DFE1DC4F3D@bsn-mail-01.bstormnetworks.com> Message-ID: >>> PANA can't help upgrade AP firmware. >> >> That is not what I am suggesting. >> >> If there is a problem or risk with using link-layer authentication and >> ciphering, and if you think the solution is to perform these operations on >> the access router, then you can use PANA for that. PANA enables you to do >> the authentication exchange between the host and the access router. You can >> use it to enable link-layer ciphers. But if you don't even want to use L2 >> ciphers, then you can use PANA to enable IPsec-based per-packet access >> control in your access network. > > I think this discussion is required in the PANA mailing list, so I will > refrain from contributing to cross-mailing list discussions, but suffice it to > say that IPSec and L2 mechanisms already exist, so adding another level of > negotiation on existing clients makes it rather difficult to deploy. But I > will admit that I am completely out of touch as to the latest progress that > PANA has made since the last BOF. I didn't quite get your point here regarding adding another level. (more precisely, what level is that?). Anyways, the latest PANA documents can be found at: http://www.ietf.org/html.charters/pana-charter.html Alper From dmolnar@legra.com Wed Jul 2 16:15:34 2003 From: dmolnar@legra.com (David Molnar) Date: Wed, 2 Jul 2003 11:15:34 -0400 Subject: [Lwapp] SessionID size and rekeying in -033 Message-ID: <004501c340ac$c92b0c20$b90ba8c0@student.harvard.edu> Hi everyone, I looked at the new -033 draft and note that the rekeying has been fixed to go from AR to AP. Thanks! Revisiting something already discussed by Nehru -- I think we have a potential problem with SessionID collisions in rekey messages, because the SessionID is only 32 bits long. This means that if two APs generate new independent random SessionIDs, the chance of them being the same is 1/2^16 by the birthday paradox. Since the SessionID is the only thing preventing replay or redirection attacks in rekeying, this seems like a problem. Here are some suggestions for fixes: 1) Increase sessionID to 128 bits, so chance of collision is 1/2^64. I think 64 bits with chance of collision 1/2^32 is not enough of a margin. The problem here is that this expands all messages using the SessionID. 2) Add a separate cryptographic nonce of at least 128 bits to the rekey message. The AP would treat the nonce identically to the way the -033 draft specifies it would treat the SessionID. I prefer this fix. 3) Include the AP's "name" in S1, so messages intended for one AP cannot be redirected to another AP. Then it wouldn't matter if two different APs have the same SessionID. The problem here is deciding what "name" means in the case that the AP does not have a certificate. -David From scott@airespace.com Wed Jul 2 17:48:19 2003 From: scott@airespace.com (Scott G. Kelly) Date: Wed, 02 Jul 2003 09:48:19 -0700 Subject: [Lwapp] SessionID size and rekeying in -033 References: <004501c340ac$c92b0c20$b90ba8c0@student.harvard.edu> Message-ID: <3F030CD3.9050008@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, David Molnar wrote: | Hi everyone, | | I looked at the new -033 draft and note that the rekeying has been fixed to | go from AR to AP. Thanks! | | Revisiting something already discussed by Nehru -- I think we have a | potential problem with SessionID collisions in rekey messages, because the | SessionID is only 32 bits long. This means that if two APs generate new | independent random SessionIDs, the chance of them being the same is 1/2^16 | by the birthday paradox. Since the SessionID is the only thing preventing | replay or redirection attacks in rekeying, this seems like a problem. I'm not a statistician, but I think the birthday paradox only applies here if you have collected lots of session IDs for which you know the keys. I think that if you know the keys for only one session ID, and you assume the session IDs are generated (i.e. distributed) randomly, then the odds of a collision are (since they are independent) 1/2^32. I might have made a math error, but I think you'd have to have over 77000 known sessionID/Key pairs before the odds would be around 1/2^16. We should also note that in order for a session id collision to be meaningful, the attacker must have compromised a key pair associated with that session id. This is not trivial, and if this has occurred, you probably have bigger problems. This should temper our estimation of how much effort it's worth to mitigate this threat. Another important point to note is that the session id in rekey messages is encrypted/authenticated with the current session keys, so the only way an observer could know this value in realtime (i.e. prior to completion of the rekey operation) and actually substitute the keys they know is if they've already compromised the existing session encryption key, and can effect a MiM attack. Given the high cost (and seemingly low probability) of this attack, is it really worth it to expend effort on mitigating it? I'm not sure, but my feeling at this point is that it is not. If it turns out that it is, then I like your fix #2 below. Scott | Here are some suggestions for fixes: | | 1) Increase sessionID to 128 bits, so chance of collision is 1/2^64. | I think 64 bits with chance of collision 1/2^32 is not enough of a | margin. | The problem here is that this expands all messages using the SessionID. | | 2) Add a separate cryptographic nonce of at least 128 bits to the | rekey message. The AP would treat the nonce identically to the way | the -033 draft specifies it would treat the SessionID. I prefer this | fix. | | 3) Include the AP's "name" in S1, so messages intended for one AP | cannot be redirected to another AP. Then it wouldn't matter if two | different APs have the same SessionID. The problem here is deciding | what "name" means in the case that the AP does not have a certificate. | | -David | | _______________________________________________ | Lwapp mailing list | Lwapp@frascone.com | http://mail.frascone.com/mailman/listinfo/lwapp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/AwzTMtIdhO0pgN4RAqyoAKCpvG/jE+ZFBdd+aHhPcKL35EeOygCgrwe6 KmHHQnsXTW9uy3r373doX5w= =u5BZ -----END PGP SIGNATURE----- From scott@airespace.com Wed Jul 2 21:12:45 2003 From: scott@airespace.com (Scott G. Kelly) Date: Wed, 02 Jul 2003 13:12:45 -0700 Subject: [Lwapp] SessionID size and rekeying in -033 References: <004501c340ac$c92b0c20$b90ba8c0@student.harvard.edu> <3F030CD3.9050008@airespace.com> Message-ID: <3F033CBD.50502@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I looked at the math again, and I think I made a mistake. Using P(collision) = 1 - exp(-n^2/2m) {from HAC, page 53} where n = number of known SessionID/key pairs m = total # possible session IDs (2^32) Solving for n when P(collision) = 1/2^16, 1 - exp(-n^2/(2^33)) = 1/2^16 exp(-n^2/2^33) = 0.999985 n = sqrt((-2^33) ln(0.999985)) = 362.04 So, if you collect 362 known sessionID/key pairs, the odds of a collision will be slightly less than 1/2^16, assuming one of the known pairs is for the session you are about to rekey (so that you can see the proposed sessionID when the AP sends it to the AR). Still a rather daunting task, and if someone is able to acquire this many session keys, you *really* have some serious security issues that won't be solved by increasing the nonce space. Scott Scott G. Kelly wrote: | Hi David, | | David Molnar wrote: | | Hi everyone, | | | | I looked at the new -033 draft and note that the rekeying has been | fixed to | | go from AR to AP. Thanks! | | | | Revisiting something already discussed by Nehru -- I think we have a | | potential problem with SessionID collisions in rekey messages, because | the | | SessionID is only 32 bits long. This means that if two APs generate new | | independent random SessionIDs, the chance of them being the same is | 1/2^16 | | by the birthday paradox. Since the SessionID is the only thing preventing | | replay or redirection attacks in rekeying, this seems like a problem. | | I'm not a statistician, but I think the birthday paradox only applies | here if you have collected lots of session IDs for which you know the | keys. I think that if you know the keys for only one session ID, and you | assume the session IDs are generated (i.e. distributed) randomly, then | the odds of a collision are (since they are independent) 1/2^32. I might | have made a math error, but I think you'd have to have over 77000 known | sessionID/Key pairs before the odds would be around 1/2^16. | | We should also note that in order for a session id collision to be | meaningful, the attacker must have compromised a key pair associated | with that session id. This is not trivial, and if this has occurred, you | probably have bigger problems. This should temper our estimation of how | much effort it's worth to mitigate this threat. | | Another important point to note is that the session id in rekey messages | is encrypted/authenticated with the current session keys, so the only | way an observer could know this value in realtime (i.e. prior to | completion of the rekey operation) and actually substitute the keys they | know is if they've already compromised the existing session encryption | key, and can effect a MiM attack. | | Given the high cost (and seemingly low probability) of this attack, is | it really worth it to expend effort on mitigating it? I'm not sure, but | my feeling at this point is that it is not. If it turns out that it is, | then I like your fix #2 below. | | Scott | | | Here are some suggestions for fixes: | | | | 1) Increase sessionID to 128 bits, so chance of collision is 1/2^64. | | I think 64 bits with chance of collision 1/2^32 is not enough of a | | margin. | | The problem here is that this expands all messages using the | SessionID. | | | | 2) Add a separate cryptographic nonce of at least 128 bits to the | | rekey message. The AP would treat the nonce identically to the way | | the -033 draft specifies it would treat the SessionID. I prefer this | | fix. | | | | 3) Include the AP's "name" in S1, so messages intended for one AP | | cannot be redirected to another AP. Then it wouldn't matter if two | | different APs have the same SessionID. The problem here is deciding | | what "name" means in the case that the AP does not have a | certificate. | | | | -David | | | | _______________________________________________ | | Lwapp mailing list | | Lwapp@frascone.com | | http://mail.frascone.com/mailman/listinfo/lwapp | _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/Azy9MtIdhO0pgN4RAnyVAJ4mNPyQxOLRR1HIykc5CPhSznxRmACcCRrE 65SQvyZ06MW9VbuguC6GOGU= =6Ct7 -----END PGP SIGNATURE----- From dmolnar@legra.com Wed Jul 2 21:43:10 2003 From: dmolnar@legra.com (David Molnar) Date: Wed, 2 Jul 2003 16:43:10 -0400 Subject: [Lwapp] SessionID size and rekeying in -033 References: <004501c340ac$c92b0c20$b90ba8c0@student.harvard.edu> <3F030CD3.9050008@airespace.com> <3F033CBD.50502@airespace.com> Message-ID: <002f01c340da$8cc6e8c0$b90ba8c0@student.harvard.edu> > n = sqrt((-2^33) ln(0.999985)) = 362.04 > > So, if you collect 362 known sessionID/key pairs, the odds of a > collision will be slightly less than 1/2^16, assuming one of the known > pairs is for the session you are about to rekey (so that you can see the > proposed sessionID when the AP sends it to the AR). Still a rather > daunting task, and if someone is able to acquire this many session keys, > you *really* have some serious security issues that won't be solved by > increasing the nonce space. Great - thanks for your note! Two things make me uncomfortable with "well, no one could ever get that many session keys" in this context. 1) The draft specifies rekey messages in part to provide perfect forward secrecy. In the PFS context, we assume that current keys have already been compromised. If we start saying, "oh, it's too hard for someone to get a current session key," it's unclear to me what PFS is still doing in the draft. If it's there, then it's unclear to me where we draw the line. 2) Relying solely on the encrypted transport to provide protection against a potential replay or redirect in the rekey message makes me very nervous. It's true that the only way we can think of now that a collision could be exploited requires gathering all these session keys, but perhaps there is something we aren't thinking of. If there is a fix with acceptable overhead, it should be considered. After all, this is a draft standard; it'll be easier to change now than later. > | completion of the rekey operation) and actually substitute the keys they > | know is if they've already compromised the existing session encryption > | key, and can effect a MiM attack. Well, as I understand it, the point of the rekey message is that it is *not* susceptible to a MiM attack even if the current session key is compromised. That is why the public key of the AR and public key of the AP are employed - the MiM does not know the private keys of the AR or AP and so they *should* be able to mutually authenticate and agree on the new session key even in the presence of a MiM. Otherwise you could acheive the equivalent result at much less cost by simply having the AR send the new key to the AP encrypted with the old session key and forget about PFS. > | Given the high cost (and seemingly low probability) of this attack, is > | it really worth it to expend effort on mitigating it? I'm not sure, but The other side of the question: How much effort is it to add an extra 128-bit nonce to the draft? It doesn't seem like much effort to me, but I may be missing something. -David From pcalhoun@airespace.com Wed Jul 2 21:54:41 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 2 Jul 2003 13:54:41 -0700 Subject: [Lwapp] CAPWAP BOF Message-ID: <40301581B2962B448690A023EF16DFE1DC5071@bsn-mail-01.bstormnetworks.com> QWxsLA0KIA0KVGhlcmUgaXMgYSBCT0YgaW4gVmllbm5hIHRvIGRpc2N1c3MgdGhlIExXQVBQIHBy b2JsZW0gc3BhY2UuDQogDQpQYXRDDQotLS0tDQpCT0YgTkFNRSAmIEFDUk9OWU06IENvbnRyb2wg QW5kIFByb3Zpc2lvbmluZyBvZiBXaXJlbGVzcyBBY2Nlc3MgUG9pbnRzDQogICAgICAgICAgICAg ICAgICAgIChjYXB3YXApDQpBUkVBOiAgICAgICAgICAgICAgIE9QUw0KQk9GIENIQUlSKFMpOiAg ICAgICBEb3JvdGh5IFN0YW5sZXkgKGRzdGFubGV5QGFnZXJlLmNvbSkNCiAgICAgICAgICAgICAg ICAgICAgSmFtZXMgS2VtcGYgKGtlbXBmQGRvY29tb2xhYnMtdXNhLmNvbSkNCg0KDQpNQUlMSU5H IExJU1Q6DQpMaXN0OiAgICAgICAgICAgICAgIGx3YXBwQGZyYXNjb25lLmNvbQ0KU3Vic2NyaWJl OiAgICAgICAgICBsd2FwcC1yZXF1ZXN0QGZyYXNjb25lLmNvbQ0KQm9keTogICAgICAgICAgICAg ICBzdWJzY3JpYmUgaW4gU3ViamVjdCBsaW5lDQpBcmNoaXZlOiAgICAgICAgICAgIGh0dHA6Ly9t YWlsLmZyYXNjb25lLmNvbS9waXBlcm1haWwvcHVibGljL2x3YXBwLyA8aHR0cDovL21haWwuZnJh c2NvbmUuY29tL3BpcGVybWFpbC9wdWJsaWMvbHdhcHAvPiANCg0KDQpBR0VOREE6DQogICAgSW50 cm8gYW5kIEFnZW5kYSBCYXNoaW5nICg1IG1pbikNCiAgICBMV0FQUCAoUGF0IENhbGhvdW4pICgx MCBtaW4pDQogICAgU05NUCAoTWFyY3VzIEJydW5uZXIpICgxMCBtaW4pDQogICAgQWNjZXNzcyBQ b2ludCBEaXNjb3ZlcnkgKEluZGVycHJlZXQgU2luZ2gpICgxMCBtaW4pLg0KICAgIFNlY3VyaXR5 IGFuZCBDZXJ0aWZpY2F0ZSBQcm92aXNpb25pbmcgKERhdmlkIE1vbG5hcikgKDEwIG1pbikNCiAg ICBEaXNjdXNzaW9uICg0MCBtaW4pDQogICAgU3VtbWFyeSBhbmQgTmV4dCBTdGVwcyAoMTAgbWlu KQ0KDQoNCkZVTEwgREVTQ1JJUFRJT046DQoNCkNvbnZlbnRpb25hbCBJRVRGIHdpc2RvbSBoYXMg aXQgdGhhdCB3aXJlbGVzcyBhY2Nlc3MgcG9pbnRzIGZvcg0Kbm9uLXByb3Zpc2lvbmVkIHdpcmVs ZXNzIG1lZGlhIGFyZSBubyBtb3JlIHRoYW4gc2ltcGxlIExheWVyIDIgYnJpZGdlcw0KdGhhdCB0 cmFuc3BhcmVudGx5IGZvcndhcmQgcGFja2V0cyBiZXR3ZWVuIHRoZSB3aXJlZCBhbmQgd2lyZWxl c3MNCmxpbmtzLiBXaGlsZSB0aGlzIGlzIGluZGVlZCB0aGVpciBwcmltYXJ5IGZ1bmN0aW9uLCBp biByZWFsaXR5LCBoaWdoZXINCmxheWVyIGZ1bmN0aW9ucyBoYXZlIGJlZW4gZ3JhZHVhbGx5IG1p Z3JhdGluZyBpbnRvIHN1Y2ggYWNjZXNzIHBvaW50cy4NCkFuIGV4YW1wbGUgaXMgbmV0d29yayBh Y2Nlc3Mgc2VydmVyIGZ1bmN0aW9uYWxpdHkuIE1hbmFnaW5nIHRoaXMNCmZ1bmN0aW9uYWxpdHks IGl0cyBpbnRlcmFjdGlvbiBiZXR3ZWVuIGFjY2VzcyBwb2ludHMsIGFuZCBiZXR3ZWVuDQphY2Nl c3MgcG9pbnRzIGFuZCBhY2Nlc3Mgcm91dGVycyBoYXMgYmVjb21lIGluY3JlYXNpbmdseSBkaWZm aWN1bHQuDQpCZWNhdXNlIHNvbWUgb2YgdGhlIGZ1bmN0aW9ucyBpbnZvbHZlIGV4Y2hhbmdlIG9m IExheWVyIDIgaW5mb3JtYXRpb24sDQpJRVRGIGhhcyB0cmFkaXRpb25hbGx5IG1haW50YWluZWQg dGhhdCBpdCBpcyAiTm90IE91ciBQcm9ibGVtIi4gT24gdGhlDQpvdGhlciBoYW5kLCBiZWNhdXNl IG1hbnkgb2YgdGhlIGZ1bmN0aW9ucyBlaXRoZXIgdXNlIG9yIHByb3ZpZGUNCnNlcnZpY2VzIHdp dGggYSBMYXllciAzIGNvbXBvbmVudCwgdGhlIHJlbGV2YW50IExheWVyIDIgc3RhbmRhcmRpemF0 aW9uDQpib2RpZXMgKHN1Y2ggYXMgSUVFRSBmb3IgODAyLjExKSBoYXZlIGJlZW4gcmVsdWN0YW50 IHRvIHN0ZXAgZm9yd2FyZA0KYW5kIG93biB0aGUgcHJvYmxlbSBlaXRoZXIuDQoNClJlY2VudGx5 LCBuZXh0IGdlbmVyYXRpb24gODAyLjExIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgKGFsc28gcmVm ZXJyZWQNCnRvIGFzIFdMQU4gc3dpdGNoZXMpIGhhdmUgc2VlbiBzaWduaWZpY2FudCBpbnRlcmVz dCBpbiB0aGUgbWFya2V0Lg0KU2V2ZXJhbCBjb21wYW5pZXMsIGJvdGggc3RhcnR1cHMgYW5kIGlu Y3VtYmVudHMgaW4gdGhlIFdMQU4gc3BhY2UsIGhhdmUNCmFubm91bmNlZCwgb3IgYXJlIHNoaXBw aW5nIHByb2R1Y3RzLiBNb3N0IG9mIHRoZXNlIHByb2R1Y3RzIGhhdmUgYQ0Kc2ltaWxhciBhcmNo aXRlY3R1cmUgd2hpY2ggc2ltcGxpZmllcyB0aGUgYWNjZXNzIHBvaW50cywgYnV0IGRvZXMgbm90 DQpyZW1vdmUgdGhlIHByb2JsZW0gb2YgbWFuYWdpbmcgdGhlIGludGVyYWN0aW9uIHdpdGggdGhl IElQIG5ldHdvcmsuDQpHaXZlbiB0aGUgaW50ZXJlc3QgaW4gdGhlIG1hcmtldCBmb3Igc3VjaCBw cm9kdWN0cywgdGhlcmUgaXMgbm8gZG91YnQNCnRoYXQgc3RhbmRhcmRpemluZyB0aGUgaW50ZXJm YWNlIGJldHdlZW4gdGhlIEFQIGFuZCB0aGUgY29udHJvbGxlciAob3INCldMQU4gc3dpdGNoKSB3 b3VsZCBiZW5lZml0IHRoZSBJbnRlcm5ldCBjb21tdW5pdHkuIFdvdWxkIGRlZmluaW5nIGEgbmV3 DQpMYXllciAyIGluZGVwZW5kZW50IHByb3RvY29sIHRvIG1hbmFnZSB3aXJlbGVzcyBhY2Nlc3Mg cG9pbnRzIGJvdGgNCmR5bmFtaWNhbGx5IGFuZCBzdGF0aWNhbGx5IGhlbHA/IENhbiBleGlzdGlu ZyBJRVRGIHNvbHV0aW9ucyBjb250cmlidXRlLA0KYW5kLCBpZiBzbywgaXMgdGhlcmUgYW55IExh eWVyIDIgaW5kZXBlbmRlbnQgd29yayB0aGF0IElFVEYgbWlnaHQgZG8gdG8NCmFkYXB0IHRob3Nl IHNvbHV0aW9ucyB0byB0aGUgcHJvYmxlbSBzcGFjZT8NCg0KV2lyZWxlc3MgYWNjZXNzIHBvaW50 cyBhbHNvIGhhdmUgYWRkaXRpb25hbCBzZWN1cml0eSBuZWVkcyB0aGF0IGFyZQ0KaWxsIG1ldCBi eSByZWdhcmRpbmcgdGhlbSBhcyBzaW1wbGUgTGF5ZXIgMiBicmlkZ2VzLiBCZWNhdXNlIHN1Y2gN CmFjY2VzcyBwb2ludHMgYXJlIGVhc3kgdG8gZGVwbG95IGJ5IGRlc2lnbiwgc2VjdXJpdHkgcHJv dmlzaW9uaW5nIGlzDQpkaWZmaWN1bHQgdG8gYWNoaWV2ZS4gSG93IGRvZXMgdGhlIG5ldHdvcmsg cHJvdmlkZXIncyByb3V0ZXIgdmVyaWZ5DQp0aGF0IGEgcGFydGljdWxhciBhY2Nlc3MgcG9pbnQg aXMgYXV0aG9yaXplZCB0byBiZSBvbiB0aGUgbmV0d29yaz8NCldpcmVsZXNzIGFjY2VzcyBwb2lu dHMgYXJlIGFsc28gYmVpbmcgY2FsbGVkIHVwb24gdG8gcHJvdmlkZQ0KaW5jcmVhc2luZ2x5IG1v cmUgY29tcGxleCBzZWN1cml0eSBmb3IgaG9zdHMsIGFwcHJvYWNoaW5nIHRoYXQNCnByb3ZpZGVk IGJ5IHRoZSBoaWdobHkgcHJvdmlzaW9uZWQgd2lyZWxlc3MgbWVkaWEgaW4gY2VsbHVsYXINCm5l dHdvcmtzLiBDYW4gdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZXNlIGZ1bmN0aW9ucyBiZSBzaW1w bGlmaWVkIGJ5DQpjZW50cmFsaXppbmcgdGhlIGludGVsbGlnZW5jZSBhbmQgZGlzdHJpYnV0aW5n IHRoZSBSRiBpbnRlcmZhY2VzPw0KDQpJbiB0aGlzIEJPRiwgd2Ugd2lsbCBkaXNjdXNzIHRoZXNl IGlzc3VlcyBhbmQgYXR0ZW1wdCB0byBjb21lIHRvIHNvbWUNCmNvbmNsdXNpb25zIGFib3V0IHdo YXQgSUVURiBtaWdodCBvciBtaWdodCBub3QgZG8gdG8gaGVscCBhZGRyZXNzIHRoZQ0KcHJvYmxl bS4NCg0KUkVBRElORyBMSVNUOg0KDQpMaWdodHdlaWdodCBBY2Nlc3MgUG9pbnQgUHJvdG9jb2wN Cg0KaHR0cDovL3d3dy5haXJlc3BhY2UuY29tL2Z0cC9kcmFmdC1jYWxob3VuLXNlYW1vYnktbHdh cHAtMDMudHh0IDxodHRwOi8vd3d3LmFpcmVzcGFjZS5jb20vZnRwL2RyYWZ0LWNhbGhvdW4tc2Vh bW9ieS1sd2FwcC0wMy50eHQ+IA0KDQoNClByb3Bvc2VkIFNvbHV0aW9uczoNClRCRA0KDQpQcm9w b3NlZCBXRyBDaGFydGVyOg0KVEJEDQoNCg0K From dmolnar@legra.com Wed Jul 2 21:56:42 2003 From: dmolnar@legra.com (David Molnar) Date: Wed, 2 Jul 2003 16:56:42 -0400 Subject: [Lwapp] SessionID size and rekeying in -033 References: <004501c340ac$c92b0c20$b90ba8c0@student.harvard.edu> <3F030CD3.9050008@airespace.com> <3F033CBD.50502@airespace.com> Message-ID: <005001c340dc$7108f0e0$b90ba8c0@student.harvard.edu> Hi Scott, > So, if you collect 362 known sessionID/key pairs, the odds of a > collision will be slightly less than 1/2^16, assuming one of the known > pairs is for the session you are about to rekey (so that you can see the > proposed sessionID when the AP sends it to the AR). Still a rather I just noticed something that leads me to believe this is not an issue after all. Namely, even if there is a Session ID collision between two different APs, the AR signs C1, and C1 is encrypted with a specific AP's public key. This means that you cannot forward messages from one AP with the same Session ID to another AP with the same Session ID; the new AP can't decrypt the forwarded C1 correctly. In this case, you only need to worry about replaying Session IDs and C1s from the same AP, which of course has probability 1/2^32. That is still a little low for my taste, but it's probably OK as long as the adversary has no way to force the AP and AR to rekey. Sorry for the confusion. :\ By the way, is it "SessionID" or "Session ID" ? Both are used in the document. thanks, -David From scott@airespace.com Wed Jul 2 22:19:52 2003 From: scott@airespace.com (Scott G. Kelly) Date: Wed, 02 Jul 2003 14:19:52 -0700 Subject: [Lwapp] SessionID size and rekeying in -033 References: <004501c340ac$c92b0c20$b90ba8c0@student.harvard.edu> <3F030CD3.9050008@airespace.com> <3F033CBD.50502@airespace.com> <005001c340dc$7108f0e0$b90ba8c0@student.harvard.edu> Message-ID: <3F034C78.6000904@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, David Molnar wrote: | Hi Scott, | | |>So, if you collect 362 known sessionID/key pairs, the odds of a |>collision will be slightly less than 1/2^16, assuming one of the known |>pairs is for the session you are about to rekey (so that you can see the |>proposed sessionID when the AP sends it to the AR). Still a rather | | | I just noticed something that leads me to believe this is not an issue after | all. Namely, even if there is a Session ID collision between two different | APs, the AR signs C1, and C1 is encrypted with a specific AP's public key. | This means that you cannot forward messages from one AP with the same | Session ID to another AP with the same Session ID; the new AP can't decrypt | the forwarded C1 correctly. | Right. | In this case, you only need to worry about replaying Session IDs and C1s | from the same AP, which of course has probability 1/2^32. That is still a | little low for my taste, but it's probably OK as long as the adversary has | no way to force the AP and AR to rekey. | | Sorry for the confusion. :\ As for your other point (PFS is in the draft, and why is it there if it's not necessary?), perhaps this should be revisited. Honestly, we added it because we could, it didn't seem to add much additional overhead, and it provides a way to recover from a compromised session. Not necessarily in that order, but a bit capriciously nonetheless. Actually, someone here said it was a bit anal at the time. I agree that it makes for a point of confusion. On the other hand, it is the public key encryption of the session keys which prevents the replay of one AP's session id and corresponding keys to another AP, isn't it? Maybe we should remove the language about PFS and replace it with a statement of this point. | By the way, is it "SessionID" or "Session ID" ? Both are used in the | document. I guess it depends on what language you're speaking (C vs English). I don't really have a preference for conversational use. I used sessionID in my emails in this thread so that I could combine it into one string when saying "sessionID/keys", but using two words seems like better English :-) Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/A0x3MtIdhO0pgN4RAtn6AKDyZxoILPVR3DtRBVRc+FXZHcxOUgCfet9d y93s/TWPUt37Yg4XJizHhIo= =L/Wa -----END PGP SIGNATURE----- From scott@airespace.com Thu Jul 3 18:51:07 2003 From: scott@airespace.com (Scott G. Kelly) Date: Thu, 03 Jul 2003 10:51:07 -0700 Subject: [Fwd: Re: [Lwapp] SessionID size and rekeying in -033] Message-ID: <3F046D0B.8070206@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 meant to cc the list on this... - -------- Original Message -------- Subject: Re: [Lwapp] SessionID size and rekeying in -033 Date: Thu, 03 Jul 2003 10:49:59 -0700 From: "Scott G. Kelly" Organization: Airespace To: David Molnar References: <004501c340ac$c92b0c20$b90ba8c0@student.harvard.edu> <3F030CD3.9050008@airespace.com> <3F033CBD.50502@airespace.com> <005001c340dc$7108f0e0$b90ba8c0@student.harvard.edu> <3F034C78.6000904@airespace.com> <001d01c34189$b8cd67a0$b90ba8c0@student.harvard.edu> Hi David, David Molnar wrote: |>On the other hand, it is the public |>key encryption of the session keys which prevents the replay of one AP's |>session id and corresponding keys to another AP, isn't it? Maybe we |>should remove the language about PFS and replace it with a statement of |>this point. | | | Yes, but the public key encryption is not necessary for this function. | Redirection of keys could be prevented simply by naming the target AP in S1 | and requiring that APs check that keys are addressed to them. Public-key | encryption is necessary only if we believe the current session key (but not | long-term private keys) is compromised and an adversary is reading current | traffic. I agree that there are other ways, but public key encryption (and certificates) solves the problem of name binding rather nicely. And as noted, it has the side effect of providing a form of PFS in the process. If you want to do this without public key encryption (e.g. with preshared keys), there is a name-binding issue. Each AP will need a unique preshared key and a unique name, and the AR must identify which psk to use based on the AP name. It is essentially a poor man's pki. In the case of public key encryption, we get this name binding for free, so to speak, since it is implicit. So, I guess I'm not clear what you're trying to say here. I was suggesting that we remove the PFS language, or at least change the language so that PFS is not the stated primary motivation for using public key encryption; in actuality, PK encryption binds the AP to the session-id/key pair. Am I misunderstanding? Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/BG0LMtIdhO0pgN4RAvRQAKCrgR7BsRBl1i/46o4A5LCXrM6ETACg9nZR hz/3e3P6DDeKv4k+bgyGTOA= =gFfE -----END PGP SIGNATURE----- From dmolnar@legra.com Thu Jul 3 19:24:26 2003 From: dmolnar@legra.com (David Molnar) Date: Thu, 3 Jul 2003 14:24:26 -0400 Subject: [Lwapp] SessionID size and rekeying in -033] References: <3F046D0B.8070206@airespace.com> Message-ID: <003701c34190$5614b6c0$b90ba8c0@student.harvard.edu> Hi Scott, > | Yes, but the public key encryption is not necessary for this function. > | Redirection of keys could be prevented simply by naming the target AP > in S1 > | and requiring that APs check that keys are addressed to them. Public-key > | encryption is necessary only if we believe the current session key > (but not > | long-term private keys) is compromised and an adversary is reading current > | traffic. > > I agree that there are other ways, but public key encryption (and > certificates) solves the problem of name binding rather nicely. And as > noted, it has the side effect of providing a form of PFS in the process. Yes, that's correct. Sorry if I was confusing -- my point was only that if we decide to drop the PFS requirement, then public-key encryption is no longer necessary in rekeying and we can make it lighter. If we stick to the context where the AP and AR have certificates, then the certificate itself is a distinguished name for each AP. Therefore we could name the AP in the session by naming its certificate and save the heavyweight public-key decryption. That's all. The case where the AP and AR have pre-shared secrets and no certificates is a separate issue, I think. What I was thinking of was the context where certificates have already been used to establish a session key and we assume that the session key is not compromised. In this case, rekeying is used to avoid encrypting too much traffic with the same key. -David From scott@airespace.com Thu Jul 3 23:15:30 2003 From: scott@airespace.com (Scott G. Kelly) Date: Thu, 03 Jul 2003 15:15:30 -0700 Subject: [Lwapp] SessionID size and rekeying in -033] References: <3F046D0B.8070206@airespace.com> <003701c34190$5614b6c0$b90ba8c0@student.harvard.edu> Message-ID: <3F04AB02.2000206@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, David Molnar wrote: |>I agree that there are other ways, but public key encryption (and |>certificates) solves the problem of name binding rather nicely. And as |>noted, it has the side effect of providing a form of PFS in the process. | | | Yes, that's correct. Sorry if I was confusing -- my point was only that if | we decide to drop the PFS requirement, then public-key encryption is no | longer necessary in rekeying and we can make it lighter. If we stick to the | context where the AP and AR have certificates, then the certificate itself | is a distinguished name for each AP. Therefore we could name the AP in the | session by naming its certificate and save the heavyweight public-key | decryption. That's all. | | The case where the AP and AR have pre-shared secrets and no certificates is | a separate issue, I think. What I was thinking of was the context where | certificates have already been used to establish a session key and we assume | that the session key is not compromised. In this case, rekeying is used to | avoid encrypting too much traffic with the same key. Okay, so you seem to be suggesting that we forego the PK encryption, and use a name (e.g. the DN from the AP cert) and an additional cryptographic nonce as part of the hash? Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/BKsBMtIdhO0pgN4RAr6DAJ9dOp+kXwm0R6Lgm6w3wQzQTu9X6QCeMDse wcFpiEqX10gebb05u/c0tVQ= =uzi9 -----END PGP SIGNATURE----- From kempf@docomolabs-usa.com Fri Jul 4 00:34:36 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 3 Jul 2003 16:34:36 -0700 Subject: [Lwapp] Updated LWAPP Draft Message-ID: <038001c341bb$aa63e8b0$636015ac@dclkempt40> An updated version of the LWAPP draft is located at: http://www.airespace.com/ftp/draft-calhoun-seamoby-lwapp-03.txt It did not get into the BOF description or into the Internet drafts directory on time. jak From rkp@intotoinc.com Fri Jul 4 04:54:58 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Fri, 04 Jul 2003 09:24:58 +0530 Subject: [Lwapp] Hi all, Message-ID: <3F04FA92.1030409@intotoinc.com> Hi, I subscribed to this list today and went through the draft very briefly. I would like to comment on whether to do LWAPP encapsulation on the data packets or not. I agree that if LWAPP encapsulation is not done on the data packets, then existing L2/L3 hardware chipsets can be used. If LWAPP encapsulation is not done, how do we authenticate the packets when they are received at AR or AP. There should be per packet authentication. Otherwise, there is a possibility of rogue AP sending the packets and AR thinking that they are coming from the right wireless station. Basically, there are two methods: 1. Centralize security at the AR (WPA and RSN tomorrow) In this case, LWAPP encapsulation don't have to be done as AR is checking for security of the packets. TKIP has per packet authentication. 2. If De-Centralization of WPA on the AP is needed, then the packets (Ethernet Packets) need to be encapsulated with LWAPP and provide per packet authentication. Regards Rama Krishna Prasad From yohba@tari.toshiba.com Fri Jul 4 16:19:24 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Fri, 4 Jul 2003 08:19:24 -0700 Subject: [Lwapp] comments on LWAPP Message-ID: <20030704151854.GA8737@steelhead> I have some comments on LWAPP. The proposal has two components: (A) AR manages APs. (B) AR optionally performs some task of wireless MAC-layer processing on behalf of APs (e.g., authentication and/or ciphering). With regard to (A), I think it does not have to be an AR that manages APs. Any IP node that supports LWAPP can manage APs. An important point in (A) would be that such an IP node is in the same LAN as the APs in order to make a discovery phase easy. With regard to (B), I'm wondering how VLAN can be supported with this proposal. Specific questions are: - Does LWAPP-aware AR need to be on on each VLAN? - How can LWAPP work with dynamic VLAN? An AP may not have a static knowledge on which station or SSID is mapped to which VLAN when such mapping is dynamically provided from a AAA server as result of authentication/authorization procedure. In this case, the proposal might be difficult to work if the AR that serves as an 802.1X authenticator for a station is different from the AR on the VLAN where the station is placed after the 802.1X authentication. Yoshihiro Ohba From esadot@avaya.com Mon Jul 7 15:10:18 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Mon, 7 Jul 2003 17:10:18 +0300 Subject: [Lwapp] Why LWAPP and not normal bridging!! Message-ID: Hello, I am not sure that the LWAPP can avoid encapsulation. I am not advising = encapsulating 802.11 data packet. Regardless the question whether or not = AP transforms 802.11 to common Ethernet packets or sends 802.11 data = packets toward the LAN, encapsulating is required. The reason is that a = layer 2 cloud may reside between AP and AR and in some cases the AR/AP = architecture obliged data packet to hit the AR. Roaming is one example: a wireless client who roams to different VLAN = (subnet) requires special network services in order to reach its = original VLAN domain. These services are most likely to be provided by = the AR. Policy (ACL/QoS), 802.1x authentication and Proxy ARP, are additional = services to be provided by the AR. Emek Sadot -----Original Message----- From: Vishal Sinha [mailto:vsinha@foundrynet.com] Sent: Friday, 27 June, 2003 12:16 AM To: LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Pat, After talking to some customers, I got the feedback that most of them want to migrate slowly to Wi-Fi. They would like to retain their existing L2 and L3 switches/Routers and would prefer just a software upgrade. Anyway, I think LWAPP should make it optional to do encapsulation of data frames. -Vishal -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Pat R. Calhoun Sent: Thursday, June 26, 2003 2:05 PM To: Vishal Sinha; James Kempf; LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > I am not very familiar with the functionality of a cryptoprocessor. > Can they do bridging too? What about the ability to remove LWAPP > header and put 802.3 header? Obviously some function is required in the data path to handle this bridging. This could be handle by some specialized processor in the fast path and does not need to be part of the crypto-processor. > I guess what I am asking is that with the help of cryptoprocessor > can we avoid sending all the LWAPP data packets to the CPU? Yes PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From vsinha@foundrynet.com Mon Jul 7 18:18:00 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Mon, 7 Jul 2003 10:18:00 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: Message-ID: Having a L2/L3 cloud between an AP and its corresponding AR has its own problems. For one, how should the new AP or AR send a L2 update message to the old L2 domain to fix the ARP table there in case of roaming? L2 Broadcast is not an option in my point of view. -Vishal -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Sadot, Emek (Emek) Sent: Monday, July 07, 2003 7:10 AM To: LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Hello, I am not sure that the LWAPP can avoid encapsulation. I am not advising encapsulating 802.11 data packet. Regardless the question whether or not AP transforms 802.11 to common Ethernet packets or sends 802.11 data packets toward the LAN, encapsulating is required. The reason is that a layer 2 cloud may reside between AP and AR and in some cases the AR/AP architecture obliged data packet to hit the AR. Roaming is one example: a wireless client who roams to different VLAN (subnet) requires special network services in order to reach its original VLAN domain. These services are most likely to be provided by the AR. Policy (ACL/QoS), 802.1x authentication and Proxy ARP, are additional services to be provided by the AR. Emek Sadot -----Original Message----- From: Vishal Sinha [mailto:vsinha@foundrynet.com] Sent: Friday, 27 June, 2003 12:16 AM To: LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Pat, After talking to some customers, I got the feedback that most of them want to migrate slowly to Wi-Fi. They would like to retain their existing L2 and L3 switches/Routers and would prefer just a software upgrade. Anyway, I think LWAPP should make it optional to do encapsulation of data frames. -Vishal -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Pat R. Calhoun Sent: Thursday, June 26, 2003 2:05 PM To: Vishal Sinha; James Kempf; LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > I am not very familiar with the functionality of a cryptoprocessor. > Can they do bridging too? What about the ability to remove LWAPP > header and put 802.3 header? Obviously some function is required in the data path to handle this bridging. This could be handle by some specialized processor in the fast path and does not need to be part of the crypto-processor. > I guess what I am asking is that with the help of cryptoprocessor > can we avoid sending all the LWAPP data packets to the CPU? Yes PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From rkp@intotoinc.com Tue Jul 8 04:33:49 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Tue, 08 Jul 2003 09:03:49 +0530 Subject: [Lwapp] Per packet authentication ICV Message-ID: <3F0A3B9D.5090307@intotoinc.com> Hi, I feel the per packet authentication (if not ciphering) should be done for data packets as well. I understand from the draft that per packet authentication and ciphering is considered for control packets, but not the data packets. Doesn't group think that AR should authenticate packets coming from trusted APs? It does not take any effort for rogue AP to send data packets as if they are coming from one of trusted APs. It is possible to spoof the MAC address and send data packets to the AR. Thanks Rama Krishna Prasad. From dmolnar@legra.com Tue Jul 8 16:50:35 2003 From: dmolnar@legra.com (David Molnar) Date: Tue, 8 Jul 2003 11:50:35 -0400 Subject: [Lwapp] SessionID size and rekeying in -033] References: <3F046D0B.8070206@airespace.com> <003701c34190$5614b6c0$b90ba8c0@student.harvard.edu> <3F04AB02.2000206@airespace.com> Message-ID: <00aa01c34568$ac9a1400$b90ba8c0@student.harvard.edu> > Okay, so you seem to be suggesting that we forego the PK encryption, and > use a name (e.g. the DN from the AP cert) and an additional > cryptographic nonce as part of the hash? Yes, that's right. Sorry for the delay. Then mandate that each AP must check the DN to ensure it matches before accepting the new key. -David From scott@airespace.com Tue Jul 8 17:00:00 2003 From: scott@airespace.com (Scott G. Kelly) Date: Tue, 08 Jul 2003 09:00:00 -0700 Subject: [Lwapp] SessionID size and rekeying in -033] References: <3F046D0B.8070206@airespace.com> <003701c34190$5614b6c0$b90ba8c0@student.harvard.edu> <3F04AB02.2000206@airespace.com> <00aa01c34568$ac9a1400$b90ba8c0@student.harvard.edu> Message-ID: <3F0AEA80.1060408@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, Perhaps it would be best if you fully describe the exchange as you envision it. Scott David Molnar wrote: |>Okay, so you seem to be suggesting that we forego the PK encryption, and |>use a name (e.g. the DN from the AP cert) and an additional |>cryptographic nonce as part of the hash? | | | Yes, that's right. Sorry for the delay. Then mandate that each AP must check | the DN to ensure it matches before accepting the new key. | | -David | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/Cup/MtIdhO0pgN4RAlcgAJ9JWv9Cib/s8P1w7hGBEG5xbBxGxQCfTRZk puMQgn2NJncJpLokacXiSAQ= =kAnm -----END PGP SIGNATURE----- From pcalhoun@airespace.com Tue Jul 8 17:13:46 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 8 Jul 2003 09:13:46 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC50CC@bsn-mail-01.bstormnetworks.com> UGVyaGFwcyB5b3UgYXJlIHJpZ2h0LCBidXQgaW4gb3JkZXIgdG8gYXR0YWNrIHRoZSBuZXR3b3Jr IGluIHN1Y2ggYSB3YXksIG9uZSBoYXMgaGFkIHRvIGdhaW4gYWNjZXNzIHRvIHRoZSB3aXJlZCBu ZXR3b3JrIGJldHdlZW4gdGhlIEFQIGFuZCB0aGUgQVIuIEF0IHRoYXQgcG9pbnQsIHdoeSBldmVu IGJvdGhlciB0cnlpbmcgdG8gc3Bvb2YgdGhlIEFQJ3MgdHJhZmZpYyBhbmQgbm90IGp1c3QgYWNj ZXNzIHRoZSBuZXR3b3JrIGRpcmVjdGx5PyBUaGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSBpbiAiYXBw bGlhbmNlIiBtb2RlLCB3aGVyZSB0aGUgQVAgYW5kIHRoZSBBUnMgYXJlIG5vdCBkaXJlY3RseSBj b25uZWN0ZWQgKG1lYW5pbmcsIHRoZXJlIGlzIGEgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBiZXR3 ZWVuIHRoZSB0d28pLg0KIA0KUGF0Qw0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJ RnJvbTogUmFtYSBrcmlzaG5hIHByYXNhZCBbbWFpbHRvOnJrcEBpbnRvdG9pbmMuY29tXSANCglT ZW50OiBNb24gNy83LzIwMDMgODozMyBQTSANCglUbzogbHdhcHBAZnJhc2NvbmUuY29tIA0KCUNj OiANCglTdWJqZWN0OiBbTHdhcHBdIFBlciBwYWNrZXQgYXV0aGVudGljYXRpb24gSUNWDQoJDQoJ DQoNCglIaSwNCgkgICBJIGZlZWwgdGhlIHBlciBwYWNrZXQgYXV0aGVudGljYXRpb24gKGlmIG5v dCBjaXBoZXJpbmcpIHNob3VsZCBiZSBkb25lIGZvciBkYXRhDQoJICAgcGFja2V0cyBhcyB3ZWxs LiBJIHVuZGVyc3RhbmQgZnJvbSB0aGUgZHJhZnQgdGhhdCBwZXIgcGFja2V0IGF1dGhlbnRpY2F0 aW9uIGFuZA0KCSAgIGNpcGhlcmluZyBpcyBjb25zaWRlcmVkIGZvciBjb250cm9sIHBhY2tldHMs IGJ1dCBub3QgdGhlIGRhdGEgcGFja2V0cy4NCgkgICBEb2Vzbid0IGdyb3VwIHRoaW5rIHRoYXQg QVIgc2hvdWxkIGF1dGhlbnRpY2F0ZSBwYWNrZXRzIGNvbWluZyBmcm9tDQoJICAgdHJ1c3RlZCBB UHM/IEl0IGRvZXMgbm90IHRha2UgYW55IGVmZm9ydCBmb3Igcm9ndWUgQVAgdG8gc2VuZCBkYXRh IHBhY2tldHMNCgkgICBhcyBpZiB0aGV5IGFyZSBjb21pbmcgZnJvbSBvbmUgb2YgdHJ1c3RlZCBB UHMuIEl0IGlzIHBvc3NpYmxlIHRvIHNwb29mIHRoZQ0KCSAgIE1BQyBhZGRyZXNzIGFuZCBzZW5k IGRhdGEgcGFja2V0cyB0byB0aGUgQVIuDQoJVGhhbmtzDQoJIFJhbWEgS3Jpc2huYSBQcmFzYWQu DQoJDQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CglMd2FwcCBtYWlsaW5nIGxpc3QNCglMd2FwcEBmcmFzY29uZS5jb20NCglodHRwOi8vbWFpbC5m cmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9sd2FwcA0KCQ0KDQo= From dmolnar@legra.com Tue Jul 8 17:34:45 2003 From: dmolnar@legra.com (David Molnar) Date: Tue, 8 Jul 2003 12:34:45 -0400 Subject: [Lwapp] Per packet authentication ICV References: <40301581B2962B448690A023EF16DFE1DC50CC@bsn-mail-01.bstormnetworks.com> Message-ID: <00df01c3456e$d79fd080$b90ba8c0@student.harvard.edu> > Perhaps you are right, but in order to attack the network in such a way, one has had >to gain access to the wired network between the AP and the AR. At that point, why >even Are we assuming that there will always be a wired network between AP and AR? If LWAPP is implemented at L3, then what prevents an AR from possibly contacting an AP via wireless link? When I first started working in this area, I was told "oh, APs will always be directly connected to ARs - you'll never have to worry about routing between them." That disappeared right quick. I agree that we should focus on control frames for LWAPP, but I do not think invoking the security of a wired network between the AP and AR is the best justification. thanks, -David From dmolnar@legra.com Tue Jul 8 17:39:06 2003 From: dmolnar@legra.com (David Molnar) Date: Tue, 8 Jul 2003 12:39:06 -0400 Subject: [Lwapp] SessionID size and rekeying in -033] References: <3F046D0B.8070206@airespace.com> <003701c34190$5614b6c0$b90ba8c0@student.harvard.edu> <3F04AB02.2000206@airespace.com> <00aa01c34568$ac9a1400$b90ba8c0@student.harvard.edu> <3F0AEA80.1060408@airespace.com> Message-ID: <00e001c3456f$731135e0$b90ba8c0@student.harvard.edu> > Hi David, > > Perhaps it would be best if you fully describe the exchange as you > envision it. OK. Here's my suggestion for A.3 . There are some notes inline. ------ The rekeying will proceed as follows: o AP generates a fresh SessionID value, generates a fresh 128-bit nonce N, and constructs a TLV payload of type SESSION which contains new SessionID and N, then sends the payload in KEY- UPDATE message to AR. o When the AR receives KEY-UPDATE request with SessionID and N it constructs the reply payload as follows: i) Randomly generate enough key material to produce an encryption key and an authentication hash key (xx bytes in length). [TBD:detailed key material generation instructions] ii) Compute S1 = S-ar{SessionID|N|Certificate-AP|KeyMaterial}; this computes the AR's digital signature over the concatenation of the sessionID, Nonce, Certificate-AP and the key material, and can be verified using the public key of the AR, "proving" that the AR produced this; this forms the basis of trust for the AP with respect to the source of the session key. [DM note: Are any of the SessionID, N, Certificate-AP, or KeyMaterial variable in length? If so, we need some kind of mechanism for delimiting unambiguously; concatenation alone may not be a good idea if the AP is trying to get the AR to sign something by choosing SessionID and N adversarially.] iv) AR then sends a KEY-UPDATE-RSP message to the AP using the new session values. o AP must maintain session state for the original SessionID, nonce, and keys until it receives the KEY-UPDATE-RSP, at which time it i) checks the Certificate-AP in the KEY-UPDATE-RSP - if it is the named AP in the Certificate-AP, continue - otherwise, drop packet and resend original request [DM note: Should AP close connection instead of resend?] ii) checks the nonce N in the KEY-UPDATE-RSP - if the nonce N matches the nonce sent by AP, continue - otherwise, drop packet and resend original request iii) checks the SessionID in the KEY-UPDATE-RSP - if the SessionID matches the SessionID sent by AP, continue -otherwise, drop packet and resend original request iv) if all checks succeed, the AP accepts the new SessionID and KeyMaterial and clears the old values. [DM comment: Should the AP acknolwedge to the AR that it has accepted the new SessionID and KeyMaterial? When does the AR clear state from the old session and switch to the new session? Note that the answer here affects what the AP's failure behavior is above; if the AR doesn't remember the old session key, the AP can't retransmit the KEY-UPDATE request] o If AP does not receive the KEY-UPDATE-RSP within a reasonable period of time (1 minute?), it will resend the original request and reset its response timer. If no response occurs by the time the original session expires, the AP will delete the new and old session information, and initiate the DISCOVER process anew. From bhandaru@legra.com Tue Jul 8 17:55:30 2003 From: bhandaru@legra.com (Nehru Bhandaru) Date: Tue, 8 Jul 2003 12:55:30 -0400 Subject: [Lwapp] Per packet authentication ICV In-Reply-To: <00df01c3456e$d79fd080$b90ba8c0@student.harvard.edu> Message-ID: <01bb01c34571$bd8d7050$7a0ba8c0@legra.com> IMO data packet encryption endpoint defines a trust boundary. If the AP->AR network is not secure/trusted, then the two choices seem to be=20 AR performs the crypto operations on data packets or lwapp protects these packets. - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of David Molnar Sent: Tuesday, July 08, 2003 12:35 PM To: Pat R. Calhoun Cc: lwapp@frascone.com Subject: Re: [Lwapp] Per packet authentication ICV > Perhaps you are right, but in order to attack the network in such a=20 > way, one has had >to gain access to the wired network between the AP and the = AR. At that point, why >even Are we assuming that there will always be a wired network between AP and = AR? If LWAPP is implemented at L3, then what prevents an AR from possibly contacting an AP via wireless link? When I first started working in this area, I was told "oh, APs will = always be directly connected to ARs - you'll never have to worry about routing between them." That disappeared right quick. I agree that we should = focus on control frames for LWAPP, but I do not think invoking the security of a wired network between the AP and AR is the best justification. thanks, -David _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From rkp@intotoinc.com Wed Jul 9 15:18:12 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Wed, 09 Jul 2003 19:48:12 +0530 Subject: [Lwapp] Per packet authentication ICV References: <40301581B2962B448690A023EF16DFE1DC50CC@bsn-mail-01.bstormnetworks.com> Message-ID: <3F0C2424.2030708@intotoinc.com> Hi, If we consider only small/Medium space environments, it may be possible. But consider factory environments where one can have several assembly floors with computers and IS department is confined to very small area where typically Intranet servers other sensitive computers are kept. There could be firewall to the IS department and this could only route the packets to trusted ARs. In this case, it is not possible for somebody to plugin some rogue AP in the IS department as it is well controlled and confined to defined area. Possibly, they can have IDS to detect any abnormal traffic. Assembly floors are not well protected and that is where APs are kept. It is possible that somebody (dis-satisfied employee) can keep their AP to access the IS resources. This is where, I feel packet authentication between AP and AR would be useful. Regards Rama Krishna Prasad > -----Original Message----- > From: Rama krishna prasad [mailto:rkp@intotoinc.com] > Sent: Mon 7/7/2003 8:33 PM > To: lwapp@frascone.com > Cc: > Subject: [Lwapp] Per packet authentication ICV > > > > Hi, > I feel the per packet authentication (if not ciphering) should be done for data > packets as well. I understand from the draft that per packet authentication and > ciphering is considered for control packets, but not the data packets. > Doesn't group think that AR should authenticate packets coming from > trusted APs? It does not take any effort for rogue AP to send data packets > as if they are coming from one of trusted APs. It is possible to spoof the > MAC address and send data packets to the AR. > Thanks > Rama Krishna Prasad. > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > >?????????????????????????????????????i????x%??K?i??ڱ?'{?(?m????????ڱ?'{?(??Y???b?ا~???i > > > From Mike.Moreton@Synad.com Wed Jul 9 15:55:00 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Wed, 9 Jul 2003 15:55:00 +0100 Subject: [Lwapp] Per packet authentication ICV Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA37C@paris.synad.com> --{0B9D0E77-AED2-4F92-984C-4EE821594B05} Content-Type: text/plain; charset="UTF-8" ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. synad.com ********************************************************************** --{0B9D0E77-AED2-4F92-984C-4EE821594B05} Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGlzIGlzIHdoZXJlLCBJIGZlZWwgcGFja2V0IGF1dGhlbnRpY2F0aW9uIGJldHdlZW4gQVAg YW5kIEFSIHdvdWxkIGJlIHVzZWZ1bC4NCg0KSXQgbWF5IGJlIHVzZWZ1bCwgYnV0IGRvZXMgaXQg aGF2ZSB0byBiZSBwcm92aWRlZCBieSBMV0FQUD8gIEkgd291bGQgaW1hZ2luZSB0aGF0IGluIHRo ZSBzY2VuYXJpbyB5b3Ugc3VnZ2VzdCBhIHJlbW90ZSBWUE4gc29sdXRpb24gbWlnaHQgYmUgbW9y ZSBhcHByb3ByaWF0ZS4NCg0KTWlrZSBNb3JldG9uDQpTeW5hZCBUZWNobm9sb2dpZXMgTHRkLg0K IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmFtYSBrcmlzaG5hIHByYXNh ZCBbbWFpbHRvOnJrcEBpbnRvdG9pbmMuY29tXSANClNlbnQ6IDA5IEp1bHkgMjAwMyAxNToxOA0K VG86IFBhdCBSLiBDYWxob3VuDQpDYzogbHdhcHBAZnJhc2NvbmUuY29tDQpTdWJqZWN0OiBSZTog W0x3YXBwXSBQZXIgcGFja2V0IGF1dGhlbnRpY2F0aW9uIElDVg0KDQpIaSwNCiAgIElmIHdlIGNv bnNpZGVyIG9ubHkgc21hbGwvTWVkaXVtIHNwYWNlIGVudmlyb25tZW50cywgaXQgbWF5IGJlIHBv c3NpYmxlLg0KICAgQnV0IGNvbnNpZGVyIGZhY3RvcnkgZW52aXJvbm1lbnRzIHdoZXJlIG9uZSBj YW4gaGF2ZSBzZXZlcmFsIGFzc2VtYmx5DQogICBmbG9vcnMgd2l0aCBjb21wdXRlcnMgYW5kIElT IGRlcGFydG1lbnQgaXMgY29uZmluZWQgdG8gdmVyeSBzbWFsbCBhcmVhDQogIHdoZXJlIHR5cGlj YWxseSBJbnRyYW5ldCBzZXJ2ZXJzIG90aGVyIHNlbnNpdGl2ZSBjb21wdXRlcnMgYXJlIGtlcHQu DQogIFRoZXJlIGNvdWxkIGJlIGZpcmV3YWxsIHRvIHRoZSBJUyBkZXBhcnRtZW50IGFuZCB0aGlz IGNvdWxkIG9ubHkgcm91dGUNCiAgdGhlIHBhY2tldHMgdG8gdHJ1c3RlZCBBUnMuIEluIHRoaXMg Y2FzZSwgaXQgaXMgbm90IHBvc3NpYmxlIGZvciBzb21lYm9keQ0KICB0byBwbHVnaW4gc29tZSBy b2d1ZSBBUCBpbiB0aGUgSVMgZGVwYXJ0bWVudCBhcyBpdCBpcyB3ZWxsIGNvbnRyb2xsZWQgYW5k DQogIGNvbmZpbmVkIHRvIGRlZmluZWQgYXJlYS4gUG9zc2libHksIHRoZXkgY2FuIGhhdmUgSURT IHRvIGRldGVjdCBhbnkNCiAgYWJub3JtYWwgdHJhZmZpYy4NCg0KICAgQXNzZW1ibHkgZmxvb3Jz IGFyZSBub3Qgd2VsbCBwcm90ZWN0ZWQgYW5kIHRoYXQgaXMgd2hlcmUgQVBzIGFyZSBrZXB0Lg0K ICAgSXQgaXMgcG9zc2libGUgdGhhdCBzb21lYm9keSAoZGlzLXNhdGlzZmllZCBlbXBsb3llZSkg Y2FuIGtlZXAgdGhlaXINCiAgIEFQIHRvIGFjY2VzcyB0aGUgSVMgcmVzb3VyY2VzLiBUaGlzIGlz IHdoZXJlLCBJIGZlZWwgcGFja2V0IGF1dGhlbnRpY2F0aW9uDQogICBiZXR3ZWVuIEFQIGFuZCBB UiB3b3VsZCBiZSB1c2VmdWwuDQoNCiAgUmVnYXJkcw0KDQogIFJhbWEgS3Jpc2huYSBQcmFzYWQN Cg0KDQoNCj4JLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQo+CUZyb206IFJhbWEga3Jpc2hu YSBwcmFzYWQgW21haWx0bzpya3BAaW50b3RvaW5jLmNvbV0gDQo+CVNlbnQ6IE1vbiA3LzcvMjAw MyA4OjMzIFBNIA0KPglUbzogbHdhcHBAZnJhc2NvbmUuY29tIA0KPglDYzogDQo+CVN1YmplY3Q6 IFtMd2FwcF0gUGVyIHBhY2tldCBhdXRoZW50aWNhdGlvbiBJQ1YNCj4JDQo+CQ0KPg0KPglIaSwN Cj4JICAgSSBmZWVsIHRoZSBwZXIgcGFja2V0IGF1dGhlbnRpY2F0aW9uIChpZiBub3QgY2lwaGVy aW5nKSBzaG91bGQgYmUgZG9uZSBmb3IgZGF0YQ0KPgkgICBwYWNrZXRzIGFzIHdlbGwuIEkgdW5k ZXJzdGFuZCBmcm9tIHRoZSBkcmFmdCB0aGF0IHBlciBwYWNrZXQgYXV0aGVudGljYXRpb24gYW5k DQo+CSAgIGNpcGhlcmluZyBpcyBjb25zaWRlcmVkIGZvciBjb250cm9sIHBhY2tldHMsIGJ1dCBu b3QgdGhlIGRhdGEgcGFja2V0cy4NCj4JICAgRG9lc24ndCBncm91cCB0aGluayB0aGF0IEFSIHNo b3VsZCBhdXRoZW50aWNhdGUgcGFja2V0cyBjb21pbmcgZnJvbQ0KPgkgICB0cnVzdGVkIEFQcz8g SXQgZG9lcyBub3QgdGFrZSBhbnkgZWZmb3J0IGZvciByb2d1ZSBBUCB0byBzZW5kIGRhdGEgcGFj a2V0cw0KPgkgICBhcyBpZiB0aGV5IGFyZSBjb21pbmcgZnJvbSBvbmUgb2YgdHJ1c3RlZCBBUHMu IEl0IGlzIHBvc3NpYmxlIHRvIHNwb29mIHRoZQ0KPgkgICBNQUMgYWRkcmVzcyBhbmQgc2VuZCBk YXRhIHBhY2tldHMgdG8gdGhlIEFSLg0KPglUaGFua3MNCj4JIFJhbWEgS3Jpc2huYSBQcmFzYWQu DQo+CQ0KPgkNCj4JX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4JTHdhcHAgbWFpbGluZyBsaXN0DQo+CUx3YXBwQGZyYXNjb25lLmNvbQ0KPglodHRwOi8v bWFpbC5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9sd2FwcA0KPgkNCj4NCj4/Pz8/Pz8/ Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/aT8/Pz94JT8/Sz9pPz/asT8nez8oPxttPz8/ Pz8/Pz/asT8nez8oPz9ZPz8/Yj/Yp34/Pz9pDQo+DQo+ICANCj4NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTHdhcHAgbWFpbGluZyBsaXN0DQpM d2FwcEBmcmFzY29uZS5jb20NCmh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3Rp bmZvL2x3YXBwDQo= --{0B9D0E77-AED2-4F92-984C-4EE821594B05}-- From kwchin@arc.corp.mot.com Thu Jul 10 00:55:34 2003 From: kwchin@arc.corp.mot.com (Kwan-Wu Chin) Date: Thu, 10 Jul 2003 09:55:34 +1000 Subject: [Lwapp] CFP: IEEE Percom'2004 Message-ID: <3F0CAB76.F06DB6A9@arc.corp.mot.com> This is a multi-part message in MIME format. --------------40868B81585F3330EE22E634 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------40868B81585F3330EE22E634 Content-Type: text/plain; charset=us-ascii; name="CFP.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="CFP.txt" -------------------------------------------------------------------------------- *** OUR SINCERE APOLOGIES IF YOU RECEIVE MULTIPLE COPIES OF THIS CFP *** -------------------------------------------------------------------------------- CONFERENCE ANNOUNCEMENT AND CALL FOR PAPERS AND WORKSHOPS Second IEEE International Conference on Pervasive Computing and Communications PerCom 2004 (http//www.percom.org) March 14-17, 2004 Orlando, FLORIDA -------------------------------------------------------------------------------- **** Paper Submission Deadline --- September 1, 2003 **** **** Workshop Proposals Deadline --- June 1, 2003 **** Sponsored by The IEEE Computer Society and The University of Texas at Arlington Cosponsored by the IEEE TCCC and the IEEE TCPP -------------------------------------------------------------------------------- IEEE PerCom 2004 will be the second annual conference on the emerging area of pervasive computing and communications aimed at providing an exciting platform and paradigm for all the time, everywhere services. This emergence is a natural outcome of the tremendous advances in wireless networks, mobile computing, sensor networks, distributed computing, and agent technologies. PerCom 2004 will provide a high profile, leading edge forum for researchers and engineers alike to present their latest research in the field of pervasive computing and communications. As in PerCom 2003, the Mark Weiser Best Paper Award will be given to the best paper judged by the award subcommittee. Also, as in PerCom 2003, a special issue of a leading journal will be published out of the selected papers. Proposals to organize Workshops are also invited. PerCom 2004 will also feature industry exhibits and demonstrations. -------------------------------------------------------------------------------- Feature Topics: ---------------- Contributions are solicited in all areas and topics pertaining to pervasive computing research and applications. These include, but are not limited to, the following topics: * Pervasive computing architectures * Intelligent environments * Wearable computers * Smart devices and smart spaces * Location-dependent / personalized applications * Service discovery mechanisms * Agent technologies * Sensors and actuators * Positioning and tracking technologies * Identification and authentication technologies * Integration of wired and wireless networks * Personal area networks * Enabling technologies such as Bluetooth, 802.11 and 802.15 * Software coordination models * Mobile / wireless computing systems and services * Context based and implicit computing * Speech processing / advanced computer vision * User interfaces and interaction models * Wireless/mobile service management and delivery * Ad hoc networking protocols and service discovery * Resource management in pervasive computing platforms * Security and privacy issues for pervasive computing systems -------------------------------------------------------------------------------- Submission Guidelines: ---------------------------------- Submitted papers must be unpublished and not currently under consideration elsewhere for publication. Only electronic submissions (PS or PDF) will be considered. Page limit is 12 pages (single column, 11 pt fonts and 1.5 line spaced, excluding references, figures and tables). Detailed procedure will be available at http://www.percom.org. All submitted papers will undergo a rigorous review process managed by the technical program committee. IEEE Computer Society Press will publish the conference proceedings. Papers of particular merit will be considered for a special issue of a journal. For organizing a workshop at PerCom'2004, please contact the Workshop Chairs. A separate proceedings of workshop papers will be published by the IEEE Computer Society Press. ###################################################### IMPORTANT DATES: Paper Submission: September 1, 2003 Workshop Proposal: June 1, 2003 Demonstration Proposal: October 31, 2003 Acceptance Notification: November 15, 2003 Camera Ready Manuscripts: December 10, 2003 Conference Dates: March 14-17, 2004 ###################################################### --------------------------------------------------------------------------------- Program Chair: Anand Tripathi University of Minnesota, Twin Cities Email: tripathi@cs.umn.edu Vice Program Committee Chairs: Liviu Iftode University of Maryland, College Park Klara Nahrstedt University of Illinois at Urbana Champaign Paddy Nixon University of Strathclyde, UK Technical Program Committee: ---------------------------- Jean Bacon, Cambridge University, UK B.R. Badrinath, Rutgers University, USA Stefano Basagni, Northeastern University, USA Bharat Bhargava, Purdue University, USA Vinny Cahill, Trinity College Dublin, Ireland Andrew Campbell, Columbia University, USA Roy Campbell, University of Illinois at Urbana-Champaign, USA Matthew Chalmers, Glasgow University, UK Marco Conti, Council of National Research, Italy Diane Cook, University of Texas at Arlington, USA Antonio Corradi, University of Bologna, Italy Kieran Delaney, NMRC, Ireland Armando Fox, Stanford University, USA Dave Garlan, Carnegie Mellon University, USA Amir Herzberg, Bar-Ilan University, Israel Lars Holmquist, Viktoria Institute, Sweden Viktor K. Prasanna, University of Southern California, USA Robin Kravets, University of Illinois at Urbana-Champaign, USA Hui Lei, IBM T.J. Watson Research Center, USA Diana Marculescu, Carnegie Mellon University, USA Dave Marples, Telecordia, USA Phil McKinley, Michigan State University, USA Lionel Ni, Hong Kong University of Science and Technology, Hong Kong Sotiris Nikoletseas, Patras University, Greece Chiara Petrioli, Rome University `La Sapienza', Italy Gopal Pingali, IBM T.J. Watson Research Center, USA Ravi Prakash, University of Texas at Dallas, USA Kishore Ramachandran, Georgia Institute of Technology, USA Ichiro Satoh, National Institute of Informatics, Tokyo, Japan Steve Shafer, Microsoft Research, USA Mukesh Singhal, University of Kentucky, USA Dave Snowdon, Xerox Research Europe, France Maarten van Steen, Vrije Universiteit, The Netherlands Roy Want, Intel Research, USA Zhi-Li Zhang, University of Minnesota, Minneapolis, USA Taieb Znati, University of Pittsburgh and NSF, USA ------------------------------------------------------------ Organizing Committee: ------------------------- General Chair: Sajal K. Das, University of Texas at Arlington, USA General Vice Chair: Mohan Kumar, University of Texas at Arlington, USA Steering Committee Chair: Behrooz A. Shirazi, University of Texas at Arlington, USA Keynote Lecture Chair: Roy Want, Intel Research, Santa Clara, USA Panel Chair: Chatschik Bisdikian, IBM T.J. Watson Research, USA Workshop Chairs: Hui Lei, IBM Research and Francis Lau, University of Hong Kong Education Workshop Chair: Scott Midkiff, Virginia Tech, USA NIST-Industry Workshop Chair: Vince Stanford, National Institute of Standards and Technology (NIST), USA Industry Liaison: Sumi Helal, University of Florida at Gainesville, USA Demonstration and Exhibit Chairs: Gopal Pingali, IBM T.J. Watson Research Center, USA Chistian Becker, University of Stuttgart, Germany Publicity Chairs: Diana Marculescu, Carnegie Mellon University, USA Kwan-Wu Chin, Motorola Australia, Sydney, Australia Sotirios Terzis, University of Strathclyde, UK Registration Chair: Gergely Zaruba, University of Texas at Arlington, USA Finance Chair: David Levine, University of Texas at Arlington, USA Local Arrangements : Ratan Guha (Chair) University of Central Florida, USA Mostafa Bassiouni, University of Central Florida, USA Mainak Chatterjee, University of Central Florida, USA Damla Turgut, University of Central Florida, USA --------------------------------------------------------------------------------- --------------40868B81585F3330EE22E634-- From rkp@intotoinc.com Thu Jul 10 04:54:44 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Thu, 10 Jul 2003 09:24:44 +0530 Subject: [Lwapp] Per packet authentication ICV References: <0D3F1B25E75EE24483A6E69201142C867DA37C@paris.synad.com> Message-ID: <3F0CE384.1020009@intotoinc.com> --------------010908080709050205050709 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, In my earlier emails, I mentioned this. You are right, if the trust relationship is maintained between wireless stations and AR, there is no issue, whether it is 802.1x+TKIP based security OR IPSEC based OR SSL based. Whatever I am suggesting is required only if IPSEC OR SSL are not used and TKIP is de-centralized to Access points. Regards Rama Krishna Prasad Mike Moreton wrote: >********************************************************************** >This email and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they >are addressed. If you have received this email in error please notify >the system manager. > >This footnote also confirms that this email message has been swept >for the presence of computer viruses. > >synad.com >********************************************************************** > > >------------------------------------------------------------------------ > > > >>This is where, I feel packet authentication between AP and AR would be useful. >> >> > >It may be useful, but does it have to be provided by LWAPP? I would imagine that in the scenario you suggest a remote VPN solution might be more appropriate. > >Mike Moreton >Synad Technologies Ltd. > > >-----Original Message----- >From: Rama krishna prasad [mailto:rkp@intotoinc.com] >Sent: 09 July 2003 15:18 >To: Pat R. Calhoun >Cc: lwapp@frascone.com >Subject: Re: [Lwapp] Per packet authentication ICV > >Hi, > If we consider only small/Medium space environments, it may be possible. > But consider factory environments where one can have several assembly > floors with computers and IS department is confined to very small area > where typically Intranet servers other sensitive computers are kept. > There could be firewall to the IS department and this could only route > the packets to trusted ARs. In this case, it is not possible for somebody > to plugin some rogue AP in the IS department as it is well controlled and > confined to defined area. Possibly, they can have IDS to detect any > abnormal traffic. > > Assembly floors are not well protected and that is where APs are kept. > It is possible that somebody (dis-satisfied employee) can keep their > AP to access the IS resources. This is where, I feel packet authentication > between AP and AR would be useful. > > Regards > > Rama Krishna Prasad > > > > > >> -----Original Message----- >> From: Rama krishna prasad [mailto:rkp@intotoinc.com] >> Sent: Mon 7/7/2003 8:33 PM >> To: lwapp@frascone.com >> Cc: >> Subject: [Lwapp] Per packet authentication ICV >> >> >> >> Hi, >> I feel the per packet authentication (if not ciphering) should be done for data >> packets as well. I understand from the draft that per packet authentication and >> ciphering is considered for control packets, but not the data packets. >> Doesn't group think that AR should authenticate packets coming from >> trusted APs? It does not take any effort for rogue AP to send data packets >> as if they are coming from one of trusted APs. It is possible to spoof the >> MAC address and send data packets to the AR. >> Thanks >> Rama Krishna Prasad. >> >> >> _______________________________________________ >> Lwapp mailing list >> Lwapp@frascone.com >> http://mail.frascone.com/mailman/listinfo/lwapp >> >> >>?????????????????????????????????????i????x%??K?i??ڱ?'{?(?m????????ڱ?'{?(??Y???b?ا~???i >> >> >> >> >> > > >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp > > --------------010908080709050205050709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 
     Hi,
         In my earlier emails, I mentioned this. You are right, if the trust relationship
         is maintained between wireless stations and AR, there is no issue, whether
         it is 802.1x+TKIP based security OR IPSEC based OR SSL based.
         Whatever I am suggesting is required only if IPSEC OR SSL are not used
         and TKIP is de-centralized to Access points.
      Regards

      Rama Krishna Prasad


Mike Moreton wrote:
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept 
for the presence of computer viruses.

synad.com
**********************************************************************
  

  
This is where, I feel packet authentication between AP and AR would be useful.
    

It may be useful, but does it have to be provided by LWAPP?  I would imagine that in the scenario you suggest a remote VPN solution might be more appropriate.

Mike Moreton
Synad Technologies Ltd.
 

-----Original Message-----
From: Rama krishna prasad [mailto:rkp@intotoinc.com] 
Sent: 09 July 2003 15:18
To: Pat R. Calhoun
Cc: lwapp@frascone.com
Subject: Re: [Lwapp] Per packet authentication ICV

Hi,
   If we consider only small/Medium space environments, it may be possible.
   But consider factory environments where one can have several assembly
   floors with computers and IS department is confined to very small area
  where typically Intranet servers other sensitive computers are kept.
  There could be firewall to the IS department and this could only route
  the packets to trusted ARs. In this case, it is not possible for somebody
  to plugin some rogue AP in the IS department as it is well controlled and
  confined to defined area. Possibly, they can have IDS to detect any
  abnormal traffic.

   Assembly floors are not well protected and that is where APs are kept.
   It is possible that somebody (dis-satisfied employee) can keep their
   AP to access the IS resources. This is where, I feel packet authentication
   between AP and AR would be useful.

  Regards

  Rama Krishna Prasad



  
	-----Original Message----- 
	From: Rama krishna prasad [mailto:rkp@intotoinc.com] 
	Sent: Mon 7/7/2003 8:33 PM 
	To: lwapp@frascone.com 
	Cc: 
	Subject: [Lwapp] Per packet authentication ICV
	
	

	Hi,
	   I feel the per packet authentication (if not ciphering) should be done for data
	   packets as well. I understand from the draft that per packet authentication and
	   ciphering is considered for control packets, but not the data packets.
	   Doesn't group think that AR should authenticate packets coming from
	   trusted APs? It does not take any effort for rogue AP to send data packets
	   as if they are coming from one of trusted APs. It is possible to spoof the
	   MAC address and send data packets to the AR.
	Thanks
	 Rama Krishna Prasad.
	
	
	_______________________________________________
	Lwapp mailing list
	Lwapp@frascone.com
	http://mail.frascone.com/mailman/listinfo/lwapp
	

?????????????????????????????????????i????x%??K?i??ڱ?'{?(?m????????ڱ?'{?(??Y???b?ا~???i

 

    


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

--------------010908080709050205050709-- From rkp@intotoinc.com Thu Jul 10 09:47:35 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Thu, 10 Jul 2003 14:17:35 +0530 Subject: [Lwapp] Per packet authentication ICV Message-ID: <3F0D2827.9070806@intotoinc.com> Hi, As we all know, wireless security can be achieved by using - IPSEC VPN tunnels - SSL and/OR - 802.1x based authentication and key management (WPA TKIP). AR will need to implement above combinations. IPSEC and SSLs are most likely implemented in AR. 802.1x key management and authentication are again most likely implemneted in AR. It is most likely TKIP security on per packet basis is implemented in the APs. Based on above, I feel it is not required that APs pass 802.11 packets ASIS in cases of IPSEC and SSL based security. But, some events should go to the AR from APs such as: - Association event - De-Association event - Idle timeout event etc.. Does group think that these events are required to be passed from APs to AR? Regards Rama Krishna Prasad From pcalhoun@airespace.com Thu Jul 10 16:08:34 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 10 Jul 2003 08:08:34 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC50F3@bsn-mail-01.bstormnetworks.com> > Does group think that these events are required to be passed from > APs to AR? Yes PatC From cchaplin@sj.symbol.com Thu Jul 10 17:14:05 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Thu, 10 Jul 2003 09:14:05 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: I have to jump in here.... The assumption that I am getting from all these discussions is that a lot of the processing will happen at the AP, rather than at the switch. Now, this may be a valid assumption for many companies, but there is currently shipping systems that do not meet this assumption: they have much less processing power in the APs, and a lot more in the central switch. The name of this group is Light Weight AP Protocol: does the term "light weight" apply to "protocol", or "AP"? Right now, there is currently shipping systems that, since the "APs" are very light weight, all processing happens in the central switch, and 802.11 packets are sent as-is (with minimal packet wrapping) between the switch and the APs. To bring this back to the point at hand, Currently shipping hardware does the TKIP processing at the switch. Clint (JOATMON) Chaplin >>> Rama krishna prasad 7/10/03 01:47:35 >>> Hi, As we all know, wireless security can be achieved by using - IPSEC VPN tunnels - SSL and/OR - 802.1x based authentication and key management (WPA TKIP). AR will need to implement above combinations. IPSEC and SSLs are most likely implemented in AR. 802.1x key management and authentication are again most likely implemneted in AR. It is most likely TKIP security on per packet basis is implemented in the APs. Based on above, I feel it is not required that APs pass 802.11 packets ASIS in cases of IPSEC and SSL based security. But, some events should go to the AR from APs such as: - Association event - De-Association event - Idle timeout event etc.. Does group think that these events are required to be passed from APs to AR? Regards Rama Krishna Prasad _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ________________________________________________________________________ This email has been scanned for computer viruses. From pcalhoun@airespace.com Thu Jul 10 18:35:43 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 10 Jul 2003 10:35:43 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC50F5@bsn-mail-01.bstormnetworks.com> > To bring this back to the point at hand, Currently shipping hardware > does the TKIP processing at the switch. And the current spec supports both. PatC From rkp@intotoinc.com Tue Jul 22 04:53:50 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Tue, 22 Jul 2003 09:23:50 +0530 Subject: [Lwapp] Per packet authentication ICV References: <40301581B2962B448690A023EF16DFE1DC50F3@bsn-mail-01.bstormnetworks.com> Message-ID: <3F1CB54E.1090607@intotoinc.com> --------------080604090500030604030502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, As I understand current specification supports the type of deployment which you are talking about. I don't mean to remove this support in the specifications. I am trying to see whether sending LWAPP encapsulation on data packet is required or not in some scenarios and if so, whether the specification is flexible or not. I think I will try to list down the scenarios as I understand based on my experience in this field so far. Scenarios: 1. SSL based ARs. 2. IPSEC based ARs 3. 802.1x based ARs - TKIP in AR 4. 802.1x based ARs - TKIP in APs 5. several combinations of above. SSL based AR OR IPSEC based AR: In these two cases, the trust relationship is between wireless stations and AR. In this case, I feel AR need not receive 802.11 packets as-is. On the wire (between AP and AR), it could be plain Ethernet packets. But, AR should know some events such as Association/De_association/ Re-association/802.11 authentication/de-auth, station Timeout events from AP . There is no need to pass the all 802.11 packets. 802.1x based ARs - TKIP in AR: Here too, trust relationship on per packet basis is maintained between warless stations and AR. Since, TKIP is centralized in AR, 802.11 packet have to be sent to AR by APs. 802.1x based ARs - TKIP in APs: In this case, per packet trust relationship is only between wireless stations and APs. Due to this, per packet authentication is required between APs and AR. Here, there is no need of sending all 802.11 packets. We only need to send data packets with LWAPP encapsulated for per packet authentication and AP events have to be sent to ARs. If all of above scenario to work, the implementations on AP should be capable\ of doing following: - Send 802.11 packets as-is to AR. - Send data packets without any encapsulation and AP events as LWAPP encapsulated messages. - Send data packets and control events with LWAPP encapsulation and with per packet authentication. Thanks for your time Rama Krishna Prasad Pat R. Calhoun wrote: > > >>Does group think that these events are required to be passed from >>APs to AR? >> >> >Yes > >PatC > > > --------------080604090500030604030502 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit 
Hi,
        As I understand current specification supports the type of deployment
        which you are talking about. I don't mean to remove this support in
        the specifications. I am trying to see whether sending LWAPP encapsulation
        on data packet is required or not in some scenarios and if so, whether the
        specification is flexible or not. I think I will try to list down the scenarios as
        I understand based on my experience in this field so far. 

        Scenarios:
        1. SSL based ARs.
        2. IPSEC based ARs
        3. 802.1x based ARs - TKIP in AR
        4. 802.1x based ARs - TKIP in APs
        5. several combinations of above.

        SSL based AR OR IPSEC based AR:
            In these two cases, the trust relationship is between wireless stations and
            AR. In this case, I feel AR need not receive 802.11 packets as-is.
            On the wire (between AP and AR), it could be plain Ethernet packets.
            But, AR should know some events such as Association/De_association/
               Re-association/802.11 authentication/de-auth,  station Timeout events from AP .
            There is no need to pass the all 802.11 packets.

        802.1x based ARs - TKIP in AR:
             Here too, trust relationship on per packet basis is maintained between warless 
             stations and AR. Since, TKIP is centralized in AR, 802.11 packet have to be
             sent to AR by APs.

        802.1x based ARs - TKIP in APs:
             In this case, per packet trust relationship is only between wireless stations and
            APs. Due to this, per packet authentication is required between APs and AR.
            Here, there is no need of sending all 802.11 packets. We only need to send 
            data packets with LWAPP encapsulated for per packet authentication and 
            AP events have to be sent to ARs.

      If all of above scenario to work, the implementations on AP should be capable\
      of doing following:
           - Send 802.11 packets as-is to AR.
           - Send data packets without any encapsulation
             and  AP events as LWAPP encapsulated messages.
          - Send data packets and control events with LWAPP encapsulation and
                 with per packet authentication.

     Thanks for your time
      Rama Krishna Prasad


Pat R. Calhoun wrote:
  
Does group think that these events are required to be passed from
APs to AR?
    
Yes

PatC

--------------080604090500030604030502-- From rkp@intotoinc.com Tue Jul 22 06:50:04 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Tue, 22 Jul 2003 11:20:04 +0530 Subject: [Lwapp] Per packet authentication ICV References: <40301581B2962B448690A023EF16DFE1DC50F3@bsn-mail-01.bstormnetworks.com> <3F1CB54E.1090607@intotoinc.com> Message-ID: <3F1CD08C.7030001@intotoinc.com> --------------090800050109040302070905 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi all, Sorry. This email is in response to email sent by Mr. Clint from Symbol. Regards Rama krishna Prasad Rama krishna prasad wrote: >Hi, > As I understand current specification supports the type of deployment > which you are talking about. I don't mean to remove this support in > the specifications. I am trying to see whether sending LWAPP encapsulation > on data packet is required or not in some scenarios and if so, whether the > specification is flexible or not. I think I will try to list down the scenarios as > I understand based on my experience in this field so far. > > Scenarios: > 1. SSL based ARs. > 2. IPSEC based ARs > 3. 802.1x based ARs - TKIP in AR > 4. 802.1x based ARs - TKIP in APs > 5. several combinations of above. > > SSL based AR OR IPSEC based AR: > In these two cases, the trust relationship is between wireless stations and > AR. In this case, I feel AR need not receive 802.11 packets as-is. > On the wire (between AP and AR), it could be plain Ethernet packets. > But, AR should know some events such as Association/De_association/ > Re-association/802.11 authentication/de-auth, station Timeout events from AP . > There is no need to pass the all 802.11 packets. > > 802.1x based ARs - TKIP in AR: > Here too, trust relationship on per packet basis is maintained between warless > stations and AR. Since, TKIP is centralized in AR, 802.11 packet have to be > sent to AR by APs. > > 802.1x based ARs - TKIP in APs: > In this case, per packet trust relationship is only between wireless stations and > APs. Due to this, per packet authentication is required between APs and AR. > Here, there is no need of sending all 802.11 packets. We only need to send > data packets with LWAPP encapsulated for per packet authentication and > AP events have to be sent to ARs. > > If all of above scenario to work, the implementations on AP should be capable\ > of doing following: > - Send 802.11 packets as-is to AR. > - Send data packets without any encapsulation > and AP events as LWAPP encapsulated messages. > - Send data packets and control events with LWAPP encapsulation and > with per packet authentication. > > Thanks for your time > Rama Krishna Prasad > > > > Pat R. Calhoun wrote: > >> >> >>>Does group think that these events are required to be passed from >>>APs to AR? >>> >>> >>Yes >> >>PatC >> >> >> > --------------090800050109040302070905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit 
Hi all,

Sorry. This email is in response to email sent by Mr. Clint from Symbol.


Regards
  Rama krishna Prasad


Rama krishna prasad wrote:
Hi,
        As I understand current specification supports the type of deployment
        which you are talking about. I don't mean to remove this support in
        the specifications. I am trying to see whether sending LWAPP encapsulation
        on data packet is required or not in some scenarios and if so, whether the
        specification is flexible or not. I think I will try to list down the scenarios as
        I understand based on my experience in this field so far. 

        Scenarios:
        1. SSL based ARs.
        2. IPSEC based ARs
        3. 802.1x based ARs - TKIP in AR
        4. 802.1x based ARs - TKIP in APs
        5. several combinations of above.

        SSL based AR OR IPSEC based AR:
            In these two cases, the trust relationship is between wireless stations and
            AR. In this case, I feel AR need not receive 802.11 packets as-is.
            On the wire (between AP and AR), it could be plain Ethernet packets.
            But, AR should know some events such as Association/De_association/
               Re-association/802.11 authentication/de-auth,  station Timeout events from AP .
            There is no need to pass the all 802.11 packets.

        802.1x based ARs - TKIP in AR:
             Here too, trust relationship on per packet basis is maintained between warless 
             stations and AR. Since, TKIP is centralized in AR, 802.11 packet have to be
             sent to AR by APs.

        802.1x based ARs - TKIP in APs:
             In this case, per packet trust relationship is only between wireless stations and
            APs. Due to this, per packet authentication is required between APs and AR.
            Here, there is no need of sending all 802.11 packets. We only need to send 
            data packets with LWAPP encapsulated for per packet authentication and 
            AP events have to be sent to ARs.

      If all of above scenario to work, the implementations on AP should be capable\
      of doing following:
           - Send 802.11 packets as-is to AR.
           - Send data packets without any encapsulation
             and  AP events as LWAPP encapsulated messages.
          - Send data packets and control events with LWAPP encapsulation and
                 with per packet authentication.

     Thanks for your time
      Rama Krishna Prasad


Pat R. Calhoun wrote:
  
Does group think that these events are required to be passed from
APs to AR?
    
Yes

PatC


--------------090800050109040302070905-- From Madjid.Nakhjiri@motorola.com Fri Jul 11 17:20:08 2003 From: Madjid.Nakhjiri@motorola.com (Nakhjiri Madjid-MNAKHJI1) Date: Fri, 11 Jul 2003 11:20:08 -0500 Subject: [Lwapp] (no subject) Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD6095@IL27EXM10.cig.mot.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C347C7.C02ECF7D Content-Type: text/plain; charset="iso-8859-1" Hi all, I am going through the LWAPP draft. Can somebody please tell me where the term "light weight AP" is originated from and is defined? I haven't gone through the entire draft yet, but from what I read so far, on one hand the draft mentions using more computing power of the AP and on the other hand, a light weight AP is brought up, and so far I haven't seen a justification for this virtual contradiction. Thanks, Madjid ------_=_NextPart_001_01C347C7.C02ECF7D Content-Type: text/html; charset="iso-8859-1"
Hi all,
 
I am going through the LWAPP draft. Can somebody please tell me where the term
"light weight AP" is originated from and is defined?
 
I haven't gone through the entire draft yet, but from what I read so far, on one
hand the draft mentions using more computing power of the AP and on the other
hand, a light weight AP is brought up, and so far I haven't seen a justification for
this virtual contradiction.
 
 
Thanks,
 Madjid

------_=_NextPart_001_01C347C7.C02ECF7D-- From pcalhoun@airespace.com Sun Jul 13 14:10:11 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sun, 13 Jul 2003 06:10:11 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC5118@bsn-mail-01.bstormnetworks.com> Right, but I am very worried about the amount of code and the processing = performance on the AP. Doing per data packet auth adds significant cost = to the AP. Most devices on the market do not have the CPU resources to = handle this. We could make this a requirement, but none of the devices = that ship would ever be able to be supported. Not sure this is a great = idea. PatC -----Original Message----- From: Rama krishna prasad [mailto:rkp@intotoinc.com] Sent: Mon 7/21/2003 8:53 PM To: lwapp@frascone.com Cc:=09 Subject: Re: [Lwapp] Per packet authentication ICV Hi, As I understand current specification supports the type of = deployment which you are talking about. I don't mean to remove this support = in the specifications. I am trying to see whether sending LWAPP = encapsulation on data packet is required or not in some scenarios and if so, = whether the specification is flexible or not. I think I will try to list = down the scenarios as I understand based on my experience in this field so far.=20 Scenarios: 1. SSL based ARs. 2. IPSEC based ARs 3. 802.1x based ARs - TKIP in AR 4. 802.1x based ARs - TKIP in APs 5. several combinations of above. SSL based AR OR IPSEC based AR: In these two cases, the trust relationship is between = wireless stations and AR. In this case, I feel AR need not receive 802.11 packets = as-is. On the wire (between AP and AR), it could be plain Ethernet = packets. But, AR should know some events such as = Association/De_association/ Re-association/802.11 authentication/de-auth, station = Timeout events from AP . There is no need to pass the all 802.11 packets. 802.1x based ARs - TKIP in AR: Here too, trust relationship on per packet basis is = maintained between warless=20 stations and AR. Since, TKIP is centralized in AR, 802.11 = packet have to be sent to AR by APs. 802.1x based ARs - TKIP in APs: In this case, per packet trust relationship is only between = wireless stations and APs. Due to this, per packet authentication is required = between APs and AR. Here, there is no need of sending all 802.11 packets. We = only need to send=20 data packets with LWAPP encapsulated for per packet = authentication and=20 AP events have to be sent to ARs. If all of above scenario to work, the implementations on AP should = be capable\ of doing following: - Send 802.11 packets as-is to AR. - Send data packets without any encapsulation and AP events as LWAPP encapsulated messages. - Send data packets and control events with LWAPP = encapsulation and with per packet authentication. Thanks for your time Rama Krishna Prasad Pat R. Calhoun wrote: > =20 > >>Does group think that these events are required to be passed from >>APs to AR? >> =20 >> >Yes > >PatC > > =20 > From pcalhoun@airespace.com Sun Jul 13 14:25:59 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sun, 13 Jul 2003 06:25:59 -0700 Subject: [Lwapp] (no subject) Message-ID: <40301581B2962B448690A023EF16DFE1DC511E@bsn-mail-01.bstormnetworks.com> > I am going through the LWAPP draft. Can somebody please tell me where = the term > "light weight AP" is originated from and is defined? =20 Not defined anywhere... it is a term used in the next gen WLAN industry. > I haven't gone through the entire draft yet, but from what I read so = far, on=20 > one hand the draft mentions using more computing power of the AP and = on the=20 > other hand, a light weight AP is brought up, and so far I haven't seen = a=20 > justification for this virtual contradiction. If you could point to where it states that we want to use MORE power on = the AP... that's obviously an editorial error. Is your justification = question in terms of why LWAPP? If so, the issue is that there are = several companies in the next gen WLAN space, all with a different = protocol, and demand for this architecture is really picking up in the = market. So it makes sense to standardize on this interface to allow the = consumers to buy any LWAPP-enabled AP. PatC From Madjid.Nakhjiri@motorola.com Mon Jul 14 16:35:16 2003 From: Madjid.Nakhjiri@motorola.com (Nakhjiri Madjid-MNAKHJI1) Date: Mon, 14 Jul 2003 10:35:16 -0500 Subject: [Lwapp] (no subject) Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD609C@IL27EXM10.cig.mot.com> Hi Pat, Thanks for your email. You are right, the draft doesn't advocate more computing power at AP, I misread the goal 1 (it says more efficient use of computing power). As far as "light weight AP", I think some explanation is needed to understand the difference between a "regular" and a light weight one. I am not saying why LWAPP, I agree that it is needed, however my confusion is: whether the "light weight" refers to the AP or to the protocol and it seems like it is the former, no? Madjid -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Sunday, July 13, 2003 8:26 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: lwapp@frascone.com Subject: RE: [Lwapp] (no subject) > I am going through the LWAPP draft. Can somebody please tell me where the term > "light weight AP" is originated from and is defined? Not defined anywhere... it is a term used in the next gen WLAN industry. > I haven't gone through the entire draft yet, but from what I read so far, on > one hand the draft mentions using more computing power of the AP and on the > other hand, a light weight AP is brought up, and so far I haven't seen a > justification for this virtual contradiction. If you could point to where it states that we want to use MORE power on the AP... that's obviously an editorial error. Is your justification question in terms of why LWAPP? If so, the issue is that there are several companies in the next gen WLAN space, all with a different protocol, and demand for this architecture is really picking up in the market. So it makes sense to standardize on this interface to allow the consumers to buy any LWAPP-enabled AP. PatC From cchaplin@sj.symbol.com Mon Jul 14 16:49:28 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Mon, 14 Jul 2003 08:49:28 -0700 Subject: [Lwapp] PKCS #5 "certificate" Message-ID: Section 5.24 states that the certificate is defined as a PKCS #5 certificate. PKCS #5 is titled "PKCS #5: Password-Based Encryption Standard", and does >not< define a certificate. Perhaps a different PKCS was meant? Clint (JOATMON) Chaplin From cchaplin@sj.symbol.com Mon Jul 14 16:53:31 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Mon, 14 Jul 2003 08:53:31 -0700 Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation. Message-ID: How is the AP supposed to validate the certificate presented to it by the AR? Is a certificate fingerprint going to have to be preinstalled in the AP, along with a certificate for the AP? How can the AR know that it can validate the AP certificate, and therefor give a Discovery Reply? Sonds like a catch-22 might be present here. It also sounds like the AP is going to have to keep state between Discovery Requests, especially if an AR rejects it because it cannot validate the AP certificate (and the opposite problem will happen when the AP cannot validate the AR's certificate). The AP isn't going to want to do the Discovery with the same AR it just failed with. Clint (JOATMON) Chaplin From dmolnar@eecs.harvard.edu Mon Jul 14 16:57:08 2003 From: dmolnar@eecs.harvard.edu (David Molnar) Date: Mon, 14 Jul 2003 11:57:08 -0400 (EDT) Subject: [Lwapp] PKCS #5 "certificate" In-Reply-To: References: Message-ID: On Mon, 14 Jul 2003, Clint Chaplin wrote: > Section 5.24 states that the certificate is defined as a PKCS #5 > certificate. PKCS #5 is titled "PKCS #5: Password-Based Encryption > Standard", and does >not< define a certificate. Perhaps a different > PKCS was meant? I can't speak for Pat or the other authors, but I note that PKCS #6 defines an extension to X.509 certs to allow certificates to hold additional attributes. http://www.rsasecurity.com/rsalabs/pkcs/pkcs-6/index.html -David From dmolnar@eecs.harvard.edu Mon Jul 14 17:10:33 2003 From: dmolnar@eecs.harvard.edu (David Molnar) Date: Mon, 14 Jul 2003 12:10:33 -0400 (EDT) Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation. In-Reply-To: References: Message-ID: On Mon, 14 Jul 2003, Clint Chaplin wrote: > How is the AP supposed to validate the certificate presented to it by > the AR? Is a certificate fingerprint going to have to be preinstalled > in the AP, along with a certificate for the AP? I've been wondering the same thing. I think the issue goes even deeper. Suppose every AP and AR shipped with a global CA public key, such as VeriSign, in them, just like browsers do. So I can go to VeriSign and register my AP and AR names. (N.B. I am *not* advocating we put VeriSign in every AP and AR...) Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone has a properly signed CA certificate attesting to their identity. Bob cannot impersonate Charlie and vice versa. Every pair can create a shared secret without anyone else being able to listen in. The questions are "How does Alice know she should be with Bob and not Charlie?" "How does Bob know Alice should be with him?" and in the scenario just outlined, I don't see any good way to answer those questions. Just having certificates, even "valid" certificates, is not enough (unless you shove the association into the name of the certificate!). We need to think about how secure associations are set up and validated. We should also think about whether setting up secure associations is within the purview of LWAPP or could be broken out into another protocol. I'm talking about these issues Friday at the BOF, for those who will be there. If you won't, I'll be happy to send you slides (once they're done). -David From suresh.h.krishnan@ericsson.com Mon Jul 14 20:21:12 2003 From: suresh.h.krishnan@ericsson.com (Suresh Krishnan (QB/LMC)) Date: Mon, 14 Jul 2003 15:21:12 -0400 Subject: [Lwapp] (no subject) In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B08AD609C@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B08AD609C@IL27EXM10.cig.mot.com> Message-ID: <3F1302A8.8070601@ericsson.ca> >I am not saying why LWAPP, I agree that it is needed, however my confusion >is: whether the "light weight" refers to the AP or to the protocol and it >seems >like it is the former, no? > >Madjid > > It refers to the Access Point being lightweight as mentioned here in draft-calhoun-seamoby-lwapp-03.txt 2. Protocol Overview LWAPP is a generic protocol defining how Light-Weight Access Points communicate with Access Routers. Access Points and Access Routers may be connected either by means of Layer 2 network or by means of a routed IP network. Regards Suresh From Madjid.Nakhjiri@motorola.com Mon Jul 14 20:46:57 2003 From: Madjid.Nakhjiri@motorola.com (Nakhjiri Madjid-MNAKHJI1) Date: Mon, 14 Jul 2003 14:46:57 -0500 Subject: [Lwapp] (no subject) Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD60A3@IL27EXM10.cig.mot.com> Yes, And that is what I started reacting to. I guess I have yet to find a definition of LWAP that I can sink my teeth into... Madjid 2. Protocol Overview LWAPP is a generic protocol defining how Light-Weight Access Points communicate with Access Routers. Access Points and Access Routers may be connected either by means of Layer 2 network or by means of a routed IP network. Regards Suresh From scott@airespace.com Mon Jul 14 23:25:54 2003 From: scott@airespace.com (Scott G. Kelly) Date: Mon, 14 Jul 2003 15:25:54 -0700 Subject: [Lwapp] PKCS #5 "certificate" References: Message-ID: <3F132DF2.5050706@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually, the current text is mistaken, and should instead say ~ The certificate message element value is a byte string containing a ~ DER-encoded x.509v3 certificate [5]. Sorry for not catching this in proof-reading. - --Scott David Molnar wrote: | | On Mon, 14 Jul 2003, Clint Chaplin wrote: | | |>Section 5.24 states that the certificate is defined as a PKCS #5 |>certificate. PKCS #5 is titled "PKCS #5: Password-Based Encryption |>Standard", and does >not< define a certificate. Perhaps a different |>PKCS was meant? | | | I can't speak for Pat or the other authors, but I note that PKCS #6 | defines an extension to X.509 certs to allow certificates to hold | additional attributes. | | http://www.rsasecurity.com/rsalabs/pkcs/pkcs-6/index.html | | -David | _______________________________________________ | Lwapp mailing list | Lwapp@frascone.com | http://mail.frascone.com/mailman/listinfo/lwapp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/Ey3yMtIdhO0pgN4RAkCEAJ9qvlyJ5B7dznNY1iWiKxchR+sDIgCeOoby RoHZegZBqra9qoE0nZzSp9c= =UKat -----END PGP SIGNATURE----- From cchaplin@sj.symbol.com Mon Jul 14 23:33:42 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Mon, 14 Jul 2003 15:33:42 -0700 Subject: [Lwapp] PKCS #5 "certificate" Message-ID: Well, that also means that you need to change the reference [5] text.... Clint (JOATMON) Chaplin >>> "Scott G. Kelly" 7/14/03 15:25:54 >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually, the current text is mistaken, and should instead say ~ The certificate message element value is a byte string containing a ~ DER-encoded x.509v3 certificate [5]. Sorry for not catching this in proof-reading. - --Scott David Molnar wrote: | | On Mon, 14 Jul 2003, Clint Chaplin wrote: | | |>Section 5.24 states that the certificate is defined as a PKCS #5 |>certificate. PKCS #5 is titled "PKCS #5: Password-Based Encryption |>Standard", and does >not< define a certificate. Perhaps a different |>PKCS was meant? | | | I can't speak for Pat or the other authors, but I note that PKCS #6 | defines an extension to X.509 certs to allow certificates to hold | additional attributes. | | http://www.rsasecurity.com/rsalabs/pkcs/pkcs-6/index.html | | -David | _______________________________________________ | Lwapp mailing list | Lwapp@frascone.com | http://mail.frascone.com/mailman/listinfo/lwapp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/Ey3yMtIdhO0pgN4RAkCEAJ9qvlyJ5B7dznNY1iWiKxchR+sDIgCeOoby RoHZegZBqra9qoE0nZzSp9c= =UKat -----END PGP SIGNATURE----- ________________________________________________________________________ This email has been scanned for computer viruses. From scott@airespace.com Mon Jul 14 23:39:42 2003 From: scott@airespace.com (Scott G. Kelly) Date: Mon, 14 Jul 2003 15:39:42 -0700 Subject: [Lwapp] PKCS #5 "certificate" References: Message-ID: <3F13312E.10600@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Agreed. In fact, I think the text is self-explanatory, and that no reference is required at all. - --Scott Clint Chaplin wrote: | Well, that also means that you need to change the reference [5] | text.... | | | Clint (JOATMON) Chaplin | | |>>>"Scott G. Kelly" 7/14/03 15:25:54 >>> |>> | Actually, the current text is mistaken, and should instead say | | ~ The certificate message element value is a byte string containing a | ~ DER-encoded x.509v3 certificate [5]. | | Sorry for not catching this in proof-reading. | | --Scott | | | David Molnar wrote: | | | | On Mon, 14 Jul 2003, Clint Chaplin wrote: | | | | | |>Section 5.24 states that the certificate is defined as a PKCS #5 | |>certificate. PKCS #5 is titled "PKCS #5: Password-Based Encryption | |>Standard", and does >not< define a certificate. Perhaps a different | |>PKCS was meant? | | | | | | I can't speak for Pat or the other authors, but I note that PKCS #6 | | defines an extension to X.509 certs to allow certificates to hold | | additional attributes. | | | | http://www.rsasecurity.com/rsalabs/pkcs/pkcs-6/index.html | | | | -David | | _______________________________________________ | | Lwapp mailing list | | Lwapp@frascone.com | | http://mail.frascone.com/mailman/listinfo/lwapp | ________________________________________________________________________ This email has been scanned for computer viruses. _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/EzEuMtIdhO0pgN4RAtl4AKCG6kuhL1fT+84hQEeyqQNTDU9+LACfcGKG eOoYR7DSIR8En+jXp260LxI= =AXp7 -----END PGP SIGNATURE----- From pcalhoun@airespace.com Tue Jul 15 10:13:47 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 15 Jul 2003 02:13:47 -0700 Subject: [Lwapp] (no subject) Message-ID: <40301581B2962B448690A023EF16DFE1DC5161@bsn-mail-01.bstormnetworks.com> > As far as "light weight AP", I think some explanation is needed to > understand the difference between a "regular" and a light weight one. A fair question indeed. Although there is no clear definition of what a = light weight access point is, in my mind (and implementation :), it = means that all access control, policy enforcements, IDS functions, = device management/configuration is handled in the AR. One of the many benefits of the architecture is that it allows the AR to = have a greater understanding of the RF topology, and can detect attacks = that may be mounted against a network as a whole, and take appropriate = action. > I am not saying why LWAPP, I agree that it is needed, however my = confusion > is: whether the "light weight" refers to the AP or to the protocol and = it > seems like it is the former, no? True, but I believe that the former can only be achieved via the latter = :) PatC From pcalhoun@airespace.com Tue Jul 15 11:18:46 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 15 Jul 2003 03:18:46 -0700 Subject: [Lwapp] (no subject) Message-ID: <40301581B2962B448690A023EF16DFE1DC516F@bsn-mail-01.bstormnetworks.com> Got it. I'll add a definition in the next rev of the spec. Thanks for the comment, PatC -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Mon 7/14/2003 12:46 PM To: 'Suresh Krishnan (QB/LMC)'; Nakhjiri Madjid-MNAKHJI1 Cc: Pat R. Calhoun; lwapp@frascone.com Subject: RE: [Lwapp] (no subject) Yes, And that is what I started reacting to. I guess I have yet to find a=20 definition of LWAP that I can sink my teeth into... Madjid 2. Protocol Overview LWAPP is a generic protocol defining how Light-Weight Access Points communicate with Access Routers. Access Points and Access Routers may be connected either by means of Layer 2 network or by means of a routed IP network. Regards Suresh From cchaplin@sj.symbol.com Tue Jul 15 20:35:22 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Tue, 15 Jul 2003 12:35:22 -0700 Subject: [Lwapp] (no subject) Message-ID: I believe that, at least in v03, many of the security issues are also assumed to take place in the AR (p6-7). This could also include encryption... Clint (JOATMON) Chaplin >>> "Pat R. Calhoun" 7/15/03 02:13:47 >>> > As far as "light weight AP", I think some explanation is needed to > understand the difference between a "regular" and a light weight one. A fair question indeed. Although there is no clear definition of what a light weight access point is, in my mind (and implementation :), it means that all access control, policy enforcements, IDS functions, device management/configuration is handled in the AR. One of the many benefits of the architecture is that it allows the AR to have a greater understanding of the RF topology, and can detect attacks that may be mounted against a network as a whole, and take appropriate action. > I am not saying why LWAPP, I agree that it is needed, however my confusion > is: whether the "light weight" refers to the AP or to the protocol and it > seems like it is the former, no? True, but I believe that the former can only be achieved via the latter :) PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ________________________________________________________________________ This email has been scanned for computer viruses. From rkp@intotoinc.com Wed Jul 16 04:43:24 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Wed, 16 Jul 2003 09:13:24 +0530 Subject: [Lwapp] Per packet authentication ICV References: <40301581B2962B448690A023EF16DFE1DC5118@bsn-mail-01.bstormnetworks.com> Message-ID: <3F14C9DC.1030505@intotoinc.com> --------------080401000109040106010606 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, Processing performance is very relative term and anyway, I also feel that it should be kept in mind. But, more importantly, I feel LWAPP is really useful in solving the problem of management. It is achieved by making AP implementation simple and devoid of any context information specific to station, such as 802.1x context, Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate problem of mobility at the AP level. OK, then let us make it simple. If we need to avoid per packet authentication, then we should go for doing TKIP at the AR level. That is all packet integrity and security should be cheeked at the AR level whether it is MAC level security, IPSEC network level security or SSL application level security. If we mandate this, then I feel there is no need for 'per packet authentication' between APs and AR. Also, the AP can send 802.11 packets to the AR and AR can extract AP events such as Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets. Since TKIP is going to be done at the AR, I assume that AR also should generate 802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this, we need to add text to this effect in the specifications. Regards Rama Krishna Prasad Pat R. Calhoun wrote: >Right, but I am very worried about the amount of code and the processing performance on the AP. Doing per data packet auth adds significant cost to the AP. Most devices on the market do not have the CPU resources to handle this. We could make this a requirement, but none of the devices that ship would ever be able to be supported. Not sure this is a great idea. > >PatC >-----Original Message----- >From: Rama krishna prasad [mailto:rkp@intotoinc.com] >Sent: Mon 7/21/2003 8:53 PM >To: lwapp@frascone.com >Cc: >Subject: Re: [Lwapp] Per packet authentication ICV >Hi, > As I understand current specification supports the type of deployment > which you are talking about. I don't mean to remove this support in > the specifications. I am trying to see whether sending LWAPP encapsulation > on data packet is required or not in some scenarios and if so, whether the > specification is flexible or not. I think I will try to list down the scenarios as > I understand based on my experience in this field so far. > > Scenarios: > 1. SSL based ARs. > 2. IPSEC based ARs > 3. 802.1x based ARs - TKIP in AR > 4. 802.1x based ARs - TKIP in APs > 5. several combinations of above. > > SSL based AR OR IPSEC based AR: > In these two cases, the trust relationship is between wireless stations and > AR. In this case, I feel AR need not receive 802.11 packets as-is. > On the wire (between AP and AR), it could be plain Ethernet packets. > But, AR should know some events such as Association/De_association/ > Re-association/802.11 authentication/de-auth, station Timeout events from AP . > There is no need to pass the all 802.11 packets. > > 802.1x based ARs - TKIP in AR: > Here too, trust relationship on per packet basis is maintained between warless > stations and AR. Since, TKIP is centralized in AR, 802.11 packet have to be > sent to AR by APs. > > 802.1x based ARs - TKIP in APs: > In this case, per packet trust relationship is only between wireless stations and > APs. Due to this, per packet authentication is required between APs and AR. > Here, there is no need of sending all 802.11 packets. We only need to send > data packets with LWAPP encapsulated for per packet authentication and > AP events have to be sent to ARs. > > If all of above scenario to work, the implementations on AP should be capable\ > of doing following: > - Send 802.11 packets as-is to AR. > - Send data packets without any encapsulation > and AP events as LWAPP encapsulated messages. > - Send data packets and control events with LWAPP encapsulation and > with per packet authentication. > > Thanks for your time > Rama Krishna Prasad > > > >Pat R. Calhoun wrote: > > > >> >> >> >> >>>Does group think that these events are required to be passed from >>>APs to AR? >>> >>> >>> >>> >>Yes >> >>PatC >> >> >> >> >> > > > > > > --------------080401000109040106010606 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit 
Hi,

        Processing performance is very relative term and anyway, I also feel that  it should be kept in mind.
       But, more importantly, I feel LWAPP is really useful in solving the problem of
           management. It is achieved by making AP implementation simple and
           devoid of any context information specific to station, such as 802.1x context,
           Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate
           problem of mobility at the AP level.

     OK, then let us make it simple. If we need to avoid per packet authentication, then
     we should go for doing TKIP at the AR level. That is all packet integrity and security
     should be cheeked at the AR level whether it is MAC level security, IPSEC network
     level security or SSL application level security.  If we mandate this, then I feel there
     is no need for 'per packet authentication' between APs and AR. Also, the AP can
     send 802.11 packets to the AR and AR can extract AP events such as
     Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets.
     Since TKIP is going to be done at the AR, I assume that AR also should generate
     802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this,
     we need to add text to this effect in the specifications.

 Regards
 Rama Krishna Prasad


Pat R. Calhoun wrote:
Right, but I am very worried about the amount of code and the processing performance on the AP. Doing per data packet auth adds significant cost to the AP. Most devices on the market do not have the CPU resources to handle this. We could make this a requirement, but none of the devices that ship would ever be able to be supported. Not sure this is a great idea.

PatC
-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent:	Mon 7/21/2003 8:53 PM
To:	lwapp@frascone.com
Cc:	
Subject:	Re: [Lwapp] Per packet authentication ICV
Hi,
        As I understand current specification supports the type of deployment
        which you are talking about. I don't mean to remove this support in
        the specifications. I am trying to see whether sending LWAPP encapsulation
        on data packet is required or not in some scenarios and if so, whether the
        specification is flexible or not. I think I will try to list down the scenarios as
        I understand based on my experience in this field so far. 

        Scenarios:
        1. SSL based ARs.
        2. IPSEC based ARs
        3. 802.1x based ARs - TKIP in AR
        4. 802.1x based ARs - TKIP in APs
        5. several combinations of above.

        SSL based AR OR IPSEC based AR:
            In these two cases, the trust relationship is between wireless stations and
            AR. In this case, I feel AR need not receive 802.11 packets as-is.
            On the wire (between AP and AR), it could be plain Ethernet packets.
            But, AR should know some events such as Association/De_association/
               Re-association/802.11 authentication/de-auth,  station Timeout events from AP .
            There is no need to pass the all 802.11 packets.

        802.1x based ARs - TKIP in AR:
             Here too, trust relationship on per packet basis is maintained between warless 
             stations and AR. Since, TKIP is centralized in AR, 802.11 packet have to be
             sent to AR by APs.

        802.1x based ARs - TKIP in APs:
             In this case, per packet trust relationship is only between wireless stations and
            APs. Due to this, per packet authentication is required between APs and AR.
            Here, there is no need of sending all 802.11 packets. We only need to send 
            data packets with LWAPP encapsulated for per packet authentication and 
            AP events have to be sent to ARs.

      If all of above scenario to work, the implementations on AP should be capable\
      of doing following:
           - Send 802.11 packets as-is to AR.
           - Send data packets without any encapsulation
             and  AP events as LWAPP encapsulated messages.
          - Send data packets and control events with LWAPP encapsulation and
                 with per packet authentication.

     Thanks for your time
      Rama Krishna Prasad



Pat R. Calhoun wrote:

  
 

    
Does group think that these events are required to be passed from
APs to AR?
   

      
Yes

PatC

--------------080401000109040106010606-- From rkp@intotoinc.com Wed Jul 16 04:45:28 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Wed, 16 Jul 2003 09:15:28 +0530 Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation. References: Message-ID: <3F14CA58.2090504@intotoinc.com> --------------090502020208060709090602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, x.509 certificates contain subject name (subject alt-name). I feel, this subject (alt) names can be used to identify the peer. For example, AP can be preinstalled with X.509 certificate signed by general CA or local CA server and also it can be pre-programmed with the names of ARs that it should join. Similarly, AR can be configured with subject (alt) names of AP that it trusts. Validation on allowing the peer can be done during the 'Discovery' phase. Regards Rama Krishna Prasad Intoto Software(I)PVT Ltd PlotNo:15 New VasaviNagar, Secundrabad. INDIA-500015 David Molnar wrote: >On Mon, 14 Jul 2003, Clint Chaplin wrote: > > > >>How is the AP supposed to validate the certificate presented to it by >>the AR? Is a certificate fingerprint going to have to be preinstalled >>in the AP, along with a certificate for the AP? >> >> > >I've been wondering the same thing. I think the issue goes even deeper. >Suppose every AP and AR shipped with a global CA public key, such as >VeriSign, in them, just like browsers do. So I can go to VeriSign and >register my AP and AR names. (N.B. I am *not* advocating we put VeriSign >in every AP and AR...) > >Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone has a >properly signed CA certificate attesting to their identity. Bob cannot >impersonate Charlie and vice versa. Every pair can create a shared secret >without anyone else being able to listen in. > >The questions are > > "How does Alice know she should be with Bob and not Charlie?" > "How does Bob know Alice should be with him?" > >and in the scenario just outlined, I don't see any good way to answer >those questions. Just having certificates, even "valid" certificates, is >not enough (unless you shove the association into the name of the >certificate!). We need to think about how secure associations are set up >and validated. We should also think about whether setting up secure >associations is within the purview of LWAPP or could be broken out into >another protocol. > >I'm talking about these issues Friday at the BOF, for those who will be >there. If you won't, I'll be happy to send you slides (once they're done). > >-David >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp > > > --------------090502020208060709090602 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi,
          x.509 certificates contain subject name (subject alt-name).  I feel, 
          this subject (alt) names can be used to identify the peer. 
          For example, AP can be preinstalled with X.509 certificate signed
          by general CA or local CA server and also it can be pre-programmed
          with the names of ARs that it should join. Similarly, AR can be configured
          with subject (alt) names of AP that it trusts. Validation on allowing the
          peer can be done during the 'Discovery' phase.
Regards
Rama Krishna Prasad
Intoto Software(I)PVT Ltd
PlotNo:15 New VasaviNagar,
Secundrabad.
INDIA-500015


David Molnar wrote:
On Mon, 14 Jul 2003, Clint Chaplin wrote:

  
How is the AP supposed to validate the certificate presented to it by
the AR?  Is a certificate fingerprint going to have to be preinstalled
in the AP, along with a certificate for the AP?
    

I've been wondering the same thing. I think the issue goes even deeper.
Suppose every AP and AR shipped with a global CA public key, such as
VeriSign, in them, just like browsers do. So I can go to VeriSign and
register my AP and AR names. (N.B. I am *not* advocating we put VeriSign
in every AP and AR...)

Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone has a
properly signed CA certificate attesting to their identity. Bob cannot
impersonate Charlie and vice versa. Every pair can create a shared secret
without anyone else being able to listen in.

The questions are

	"How does Alice know she should be with Bob and not Charlie?"
	"How does Bob know Alice should be with him?"

and in the scenario just outlined, I don't see any good way to answer
those questions. Just having certificates, even "valid" certificates, is
not enough (unless you shove the association into the name of the
certificate!). We need to think about how secure associations are set up
and validated. We should also think about whether setting up secure
associations is within the purview of LWAPP or could be broken out into
another protocol.

I'm talking about these issues Friday at the BOF, for those who will be
there. If you won't, I'll be happy to send you slides (once they're done).

-David
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

--------------090502020208060709090602-- From isingh@chantrynetworks.com Wed Jul 16 11:11:24 2003 From: isingh@chantrynetworks.com (Inderpreet Singh) Date: Wed, 16 Jul 2003 06:11:24 -0400 Subject: [Lwapp] (no subject) In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5161@bsn-mail-01.bstormnetworks.com> Message-ID: <001a01c34b82$ad452f50$6705a8c0@toronto.chantrynetworks.com> > > > As far as "light weight AP", I think some explanation is needed to > > understand the difference between a "regular" and a light weight one. > > A fair question indeed. Although there is no clear definition of what a > light weight access point is, in my mind (and implementation :), it means > that all access control, policy enforcements, IDS functions, device > management/configuration is handled in the AR. > Agreed with a few changes based on my thoughts (and implementation..:-) ... All access control, majority of policy enforcement, IDS functions, device management/configuration, and wireless station policy management is handled in the AR. It DOES NOT mean that all or even some 802.11 packet handling is done in the AR. The MAC and PHY are integral to the AP. In order to be centrally configured and provisioned the lightweight AP includes the signaling functionality that is currently proposed by LWAPP. Thanks Inderpreet From pcalhoun@airespace.com Wed Jul 16 12:47:04 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 16 Jul 2003 04:47:04 -0700 Subject: [Lwapp] (no subject) Message-ID: <40301581B2962B448690A023EF16DFE1DC51B7@bsn-mail-01.bstormnetworks.com> > I believe that, at least in v03, many of the security issues are also > assumed to take place in the AR (p6-7). This could also include > encryption... Correct, but the document allows encryption to occur in either. = Realistically, since most 802.11 chipsets include crypto functions, it = makes sense to use that function, and reduce the need for specialized = TKIP/WEP crypto functions in the AR - reducing the cost of the device. PatC From isingh@chantrynetworks.com Wed Jul 16 12:51:13 2003 From: isingh@chantrynetworks.com (Inderpreet Singh) Date: Wed, 16 Jul 2003 07:51:13 -0400 Subject: [Lwapp] Per packet authentication ICV In-Reply-To: <3F14C9DC.1030505@intotoinc.com> Message-ID: <002201c34b90$9edd6870$6705a8c0@toronto.chantrynetworks.com> This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C34B6F.17CBC870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Things were sounding fine until I saw "mandate 802.11 processing in the AR". I beg to differ. Mandating any kind of 802.11 processing on the AR is enforcing an architectural solution to a performance and cost of hardware problem. There is no technical merit to doing this from a protocol perspective. Furthermore, correct me if I am wrong, but shouldn't we shy away from mandating the physical or logical location of where IEEE protocols (L2 packets) are processed. This doesn't seem to me to be theIETF approach. So, the security threats and vulnerabilities of unencrypted encapsulated data packets are obvious (or maybe not). But note that there is no guarantee that the packets are going to be protected with 802.11i (or WPA in the interim) in the first place.so mandating 802.11 processing in the AR doesn't solve the inherent security threat. To make it flexible and to meet the security requirements why not approach it as such: Data packet encapsulation - 2 negotiable options within the protocol spec 1) 802.3 encapsulation - wireless client's 802.11 data is first bridged by AP into 802.3 and then use lwapp to encapsulate and send to AR 2) 802.11 encapsulation - wireless client's 802.11 data is directly encapsulated with lwapp and sent to AR If option 1 is the negotiated then the implementation SHOULD enforce higher layer security policies for the data traffic. For example, data traffic is secured via IPsec or SSL, etc. In addition, an implementation MAY secure (per-packet auth) the transport of the encapsulated data packets (between AP and AR) If option 2 is negotiated then the implementation MAY enforce that 802.11 security mechanisms like WPA and eventually 802.11i have been used to secure the user's data. (of course it may further enforce higher layer security protection as well.). In addition, an implementation MAY secure (per-packet auth) the transport of the encapsulated data packets This is a high level proposal.we could discuss further online and also at the BOF. Comments? Inderpreet -- -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Rama krishna prasad Sent: Tuesday, July 15, 2003 11:43 PM To: Pat R. Calhoun Cc: lwapp@frascone.com Subject: Re: [Lwapp] Per packet authentication ICV Hi, Processing performance is very relative term and anyway, I also feel that it should be kept in mind. But, more importantly, I feel LWAPP is really useful in solving the problem of management. It is achieved by making AP implementation simple and devoid of any context information specific to station, such as 802.1x context, Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate problem of mobility at the AP level. OK, then let us make it simple. If we need to avoid per packet authentication, then we should go for doing TKIP at the AR level. That is all packet integrity and security should be cheeked at the AR level whether it is MAC level security, IPSEC network level security or SSL application level security. If we mandate this, then I feel there is no need for 'per packet authentication' between APs and AR. Also, the AP can send 802.11 packets to the AR and AR can extract AP events such as Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets. Since TKIP is going to be done at the AR, I assume that AR also should generate 802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this, we need to add text to this effect in the specifications. Regards Rama Krishna Prasad ------=_NextPart_000_0023_01C34B6F.17CBC870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Things were sounding fine until I = saw “mandate 802.11 processing in the AR”. 

 

I beg to differ.  Mandating any kind of 802.11 = processing on the AR is enforcing an architectural solution to a performance and = cost of hardware problem.  There is = no technical merit to doing this from a protocol perspective.  Furthermore, correct me if I am = wrong, but shouldn’t we shy away from mandating the physical or logical = location of where IEEE protocols (L2 packets) are processed.  This doesn’t seem to me = to be theIETF approach.

 

So, the security threats and vulnerabilities of unencrypted encapsulated data packets are obvious (or = maybe not). But note that there is no guarantee that the packets are going to = be protected with 802.11i (or WPA in the interim) in the first = place…so mandating 802.11 processing in the AR doesn’t solve the inherent security threat.  

 

To make it flexible and to meet the security requirements why not approach it as = such:

 

Data packet encapsulation – 2 = negotiable options within the protocol spec

 

1)       = 802.3 encapsulation – wireless = client’s 802.11 data is first bridged by AP into 802.3 and then use lwapp to = encapsulate and send to AR

2)       = 802.11 encapsulation – wireless = client’s 802.11 data is directly encapsulated with lwapp and sent to = AR

 

If option 1 is the negotiated then = the implementation SHOULD enforce higher layer security policies for the = data traffic.  For example, data = traffic is secured via IPsec or SSL, etc.  = In addition, an implementation MAY secure (per-packet auth) the transport = of the encapsulated data packets (between AP and AR)

 

If option 2 is negotiated then the implementation MAY enforce that 802.11 security mechanisms like WPA and eventually 802.11i have been used to secure the user’s data. = (of course it may further enforce higher layer = security protection as well.).  In = addition, an implementation MAY secure (per-packet auth) the transport of the = encapsulated data packets

 

This is a high level = proposal…we could discuss further online and also at the = BOF.

 

Comments?

 

Inderpreet<= /p>

--

-----Original Message-----
From: = lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of Rama krishna prasad
Sent: = Tuesday, July 15, = 2003 11:43 PM
To: Pat R. Calhoun
Cc: = lwapp@frascone.com
Subject: Re: [Lwapp] Per = packet authentication ICV

 

Hi,
 
        =
Processing performance is very relative term and anyway, I also =
feel that  it should be =
kept in mind.
       =
But, more importantly, I feel LWAPP is really useful in solving =
the problem of
       &nbs=
p;   management. It is achieved by making AP =
implementation simple and
       &nbs=
p;   devoid of any context information specific to =
station, such as 802.1x =
context,
       &nbs=
p;   Firewall/NAT context,SSL context, QoS Context =
etc.. This will eliminate
       &nbs=
p;   problem of mobility at the AP =
level.
 
     OK, then let =
us make it simple. If we need to avoid per packet authentication, =
then
     we should go =
for doing TKIP at the AR level. That is all packet integrity and =
security
     should be =
cheeked at the AR level whether it is MAC level security, IPSEC =
network
     level =
security or SSL application level security.  If we mandate this, then I feel =
there
     is no need =
for 'per packet authentication' between APs and AR. Also, the AP =
can
     send 802.11 =
packets to the AR and AR can extract AP events such =
as
     =
Associate/De-Associate/Re-Associate/Open authentication from the =
802.11 packets.
     Since TKIP is =
going to be done at the AR, I assume that AR also should =
generate
     802.11 =
packets, which inturn will be forwarded to stations by the APs. If we =
agree to this,
     we need to =
add text to this effect in the =
specifications.
 
 =
Regards
 Rama =
Krishna Prasad
------=_NextPart_000_0023_01C34B6F.17CBC870-- From esadot@avaya.com Wed Jul 16 13:44:09 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Wed, 16 Jul 2003 15:44:09 +0300 Subject: [Lwapp] Per packet authentication ICV Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C34B97.F36B9C28 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, =20 I feel that we should be very careful with the requirement to force = 802.11 packet encapsulation toward the AR. Please keep in mind that such = architecture call off the HW component within the AR, in other words all = packets must traverse the AR CPU =96 I doubt if it would it be = acceptable. =20 Emek =20 -----Original Message----- From: Rama krishna prasad [mailto:rkp@intotoinc.com] Sent: Wednesday, 16 July, 2003 6:43 AM To: Pat R. Calhoun Cc: lwapp@frascone.com Subject: Re: [Lwapp] Per packet authentication ICV =20 Hi, =20 Processing performance is very relative term and anyway, I also = feel that it should be kept in mind. But, more importantly, I feel LWAPP is really useful in solving = the problem of management. It is achieved by making AP implementation simple = and devoid of any context information specific to station, such = as 802.1x context, Firewall/NAT context,SSL context, QoS Context etc.. This will = eliminate problem of mobility at the AP level. =20 OK, then let us make it simple. If we need to avoid per packet = authentication, then we should go for doing TKIP at the AR level. That is all packet = integrity and security should be cheeked at the AR level whether it is MAC level security, = IPSEC network level security or SSL application level security. If we mandate = this, then I feel there is no need for 'per packet authentication' between APs and AR. = Also, the AP can send 802.11 packets to the AR and AR can extract AP events such as Associate/De-Associate/Re-Associate/Open authentication from the = 802.11 packets. Since TKIP is going to be done at the AR, I assume that AR also = should generate 802.11 packets, which inturn will be forwarded to stations by the = APs. If we agree to this, we need to add text to this effect in the specifications. =20 Regards Rama Krishna Prasad Pat R. Calhoun wrote: Right, but I am very worried about the amount of code and the processing = performance on the AP. Doing per data packet auth adds significant cost = to the AP. Most devices on the market do not have the CPU resources to = handle this. We could make this a requirement, but none of the devices = that ship would ever be able to be supported. Not sure this is a great = idea. =20 PatC -----Original Message----- From: Rama krishna prasad [ mailto:rkp@intotoinc.com] Sent: Mon 7/21/2003 8:53 PM To: lwapp@frascone.com Cc:=20 Subject: Re: [Lwapp] Per packet authentication ICV Hi, As I understand current specification supports the type of = deployment which you are talking about. I don't mean to remove this support = in the specifications. I am trying to see whether sending LWAPP = encapsulation on data packet is required or not in some scenarios and if so, = whether the specification is flexible or not. I think I will try to list = down the scenarios as I understand based on my experience in this field so far.=20 =20 Scenarios: 1. SSL based ARs. 2. IPSEC based ARs 3. 802.1x based ARs - TKIP in AR 4. 802.1x based ARs - TKIP in APs 5. several combinations of above. =20 SSL based AR OR IPSEC based AR: In these two cases, the trust relationship is between = wireless stations and AR. In this case, I feel AR need not receive 802.11 packets = as-is. On the wire (between AP and AR), it could be plain Ethernet = packets. But, AR should know some events such as = Association/De_association/ Re-association/802.11 authentication/de-auth, station = Timeout events from AP . There is no need to pass the all 802.11 packets. =20 802.1x based ARs - TKIP in AR: Here too, trust relationship on per packet basis is = maintained between warless=20 stations and AR. Since, TKIP is centralized in AR, 802.11 = packet have to be sent to AR by APs. =20 802.1x based ARs - TKIP in APs: In this case, per packet trust relationship is only between = wireless stations and APs. Due to this, per packet authentication is required = between APs and AR. Here, there is no need of sending all 802.11 packets. We = only need to send=20 data packets with LWAPP encapsulated for per packet = authentication and=20 AP events have to be sent to ARs. =20 If all of above scenario to work, the implementations on AP should = be capable\ of doing following: - Send 802.11 packets as-is to AR. - Send data packets without any encapsulation and AP events as LWAPP encapsulated messages. - Send data packets and control events with LWAPP = encapsulation and with per packet authentication. =20 Thanks for your time Rama Krishna Prasad =20 =20 =20 Pat R. Calhoun wrote: =20 =20 =20 =20 =20 Does group think that these events are required to be passed from APs to AR? =20 =20 =20 Yes =20 PatC =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C34B97.F36B9C28 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

I feel that we = should be very careful with the requirement to force 802.11 packet encapsulation = toward the AR. Please keep in mind that such architecture call off the HW = component within the AR, in other words all packets must traverse the AR CPU =96 I doubt = if it would it be acceptable.

 

Emek

 

-----Original Message-----
From: Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent: Wednesday, 16 July, = 2003 6:43 AM
To: Pat R. Calhoun
Cc: = lwapp@frascone.com
Subject: Re: [Lwapp] Per = packet authentication ICV

 

Hi,<=
/pre>
 <=
/pre>
=A0=A0=A0=A0=A0=A0=A0 Processing performance is very =
relative term and anyway, I also feel that=A0 it should be kept in mind.<=
/pre>
=A0=A0=A0=A0=A0=A0 But, more importantly, I feel LWAPP is =
really useful in solving the problem of<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 management. It is achieved by =
making AP implementation simple and<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 devoid of any context =
information specific to station, such as 802.1x =
context,<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Firewall/NAT context,SSL =
context, QoS Context etc.. This will eliminate<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 problem of mobility at the AP =
level.<=
/pre>
 <=
/pre>
=A0=A0=A0=A0 OK, then let us make it simple. If we need to =
avoid per packet authentication, then<=
/pre>
=A0=A0=A0=A0 we should go for doing TKIP at the AR level. =
That is all packet integrity and security<=
/pre>
=A0=A0=A0=A0 should be cheeked at the AR level whether it is =
MAC level security, IPSEC network<=
/pre>
=A0=A0=A0=A0 level security or SSL application level =
security.=A0 If we mandate =
this, then I feel there<=
/pre>
=A0=A0=A0=A0 is no need for 'per packet authentication' =
between APs and AR. Also, the AP can<=
/pre>
=A0=A0=A0=A0 send 802.11 packets to the AR and AR can =
extract AP events such as<=
/pre>
=A0=A0=A0=A0 Associate/De-Associate/Re-Associate/Open =
authentication from the 802.11 packets.<=
/pre>
=A0=A0=A0=A0 Since TKIP is going to be done at the AR, I =
assume that AR also should generate<=
/pre>
=A0=A0=A0=A0 802.11 packets, which inturn will be forwarded =
to stations by the APs. If we agree to this,<=
/pre>
=A0=A0=A0=A0 we need to add text to this effect in the =
specifications.<=
/pre>
 <=
/pre>
 Regards<=
/pre>
 Rama Krishna =
Prasad<=
/pre>






Pat R. Calhoun wrote:







Right, =
but I am very worried about the amount of code and the processing =
performance on the AP. Doing per data packet auth adds significant cost =
to the AP. Most devices on the market do not have the CPU resources to =
handle this. We could make this a requirement, but none of the devices =
that ship would ever be able to be supported. Not sure this is a great =
idea.<=
/pre>
 <=
/pre>
PatC<=
/pre>
-----Original =
Message-----<=
/pre>
From:=A0=A0=A0=A0=A0 Rama krishna prasad [mailto:rkp@intotoinc.com]<=
/pre>
Sent:=A0=A0=A0=A0=A0 Mon 7/21/2003 8:53 =
PM<=
/pre>
To: lwapp@frascone.com<=
/pre>
Cc: <=
/pre>
Subject:=A0=A0 Re: [Lwapp] Per packet =
authentication ICV<=
/pre>
Hi,<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 As I understand current specification =
supports the type of deployment<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 which you are talking about. I don't =
mean to remove this support in<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 the specifications. I am trying to see =
whether sending LWAPP encapsulation<=
/pre>
=A0=A0=A0=A0=A0 =A0=A0on data packet is required or not in some scenarios =
and if so, whether the<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 specification is flexible or not. I =
think I will try to list down the scenarios as<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 I understand based on my experience in =
this field so far. <=
/pre>
 <=
/pre>
=A0=A0=A0=A0=A0=A0=A0 Scenarios:<=
/pre>
 =A0=A0=A0=A0=A0=A0=A01. SSL based ARs.<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 2. IPSEC based ARs<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 3. 802.1x based ARs - TKIP in =
AR<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 4. 802.1x based ARs - TKIP in =
APs<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 5. several combinations of =
above.<=
/pre>
 <=
/pre>
=A0=A0=A0=A0=A0=A0=A0 SSL based AR OR IPSEC based =
AR:<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In these two cases, the =
trust relationship is between wireless stations and<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AR. In this case, I feel =
AR need not receive 802.11 packets as-is.<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 On the wire (between AP =
and AR), it could be plain Ethernet packets.<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 But, AR should know some =
events such as Association/De_association/<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Re-association/802.11 authentication/de-auth,=A0 station Timeout events from AP =
.<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 There is no need to pass =
the all 802.11 packets.<=
/pre>
 <=
/pre>
=A0=A0=A0=A0=A0=A0=A0 802.1x based ARs - TKIP in =
AR:<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Here too, trust =
relationship on per packet basis is maintained between warless =
<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0stations and AR. =
Since, TKIP is centralized in AR, 802.11 packet have to =
be<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sent to AR by =
APs.<=
/pre>
 <=
/pre>
=A0=A0=A0=A0=A0=A0=A0 802.1x based ARs - TKIP in =
APs:<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In this case, per =
packet trust relationship is only between wireless stations =
and<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 APs. Due to this, per =
packet authentication is required between APs and AR.<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Here, there is no need of =
sending all 802.11 packets. We only need to send <=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0data packets with LWAPP =
encapsulated for per packet authentication and <=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0AP events have to be =
sent to ARs.<=
/pre>
 <=
/pre>
=A0=A0=A0=A0=A0 If all of above scenario to work, the =
implementations on AP should be capable\<=
/pre>
=A0=A0=A0=A0=A0 of doing following:<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Send 802.11 packets as-is =
to AR.<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Send data packets without =
any encapsulation<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 and=A0 AP events as LWAPP encapsulated =
messages.<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Send data packets and control =
events with LWAPP encapsulation and<=
/pre>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 with per =
packet authentication.<=
/pre>
 <=
/pre>
=A0=A0=A0=A0 Thanks for your time<=
/pre>
=A0=A0=A0=A0=A0 Rama Krishna Prasad<=
/pre>
 <=
/pre>
 <=
/pre>
 <=
/pre>
Pat R. Calhoun =
wrote:<=
/pre>
 <=
/pre>
=A0 <=
/pre>
=A0<=
/pre>
 <=
/pre>
=A0=A0=A0 <=
/pre>
Does =
group think that these events are required to be passed =
from<=
/pre>
APs to =
AR?<=
/pre>
=A0=A0 <=
/pre>
 <=
/pre>
=A0=A0=A0=A0=A0 <=
/pre>
Yes<=
/pre>
 <=
/pre>
PatC<=
/pre>
 <=
/pre>
 <=
/pre>
 <=
/pre>
=A0=A0=A0 <=
/pre>
 <=
/pre>
 <=
/pre>
 <=
/pre>
 <=
/pre>
=A0 <=
/pre>


 <=
/p>
------_=_NextPart_001_01C34B97.F36B9C28-- From cchaplin@sj.symbol.com Wed Jul 16 18:59:29 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Wed, 16 Jul 2003 10:59:29 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: I must point out a potential problem here, one that might force at least some 802.11 processing into the APs: The solution for QoS that is being proposed by IEEE 802.11 TGe will force any decisions as to what to send and when into the AP itself; the AP simply will not have enough time to poll the AR for information/guidance. In addition, the decision as to where to split a MSDU into MPDUs in order to fit into the given time slot must be made >now< and at the AP, and that includes encrypting the MPDUs. Therefor, it will be impossible for the AR to do the TKIP encryption; it will have to be handled by the AP. Which means that the packets data packets between the AR and the AP will have to be protected in some other way. Clint (JOATMON) Chaplin >>> "Inderpreet Singh" 7/16/03 04:51:13 >>> Things were sounding fine until I saw "mandate 802.11 processing in the AR". I beg to differ. Mandating any kind of 802.11 processing on the AR is enforcing an architectural solution to a performance and cost of hardware problem. There is no technical merit to doing this from a protocol perspective. Furthermore, correct me if I am wrong, but shouldn't we shy away from mandating the physical or logical location of where IEEE protocols (L2 packets) are processed. This doesn't seem to me to be theIETF approach. So, the security threats and vulnerabilities of unencrypted encapsulated data packets are obvious (or maybe not). But note that there is no guarantee that the packets are going to be protected with 802.11i (or WPA in the interim) in the first place.so mandating 802.11 processing in the AR doesn't solve the inherent security threat. To make it flexible and to meet the security requirements why not approach it as such: Data packet encapsulation - 2 negotiable options within the protocol spec 1) 802.3 encapsulation - wireless client's 802.11 data is first bridged by AP into 802.3 and then use lwapp to encapsulate and send to AR 2) 802.11 encapsulation - wireless client's 802.11 data is directly encapsulated with lwapp and sent to AR If option 1 is the negotiated then the implementation SHOULD enforce higher layer security policies for the data traffic. For example, data traffic is secured via IPsec or SSL, etc. In addition, an implementation MAY secure (per-packet auth) the transport of the encapsulated data packets (between AP and AR) If option 2 is negotiated then the implementation MAY enforce that 802.11 security mechanisms like WPA and eventually 802.11i have been used to secure the user's data. (of course it may further enforce higher layer security protection as well.). In addition, an implementation MAY secure (per-packet auth) the transport of the encapsulated data packets This is a high level proposal.we could discuss further online and also at the BOF. Comments? Inderpreet -- -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Rama krishna prasad Sent: Tuesday, July 15, 2003 11:43 PM To: Pat R. Calhoun Cc: lwapp@frascone.com Subject: Re: [Lwapp] Per packet authentication ICV Hi, Processing performance is very relative term and anyway, I also feel that it should be kept in mind. But, more importantly, I feel LWAPP is really useful in solving the problem of management. It is achieved by making AP implementation simple and devoid of any context information specific to station, such as 802.1x context, Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate problem of mobility at the AP level. OK, then let us make it simple. If we need to avoid per packet authentication, then we should go for doing TKIP at the AR level. That is all packet integrity and security should be cheeked at the AR level whether it is MAC level security, IPSEC network level security or SSL application level security. If we mandate this, then I feel there is no need for 'per packet authentication' between APs and AR. Also, the AP can send 802.11 packets to the AR and AR can extract AP events such as Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets. Since TKIP is going to be done at the AR, I assume that AR also should generate 802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this, we need to add text to this effect in the specifications. Regards Rama Krishna Prasad ________________________________________________________________________ This email has been scanned for computer viruses. From rkp@intotoinc.com Thu Jul 17 04:48:36 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Thu, 17 Jul 2003 09:18:36 +0530 Subject: [Lwapp] Per packet authentication ICV References: <002201c34b90$9edd6870$6705a8c0@toronto.chantrynetworks.com> Message-ID: <3F161C94.2090704@intotoinc.com> --------------080508030201090607080504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, This proposal seems good. Option 1: As I understand, in this method 802.11 header is stripped off in AP and 802.3 data packets are sent to the AR with LWAPP encapsulation. A. We need following sub-options in this. - Enable LWAPP security on the 802.3 packets (It involves the encryption/ICV addition as done for LWAPP control packets). This option is typically selected when TKIP is done in the APs and if AR knows that there is no other security between stations and AR. - Disable LWAPP Security (This option can be selected by AR when it knows that traffic from Stations to the AR is secured by IPSEC or SSL. AR can select this option if UDP transport is selected between AP and AR and if UDP transport is secured by IPSEC). Points to ponder here: - Given an AP can support multiple WLANs (Multiple radios in AP Or Multiple SSID support in AP for one radio). For one WLAN, IPSEC/SSL would have been enabled between stations and AR and for other it could 802.11 WPA. In this case, it is not necessary to secure the traffic for first WLAN. It may be needed to specific 'Enable LWAPP security on data pkts' on per WLAN basis. - Is it meaningful to have IPSEC security between some stations to AR and TKIP (WPA) for some stations belonging to same WLAN? B. Since, 802.11 header is stripped in this case, then there should be mechanism to transfer AP events to AR. These are typically related to Management frames between AP and stations. We need to identify these events and define packet formats for these. C. I guess we need not worry about 802.11 control frames as they are meant to be between AP and stations. Option 2: Sending all 802.11 frames from AP to AR after encapsulating in LWAPP. We can put some thinking on whether this is really required or not, if security is ensured (as mentioned in option1 ) between AP and AR. Any comments? Regards RamaKrishna Prasad Inderpreet Singh wrote: > Things were sounding fine until I saw "mandate 802.11 processing in > the AR". > > > > I beg to differ. Mandating any kind of 802.11 processing on the AR is > enforcing an architectural solution to a performance and cost of > hardware problem. There is no technical merit to doing this from a > protocol perspective. Furthermore, correct me if I am wrong, but > shouldn't we shy away from mandating the physical or logical location > of where IEEE protocols (L2 packets) are processed. This doesn't seem > to me to be theIETF approach. > > > > So, the security threats and vulnerabilities of unencrypted > encapsulated data packets are obvious (or maybe not). But note that > there is no guarantee that the packets are going to be protected with > 802.11i (or WPA in the interim) in the first place...so mandating > 802.11 processing in the AR doesn't solve the inherent security threat. > > > > To make it flexible and to meet the security requirements why not > approach it as such: > > > > Data packet encapsulation - 2 negotiable options within the protocol spec > > > > 1) 802.3 encapsulation - wireless client's 802.11 data is first > bridged by AP into 802.3 and then use lwapp to encapsulate and send to AR > > 2) 802.11 encapsulation - wireless client's 802.11 data is > directly encapsulated with lwapp and sent to AR > > > > If option 1 is the negotiated then the implementation SHOULD enforce > higher layer security policies for the data traffic. For example, > data traffic is secured via IPsec or SSL, etc. In addition, an > implementation MAY secure (per-packet auth) the transport of the > encapsulated data packets (between AP and AR) > > > > If option 2 is negotiated then the implementation MAY enforce that > 802.11 security mechanisms like WPA and eventually 802.11i have been > used to secure the user's data. (of course it may further enforce > higher layer security protection as well.). In addition, an > implementation MAY secure (per-packet auth) the transport of the > encapsulated data packets > > > > This is a high level proposal...we could discuss further online and > also at the BOF. > > > > Comments? > > > > Inderpreet > > -- > > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On > Behalf Of Rama krishna prasad > Sent: Tuesday, July 15, 2003 11:43 PM > To: Pat R. Calhoun > Cc: lwapp@frascone.com > Subject: Re: [Lwapp] Per packet authentication ICV > > > >Hi, > > > > Processing performance is very relative term and anyway, I also feel that it should be kept in mind. > > But, more importantly, I feel LWAPP is really useful in solving the problem of > > management. It is achieved by making AP implementation simple and > > devoid of any context information specific to station, such as 802.1x context, > > Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate > > problem of mobility at the AP level. > > > > OK, then let us make it simple. If we need to avoid per packet authentication, then > > we should go for doing TKIP at the AR level. That is all packet integrity and security > > should be cheeked at the AR level whether it is MAC level security, IPSEC network > > level security or SSL application level security. If we mandate this, then I feel there > > is no need for 'per packet authentication' between APs and AR. Also, the AP can > > send 802.11 packets to the AR and AR can extract AP events such as > > Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets. > > Since TKIP is going to be done at the AR, I assume that AR also should generate > > 802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this, > > we need to add text to this effect in the specifications. > > > > Regards > > Rama Krishna Prasad > --------------080508030201090607080504 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi all,

This proposal seems good. 
      Option 1:
           As I understand, in this method 802.11 header is stripped off in
           AP and 802.3 data packets are sent to the AR with LWAPP
           encapsulation. 
         A.  We need following sub-options in this.
            - Enable LWAPP security on the 802.3 packets (It involves the
              encryption/ICV addition as done for LWAPP control packets).
              This option is typically selected when TKIP is done in the APs
               and if AR knows that there is no other security between stations
               and AR.
            - Disable LWAPP Security (This option can be selected by AR
              when it knows that traffic from Stations to the AR is secured by
              IPSEC or SSL. AR can select this option if UDP transport is
              selected between AP and AR and if UDP transport is secured by
              IPSEC).
              Points to ponder here:
              - Given an AP can support multiple WLANs (Multiple radios in
                 AP Or Multiple SSID support in AP for one radio).  For one WLAN,
                 IPSEC/SSL would have been enabled between stations and AR 
                 and for other it could 802.11 WPA.
                 In this case, it is not necessary to secure the traffic for first WLAN.
                 It may be needed to specific 'Enable LWAPP security on data pkts'
                 on per WLAN basis.
              -  Is it meaningful to have IPSEC security between some stations to
                 AR and TKIP (WPA) for some stations belonging to same WLAN?
                 
          B.  Since, 802.11 header is stripped in this case, then there should be
                mechanism to transfer AP events to AR. These are typically related
                to Management frames between AP and stations. 

               We need to identify these events and define packet formats for these.

          C. I guess we need not worry about 802.11 control frames as they are
               meant to be between AP and stations.

     Option 2:
           Sending all 802.11 frames from AP to AR after encapsulating in LWAPP.
           We can put some thinking on whether this is really required or not,
            if security is ensured (as mentioned in option1 ) between AP and AR.
           Any comments?

     Regards
     RamaKrishna Prasad


Inderpreet Singh wrote:

Things were sounding fine until I saw “mandate 802.11 processing in the AR”. 

 

I beg to differ.  Mandating any kind of 802.11 processing on the AR is enforcing an architectural solution to a performance and cost of hardware problem.  There is no technical merit to doing this from a protocol perspective.  Furthermore, correct me if I am wrong, but shouldn’t we shy away from mandating the physical or logical location of where IEEE protocols (L2 packets) are processed.  This doesn’t seem to me to be theIETF approach.

 

So, the security threats and vulnerabilities of unencrypted encapsulated data packets are obvious (or maybe not). But note that there is no guarantee that the packets are going to be protected with 802.11i (or WPA in the interim) in the first place…so mandating 802.11 processing in the AR doesn’t solve the inherent security threat.  

 

To make it flexible and to meet the security requirements why not approach it as such:

 

Data packet encapsulation – 2 negotiable options within the protocol spec

 

1)       802.3 encapsulation – wireless client’s 802.11 data is first bridged by AP into 802.3 and then use lwapp to encapsulate and send to AR

2)       802.11 encapsulation – wireless client’s 802.11 data is directly encapsulated with lwapp and sent to AR

 

If option 1 is the negotiated then the implementation SHOULD enforce higher layer security policies for the data traffic.  For example, data traffic is secured via IPsec or SSL, etc.  In addition, an implementation MAY secure (per-packet auth) the transport of the encapsulated data packets (between AP and AR)

 

If option 2 is negotiated then the implementation MAY enforce that 802.11 security mechanisms like WPA and eventually 802.11i have been used to secure the user’s data. (of course it may further enforce higher layer security protection as well.).  In addition, an implementation MAY secure (per-packet auth) the transport of the encapsulated data packets

 

This is a high level proposal…we could discuss further online and also at the BOF.

 

Comments?

 

Inderpreet

--

-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Rama krishna prasad
Sent: Tuesday, July 15, 2003 11:43 PM
To: Pat R. Calhoun
Cc: lwapp@frascone.com
Subject: Re: [Lwapp] Per packet authentication ICV

 

Hi,
 
        Processing performance is very relative term and anyway, I also feel that  it should be kept in mind.
       But, more importantly, I feel LWAPP is really useful in solving the problem of
           management. It is achieved by making AP implementation simple and
           devoid of any context information specific to station, such as 802.1x context,
           Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate
           problem of mobility at the AP level.
 
     OK, then let us make it simple. If we need to avoid per packet authentication, then
     we should go for doing TKIP at the AR level. That is all packet integrity and security
     should be cheeked at the AR level whether it is MAC level security, IPSEC network
     level security or SSL application level security.  If we mandate this, then I feel there
     is no need for 'per packet authentication' between APs and AR. Also, the AP can
     send 802.11 packets to the AR and AR can extract AP events such as
     Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets.
     Since TKIP is going to be done at the AR, I assume that AR also should generate
     802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this,
     we need to add text to this effect in the specifications.
 
 Regards
 Rama Krishna Prasad

--------------080508030201090607080504-- From kempf@docomolabs-usa.com Thu Jul 17 06:05:39 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 17 Jul 2003 07:05:39 +0200 Subject: [Lwapp] Per packet authentication ICV References: <002201c34b90$9edd6870$6705a8c0@toronto.chantrynetworks.com> <3F161C94.2090704@intotoinc.com> Message-ID: <006701c34c21$12ac2850$566015ac@dclkempt40> Option 2 sounds simpler, but maybe there's some other significant drawback? jak ----- Original Message ----- From: "Rama krishna prasad" To: "Inderpreet Singh" Cc: "'Pat R. Calhoun'" ; Sent: Thursday, July 17, 2003 5:48 AM Subject: Re: [Lwapp] Per packet authentication ICV > Hi all, > > This proposal seems good. > Option 1: > As I understand, in this method 802.11 header is stripped off in > AP and 802.3 data packets are sent to the AR with LWAPP > encapsulation. > A. We need following sub-options in this. > - Enable LWAPP security on the 802.3 packets (It involves the > encryption/ICV addition as done for LWAPP control packets). > This option is typically selected when TKIP is done in the APs > and if AR knows that there is no other security between stations > and AR. > - Disable LWAPP Security (This option can be selected by AR > when it knows that traffic from Stations to the AR is secured by > IPSEC or SSL. AR can select this option if UDP transport is > selected between AP and AR and if UDP transport is secured by > IPSEC). > Points to ponder here: > - Given an AP can support multiple WLANs (Multiple radios in > AP Or Multiple SSID support in AP for one radio). For one WLAN, > IPSEC/SSL would have been enabled between stations and AR > and for other it could 802.11 WPA. > In this case, it is not necessary to secure the traffic for first WLAN. > It may be needed to specific 'Enable LWAPP security on data pkts' > on per WLAN basis. > - Is it meaningful to have IPSEC security between some stations to > AR and TKIP (WPA) for some stations belonging to same WLAN? > > B. Since, 802.11 header is stripped in this case, then there should be > mechanism to transfer AP events to AR. These are typically related > to Management frames between AP and stations. > > We need to identify these events and define packet formats for these. > > C. I guess we need not worry about 802.11 control frames as they are > meant to be between AP and stations. > > Option 2: > Sending all 802.11 frames from AP to AR after encapsulating in LWAPP. > We can put some thinking on whether this is really required or not, > if security is ensured (as mentioned in option1 ) between AP and AR. > Any comments? > > Regards > RamaKrishna Prasad > > > > Inderpreet Singh wrote: > > > Things were sounding fine until I saw "mandate 802.11 processing in > > the AR". > > > > > > > > I beg to differ. Mandating any kind of 802.11 processing on the AR is > > enforcing an architectural solution to a performance and cost of > > hardware problem. There is no technical merit to doing this from a > > protocol perspective. Furthermore, correct me if I am wrong, but > > shouldn't we shy away from mandating the physical or logical location > > of where IEEE protocols (L2 packets) are processed. This doesn't seem > > to me to be theIETF approach. > > > > > > > > So, the security threats and vulnerabilities of unencrypted > > encapsulated data packets are obvious (or maybe not). But note that > > there is no guarantee that the packets are going to be protected with > > 802.11i (or WPA in the interim) in the first place...so mandating > > 802.11 processing in the AR doesn't solve the inherent security threat. > > > > > > > > To make it flexible and to meet the security requirements why not > > approach it as such: > > > > > > > > Data packet encapsulation - 2 negotiable options within the protocol spec > > > > > > > > 1) 802.3 encapsulation - wireless client's 802.11 data is first > > bridged by AP into 802.3 and then use lwapp to encapsulate and send to AR > > > > 2) 802.11 encapsulation - wireless client's 802.11 data is > > directly encapsulated with lwapp and sent to AR > > > > > > > > If option 1 is the negotiated then the implementation SHOULD enforce > > higher layer security policies for the data traffic. For example, > > data traffic is secured via IPsec or SSL, etc. In addition, an > > implementation MAY secure (per-packet auth) the transport of the > > encapsulated data packets (between AP and AR) > > > > > > > > If option 2 is negotiated then the implementation MAY enforce that > > 802.11 security mechanisms like WPA and eventually 802.11i have been > > used to secure the user's data. (of course it may further enforce > > higher layer security protection as well.). In addition, an > > implementation MAY secure (per-packet auth) the transport of the > > encapsulated data packets > > > > > > > > This is a high level proposal...we could discuss further online and > > also at the BOF. > > > > > > > > Comments? > > > > > > > > Inderpreet > > > > -- > > > > -----Original Message----- > > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On > > Behalf Of Rama krishna prasad > > Sent: Tuesday, July 15, 2003 11:43 PM > > To: Pat R. Calhoun > > Cc: lwapp@frascone.com > > Subject: Re: [Lwapp] Per packet authentication ICV > > > > > > > >Hi, > > > > > > > > Processing performance is very relative term and anyway, I also feel that it should be kept in mind. > > > > But, more importantly, I feel LWAPP is really useful in solving the problem of > > > > management. It is achieved by making AP implementation simple and > > > > devoid of any context information specific to station, such as 802.1x context, > > > > Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate > > > > problem of mobility at the AP level. > > > > > > > > OK, then let us make it simple. If we need to avoid per packet authentication, then > > > > we should go for doing TKIP at the AR level. That is all packet integrity and security > > > > should be cheeked at the AR level whether it is MAC level security, IPSEC network > > > > level security or SSL application level security. If we mandate this, then I feel there > > > > is no need for 'per packet authentication' between APs and AR. Also, the AP can > > > > send 802.11 packets to the AR and AR can extract AP events such as > > > > Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets. > > > > Since TKIP is going to be done at the AR, I assume that AR also should generate > > > > 802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this, > > > > we need to add text to this effect in the specifications. > > > > > > > > Regards > > > > Rama Krishna Prasad > > > > From pcalhoun@airespace.com Thu Jul 17 09:09:09 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 01:09:09 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC5200@bsn-mail-01.bstormnetworks.com> But the reality is that most 802.11 chipsets support TKIP in hardware, = and there is not a single crypto accelerator that provides fast TKIP = performance (or even any TKIP support). So we would be creating a = standard where one has to design an expensive fast path crypto processor = to handle a crypto protocol that is known to be a short term solution = (RSN supports AES-CCM, not TKIP). I'm not convinced this is the right approach. PatC -----Original Message----- From: Rama krishna prasad [mailto:rkp@intotoinc.com] Sent: Tue 7/15/2003 8:43 PM To: Pat R. Calhoun Cc: lwapp@frascone.com Subject: Re: [Lwapp] Per packet authentication ICV Hi, Processing performance is very relative term and anyway, I also = feel that it should be kept in mind. But, more importantly, I feel LWAPP is really useful in solving = the problem of management. It is achieved by making AP implementation simple = and devoid of any context information specific to station, such = as 802.1x context, Firewall/NAT context,SSL context, QoS Context etc.. This will = eliminate problem of mobility at the AP level. OK, then let us make it simple. If we need to avoid per packet = authentication, then we should go for doing TKIP at the AR level. That is all packet = integrity and security should be cheeked at the AR level whether it is MAC level security, = IPSEC network level security or SSL application level security. If we mandate = this, then I feel there is no need for 'per packet authentication' between APs and AR. = Also, the AP can send 802.11 packets to the AR and AR can extract AP events such as Associate/De-Associate/Re-Associate/Open authentication from the = 802.11 packets. Since TKIP is going to be done at the AR, I assume that AR also = should generate 802.11 packets, which inturn will be forwarded to stations by the = APs. If we agree to this, we need to add text to this effect in the specifications. Regards Rama Krishna Prasad Pat R. Calhoun wrote: >Right, but I am very worried about the amount of code and the = processing performance on the AP. Doing per data packet auth adds = significant cost to the AP. Most devices on the market do not have the = CPU resources to handle this. We could make this a requirement, but none = of the devices that ship would ever be able to be supported. Not sure = this is a great idea. > >PatC >-----Original Message----- >From: Rama krishna prasad [mailto:rkp@intotoinc.com] >Sent: Mon 7/21/2003 8:53 PM >To: lwapp@frascone.com >Cc:=09 >Subject: Re: [Lwapp] Per packet authentication ICV >Hi, > As I understand current specification supports the type of = deployment > which you are talking about. I don't mean to remove this = support in > the specifications. I am trying to see whether sending LWAPP = encapsulation > on data packet is required or not in some scenarios and if so, = whether the > specification is flexible or not. I think I will try to list = down the scenarios as > I understand based on my experience in this field so far.=20 > > Scenarios: > 1. SSL based ARs. > 2. IPSEC based ARs > 3. 802.1x based ARs - TKIP in AR > 4. 802.1x based ARs - TKIP in APs > 5. several combinations of above. > > SSL based AR OR IPSEC based AR: > In these two cases, the trust relationship is between = wireless stations and > AR. In this case, I feel AR need not receive 802.11 packets = as-is. > On the wire (between AP and AR), it could be plain Ethernet = packets. > But, AR should know some events such as = Association/De_association/ > Re-association/802.11 authentication/de-auth, station = Timeout events from AP . > There is no need to pass the all 802.11 packets. > > 802.1x based ARs - TKIP in AR: > Here too, trust relationship on per packet basis is = maintained between warless=20 > stations and AR. Since, TKIP is centralized in AR, 802.11 = packet have to be > sent to AR by APs. > > 802.1x based ARs - TKIP in APs: > In this case, per packet trust relationship is only = between wireless stations and > APs. Due to this, per packet authentication is required = between APs and AR. > Here, there is no need of sending all 802.11 packets. We = only need to send=20 > data packets with LWAPP encapsulated for per packet = authentication and=20 > AP events have to be sent to ARs. > > If all of above scenario to work, the implementations on AP = should be capable\ > of doing following: > - Send 802.11 packets as-is to AR. > - Send data packets without any encapsulation > and AP events as LWAPP encapsulated messages. > - Send data packets and control events with LWAPP = encapsulation and > with per packet authentication. > > Thanks for your time > Rama Krishna Prasad > > > >Pat R. Calhoun wrote: > > =20 > >>=20 >> >> =20 >> >>>Does group think that these events are required to be passed from >>>APs to AR? >>> =20 >>> >>> =20 >>> >>Yes >> >>PatC >> >>=20 >> >> =20 >> > > > > > =20 > From pcalhoun@airespace.com Thu Jul 17 09:11:30 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 01:11:30 -0700 Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation. Message-ID: <40301581B2962B448690A023EF16DFE1DC5201@bsn-mail-01.bstormnetworks.com> My thoughts exactly. It is very easy to configure the known peers on the = AP, and if the peer's name is present in the certificate, validation can = be done there. As far as certificate validation on the AP, this is = really no different from how most browsers work today. However, since = most APs are not directly connected to the AR, they have access to the = network. So there is no reason why a particular implementation could not = validate a given AR's cert via whatever local means are available. PatC -----Original Message----- From: Rama krishna prasad [mailto:rkp@intotoinc.com] Sent: Tue 7/15/2003 8:45 PM To: David Molnar Cc: Clint Chaplin; lwapp@frascone.com Subject: Re: [Lwapp] Certificates, Discovery Request/Reply, and = validation. Hi, x.509 certificates contain subject name (subject alt-name). I = feel,=20 this subject (alt) names can be used to identify the peer.=20 For example, AP can be preinstalled with X.509 certificate = signed by general CA or local CA server and also it can be = pre-programmed with the names of ARs that it should join. Similarly, AR can = be configured with subject (alt) names of AP that it trusts. Validation on = allowing the peer can be done during the 'Discovery' phase. Regards Rama Krishna Prasad Intoto Software(I)PVT Ltd PlotNo:15 New VasaviNagar, Secundrabad. INDIA-500015 David Molnar wrote: >On Mon, 14 Jul 2003, Clint Chaplin wrote: > > =20 > >>How is the AP supposed to validate the certificate presented to it by >>the AR? Is a certificate fingerprint going to have to be preinstalled >>in the AP, along with a certificate for the AP? >> =20 >> > >I've been wondering the same thing. I think the issue goes even deeper. >Suppose every AP and AR shipped with a global CA public key, such as >VeriSign, in them, just like browsers do. So I can go to VeriSign and >register my AP and AR names. (N.B. I am *not* advocating we put = VeriSign >in every AP and AR...) > >Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone has = a >properly signed CA certificate attesting to their identity. Bob cannot >impersonate Charlie and vice versa. Every pair can create a shared = secret >without anyone else being able to listen in. > >The questions are > > "How does Alice know she should be with Bob and not Charlie?" > "How does Bob know Alice should be with him?" > >and in the scenario just outlined, I don't see any good way to answer >those questions. Just having certificates, even "valid" certificates, = is >not enough (unless you shove the association into the name of the >certificate!). We need to think about how secure associations are set = up >and validated. We should also think about whether setting up secure >associations is within the purview of LWAPP or could be broken out into >another protocol. > >I'm talking about these issues Friday at the BOF, for those who will be >there. If you won't, I'll be happy to send you slides (once they're = done). > >-David >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp > > =20 > From pcalhoun@airespace.com Thu Jul 17 09:16:46 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 01:16:46 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC5202@bsn-mail-01.bstormnetworks.com> > I beg to differ. Mandating any kind of 802.11 processing on the AR is > enforcing an architectural solution to a performance and cost of > hardware problem. There is no technical merit to doing this from a > protocol perspective. Furthermore, correct me if I am wrong, but > shouldn't we shy away from mandating the physical or logical location = of > where IEEE protocols (L2 packets) are processed. This doesn't seem to > me to be theIETF approach. Actually, I disagree. Having full access to the 802.11 frame in the AR = provides the system will a complete view of such things as RSSI & SNR, = which can be *very* useful for various mobility and load balancing = functions. Leaving the APs as fat APs, and only providing consolidation = of management in the AR is interesting, but not sufficient. A good AR = would use various Layer 2 (802.11) information as well as IP+ = information in it's IDS and policy enforcement functions. PatC From pcalhoun@airespace.com Thu Jul 17 09:18:43 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 01:18:43 -0700 Subject: [Lwapp] (no subject) Message-ID: <40301581B2962B448690A023EF16DFE1DC5203@bsn-mail-01.bstormnetworks.com> > All access control, majority of policy enforcement, IDS functions, > device management/configuration, and wireless station policy = management > is handled in the AR. It DOES NOT mean that all or even some 802.11 > packet handling is done in the AR. The MAC and PHY are integral to = the > AP. In order to be centrally configured and provisioned the = lightweight > AP includes the signaling functionality that is currently proposed by > LWAPP. I disagree. How would you handle IDS functions at the MAC layer that is = capable of detecting attacks on the network vs. a single cell? PatC From pcalhoun@airespace.com Thu Jul 17 09:25:40 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 01:25:40 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC5205@bsn-mail-01.bstormnetworks.com> > Option 2: > Sending all 802.11 frames from AP to AR after encapsulating = in LWAPP. > We can put some thinking on whether this is really required = or not, > if security is ensured (as mentioned in option1 ) between = AP and AR. > Any comments? Yup this is the way to do it. We will need to work on the security = aspect of these data packets. However, the AR is not just a management = box of APs. It provides many additional security and mobility services = for the *network*. It cannot do so if it has no visibility into the MAC.=20 PatC From pcalhoun@airespace.com Thu Jul 17 09:27:03 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 01:27:03 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC5206@bsn-mail-01.bstormnetworks.com> Exactly. If you don't do this, then you end up complicating the protocol = so you can send 802.11 management events back to the AR. Why bother? = That information is readily available in the 802.11 management message! PatC -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wed 7/16/2003 10:05 PM To: rkp@intotoinc.com; Inderpreet Singh Cc: Pat R. Calhoun; lwapp@frascone.com Subject: Re: [Lwapp] Per packet authentication ICV Option 2 sounds simpler, but maybe there's some other significant = drawback? jak ----- Original Message -----=20 From: "Rama krishna prasad" To: "Inderpreet Singh" Cc: "'Pat R. Calhoun'" ; Sent: Thursday, July 17, 2003 5:48 AM Subject: Re: [Lwapp] Per packet authentication ICV > Hi all, > > This proposal seems good. > Option 1: > As I understand, in this method 802.11 header is stripped = off in > AP and 802.3 data packets are sent to the AR with LWAPP > encapsulation. > A. We need following sub-options in this. > - Enable LWAPP security on the 802.3 packets (It involves = the > encryption/ICV addition as done for LWAPP control = packets). > This option is typically selected when TKIP is done in = the APs > and if AR knows that there is no other security between stations > and AR. > - Disable LWAPP Security (This option can be selected by = AR > when it knows that traffic from Stations to the AR is secured by > IPSEC or SSL. AR can select this option if UDP transport = is > selected between AP and AR and if UDP transport is = secured by > IPSEC). > Points to ponder here: > - Given an AP can support multiple WLANs (Multiple = radios in > AP Or Multiple SSID support in AP for one radio). = For one WLAN, > IPSEC/SSL would have been enabled between stations = and AR > and for other it could 802.11 WPA. > In this case, it is not necessary to secure the = traffic for first WLAN. > It may be needed to specific 'Enable LWAPP security = on data pkts' > on per WLAN basis. > - Is it meaningful to have IPSEC security between some stations to > AR and TKIP (WPA) for some stations belonging to same WLAN? > > B. Since, 802.11 header is stripped in this case, then = there should be > mechanism to transfer AP events to AR. These are = typically related > to Management frames between AP and stations. > > We need to identify these events and define packet = formats for these. > > C. I guess we need not worry about 802.11 control frames as = they are > meant to be between AP and stations. > > Option 2: > Sending all 802.11 frames from AP to AR after encapsulating = in LWAPP. > We can put some thinking on whether this is really required = or not, > if security is ensured (as mentioned in option1 ) between = AP and AR. > Any comments? > > Regards > RamaKrishna Prasad > > > > Inderpreet Singh wrote: > > > Things were sounding fine until I saw "mandate 802.11 processing in > > the AR". > > > > > > > > I beg to differ. Mandating any kind of 802.11 processing on the AR = is > > enforcing an architectural solution to a performance and cost of > > hardware problem. There is no technical merit to doing this from a > > protocol perspective. Furthermore, correct me if I am wrong, but > > shouldn't we shy away from mandating the physical or logical = location > > of where IEEE protocols (L2 packets) are processed. This doesn't = seem > > to me to be theIETF approach. > > > > > > > > So, the security threats and vulnerabilities of unencrypted > > encapsulated data packets are obvious (or maybe not). But note that > > there is no guarantee that the packets are going to be protected = with > > 802.11i (or WPA in the interim) in the first place...so mandating > > 802.11 processing in the AR doesn't solve the inherent security = threat. > > > > > > > > To make it flexible and to meet the security requirements why not > > approach it as such: > > > > > > > > Data packet encapsulation - 2 negotiable options within the protocol spec > > > > > > > > 1) 802.3 encapsulation - wireless client's 802.11 data is = first > > bridged by AP into 802.3 and then use lwapp to encapsulate and send = to AR > > > > 2) 802.11 encapsulation - wireless client's 802.11 data is > > directly encapsulated with lwapp and sent to AR > > > > > > > > If option 1 is the negotiated then the implementation SHOULD enforce > > higher layer security policies for the data traffic. For example, > > data traffic is secured via IPsec or SSL, etc. In addition, an > > implementation MAY secure (per-packet auth) the transport of the > > encapsulated data packets (between AP and AR) > > > > > > > > If option 2 is negotiated then the implementation MAY enforce that > > 802.11 security mechanisms like WPA and eventually 802.11i have been > > used to secure the user's data. (of course it may further enforce > > higher layer security protection as well.). In addition, an > > implementation MAY secure (per-packet auth) the transport of the > > encapsulated data packets > > > > > > > > This is a high level proposal...we could discuss further online and > > also at the BOF. > > > > > > > > Comments? > > > > > > > > Inderpreet > > > > -- > > > > -----Original Message----- > > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On > > Behalf Of Rama krishna prasad > > Sent: Tuesday, July 15, 2003 11:43 PM > > To: Pat R. Calhoun > > Cc: lwapp@frascone.com > > Subject: Re: [Lwapp] Per packet authentication ICV > > > > > > > >Hi, > > > > > > > > Processing performance is very relative term and anyway, I = also feel that it should be kept in mind. > > > > But, more importantly, I feel LWAPP is really useful in = solving the problem of > > > > management. It is achieved by making AP implementation = simple and > > > > devoid of any context information specific to station, = such as 802.1x context, > > > > Firewall/NAT context,SSL context, QoS Context etc.. This = will eliminate > > > > problem of mobility at the AP level. > > > > > > > > OK, then let us make it simple. If we need to avoid per packet authentication, then > > > > we should go for doing TKIP at the AR level. That is all packet integrity and security > > > > should be cheeked at the AR level whether it is MAC level = security, IPSEC network > > > > level security or SSL application level security. If we mandate this, then I feel there > > > > is no need for 'per packet authentication' between APs and AR. = Also, the AP can > > > > send 802.11 packets to the AR and AR can extract AP events such = as > > > > Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets. > > > > Since TKIP is going to be done at the AR, I assume that AR also should generate > > > > 802.11 packets, which inturn will be forwarded to stations by = the APs. If we agree to this, > > > > we need to add text to this effect in the specifications. > > > > > > > > Regards > > > > Rama Krishna Prasad > > > > From Mike.Moreton@Synad.com Thu Jul 17 10:26:08 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Thu, 17 Jul 2003 10:26:08 +0100 Subject: [Lwapp] Per packet authentication ICV Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA54A@paris.synad.com> Clint, As I understand it, dynamic fragmentation is an issue at the STA more than at the AP. The AP can always "change the rules" to send out any length of fragment it wants. I'd also say that the polled access variant of TGe is somewhat incompatible with the idea of a thin AP in any case. For EDCA I'd agree that it's logical to put the (relatively simple) functionality in the AP. Mike Moreton Synad Technologies Ltd. =20 -----Original Message----- From: Clint Chaplin [mailto:cchaplin@sj.symbol.com]=20 Sent: 16 July 2003 18:59 To: pcalhoun@airespace.com; isingh@chantrynetworks.com; rkp@intotoinc.com Cc: lwapp@frascone.com Subject: RE: [Lwapp] Per packet authentication ICV I must point out a potential problem here, one that might force at least some 802.11 processing into the APs: The solution for QoS that is being proposed by IEEE 802.11 TGe will force any decisions as to what to send and when into the AP itself; the AP simply will not have enough time to poll the AR for information/guidance. In addition, the decision as to where to split a MSDU into MPDUs in order to fit into the given time slot must be made >now< and at the AP, and that includes encrypting the MPDUs. Therefor, it will be impossible for the AR to do the TKIP encryption; it will have to be handled by the AP. Which means that the packets data packets between the AR and the AP will have to be protected in some other way. Clint (JOATMON) Chaplin >>> "Inderpreet Singh" 7/16/03 04:51:13 >>> Things were sounding fine until I saw "mandate 802.11 processing in the AR". =20 =20 I beg to differ. Mandating any kind of 802.11 processing on the AR is enforcing an architectural solution to a performance and cost of hardware problem. There is no technical merit to doing this from a protocol perspective. Furthermore, correct me if I am wrong, but shouldn't we shy away from mandating the physical or logical location of where IEEE protocols (L2 packets) are processed. This doesn't seem to me to be theIETF approach. =20 So, the security threats and vulnerabilities of unencrypted encapsulated data packets are obvious (or maybe not). But note that there is no guarantee that the packets are going to be protected with 802.11i (or WPA in the interim) in the first place.so mandating 802.11 processing in the AR doesn't solve the inherent security threat. =20 =20 To make it flexible and to meet the security requirements why not approach it as such: =20 Data packet encapsulation - 2 negotiable options within the protocol spec =20 1) 802.3 encapsulation - wireless client's 802.11 data is first bridged by AP into 802.3 and then use lwapp to encapsulate and send to AR 2) 802.11 encapsulation - wireless client's 802.11 data is directly encapsulated with lwapp and sent to AR =20 If option 1 is the negotiated then the implementation SHOULD enforce higher layer security policies for the data traffic. For example, data traffic is secured via IPsec or SSL, etc. In addition, an implementation MAY secure (per-packet auth) the transport of the encapsulated data packets (between AP and AR) =20 If option 2 is negotiated then the implementation MAY enforce that 802.11 security mechanisms like WPA and eventually 802.11i have been used to secure the user's data. (of course it may further enforce higher layer security protection as well.). In addition, an implementation MAY secure (per-packet auth) the transport of the encapsulated data packets =20 This is a high level proposal.we could discuss further online and also at the BOF. =20 Comments? =20 Inderpreet -- -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Rama krishna prasad Sent: Tuesday, July 15, 2003 11:43 PM To: Pat R. Calhoun Cc: lwapp@frascone.com=20 Subject: Re: [Lwapp] Per packet authentication ICV =20 Hi, =20 Processing performance is very relative term and anyway, I also feel that it should be kept in mind. But, more importantly, I feel LWAPP is really useful in solving the problem of management. It is achieved by making AP implementation simple and devoid of any context information specific to station, such as 802.1x context, Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate problem of mobility at the AP level. =20 OK, then let us make it simple. If we need to avoid per packet authentication, then we should go for doing TKIP at the AR level. That is all packet integrity and security should be cheeked at the AR level whether it is MAC level security, IPSEC network level security or SSL application level security. If we mandate this, then I feel there is no need for 'per packet authentication' between APs and AR. Also, the AP can send 802.11 packets to the AR and AR can extract AP events such as Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets. Since TKIP is going to be done at the AR, I assume that AR also should generate 802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this, we need to add text to this effect in the specifications. =20 Regards Rama Krishna Prasad=20 ________________________________________________________________________ This email has been scanned for computer viruses. _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From Madjid.Nakhjiri@motorola.com Thu Jul 17 10:31:57 2003 From: Madjid.Nakhjiri@motorola.com (Nakhjiri Madjid-MNAKHJI1) Date: Thu, 17 Jul 2003 04:31:57 -0500 Subject: [Lwapp] (no subject) Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD60AC@IL27EXM10.cig.mot.com> Hi Pat, -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 15, 2003 4:14 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: lwapp@frascone.com Subject: RE: [Lwapp] (no subject) > As far as "light weight AP", I think some explanation is needed to > understand the difference between a "regular" and a light weight one. A fair question indeed. Although there is no clear definition of what a light weight access point is, in my mind (and implementation :), it means that all access control, policy enforcements, IDS functions, device management/configuration is handled in the AR. Madjid>> thank you, this clears a lot of things and can be added to the draft :) Does this mean, all the network's internal node in need of communication with AP (say a policy server or an authentication server) need to go through AR to get to AP? I am not entirely against that, but just like to understand the architecture. Also, the BoF desciption says that NAS functionality will be planted into AP, is that Lwapp philosophy as well? I have an issue with having the policy enforcements being handled by AR though, -for QoS policies, this means, packet filtering and policing is done at AR and not AP, hence you run the risk of having unauthorized (or nonconforming users) clog the backhaul. -For security policies, you let rouge traffic penetrate the network, shouldn't filtering be implemented in the AP? One of the many benefits of the architecture is that it allows the AR to have a greater understanding of the RF topology, and can detect attacks that may be mounted against a network as a whole, and take appropriate action. Madjid>> agreed, this will allow heterogeneous access tech. support (maybe even help the discovery process). Regards, Madjid From Mike.Moreton@Synad.com Thu Jul 17 10:37:53 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Thu, 17 Jul 2003 10:37:53 +0100 Subject: [Lwapp] Per packet authentication ICV Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA54E@paris.synad.com> As one of TGi's leading terminology pedants, I'd just like to point out that RSN includes both AES-CCM and TKIP. It may not be completely popular, but that's the way the definition is at the moment... To me, any LWAPP solution has to support 802.11 encryption/decryption in either the AR or the AP. Choosing either one eliminates a whole set of possible architectures. Mike Moreton Synad Technologies Ltd. =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: 17 July 2003 09:09 To: rkp@intotoinc.com Cc: lwapp@frascone.com Subject: RE: [Lwapp] Per packet authentication ICV But the reality is that most 802.11 chipsets support TKIP in hardware, and there is not a single crypto accelerator that provides fast TKIP performance (or even any TKIP support). So we would be creating a standard where one has to design an expensive fast path crypto processor to handle a crypto protocol that is known to be a short term solution (RSN supports AES-CCM, not TKIP). I'm not convinced this is the right approach. PatC -----Original Message----- From: Rama krishna prasad [mailto:rkp@intotoinc.com] Sent: Tue 7/15/2003 8:43 PM To: Pat R. Calhoun Cc: lwapp@frascone.com Subject: Re: [Lwapp] Per packet authentication ICV Hi, Processing performance is very relative term and anyway, I also feel that it should be kept in mind. But, more importantly, I feel LWAPP is really useful in solving the problem of management. It is achieved by making AP implementation simple and devoid of any context information specific to station, such as 802.1x context, Firewall/NAT context,SSL context, QoS Context etc.. This will eliminate problem of mobility at the AP level. OK, then let us make it simple. If we need to avoid per packet authentication, then we should go for doing TKIP at the AR level. That is all packet integrity and security should be cheeked at the AR level whether it is MAC level security, IPSEC network level security or SSL application level security. If we mandate this, then I feel there is no need for 'per packet authentication' between APs and AR. Also, the AP can send 802.11 packets to the AR and AR can extract AP events such as Associate/De-Associate/Re-Associate/Open authentication from the 802.11 packets. Since TKIP is going to be done at the AR, I assume that AR also should generate 802.11 packets, which inturn will be forwarded to stations by the APs. If we agree to this, we need to add text to this effect in the specifications. Regards Rama Krishna Prasad Pat R. Calhoun wrote: >Right, but I am very worried about the amount of code and the processing performance on the AP. Doing per data packet auth adds significant cost to the AP. Most devices on the market do not have the CPU resources to handle this. We could make this a requirement, but none of the devices that ship would ever be able to be supported. Not sure this is a great idea. > >PatC >-----Original Message----- >From: Rama krishna prasad [mailto:rkp@intotoinc.com] >Sent: Mon 7/21/2003 8:53 PM >To: lwapp@frascone.com >Cc:=09 >Subject: Re: [Lwapp] Per packet authentication ICV >Hi, > As I understand current specification supports the type of deployment > which you are talking about. I don't mean to remove this support in > the specifications. I am trying to see whether sending LWAPP encapsulation > on data packet is required or not in some scenarios and if so, whether the > specification is flexible or not. I think I will try to list down the scenarios as > I understand based on my experience in this field so far.=20 > > Scenarios: > 1. SSL based ARs. > 2. IPSEC based ARs > 3. 802.1x based ARs - TKIP in AR > 4. 802.1x based ARs - TKIP in APs > 5. several combinations of above. > > SSL based AR OR IPSEC based AR: > In these two cases, the trust relationship is between wireless stations and > AR. In this case, I feel AR need not receive 802.11 packets as-is. > On the wire (between AP and AR), it could be plain Ethernet packets. > But, AR should know some events such as Association/De_association/ > Re-association/802.11 authentication/de-auth, station Timeout events from AP . > There is no need to pass the all 802.11 packets. > > 802.1x based ARs - TKIP in AR: > Here too, trust relationship on per packet basis is maintained between warless=20 > stations and AR. Since, TKIP is centralized in AR, 802.11 packet have to be > sent to AR by APs. > > 802.1x based ARs - TKIP in APs: > In this case, per packet trust relationship is only between wireless stations and > APs. Due to this, per packet authentication is required between APs and AR. > Here, there is no need of sending all 802.11 packets. We only need to send=20 > data packets with LWAPP encapsulated for per packet authentication and=20 > AP events have to be sent to ARs. > > If all of above scenario to work, the implementations on AP should be capable\ > of doing following: > - Send 802.11 packets as-is to AR. > - Send data packets without any encapsulation > and AP events as LWAPP encapsulated messages. > - Send data packets and control events with LWAPP encapsulation and > with per packet authentication. > > Thanks for your time > Rama Krishna Prasad > > > >Pat R. Calhoun wrote: > > =20 > >>=20 >> >> =20 >> >>>Does group think that these events are required to be passed from >>>APs to AR? >>> =20 >>> >>> =20 >>> >>Yes >> >>PatC >> >>=20 >> >> =20 >> > > > > > =20 > _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From Mike.Moreton@Synad.com Thu Jul 17 10:41:38 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Thu, 17 Jul 2003 10:41:38 +0100 Subject: [Lwapp] Per packet authentication ICV Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA550@paris.synad.com> Pat, Neither RSSI or SNR is part of the 802.11 frame, as it is not something the transmitting station would know. Many chipset implementations associate it with the frame in a data structure, but it's not a standard thing. Mike Moreton Synad Technologies Ltd. =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: 17 July 2003 09:17 To: Inderpreet Singh; rkp@intotoinc.com Cc: lwapp@frascone.com Subject: RE: [Lwapp] Per packet authentication ICV > I beg to differ. Mandating any kind of 802.11 processing on the AR is > enforcing an architectural solution to a performance and cost of > hardware problem. There is no technical merit to doing this from a > protocol perspective. Furthermore, correct me if I am wrong, but > shouldn't we shy away from mandating the physical or logical location of > where IEEE protocols (L2 packets) are processed. This doesn't seem to > me to be theIETF approach. Actually, I disagree. Having full access to the 802.11 frame in the AR provides the system will a complete view of such things as RSSI & SNR, which can be *very* useful for various mobility and load balancing functions. Leaving the APs as fat APs, and only providing consolidation of management in the AR is interesting, but not sufficient. A good AR would use various Layer 2 (802.11) information as well as IP+ information in it's IDS and policy enforcement functions. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Thu Jul 17 12:17:22 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 04:17:22 -0700 Subject: [Lwapp] (no subject) Message-ID: <40301581B2962B448690A023EF16DFE1DC520F@bsn-mail-01.bstormnetworks.com> >> As far as "light weight AP", I think some explanation is needed to >> understand the difference between a "regular" and a light weight one. > > A fair question indeed. Although there is no clear definition of what = a > light weight access point is, in my mind (and implementation :), it = means > that all access control, policy enforcements, IDS functions, device > management/configuration is handled in the AR. >=20 > Madjid>> thank you, this clears a lot of things and can be added to = the > draft :) From the draft 03, end of page 8: 2. Centralization of the bridging, forwarding, authentication, encryption and policy enforcement functions for a WLAN, to apply the capabilities of network processing silicon to the WLAN, as it has already been applied to wired LANs. I could add more if it is needed. > Does this mean, all the network's internal node in need of = communication > with AP > (say a policy server or an authentication server) need to go through = AR to > get to=20 > AP? No - these functions exist in the AR, not in the AP. So there is no = communication per se, except for as I note below. > I am not entirely against that, but just like to understand the > architecture. > Also, the BoF desciption says that NAS functionality will be planted = into > AP, > is that Lwapp philosophy as well? nope, into the AR. The goal is to REMOVE the NAS functionality from the = AP. > I have an issue with having the policy enforcements being handled by = AR > though, > -for QoS policies, this means, packet filtering and policing is done > at AR and=20 > not AP, hence you run the risk of having unauthorized (or > nonconforming users) > clog the backhaul. > -For security policies, you let rouge traffic penetrate the network, > shouldn't=20 > filtering be implemented in the AP? nope. The protocol has a message from the AR to the AP allowing = "filters" to be created on the AP. This is called the = Add-Mobile/Delete-Mobile message. PatC From pcalhoun@airespace.com Thu Jul 17 12:19:22 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 04:19:22 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC5210@bsn-mail-01.bstormnetworks.com> > As one of TGi's leading terminology pedants, I'd just like to point = out > that RSN includes both AES-CCM and TKIP. It may not be completely > popular, but that's the way the definition is at the moment... Thanks for the clarification. My understanding was to phase out TKIP. > To me, any LWAPP solution has to support 802.11 encryption/decryption = in > either the AR or the AP. Choosing either one eliminates a whole set = of > possible architectures. That is what the spec currently specifies. PatC From pcalhoun@airespace.com Thu Jul 17 12:20:25 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 04:20:25 -0700 Subject: [Lwapp] Per packet authentication ICV Message-ID: <40301581B2962B448690A023EF16DFE1DC5211@bsn-mail-01.bstormnetworks.com> Right, but we add that information in the LWAPP header. I guess the = point I was trying to make, rather vaguely, is that such information is = really useful. Getting access to the 802.11 frame provides other very = useful information as well. PatC -----Original Message----- From: Mike Moreton [mailto:Mike.Moreton@Synad.com] Sent: Thu 7/17/2003 2:41 AM To: Pat R. Calhoun; Inderpreet Singh; rkp@intotoinc.com Cc: lwapp@frascone.com Subject: RE: [Lwapp] Per packet authentication ICV Pat, Neither RSSI or SNR is part of the 802.11 frame, as it is not something the transmitting station would know. Many chipset implementations associate it with the frame in a data structure, but it's not a standard thing. Mike Moreton Synad Technologies Ltd. =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: 17 July 2003 09:17 To: Inderpreet Singh; rkp@intotoinc.com Cc: lwapp@frascone.com Subject: RE: [Lwapp] Per packet authentication ICV > I beg to differ. Mandating any kind of 802.11 processing on the AR is > enforcing an architectural solution to a performance and cost of > hardware problem. There is no technical merit to doing this from a > protocol perspective. Furthermore, correct me if I am wrong, but > shouldn't we shy away from mandating the physical or logical location of > where IEEE protocols (L2 packets) are processed. This doesn't seem to > me to be theIETF approach. Actually, I disagree. Having full access to the 802.11 frame in the AR provides the system will a complete view of such things as RSSI & SNR, which can be *very* useful for various mobility and load balancing functions. Leaving the APs as fat APs, and only providing consolidation of management in the AR is interesting, but not sufficient. A good AR would use various Layer 2 (802.11) information as well as IP+ information in it's IDS and policy enforcement functions. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From alper@docomolabs-usa.com Thu Jul 17 13:53:40 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 17 Jul 2003 05:53:40 -0700 Subject: [Lwapp] (no subject) In-Reply-To: <40301581B2962B448690A023EF16DFE1DC520F@bsn-mail-01.bstormnetworks.com> Message-ID: >> From the draft 03, end of page 8: > 2. Centralization of the bridging, forwarding, authentication, > encryption and policy enforcement functions for a WLAN, to apply > the capabilities of network processing silicon to the WLAN, as it > has already been applied to wired LANs. > > I could add more if it is needed. Why not achieve these goals by: - Running PANA between the station and access router. - Having AP relay interesting IEEE 802.11 bits to the access router as it bridges (forwards) the packets. This can be carried as some sort of auxilary data as part of the IEEE headers. IEEE (SDO) could define this. Alper From pcalhoun@airespace.com Thu Jul 17 13:55:52 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 05:55:52 -0700 Subject: [Lwapp] (no subject) Message-ID: <40301581B2962B448690A023EF16DFE1DC521E@bsn-mail-01.bstormnetworks.com> > Why not achieve these goals by: > - Running PANA between the station and access router. PANA assumes a completely different architecture - not one that any of = the startups seemed to have adopted. I suppose it would be ok for the = IETF to work on something that is not being productized, but I'd wonder = why... > - Having AP relay interesting IEEE 802.11 bits to the access router as = it > bridges (forwards) the packets. This can be carried as some sort of = auxilary > data as part of the IEEE headers. IEEE (SDO) could define this. This is what LWAPP does, right? I don't see this as a MAC or PHY layer = thing, so I don't see why IEEE would be interested. PatC From waa@cs.umd.edu Thu Jul 17 14:26:36 2003 From: waa@cs.umd.edu (William Arbaugh) Date: Thu, 17 Jul 2003 09:26:36 -0400 Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation. In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5201@bsn-mail-01.bstormnetworks.com> Message-ID: <4A3F3842-B85A-11D7-B085-000A957E8894@cs.umd.edu> If I understand this correctly (the AP's are validating the AR's cert), then this implies that the AP will support RSA and/or DSA and SHA1and/or MD5. Is this correct? If so, this might help solve the ICV problem except perhaps a performance issue. On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote: > My thoughts exactly. It is very easy to configure the known peers on > the AP, and if the peer's name is present in the certificate, > validation can be done there. As far as certificate validation on the > AP, this is really no different from how most browsers work today. > However, since most APs are not directly connected to the AR, they > have access to the network. So there is no reason why a particular > implementation could not validate a given AR's cert via whatever local > means are available. > > PatC > -----Original Message----- > From: Rama krishna prasad [mailto:rkp@intotoinc.com] > Sent: Tue 7/15/2003 8:45 PM > To: David Molnar > Cc: Clint Chaplin; lwapp@frascone.com > Subject: Re: [Lwapp] Certificates, Discovery Request/Reply, and > validation. > Hi, > x.509 certificates contain subject name (subject alt-name). > I feel, > this subject (alt) names can be used to identify the peer. > For example, AP can be preinstalled with X.509 certificate > signed > by general CA or local CA server and also it can be > pre-programmed > with the names of ARs that it should join. Similarly, AR can > be configured > with subject (alt) names of AP that it trusts. Validation on > allowing the > peer can be done during the 'Discovery' phase. > Regards > Rama Krishna Prasad > Intoto Software(I)PVT Ltd > PlotNo:15 New VasaviNagar, > Secundrabad. > INDIA-500015 > > > > David Molnar wrote: > >> On Mon, 14 Jul 2003, Clint Chaplin wrote: >> >> >> >>> How is the AP supposed to validate the certificate presented to it by >>> the AR? Is a certificate fingerprint going to have to be >>> preinstalled >>> in the AP, along with a certificate for the AP? >>> >>> >> >> I've been wondering the same thing. I think the issue goes even >> deeper. >> Suppose every AP and AR shipped with a global CA public key, such as >> VeriSign, in them, just like browsers do. So I can go to VeriSign and >> register my AP and AR names. (N.B. I am *not* advocating we put >> VeriSign >> in every AP and AR...) >> >> Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone >> has a >> properly signed CA certificate attesting to their identity. Bob cannot >> impersonate Charlie and vice versa. Every pair can create a shared >> secret >> without anyone else being able to listen in. >> >> The questions are >> >> "How does Alice know she should be with Bob and not Charlie?" >> "How does Bob know Alice should be with him?" >> >> and in the scenario just outlined, I don't see any good way to answer >> those questions. Just having certificates, even "valid" certificates, >> is >> not enough (unless you shove the association into the name of the >> certificate!). We need to think about how secure associations are set >> up >> and validated. We should also think about whether setting up secure >> associations is within the purview of LWAPP or could be broken out >> into >> another protocol. >> >> I'm talking about these issues Friday at the BOF, for those who will >> be >> there. If you won't, I'll be happy to send you slides (once they're >> done). >> >> -David >> _______________________________________________ >> Lwapp mailing list >> Lwapp@frascone.com >> http://mail.frascone.com/mailman/listinfo/lwapp >> >> >> > > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From pcalhoun@airespace.com Thu Jul 17 14:31:56 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 06:31:56 -0700 Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation. Message-ID: <40301581B2962B448690A023EF16DFE1DC521F@bsn-mail-01.bstormnetworks.com> > If I understand this correctly (the AP's are validating the AR's = cert),=20 > then this implies that the AP will support RSA and/or DSA and=20 > SHA1and/or MD5. Is this correct? That is probably a safe assumption. > If so, this might help solve the ICV=20 > problem except perhaps a performance issue. You mean on the data path? Yes, securing data packets does require = probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g = APs). PatC=20 On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote: > My thoughts exactly. It is very easy to configure the known peers on=20 > the AP, and if the peer's name is present in the certificate,=20 > validation can be done there. As far as certificate validation on the=20 > AP, this is really no different from how most browsers work today.=20 > However, since most APs are not directly connected to the AR, they=20 > have access to the network. So there is no reason why a particular=20 > implementation could not validate a given AR's cert via whatever local = > means are available. > > PatC > -----Original Message----- > From: Rama krishna prasad [mailto:rkp@intotoinc.com] > Sent: Tue 7/15/2003 8:45 PM > To: David Molnar > Cc: Clint Chaplin; lwapp@frascone.com > Subject: Re: [Lwapp] Certificates, Discovery Request/Reply, and=20 > validation. > Hi, > x.509 certificates contain subject name (subject alt-name). = > I feel, > this subject (alt) names can be used to identify the peer. > For example, AP can be preinstalled with X.509 certificate=20 > signed > by general CA or local CA server and also it can be=20 > pre-programmed > with the names of ARs that it should join. Similarly, AR can = > be configured > with subject (alt) names of AP that it trusts. Validation on = > allowing the > peer can be done during the 'Discovery' phase. > Regards > Rama Krishna Prasad > Intoto Software(I)PVT Ltd > PlotNo:15 New VasaviNagar, > Secundrabad. > INDIA-500015 > > > > David Molnar wrote: > >> On Mon, 14 Jul 2003, Clint Chaplin wrote: >> >> >> >>> How is the AP supposed to validate the certificate presented to it = by >>> the AR? Is a certificate fingerprint going to have to be=20 >>> preinstalled >>> in the AP, along with a certificate for the AP? >>> >>> >> >> I've been wondering the same thing. I think the issue goes even=20 >> deeper. >> Suppose every AP and AR shipped with a global CA public key, such as >> VeriSign, in them, just like browsers do. So I can go to VeriSign and >> register my AP and AR names. (N.B. I am *not* advocating we put=20 >> VeriSign >> in every AP and AR...) >> >> Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone=20 >> has a >> properly signed CA certificate attesting to their identity. Bob = cannot >> impersonate Charlie and vice versa. Every pair can create a shared=20 >> secret >> without anyone else being able to listen in. >> >> The questions are >> >> "How does Alice know she should be with Bob and not Charlie?" >> "How does Bob know Alice should be with him?" >> >> and in the scenario just outlined, I don't see any good way to answer >> those questions. Just having certificates, even "valid" certificates, = >> is >> not enough (unless you shove the association into the name of the >> certificate!). We need to think about how secure associations are set = >> up >> and validated. We should also think about whether setting up secure >> associations is within the purview of LWAPP or could be broken out=20 >> into >> another protocol. >> >> I'm talking about these issues Friday at the BOF, for those who will=20 >> be >> there. If you won't, I'll be happy to send you slides (once they're=20 >> done). >> >> -David >> _______________________________________________ >> Lwapp mailing list >> Lwapp@frascone.com >> http://mail.frascone.com/mailman/listinfo/lwapp >> >> >> > > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From waa@cs.umd.edu Thu Jul 17 14:45:18 2003 From: waa@cs.umd.edu (William Arbaugh) Date: Thu, 17 Jul 2003 09:45:18 -0400 Subject: [Lwapp] Security requirements for LWAPP? Message-ID: We've been talking about the best way to protect the LWAPP packets, and I just wanted to do a quick check on what people feel are the requirements. Here's a quick view from myself: Authentication: AP to AR and AR to AP (counters masquerading AR's and rogue AP's) Integrity: All packets (prevents injections and modification attacks) Confidentiality: Not sure if this is needed Key Management: Something beyond EAPoL-key needed? Bill From alper@docomolabs-usa.com Thu Jul 17 15:32:44 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 17 Jul 2003 07:32:44 -0700 Subject: [Lwapp] (no subject) In-Reply-To: <40301581B2962B448690A023EF16DFE1DC521E@bsn-mail-01.bstormnetworks.com> Message-ID: >> Why not achieve these goals by: >> - Running PANA between the station and access router. > PANA assumes a completely different architecture - not one that any of the > startups seemed to have adopted. I'm going by your description of the arch in this thread. Maybe there are missing details that make a difference. Please share. > I suppose it would be ok for the IETF to work > on something that is not being productized, but I'd wonder why... It is not just OK, it is even better. Trying to solve yesterday's problem that will miss the train is not the right model for IETF. > >> - Having AP relay interesting IEEE 802.11 bits to the access router as it >> bridges (forwards) the packets. This can be carried as some sort of auxilary >> data as part of the IEEE headers. IEEE (SDO) could define this. > This is what LWAPP does, right? Our aim is not finding problems to a solution, it is finding the right solutions to a problem. > I don't see this as a MAC or PHY layer thing, > so I don't see why IEEE would be interested. Well, note that we are trying to glue two pieces (AP and AR) that IEEE broke apart, not IETF. Alper From pcalhoun@airespace.com Thu Jul 17 19:10:51 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 11:10:51 -0700 Subject: [Lwapp] (no subject) Message-ID: <40301581B2962B448690A023EF16DFE1DC5232@bsn-mail-01.bstormnetworks.com> >>> Why not achieve these goals by: >>> - Running PANA between the station and access router. >> PANA assumes a completely different architecture - not one that any = of the >> startups seemed to have adopted. > >I'm going by your description of the arch in this thread. Maybe there = are >missing details that make a difference. Please share. I really don't want to rehash the whole spec here in a single e-mail, = but the key difference here is that the 802.11 MAC (or at least the data = and management component) terminate in the AR. This is completely = different from the PANA architecture that attempts to re-use most of the = traditional APs. We are trying to move most software functions back into = the AR to: 1. reduce CPU cycles on the AP, making it less expensive. 2. reduce the amount of software required on the AP, making it cheaper 3. Move all "enterprise" class features into the AR 4. etc, etc, etc. As I've mentioned in another e-mail, having real-time access to the data = from the AP at the AR let's the AR handle centralized policy = enforcement, IDS features, etc with a complete RF topology in mind, not = just a single cell. It is very similar to the architecture used in cellular networks today = (RANs). >> I suppose it would be ok for the IETF to work >> on something that is not being productized, but I'd wonder why... > >It is not just OK, it is even better. Trying to solve yesterday's = problem >that will miss the train is not the right model for IETF. I really don't think that WG bashing is appropriate here, but the = architecture you propose is actually behind the LWAPP architecture. PANA = is much closer to older architectures, such as Vernier, Reef Edge, etc. >>=20 >>> - Having AP relay interesting IEEE 802.11 bits to the access router = as it >>> bridges (forwards) the packets. This can be carried as some sort of = >auxilary >>> data as part of the IEEE headers. IEEE (SDO) could define this. >> This is what LWAPP does, right? > >Our aim is not finding problems to a solution, it is finding the right >solutions to a problem. No. Our aim is to solve problems that exist. Products with an LWAPP-like = architecture are beginning to ship, and there are many startups (and = incumbents) following a similar architecture. So this is not a solution = looking for a problem. This is an attempt to ensure that we can get = interoperability asap so folks that create APs can get to participate in = this new exciting space. >> I don't see this as a MAC or PHY layer thing, >> so I don't see why IEEE would be interested. > >Well, note that we are trying to glue two pieces (AP and AR) that IEEE = broke >apart, not IETF. Explain to me how this is different from L2TP? L2TP runs PPP, which is a = link layer (designed by the IETF, no less). L2TP allows the traditional = PPP functions to be split among two devices. Similar issue, but different problem space. PatC From pcalhoun@airespace.com Thu Jul 17 19:12:20 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 17 Jul 2003 11:12:20 -0700 Subject: [Lwapp] RE: Security requirements for LWAPP? Message-ID: <40301581B2962B448690A023EF16DFE1DC5233@bsn-mail-01.bstormnetworks.com> > Authentication: AP to AR and AR to AP (counters masquerading AR's and=20 > rogue AP's) yes > Integrity: All packets (prevents injections and modification attacks) yes, but the question is whether the data packets also need protection. > Confidentiality: Not sure if this is needed yes. Sensitive keying information is passed down to the AP if encryption = is performed in the AP itself.=20 > Key Management: Something beyond EAPoL-key needed? See previous answer (yes) PatC From alper@docomolabs-usa.com Thu Jul 17 19:54:58 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 17 Jul 2003 11:54:58 -0700 Subject: [Lwapp] (no subject) In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5232@bsn-mail-01.bstormnetworks.com> Message-ID: >> I'm going by your description of the arch in this thread. Maybe there are >> missing details that make a difference. Please share. > > I really don't want to rehash the whole spec here in a single e-mail, but the > key difference here is that the 802.11 MAC (or at least the data and > management component) terminate in the AR. This is completely different from > the PANA architecture that attempts to re-use most of the traditional APs. I don't know how up-to-date you are with PANA, but PANA can enable AR as the client-authenticator, and it can enable either of AP and AR as the end-point of data traffic authenticator/decryptor. > We > are trying to move most software functions back into the AR to: > > 1. reduce CPU cycles on the AP, making it less expensive. > 2. reduce the amount of software required on the AP, making it cheaper > 3. Move all "enterprise" class features into the AR > 4. etc, etc, etc. > > As I've mentioned in another e-mail, having real-time access to the data from > the AP at the AR let's the AR handle centralized policy enforcement, IDS > features, etc with a complete RF topology in mind, not just a single cell. > > It is very similar to the architecture used in cellular networks today (RANs). Yes, I see the direction. > >>> I suppose it would be ok for the IETF to work >>> on something that is not being productized, but I'd wonder why... >> >> It is not just OK, it is even better. Trying to solve yesterday's problem >> that will miss the train is not the right model for IETF. > > I really don't think that WG bashing is appropriate here, but the architecture > you propose is actually behind the LWAPP architecture. PANA is much closer to > older architectures, such as Vernier, Reef Edge, etc. Until you give us some high-level architectural clues, I cannot understand the difference. > >>> >>>> - Having AP relay interesting IEEE 802.11 bits to the access router as it >>>> bridges (forwards) the packets. This can be carried as some sort of >>>> >auxilary >>>> data as part of the IEEE headers. IEEE (SDO) could define this. >>> This is what LWAPP does, right? >> >> Our aim is not finding problems to a solution, it is finding the right >> solutions to a problem. > > No. Our aim is to solve problems that exist. Products with an LWAPP-like > architecture are beginning to ship, and there are many startups (and > incumbents) following a similar architecture. So this is not a solution > looking for a problem. This is an attempt to ensure that we can get > interoperability asap so folks that create APs can get to participate in this > new exciting space. OK. > >>> I don't see this as a MAC or PHY layer thing, >>> so I don't see why IEEE would be interested. >> >> Well, note that we are trying to glue two pieces (AP and AR) that IEEE broke >> apart, not IETF. > > Explain to me how this is different from L2TP? L2TP runs PPP, which is a link > layer (designed by the IETF, no less). L2TP allows the traditional PPP > functions to be split among two devices. > > Similar issue, but different problem space. OK, I see the similarity. But I still don't understand why you think IEEE is not appropriate. Above you say this is not a MAC thing. This is in a way bridging, how is that not a MAC thing? Alper From michaelv@legra.com Thu Jul 17 21:46:38 2003 From: michaelv@legra.com (Michael Vakulenko) Date: Thu, 17 Jul 2003 16:46:38 -0400 Subject: [Lwapp] Per packet authentication ICV In-Reply-To: Message-ID: <5.2.0.9.0.20030717160354.035fa040@in.legra.com> --=====================_262237317==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 802.11e says that station may fragment MSDUs in order to increase the probability of successful transfer across the WM and/or in order to use available TXOP duration limits efficiently in cases where the remaining TXOP duration is shorter than the time required to transmit the entire pending MSDU. In the specific case you've noted, AP also acts as a coordinator that is responsible for scheduling in the QBSS, thus controlling TXOPs. So, it's up to AP to implement efficient scheduling that takes into account sizes of queued MPDUs to better utilize WM. If it's the mobile station that fragments the MSDU, then the AP performs reassembly, in which case the AP do not have to take any real-time decisions. Thanks, -- Michael Vakulenko. At 01:59 PM 7/16/2003, Clint Chaplin wrote: >I must point out a potential problem here, one that might force at least >some 802.11 processing into the APs: >The solution for QoS that is being proposed by IEEE 802.11 TGe will >force any decisions as to what to send and when into the AP itself; the >AP simply will not have enough time to poll the AR for >information/guidance. In addition, the decision as to where to split a >MSDU into MPDUs in order to fit into the given time slot must be made > >now< and at the AP, and that includes encrypting the MPDUs. Therefor, >it will be impossible for the AR to do the TKIP encryption; it will have >to be handled by the AP. > >Which means that the packets data packets between the AR and the AP >will have to be protected in some other way. > >Clint (JOATMON) Chaplin > > >>> "Inderpreet Singh" 7/16/03 04:51:13 > >>> >Things were sounding fine until I saw "mandate 802.11 processing in >the >AR". > >I beg to differ. Mandating any kind of 802.11 processing on the AR is >enforcing an architectural solution to a performance and cost of >hardware problem. There is no technical merit to doing this from a >protocol perspective. Furthermore, correct me if I am wrong, but >shouldn't we shy away from mandating the physical or logical location >of >where IEEE protocols (L2 packets) are processed. This doesn't seem to >me to be theIETF approach. > >So, the security threats and vulnerabilities of unencrypted >encapsulated >data packets are obvious (or maybe not). But note that there is no >guarantee that the packets are going to be protected with 802.11i (or >WPA in the interim) in the first place.so mandating 802.11 processing >in >the AR doesn't solve the inherent security threat. > >To make it flexible and to meet the security requirements why not >approach it as such: > >Data packet encapsulation - 2 negotiable options within the protocol >spec > >1) 802.3 encapsulation - wireless client's 802.11 data is first >bridged by AP into 802.3 and then use lwapp to encapsulate and send to >AR >2) 802.11 encapsulation - wireless client's 802.11 data is >directly encapsulated with lwapp and sent to AR > >If option 1 is the negotiated then the implementation SHOULD enforce >higher layer security policies for the data traffic. For example, >data >traffic is secured via IPsec or SSL, etc. In addition, an >implementation MAY secure (per-packet auth) the transport of the >encapsulated data packets (between AP and AR) > >If option 2 is negotiated then the implementation MAY enforce that >802.11 security mechanisms like WPA and eventually 802.11i have been >used to secure the user's data. (of course it may further enforce >higher >layer security protection as well.). In addition, an implementation >MAY >secure (per-packet auth) the transport of the encapsulated data packets > > >This is a high level proposal.we could discuss further online and also >at the BOF. > >Comments? > >Inderpreet >-- >-----Original Message----- >From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On >Behalf Of Rama krishna prasad >Sent: Tuesday, July 15, 2003 11:43 PM >To: Pat R. Calhoun >Cc: lwapp@frascone.com >Subject: Re: [Lwapp] Per packet authentication ICV > >Hi, > > Processing performance is very relative term and anyway, I >also >feel that it should be kept in mind. > But, more importantly, I feel LWAPP is really useful in solving >the problem of > management. It is achieved by making AP implementation >simple >and > devoid of any context information specific to station, such >as 802.1x context, > Firewall/NAT context,SSL context, QoS Context etc.. This >will >eliminate > problem of mobility at the AP level. > > OK, then let us make it simple. If we need to avoid per packet >authentication, then > we should go for doing TKIP at the AR level. That is all packet >integrity and security > should be cheeked at the AR level whether it is MAC level >security, >IPSEC network > level security or SSL application level security. If we mandate >this, then I feel there > is no need for 'per packet authentication' between APs and AR. >Also, the AP can > send 802.11 packets to the AR and AR can extract AP events such >as > Associate/De-Associate/Re-Associate/Open authentication from the >802.11 packets. > Since TKIP is going to be done at the AR, I assume that AR also >should generate > 802.11 packets, which inturn will be forwarded to stations by the >APs. If we agree to this, > we need to add text to this effect in the specifications. > > Regards > Rama Krishna Prasad > > >________________________________________________________________________ >This email has been scanned for computer viruses. >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp --=====================_262237317==.ALT Content-Type: text/html; charset="us-ascii" 802.11e says that station may fragment MSDUs in order to increase the probability of successful transfer across the WM and/or in order to use available TXOP duration limits efficiently in cases where the remaining TXOP duration is shorter than the
time required to transmit the entire pending MSDU.

In the specific case you've noted, AP also acts as a coordinator that is responsible for scheduling in the QBSS, thus controlling TXOPs. So, it's up to AP to implement efficient scheduling that takes into account sizes of queued MPDUs to better utilize WM.

If it's the mobile station that fragments the MSDU, then the AP performs reassembly, in which case the AP do not have to take any real-time decisions.

Thanks,

-- Michael Vakulenko.

At 01:59 PM 7/16/2003, Clint Chaplin wrote:
I must point out a potential problem here, one that might force at least
some 802.11 processing into the APs:
The solution for QoS that is being proposed by IEEE 802.11 TGe will
force any decisions as to what to send and when into the AP itself; the
AP simply will not have enough time to poll the AR for
information/guidance.  In addition, the decision as to where to split a
MSDU into MPDUs in order to fit into the given time slot must be made
>now< and at the AP, and that includes encrypting the MPDUs.  Therefor,
it will be impossible for the AR to do the TKIP encryption; it will have
to be handled by the AP.

Which means that the packets data packets between the AR and the AP
will have to be protected in some other way.

Clint (JOATMON) Chaplin

>>> "Inderpreet Singh" <isingh@chantrynetworks.com> 7/16/03 04:51:13
>>>
Things were sounding fine until I saw "mandate 802.11 processing in
the
AR". 
 
I beg to differ.  Mandating any kind of 802.11 processing on the AR is
enforcing an architectural solution to a performance and cost of
hardware problem.  There is no technical merit to doing this from a
protocol perspective.  Furthermore, correct me if I am wrong, but
shouldn't we shy away from mandating the physical or logical location
of
where IEEE protocols (L2 packets) are processed.  This doesn't seem to
me to be theIETF approach.
 
So, the security threats and vulnerabilities of unencrypted
encapsulated
data packets are obvious (or maybe not). But note that there is no
guarantee that the packets are going to be protected with 802.11i (or
WPA in the interim) in the first place.so mandating 802.11 processing
in
the AR doesn't solve the inherent security threat. 
 
To make it flexible and to meet the security requirements why not
approach it as such:
 
Data packet encapsulation - 2 negotiable options within the protocol
spec
 
1)       802.3 encapsulation - wireless client's 802.11 data is first
bridged by AP into 802.3 and then use lwapp to encapsulate and send to
AR
2)       802.11 encapsulation - wireless client's 802.11 data is
directly encapsulated with lwapp and sent to AR
 
If option 1 is the negotiated then the implementation SHOULD enforce
higher layer security policies for the data traffic.  For example,
data
traffic is secured via IPsec or SSL, etc.  In addition, an
implementation MAY secure (per-packet auth) the transport of the
encapsulated data packets (between AP and AR)
 
If option 2 is negotiated then the implementation MAY enforce that
802.11 security mechanisms like WPA and eventually 802.11i have been
used to secure the user's data. (of course it may further enforce
higher
layer security protection as well.).  In addition, an implementation
MAY
secure (per-packet auth) the transport of the encapsulated data packets

 
This is a high level proposal.we could discuss further online and also
at the BOF.
 
Comments?
 
Inderpreet
--
-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On
Behalf Of Rama krishna prasad
Sent: Tuesday, July 15, 2003 11:43 PM
To: Pat R. Calhoun
Cc: lwapp@frascone.com
Subject: Re: [Lwapp] Per packet authentication ICV
 
Hi,
 
        Processing performance is very relative term and anyway, I
also
feel that  it should be kept in mind.
       But, more importantly, I feel LWAPP is really useful in solving
the problem of
           management. It is achieved by making AP implementation
simple
and
           devoid of any context information specific to station, such
as 802.1x context,
           Firewall/NAT context,SSL context, QoS Context etc.. This
will
eliminate
           problem of mobility at the AP level.
 
     OK, then let us make it simple. If we need to avoid per packet
authentication, then
     we should go for doing TKIP at the AR level. That is all packet
integrity and security
     should be cheeked at the AR level whether it is MAC level
security,
IPSEC network
     level security or SSL application level security.  If we mandate
this, then I feel there
     is no need for 'per packet authentication' between APs and AR.
Also, the AP can
     send 802.11 packets to the AR and AR can extract AP events such
as
     Associate/De-Associate/Re-Associate/Open authentication from the
802.11 packets.
     Since TKIP is going to be done at the AR, I assume that AR also
should generate
     802.11 packets, which inturn will be forwarded to stations by the
APs. If we agree to this,
     we need to add text to this effect in the specifications.
 
 Regards
 Rama Krishna Prasad


________________________________________________________________________
This email has been scanned for computer viruses.
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp
--=====================_262237317==.ALT-- From kempf@docomolabs-usa.com Fri Jul 18 06:58:15 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Fri, 18 Jul 2003 07:58:15 +0200 Subject: [Lwapp] Charter Proposal Message-ID: <007501c34cf1$95eaacc0$ab6015ac@dclkempt40> At the LWAPP BOF this morning, the charter bullet points below are going to be proposed. Could someone in Vienna start up a Jabber session for the BOF? Apologies to North Americans and Japanese for not having arranged this in advance. I hadn't expected the degree of interest. jak -------------------------------- Develop a protocol controlling wireless access points with the following features: .Independent of wireless link protocol. .Discovery of a CAPWAP manager (AR, IP addressable switch). .Acquisition of APs by CAPWAP manager. .Configuration and monitoring of wireless link by CAPWAP manager. .Partially and/or fully terminate the wireless MAC layer at the CAPWAP manager. -Including security of host traffic. -NOT intended to define changes in MAC! .Control of AP host load. .Security for CAPWAP signaling. From rkp@intotoinc.com Fri Jul 18 08:27:02 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Fri, 18 Jul 2003 12:57:02 +0530 Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation. References: <40301581B2962B448690A023EF16DFE1DC521F@bsn-mail-01.bstormnetworks.com> Message-ID: <3F17A146.5070100@intotoinc.com> --------------000909010607090600030606 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi all, Certificate exchange should happen in 'Discovery' phase for this. 'Certificate' message element should be sent in 'Discovery' request by the APs and ARs should send this message element in 'Discovery' reply packets. lwapp-03.txt draft today sends 'Certificate' message element in Join phase. This should be changed in the draft. Discover phase will happen this way: AP sends Discover request with its certificate. When ARs receive the request, they check their local configuration and decide on whether this AP is allowed to join this AR. If it is allowed, AR sends Discover reply with its certificate. AP, upon receiving multiple 'Discover replies' selects the AR based on its local configuration and then sends Join request to the selected AR. On a different note: Certificate is defined in PKCS5 format. Is it not simple to send certificate in DER format? Typically certificates are loaded in the box (AP or AR) in either DER/PEM form. So, it makes it simpler to send these X.509 certificates in this form? Is there any specific reason to select PKCS5 ( I had to admit, I don't know much about PKCS5)? Regards Rama Krishna Prasad Intoto Software (India) Pvt Ltd Pat R. Calhoun wrote: >>If I understand this correctly (the AP's are validating the AR's cert), >>then this implies that the AP will support RSA and/or DSA and >>SHA1and/or MD5. Is this correct? >> >> >That is probably a safe assumption. > > > >>If so, this might help solve the ICV >>problem except perhaps a performance issue. >> >> >You mean on the data path? Yes, securing data packets does require probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g APs). > >PatC >On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote: > > > >>My thoughts exactly. It is very easy to configure the known peers on >>the AP, and if the peer's name is present in the certificate, >>validation can be done there. As far as certificate validation on the >>AP, this is really no different from how most browsers work today. >>However, since most APs are not directly connected to the AR, they >>have access to the network. So there is no reason why a particular >>implementation could not validate a given AR's cert via whatever local >>means are available. >> >>PatC >>-----Original Message----- >>From: Rama krishna prasad [mailto:rkp@intotoinc.com] >>Sent: Tue 7/15/2003 8:45 PM >>To: David Molnar >>Cc: Clint Chaplin; lwapp@frascone.com >>Subject: Re: [Lwapp] Certificates, Discovery Request/Reply, and >>validation. >>Hi, >> x.509 certificates contain subject name (subject alt-name). >>I feel, >> this subject (alt) names can be used to identify the peer. >> For example, AP can be preinstalled with X.509 certificate >>signed >> by general CA or local CA server and also it can be >>pre-programmed >> with the names of ARs that it should join. Similarly, AR can >>be configured >> with subject (alt) names of AP that it trusts. Validation on >>allowing the >> peer can be done during the 'Discovery' phase. >>Regards >>Rama Krishna Prasad >>Intoto Software(I)PVT Ltd >>PlotNo:15 New VasaviNagar, >>Secundrabad. >>INDIA-500015 >> >> >> >>David Molnar wrote: >> >> >> >>>On Mon, 14 Jul 2003, Clint Chaplin wrote: >>> >>> >>> >>> >>> >>>>How is the AP supposed to validate the certificate presented to it by >>>>the AR? Is a certificate fingerprint going to have to be >>>>preinstalled >>>>in the AP, along with a certificate for the AP? >>>> >>>> >>>> >>>> >>>I've been wondering the same thing. I think the issue goes even >>>deeper. >>>Suppose every AP and AR shipped with a global CA public key, such as >>>VeriSign, in them, just like browsers do. So I can go to VeriSign and >>>register my AP and AR names. (N.B. I am *not* advocating we put >>>VeriSign >>>in every AP and AR...) >>> >>>Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone >>>has a >>>properly signed CA certificate attesting to their identity. Bob cannot >>>impersonate Charlie and vice versa. Every pair can create a shared >>>secret >>>without anyone else being able to listen in. >>> >>>The questions are >>> >>> "How does Alice know she should be with Bob and not Charlie?" >>> "How does Bob know Alice should be with him?" >>> >>>and in the scenario just outlined, I don't see any good way to answer >>>those questions. Just having certificates, even "valid" certificates, >>>is >>>not enough (unless you shove the association into the name of the >>>certificate!). We need to think about how secure associations are set >>>up >>>and validated. We should also think about whether setting up secure >>>associations is within the purview of LWAPP or could be broken out >>>into >>>another protocol. >>> >>>I'm talking about these issues Friday at the BOF, for those who will >>>be >>>there. If you won't, I'll be happy to send you slides (once they're >>>done). >>> >>>-David >>>_______________________________________________ >>>Lwapp mailing list >>>Lwapp@frascone.com >>>http://mail.frascone.com/mailman/listinfo/lwapp >>> >>> >>> >>> >>> >> >> >>_______________________________________________ >>Lwapp mailing list >>Lwapp@frascone.com >>http://mail.frascone.com/mailman/listinfo/lwapp >> >> >> > > > > > > --------------000909010607090600030606 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit 
Hi all,

Certificate exchange should happen in 'Discovery' phase for this.
'Certificate' message element should be sent in 'Discovery' request
by the APs and ARs should send this message element in 'Discovery'
reply packets.

lwapp-03.txt draft today sends 'Certificate' message element in
Join phase. This should be changed in the draft.

Discover phase will happen this way:
AP sends Discover request with its certificate.
When ARs receive the request, they check their local configuration and
decide on whether this AP is allowed to join this AR. If it is allowed, AR
sends Discover reply with its certificate.
AP, upon receiving multiple 'Discover replies' selects the AR based
on its local configuration and then sends Join request to the selected AR.

On a different note:
Certificate is defined in PKCS5 format.
Is it not simple to send certificate in DER format? Typically certificates
are loaded in the box  (AP or AR) in either DER/PEM form. So, it makes it simpler
to send these X.509 certificates in this form?  Is there any specific
reason to select PKCS5 ( I had to admit, I don't know much about
PKCS5)?

Regards
Rama Krishna Prasad
Intoto Software (India) Pvt Ltd


Pat R. Calhoun wrote:
If I understand this correctly (the AP's are validating the AR's cert), 
then this implies that the AP will support RSA and/or DSA and 
SHA1and/or MD5. Is this correct?
    
That is probably a safe assumption.

  
If so, this might help solve the ICV 
problem except perhaps a performance issue.
    
You mean on the data path? Yes, securing data packets does require probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g APs).

PatC 
On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:

  
My thoughts exactly. It is very easy to configure the known peers on 
the AP, and if the peer's name is present in the certificate, 
validation can be done there. As far as certificate validation on the 
AP, this is really no different from how most browsers work today. 
However, since most APs are not directly connected to the AR, they 
have access to the network. So there is no reason why a particular 
implementation could not validate a given AR's cert via whatever local 
means are available.

PatC
-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent:	Tue 7/15/2003 8:45 PM
To:	David Molnar
Cc:	Clint Chaplin; lwapp@frascone.com
Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and 
validation.
Hi,
          x.509 certificates contain subject name (subject alt-name).  
I feel,
          this subject (alt) names can be used to identify the peer.
          For example, AP can be preinstalled with X.509 certificate 
signed
          by general CA or local CA server and also it can be 
pre-programmed
          with the names of ARs that it should join. Similarly, AR can 
be configured
          with subject (alt) names of AP that it trusts. Validation on 
allowing the
          peer can be done during the 'Discovery' phase.
Regards
Rama Krishna Prasad
Intoto Software(I)PVT Ltd
PlotNo:15 New VasaviNagar,
Secundrabad.
INDIA-500015



David Molnar wrote:

    
On Mon, 14 Jul 2003, Clint Chaplin wrote:



      
How is the AP supposed to validate the certificate presented to it by
the AR?  Is a certificate fingerprint going to have to be 
preinstalled
in the AP, along with a certificate for the AP?


        
I've been wondering the same thing. I think the issue goes even 
deeper.
Suppose every AP and AR shipped with a global CA public key, such as
VeriSign, in them, just like browsers do. So I can go to VeriSign and
register my AP and AR names. (N.B. I am *not* advocating we put 
VeriSign
in every AP and AR...)

Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone 
has a
properly signed CA certificate attesting to their identity. Bob cannot
impersonate Charlie and vice versa. Every pair can create a shared 
secret
without anyone else being able to listen in.

The questions are

	"How does Alice know she should be with Bob and not Charlie?"
	"How does Bob know Alice should be with him?"

and in the scenario just outlined, I don't see any good way to answer
those questions. Just having certificates, even "valid" certificates, 
is
not enough (unless you shove the association into the name of the
certificate!). We need to think about how secure associations are set 
up
and validated. We should also think about whether setting up secure
associations is within the purview of LWAPP or could be broken out 
into
another protocol.

I'm talking about these issues Friday at the BOF, for those who will 
be
there. If you won't, I'll be happy to send you slides (once they're 
done).

-David
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp



      


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

--------------000909010607090600030606-- From rkp@intotoinc.com Fri Jul 18 08:31:05 2003 From: rkp@intotoinc.com (Rama krishna prasad) Date: Fri, 18 Jul 2003 13:01:05 +0530 Subject: [Lwapp] Per packet authentication ICV References: <40301581B2962B448690A023EF16DFE1DC5205@bsn-mail-01.bstormnetworks.com> Message-ID: <3F17A239.9080008@intotoinc.com> --------------010601080906010706010101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi all, I have some questions on Option 2: 1. There will be packets going from Wireless stations to AR and AR to stations via AP. From Stations to AR, in this method, 802.11 data/management frames are sent with LWAPP encapsulation. What about packets going to stations from AR. Does AR going to be do 802.11 encapsulation before sending on LWAPP? 2. There are some management packets go to Wireless station from AP today. Beacons/Probe responses can be sent by AP itself. Dis-Association and De-Authentication messages also can be sent to stations. Currently, AP check for station association inactivity time and if no packets, it sends De-Authentication frame to station. Who is going to take this responsibility of detecting inactivity and sending management frames? Will this be done by AP or AR. If it is done by AP, then how does it inform this event to the AR? Thanks Rama Krishna Prasad Intoto Software (India) pvt Ltd. Pat R. Calhoun wrote: >> Option 2: >> Sending all 802.11 frames from AP to AR after encapsulating in LWAPP. >> We can put some thinking on whether this is really required or not, >> if security is ensured (as mentioned in option1 ) between AP and AR. >> Any comments? >> >> > >Yup this is the way to do it. We will need to work on the security aspect of these data packets. However, the AR is not just a management box of APs. It provides many additional security and mobility services for the *network*. > >It cannot do so if it has no visibility into the MAC. > >PatC > > --------------010601080906010706010101 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit 


Hi all,

I have some questions on Option 2:
       1. There will be packets going from Wireless stations to AR and AR to stations via AP.
            From Stations to AR, in this method, 802.11 data/management frames are sent
            with LWAPP encapsulation. What about packets going to stations from AR.
            Does AR going to be do 802.11 encapsulation before sending on LWAPP?
       2.  There are some management packets go to Wireless station from AP today.
             Beacons/Probe responses can be sent by AP itself.
             Dis-Association and De-Authentication messages also can be sent to stations.
             Currently, AP check for station association inactivity time and if no packets, it sends
             De-Authentication frame to station.
             Who is going to take this responsibility of detecting inactivity and sending management
             frames? Will this be done by AP or AR. If it is done by AP, then how does it inform
             this event to the AR?
     Thanks
      Rama Krishna Prasad
      Intoto Software (India) pvt Ltd.





Pat R. Calhoun wrote:



  

    
    Option 2:
          Sending all 802.11 frames from AP to AR after encapsulating in LWAPP.
          We can put some thinking on whether this is really required or not,
           if security is ensured (as mentioned in option1 ) between AP and AR.
          Any comments?
    

  

  

Yup this is the way to do it. We will need to work on the security aspect of these data packets. However, the AR is not just a management box of APs. It provides many additional security and mobility services for the *network*.

It cannot do so if it has no visibility into the MAC. 

PatC
  








--------------010601080906010706010101--


From rkp@intotoinc.com  Fri Jul 18 08:33:07 2003
From: rkp@intotoinc.com (Rama krishna prasad)
Date: Fri, 18 Jul 2003 13:03:07 +0530
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
References: <40301581B2962B448690A023EF16DFE1DC521F@bsn-mail-01.bstormnetworks.com> <3F17A146.5070100@intotoinc.com>
Message-ID: <3F17A2B3.8070104@intotoinc.com>

--------------020700000602020805000005
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,
 
 I have one more thought. Here, we are talking about AP and AR authenticating
         mutually. Also, as part of this authentication, we are also thinking of
         generating shared key which can be used to encrypt/generate ICV on per
         packet basis to achieve confidentiality/authentication and anti-replay protection.
         EAP based authentication and key exchange is becoming quite popular and
         provides extensibility in user/device authentication methods.  802.1x uses this.
         PPP extensions do this.  IKEv2 is incorporating this.
         I think we also should think of using EAP based
         user/device mutual authentication and session key generation.

         LWAPP can have three phases and wherever possible we can think of using
         existing protocols.

          Phase1:
                  Discovery of ARs.
          Phase2:
                  Mutual Authentication with Selected ARs (try out all ARs)
                  Here, we can use EAP method.
                  If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then session key
                     can be generated for ciphering and per-packet authentication.
                  In case of EAP-MD5, static key can be used.
          Phase 3:
                  Provisioning and configuration of AP, If needed, updating the image on AP
                        and other AP management activities.
                  Transferring data packets and management packets from AP to AR etc..
               All phase 3 packets are secured based on session cipher and authentication keys.


          For phase2:
                PANA seems to be defining physical/link layer independent authentication mechanism.
                That might be suitable here. Comments?
         Regards
         Rama Krishna Prasad
         Intoto Software (India) Pvt Ltd.



Rama krishna prasad wrote:

>Hi all,
>
>Certificate exchange should happen in 'Discovery' phase for this.
>'Certificate' message element should be sent in 'Discovery' request
>by the APs and ARs should send this message element in 'Discovery'
>reply packets.
>
>lwapp-03.txt draft today sends 'Certificate' message element in
>Join phase. This should be changed in the draft.
>
>Discover phase will happen this way:
>AP sends Discover request with its certificate.
>When ARs receive the request, they check their local configuration and
>decide on whether this AP is allowed to join this AR. If it is allowed, AR
>sends Discover reply with its certificate.
>AP, upon receiving multiple 'Discover replies' selects the AR based
>on its local configuration and then sends Join request to the selected AR.
>
>On a different note:
>Certificate is defined in PKCS5 format.
>Is it not simple to send certificate in DER format? Typically certificates
>are loaded in the box  (AP or AR) in either DER/PEM form. So, it makes it simpler
>to send these X.509 certificates in this form?  Is there any specific
>reason to select PKCS5 ( I had to admit, I don't know much about
>PKCS5)?
>
>Regards
>Rama Krishna Prasad
>Intoto Software (India) Pvt Ltd
>
>
>
> Pat R. Calhoun wrote:
>
>>>If I understand this correctly (the AP's are validating the AR's cert), 
>>>then this implies that the AP will support RSA and/or DSA and 
>>>SHA1and/or MD5. Is this correct?
>>>    
>>>
>>That is probably a safe assumption.
>>
>>  
>>
>>>If so, this might help solve the ICV 
>>>problem except perhaps a performance issue.
>>>    
>>>
>>You mean on the data path? Yes, securing data packets does require probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g APs).
>>
>>PatC 
>>On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:
>>
>>  
>>
>>>My thoughts exactly. It is very easy to configure the known peers on 
>>>the AP, and if the peer's name is present in the certificate, 
>>>validation can be done there. As far as certificate validation on the 
>>>AP, this is really no different from how most browsers work today. 
>>>However, since most APs are not directly connected to the AR, they 
>>>have access to the network. So there is no reason why a particular 
>>>implementation could not validate a given AR's cert via whatever local 
>>>means are available.
>>>
>>>PatC
>>>-----Original Message-----
>>>From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
>>>Sent:	Tue 7/15/2003 8:45 PM
>>>To:	David Molnar
>>>Cc:	Clint Chaplin; lwapp@frascone.com
>>>Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and 
>>>validation.
>>>Hi,
>>>          x.509 certificates contain subject name (subject alt-name).  
>>>I feel,
>>>          this subject (alt) names can be used to identify the peer.
>>>          For example, AP can be preinstalled with X.509 certificate 
>>>signed
>>>          by general CA or local CA server and also it can be 
>>>pre-programmed
>>>          with the names of ARs that it should join. Similarly, AR can 
>>>be configured
>>>          with subject (alt) names of AP that it trusts. Validation on 
>>>allowing the
>>>          peer can be done during the 'Discovery' phase.
>>>Regards
>>>Rama Krishna Prasad
>>>Intoto Software(I)PVT Ltd
>>>PlotNo:15 New VasaviNagar,
>>>Secundrabad.
>>>INDIA-500015
>>>
>>>
>>>
>>>David Molnar wrote:
>>>
>>>    
>>>
>>>>On Mon, 14 Jul 2003, Clint Chaplin wrote:
>>>>
>>>>
>>>>
>>>>      
>>>>
>>>>>How is the AP supposed to validate the certificate presented to it by
>>>>>the AR?  Is a certificate fingerprint going to have to be 
>>>>>preinstalled
>>>>>in the AP, along with a certificate for the AP?
>>>>>
>>>>>
>>>>>        
>>>>>
>>>>I've been wondering the same thing. I think the issue goes even 
>>>>deeper.
>>>>Suppose every AP and AR shipped with a global CA public key, such as
>>>>VeriSign, in them, just like browsers do. So I can go to VeriSign and
>>>>register my AP and AR names. (N.B. I am *not* advocating we put 
>>>>VeriSign
>>>>in every AP and AR...)
>>>>
>>>>Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone 
>>>>has a
>>>>properly signed CA certificate attesting to their identity. Bob cannot
>>>>impersonate Charlie and vice versa. Every pair can create a shared 
>>>>secret
>>>>without anyone else being able to listen in.
>>>>
>>>>The questions are
>>>>
>>>>	"How does Alice know she should be with Bob and not Charlie?"
>>>>	"How does Bob know Alice should be with him?"
>>>>
>>>>and in the scenario just outlined, I don't see any good way to answer
>>>>those questions. Just having certificates, even "valid" certificates, 
>>>>is
>>>>not enough (unless you shove the association into the name of the
>>>>certificate!). We need to think about how secure associations are set 
>>>>up
>>>>and validated. We should also think about whether setting up secure
>>>>associations is within the purview of LWAPP or could be broken out 
>>>>into
>>>>another protocol.
>>>>
>>>>I'm talking about these issues Friday at the BOF, for those who will 
>>>>be
>>>>there. If you won't, I'll be happy to send you slides (once they're 
>>>>done).
>>>>
>>>>-David
>>>>_______________________________________________
>>>>Lwapp mailing list
>>>>Lwapp@frascone.com
>>>>http://mail.frascone.com/mailman/listinfo/lwapp
>>>>
>>>>
>>>>
>>>>      
>>>>
>>>
>>>_______________________________________________
>>>Lwapp mailing list
>>>Lwapp@frascone.com
>>>http://mail.frascone.com/mailman/listinfo/lwapp
>>>
>>>    
>>>
>>
>>
>>
>>
>>  
>>
>


--------------020700000602020805000005
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit




  
  



Hi all,
 
 I have one more thought. Here, we are talking about AP and AR authenticating
         mutually. Also, as part of this authentication, we are also thinking of
         generating shared key which can be used to encrypt/generate ICV on per
         packet basis to achieve confidentiality/authentication and anti-replay protection.
         EAP based authentication and key exchange is becoming quite popular and
         provides extensibility in user/device authentication methods.  802.1x uses this.
         PPP extensions do this.  IKEv2 is incorporating this.
         I think we also should think of using EAP based
         user/device mutual authentication and session key generation.

         LWAPP can have three phases and wherever possible we can think of using
         existing protocols.

          Phase1:
                  Discovery of ARs.
          Phase2:
                  Mutual Authentication with Selected ARs (try out all ARs)
                  Here, we can use EAP method.
                  If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then session key
                     can be generated for ciphering and per-packet authentication.
                  In case of EAP-MD5, static key can be used.
          Phase 3:
                  Provisioning and configuration of AP, If needed, updating the image on AP
                        and other AP management activities.
                  Transferring data packets and management packets from AP to AR etc..
               All phase 3 packets are secured based on session cipher and authentication keys.


          For phase2:
                PANA seems to be defining physical/link layer independent authentication mechanism.
                That might be suitable here. Comments?
         Regards
         Rama Krishna Prasad
         Intoto Software (India) Pvt Ltd.





Rama krishna prasad wrote:



  
       
  
Hi all,

Certificate exchange should happen in 'Discovery' phase for this.
'Certificate' message element should be sent in 'Discovery' request
by the APs and ARs should send this message element in 'Discovery'
reply packets.

lwapp-03.txt draft today sends 'Certificate' message element in
Join phase. This should be changed in the draft.

Discover phase will happen this way:
AP sends Discover request with its certificate.
When ARs receive the request, they check their local configuration and
decide on whether this AP is allowed to join this AR. If it is allowed, AR
sends Discover reply with its certificate.
AP, upon receiving multiple 'Discover replies' selects the AR based
on its local configuration and then sends Join request to the selected AR.

On a different note:
Certificate is defined in PKCS5 format.
Is it not simple to send certificate in DER format? Typically certificates
are loaded in the box  (AP or AR) in either DER/PEM form. So, it makes it simpler
to send these X.509 certificates in this form?  Is there any specific
reason to select PKCS5 ( I had to admit, I don't know much about
PKCS5)?

Regards
Rama Krishna Prasad
Intoto Software (India) Pvt Ltd

 

 

 Pat R. Calhoun wrote:

 
  
 
  
    
     
      
If I understand this correctly (the AP's are validating the AR's cert), 
then this implies that the AP will support RSA and/or DSA and 
SHA1and/or MD5. Is this correct?
    

   

   
    
That is probably a safe assumption.

  

   
    
     
      
If so, this might help solve the ICV 
problem except perhaps a performance issue.
    

   

   
    
You mean on the data path? Yes, securing data packets does require probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g APs).

PatC 
On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:

  

   
    
     
      
My thoughts exactly. It is very easy to configure the known peers on 
the AP, and if the peer's name is present in the certificate, 
validation can be done there. As far as certificate validation on the 
AP, this is really no different from how most browsers work today. 
However, since most APs are not directly connected to the AR, they 
have access to the network. So there is no reason why a particular 
implementation could not validate a given AR's cert via whatever local 
means are available.

PatC
-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent:	Tue 7/15/2003 8:45 PM
To:	David Molnar
Cc:	Clint Chaplin; lwapp@frascone.com
Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and 
validation.
Hi,
          x.509 certificates contain subject name (subject alt-name).  
I feel,
          this subject (alt) names can be used to identify the peer.
          For example, AP can be preinstalled with X.509 certificate 
signed
          by general CA or local CA server and also it can be 
pre-programmed
          with the names of ARs that it should join. Similarly, AR can 
be configured
          with subject (alt) names of AP that it trusts. Validation on 
allowing the
          peer can be done during the 'Discovery' phase.
Regards
Rama Krishna Prasad
Intoto Software(I)PVT Ltd
PlotNo:15 New VasaviNagar,
Secundrabad.
INDIA-500015



David Molnar wrote:

    

     
      
       
        
On Mon, 14 Jul 2003, Clint Chaplin wrote:



      

       
        
         
          
How is the AP supposed to validate the certificate presented to it by
the AR?  Is a certificate fingerprint going to have to be 
preinstalled
in the AP, along with a certificate for the AP?


        

       

       
        
I've been wondering the same thing. I think the issue goes even 
deeper.
Suppose every AP and AR shipped with a global CA public key, such as
VeriSign, in them, just like browsers do. So I can go to VeriSign and
register my AP and AR names. (N.B. I am *not* advocating we put 
VeriSign
in every AP and AR...)

Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone 
has a
properly signed CA certificate attesting to their identity. Bob cannot
impersonate Charlie and vice versa. Every pair can create a shared 
secret
without anyone else being able to listen in.

The questions are

	"How does Alice know she should be with Bob and not Charlie?"
	"How does Bob know Alice should be with him?"

and in the scenario just outlined, I don't see any good way to answer
those questions. Just having certificates, even "valid" certificates, 
is
not enough (unless you shove the association into the name of the
certificate!). We need to think about how secure associations are set 
up
and validated. We should also think about whether setting up secure
associations is within the purview of LWAPP or could be broken out 
into
another protocol.

I'm talking about these issues Friday at the BOF, for those who will 
be
there. If you won't, I'll be happy to send you slides (once they're 
done).

-David
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp



      

     

     
      

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

    

   

   
    




  

 

 

 






--------------020700000602020805000005--


From starsu.lee@samsung.com  Fri Jul 18 08:29:51 2003
From: starsu.lee@samsung.com (=?EUC-KR?B?wMy8usf1?=)
Date: Fri, 18 Jul 2003 07:29:51 +0000 (GMT)
Subject: [Lwapp] [capwap] Presentation slide
Message-ID: <3203448.1058513384238.JavaMail.weblogic@ep_app01>

Hi Dorothy and James,

I hope that CAPWAP will be going well.
Looking forward to see vivid GAPWAP.

Please, send me the presentation file or upload it in the capwap mailing list

Regards & Good Luck,

Sung Hyuck Lee

********************^^*************************
Sung Hyuck Lee 

NPTG, i-Networking Lab.
Samsung Advanced Institute of Technology (SAIT)

Tel: +82-31-280-9585
Fax: +82-31-280-9569
Cell: +82-11-9039-2615
e-mail: starsu.lee@samsung.com
********************^^**************************

From kempf@docomolabs-usa.com  Fri Jul 18 10:39:28 2003
From: kempf@docomolabs-usa.com (James Kempf)
Date: Fri, 18 Jul 2003 11:39:28 +0200
Subject: [Lwapp] IETF 57 CAPWAP BOF Slides
Message-ID: <00c001c34d10$7ca5ec10$ab6015ac@dclkempt40>

... are available at http://www.geocities.com/kempf42/capwap.zip.

            jak

From waa@cs.umd.edu  Fri Jul 18 12:14:48 2003
From: waa@cs.umd.edu (William Arbaugh)
Date: Fri, 18 Jul 2003 07:14:48 -0400
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <3F17A2B3.8070104@intotoinc.com>
Message-ID: <0B095A68-B911-11D7-BD0B-000A957E8894@cs.umd.edu>

Rama,

Not bad ideas. However, I want to ask the vendors participating in this=20=

group a question. First, some background.

There was some discussion a few years back in TGi about adding public=20
key support to the AP and including it in the authentication process=20
(for those that don't know- there is no authentication between the AP=20
and the STA). The rational behind this decision (one which I do not=20
like) was that the vendors in TGi did not want to add public key=20
support to the AP, nor did they like the idea of the AP performing an=20
EAP-TLS session. They wanted a cheap and dump AP.

The goals of LWAP, as I understand them, are similar-- to make the AP=20
as "dumb" and as "cheap" as possible and move the "smarts" back to the=20=

AR. TGi thought that adding public key, ASN1, TLS, etc. was too heavy=20
weight for an AP. What do the participants here think?

I ask because this is may be a fundamental difference in the thinking=20
between the 802.11 group and this group (which may not be a bad thing).

thanks, bill

p.s. My thoughts are that if these functions are ONLY used during the=20
bootstrap phase (authentication with AR, and key establishment), then=20
it will probably be OK. Although the bootstrap phase make take a long=20
while.


On Friday, July 18, 2003, at 03:33 AM, Rama krishna prasad wrote:

> Hi all,
> =A0
>  I have one more thought. Here, we are talking about AP and AR=20
> authenticating
>          mutually. Also, as part of this authentication, we are also=20=

> thinking of
>          generating shared key which can be used to encrypt/generate=20=

> ICV on per
>          packet basis to achieve confidentiality/authentication and=20
> anti-replay protection.
>          EAP based authentication and key exchange is becoming quite=20=

> popular and
>          provides extensibility in user/device authentication methods.=20=

>  802.1x uses this.
>          PPP extensions do this.  IKEv2 is incorporating this.
>          I think we also should think of using EAP based
>          user/device mutual authentication and session key generation.
>
>          LWAPP can have three phases and wherever possible we can=20
> think of using
>          existing protocols.
>
>           Phase1:
>                   Discovery of ARs.
>           Phase2:
>                   Mutual Authentication with Selected ARs (try out all=20=

> ARs)
>                   Here, we can use EAP method.
>                   If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then=20
> session key
>                      can be generated for ciphering and per-packet=20
> authentication.
>                   In case of EAP-MD5, static key can be used.
>           Phase 3:
>                   Provisioning and configuration of AP, If needed,=20
> updating the image on AP
>                         and other AP management activities.
>                   Transferring data packets and management packets=20
> from AP to AR etc..
>                All phase 3 packets are secured based on session cipher=20=

> and authentication keys.
>
>
>           For phase2:
>                 PANA seems to be defining physical/link layer=20
> independent authentication mechanism.
>                 That might be suitable here. Comments?
>          Regards
>          Rama Krishna Prasad
>          Intoto Software (India) Pvt Ltd.
>
>
>
> Rama krishna prasad wrote:
>
>
>
> Hi all,
>
> Certificate exchange should happen in 'Discovery' phase for this.
> 'Certificate' message element should be sent in 'Discovery' request
> by the APs and ARs should send this message element in 'Discovery'
> reply packets.
>
> lwapp-03.txt draft today sends 'Certificate' message element in
> Join phase. This should be changed in the draft.
>
> Discover phase will happen this way:
> AP sends Discover request with its certificate.
> When ARs receive the request, they check their local configuration and
> decide on whether this AP is allowed to join this AR. If it is=20
> allowed, AR
> sends Discover reply with its certificate.
> AP, upon receiving multiple 'Discover replies' selects the AR based
> on its local configuration and then sends Join request to the selected=20=

> AR.
>
> On a different note:
> Certificate is defined in PKCS5 format.
> Is it not simple to send certificate in DER format? Typically=20
> certificates
> are loaded in the box  (AP or AR) in either DER/PEM form. So, it makes=20=

> it simpler
> to send these X.509 certificates in this form?  Is there any specific
> reason to select PKCS5 ( I had to admit, I don't know much about
> PKCS5)?
>
> Regards
> Rama Krishna Prasad
> Intoto Software (India) Pvt Ltd
>
>
>
> Pat R. Calhoun wrote:
>
> If I understand this correctly (the AP's are validating the AR's =
cert),
> then this implies that the AP will support RSA and/or DSA and
> SHA1and/or MD5. Is this correct?
>
>
> That is probably a safe assumption.
>
>
>
> If so, this might help solve the ICV
> problem except perhaps a performance issue.
>
>
> You mean on the data path? Yes, securing data packets does require=20
> probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g=20
> APs).
>
> PatC
> On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:
>
>
>
> My thoughts exactly. It is very easy to configure the known peers on
> the AP, and if the peer's name is present in the certificate,
> validation can be done there. As far as certificate validation on the
> AP, this is really no different from how most browsers work today.
> However, since most APs are not directly connected to the AR, they
> have access to the network. So there is no reason why a particular
> implementation could not validate a given AR's cert via whatever local
> means are available.
>
> PatC
> -----Original Message-----
> From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
> Sent:	Tue 7/15/2003 8:45 PM
> To:	David Molnar
> Cc:	Clint Chaplin; lwapp@frascone.com
> Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and
> validation.
> Hi,
>           x.509 certificates contain subject name (subject alt-name).
> I feel,
>           this subject (alt) names can be used to identify the peer.
>           For example, AP can be preinstalled with X.509 certificate
> signed
>           by general CA or local CA server and also it can be
> pre-programmed
>           with the names of ARs that it should join. Similarly, AR can
> be configured
>           with subject (alt) names of AP that it trusts. Validation on
> allowing the
>           peer can be done during the 'Discovery' phase.
> Regards
> Rama Krishna Prasad
> Intoto Software(I)PVT Ltd
> PlotNo:15 New VasaviNagar,
> Secundrabad.
> INDIA-500015
>
>
>
> David Molnar wrote:
>
>
>
> On Mon, 14 Jul 2003, Clint Chaplin wrote:
>
>
>
>
>
> How is the AP supposed to validate the certificate presented to it by
> the AR?  Is a certificate fingerprint going to have to be
> preinstalled
> in the AP, along with a certificate for the AP?
>
>
>
>
> I've been wondering the same thing. I think the issue goes even
> deeper.
> Suppose every AP and AR shipped with a global CA public key, such as
> VeriSign, in them, just like browsers do. So I can go to VeriSign and
> register my AP and AR names. (N.B. I am *not* advocating we put
> VeriSign
> in every AP and AR...)
>
> Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone
> has a
> properly signed CA certificate attesting to their identity. Bob cannot
> impersonate Charlie and vice versa. Every pair can create a shared
> secret
> without anyone else being able to listen in.
>
> The questions are
>
> 	"How does Alice know she should be with Bob and not Charlie?"
> 	"How does Bob know Alice should be with him?"
>
> and in the scenario just outlined, I don't see any good way to answer
> those questions. Just having certificates, even "valid" certificates,
> is
> not enough (unless you shove the association into the name of the
> certificate!). We need to think about how secure associations are set
> up
> and validated. We should also think about whether setting up secure
> associations is within the purview of LWAPP or could be broken out
> into
> another protocol.
>
> I'm talking about these issues Friday at the BOF, for those who will
> be
> there. If you won't, I'll be happy to send you slides (once they're
> done).
>
> -David
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>
>
>
>
>
>
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>
>
>
>
>
>
>
>
>
>
>


From bob@airespace.com  Fri Jul 18 16:10:22 2003
From: bob@airespace.com (Bob O'Hara)
Date: Fri, 18 Jul 2003 08:10:22 -0700
Subject: [Lwapp] Per packet authentication ICV
Message-ID: <40301581B2962B448690A023EF16DFE1C8F37F@bsn-mail-01.bstormnetworks.com>

Michael,

As you point out, it is up to the AP to implement efficient scheduling.
As the AP is also an 802.11e station, by definition, it may also
fragment MSDUs in order to achieve that goal of efficient scheduling.
Given particular TSPECs and station TXOPs, the only way that efficiency
may be achieved in some cases is to fragment MSDUs to fill the air time
that would otherwise be wasted.  This does require real-time scheduling
decisions to be made in the AP, potentially on a frame by frame basis.

 -Bob
 =20
-----Original Message-----
From: Michael Vakulenko [mailto:michaelv@legra.com]=20
Sent: Thursday, July 17, 2003 1:47 PM
To: Clint Chaplin
Cc: lwapp@frascone.com
Subject: RE: [Lwapp] Per packet authentication ICV


802.11e says that station may fragment MSDUs in order to increase the
probability of successful transfer across the WM and/or in order to use
available TXOP duration limits efficiently in cases where the remaining
TXOP duration is shorter than the
time required to transmit the entire pending MSDU.=20

In the specific case you've noted, AP also acts as a coordinator that is
responsible for scheduling in the QBSS, thus controlling TXOPs. So, it's
up to AP to implement efficient scheduling that takes into account sizes
of queued MPDUs to better utilize WM.=20

If it's the mobile station that fragments the MSDU, then the AP performs
reassembly, in which case the AP do not have to take any real-time
decisions.

Thanks,

-- Michael Vakulenko.

At 01:59 PM 7/16/2003, Clint Chaplin wrote:

I must point out a potential problem here, one that might force at least
some 802.11 processing into the APs:
The solution for QoS that is being proposed by IEEE 802.11 TGe will
force any decisions as to what to send and when into the AP itself; the
AP simply will not have enough time to poll the AR for
information/guidance.  In addition, the decision as to where to split a
MSDU into MPDUs in order to fit into the given time slot must be made
>now< and at the AP, and that includes encrypting the MPDUs.  Therefor,
it will be impossible for the AR to do the TKIP encryption; it will have
to be handled by the AP.

Which means that the packets data packets between the AR and the AP
will have to be protected in some other way.

Clint (JOATMON) Chaplin

>>> "Inderpreet Singh"  7/16/03 04:51:13
>>>
Things were sounding fine until I saw "mandate 802.11 processing in
the
AR". =20
=20
I beg to differ.  Mandating any kind of 802.11 processing on the AR is
enforcing an architectural solution to a performance and cost of
hardware problem.  There is no technical merit to doing this from a
protocol perspective.  Furthermore, correct me if I am wrong, but
shouldn't we shy away from mandating the physical or logical location
of
where IEEE protocols (L2 packets) are processed.  This doesn't seem to
me to be theIETF approach.
=20
So, the security threats and vulnerabilities of unencrypted
encapsulated
data packets are obvious (or maybe not). But note that there is no
guarantee that the packets are going to be protected with 802.11i (or
WPA in the interim) in the first place.so mandating 802.11 processing
in
the AR doesn't solve the inherent security threat. =20
=20
To make it flexible and to meet the security requirements why not
approach it as such:
=20
Data packet encapsulation - 2 negotiable options within the protocol
spec
=20
1)       802.3 encapsulation - wireless client's 802.11 data is first
bridged by AP into 802.3 and then use lwapp to encapsulate and send to
AR
2)       802.11 encapsulation - wireless client's 802.11 data is
directly encapsulated with lwapp and sent to AR
=20
If option 1 is the negotiated then the implementation SHOULD enforce
higher layer security policies for the data traffic.  For example,
data
traffic is secured via IPsec or SSL, etc.  In addition, an
implementation MAY secure (per-packet auth) the transport of the
encapsulated data packets (between AP and AR)
=20
If option 2 is negotiated then the implementation MAY enforce that
802.11 security mechanisms like WPA and eventually 802.11i have been
used to secure the user's data. (of course it may further enforce
higher
layer security protection as well.).  In addition, an implementation
MAY
secure (per-packet auth) the transport of the encapsulated data packets

=20
This is a high level proposal.we could discuss further online and also
at the BOF.
=20
Comments?
=20
Inderpreet
--
-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On
Behalf Of Rama krishna prasad
Sent: Tuesday, July 15, 2003 11:43 PM
To: Pat R. Calhoun
Cc: lwapp@frascone.com=20
Subject: Re: [Lwapp] Per packet authentication ICV
=20
Hi,
=20
        Processing performance is very relative term and anyway, I
also
feel that  it should be kept in mind.
       But, more importantly, I feel LWAPP is really useful in solving
the problem of
           management. It is achieved by making AP implementation
simple
and
           devoid of any context information specific to station, such
as 802.1x context,
           Firewall/NAT context,SSL context, QoS Context etc.. This
will
eliminate
           problem of mobility at the AP level.
=20
     OK, then let us make it simple. If we need to avoid per packet
authentication, then
     we should go for doing TKIP at the AR level. That is all packet
integrity and security
     should be cheeked at the AR level whether it is MAC level
security,
IPSEC network
     level security or SSL application level security.  If we mandate
this, then I feel there
     is no need for 'per packet authentication' between APs and AR.
Also, the AP can
     send 802.11 packets to the AR and AR can extract AP events such
as
     Associate/De-Associate/Re-Associate/Open authentication from the
802.11 packets.
     Since TKIP is going to be done at the AR, I assume that AR also
should generate
     802.11 packets, which inturn will be forwarded to stations by the
APs. If we agree to this,
     we need to add text to this effect in the specifications.
=20
 Regards
 Rama Krishna Prasad=20


________________________________________________________________________
This email has been scanned for computer viruses.
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp=20

From Mike.Moreton@Synad.com  Fri Jul 18 16:26:05 2003
From: Mike.Moreton@Synad.com (Mike Moreton)
Date: Fri, 18 Jul 2003 16:26:05 +0100
Subject: [Lwapp] Per packet authentication ICV
Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA5FD@paris.synad.com>

Bob,

If your scheduling requirements are so tight that they can only be
achieved by dynamic fragmentation, then given the error prone
environment that 802.11 works in, I can't help feeling that you're
probably dead already.

If ignoring dynamic fragmentation could substantially improve LWAPP,
then I'd personally see that as a price well worth paying.

Just a personal opinion...


Mike Moreton
Synad Technologies Ltd.
=20

-----Original Message-----
From: Bob O'Hara [mailto:bob@airespace.com]=20
Sent: 18 July 2003 16:10
To: Michael Vakulenko; Clint Chaplin
Cc: lwapp@frascone.com
Subject: RE: [Lwapp] Per packet authentication ICV

Michael,

As you point out, it is up to the AP to implement efficient scheduling.
As the AP is also an 802.11e station, by definition, it may also
fragment MSDUs in order to achieve that goal of efficient scheduling.
Given particular TSPECs and station TXOPs, the only way that efficiency
may be achieved in some cases is to fragment MSDUs to fill the air time
that would otherwise be wasted.  This does require real-time scheduling
decisions to be made in the AP, potentially on a frame by frame basis.

 -Bob
 =20
-----Original Message-----
From: Michael Vakulenko [mailto:michaelv@legra.com]=20
Sent: Thursday, July 17, 2003 1:47 PM
To: Clint Chaplin
Cc: lwapp@frascone.com
Subject: RE: [Lwapp] Per packet authentication ICV


802.11e says that station may fragment MSDUs in order to increase the
probability of successful transfer across the WM and/or in order to use
available TXOP duration limits efficiently in cases where the remaining
TXOP duration is shorter than the
time required to transmit the entire pending MSDU.=20

In the specific case you've noted, AP also acts as a coordinator that is
responsible for scheduling in the QBSS, thus controlling TXOPs. So, it's
up to AP to implement efficient scheduling that takes into account sizes
of queued MPDUs to better utilize WM.=20

If it's the mobile station that fragments the MSDU, then the AP performs
reassembly, in which case the AP do not have to take any real-time
decisions.

Thanks,

-- Michael Vakulenko.

At 01:59 PM 7/16/2003, Clint Chaplin wrote:

I must point out a potential problem here, one that might force at least
some 802.11 processing into the APs:
The solution for QoS that is being proposed by IEEE 802.11 TGe will
force any decisions as to what to send and when into the AP itself; the
AP simply will not have enough time to poll the AR for
information/guidance.  In addition, the decision as to where to split a
MSDU into MPDUs in order to fit into the given time slot must be made
>now< and at the AP, and that includes encrypting the MPDUs.  Therefor,
it will be impossible for the AR to do the TKIP encryption; it will have
to be handled by the AP.

Which means that the packets data packets between the AR and the AP
will have to be protected in some other way.

Clint (JOATMON) Chaplin

>>> "Inderpreet Singh"  7/16/03 04:51:13
>>>
Things were sounding fine until I saw "mandate 802.11 processing in
the
AR". =20
=20
I beg to differ.  Mandating any kind of 802.11 processing on the AR is
enforcing an architectural solution to a performance and cost of
hardware problem.  There is no technical merit to doing this from a
protocol perspective.  Furthermore, correct me if I am wrong, but
shouldn't we shy away from mandating the physical or logical location
of
where IEEE protocols (L2 packets) are processed.  This doesn't seem to
me to be theIETF approach.
=20
So, the security threats and vulnerabilities of unencrypted
encapsulated
data packets are obvious (or maybe not). But note that there is no
guarantee that the packets are going to be protected with 802.11i (or
WPA in the interim) in the first place.so mandating 802.11 processing
in
the AR doesn't solve the inherent security threat. =20
=20
To make it flexible and to meet the security requirements why not
approach it as such:
=20
Data packet encapsulation - 2 negotiable options within the protocol
spec
=20
1)       802.3 encapsulation - wireless client's 802.11 data is first
bridged by AP into 802.3 and then use lwapp to encapsulate and send to
AR
2)       802.11 encapsulation - wireless client's 802.11 data is
directly encapsulated with lwapp and sent to AR
=20
If option 1 is the negotiated then the implementation SHOULD enforce
higher layer security policies for the data traffic.  For example,
data
traffic is secured via IPsec or SSL, etc.  In addition, an
implementation MAY secure (per-packet auth) the transport of the
encapsulated data packets (between AP and AR)
=20
If option 2 is negotiated then the implementation MAY enforce that
802.11 security mechanisms like WPA and eventually 802.11i have been
used to secure the user's data. (of course it may further enforce
higher
layer security protection as well.).  In addition, an implementation
MAY
secure (per-packet auth) the transport of the encapsulated data packets

=20
This is a high level proposal.we could discuss further online and also
at the BOF.
=20
Comments?
=20
Inderpreet
--
-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On
Behalf Of Rama krishna prasad
Sent: Tuesday, July 15, 2003 11:43 PM
To: Pat R. Calhoun
Cc: lwapp@frascone.com=20
Subject: Re: [Lwapp] Per packet authentication ICV
=20
Hi,
=20
        Processing performance is very relative term and anyway, I
also
feel that  it should be kept in mind.
       But, more importantly, I feel LWAPP is really useful in solving
the problem of
           management. It is achieved by making AP implementation
simple
and
           devoid of any context information specific to station, such
as 802.1x context,
           Firewall/NAT context,SSL context, QoS Context etc.. This
will
eliminate
           problem of mobility at the AP level.
=20
     OK, then let us make it simple. If we need to avoid per packet
authentication, then
     we should go for doing TKIP at the AR level. That is all packet
integrity and security
     should be cheeked at the AR level whether it is MAC level
security,
IPSEC network
     level security or SSL application level security.  If we mandate
this, then I feel there
     is no need for 'per packet authentication' between APs and AR.
Also, the AP can
     send 802.11 packets to the AR and AR can extract AP events such
as
     Associate/De-Associate/Re-Associate/Open authentication from the
802.11 packets.
     Since TKIP is going to be done at the AR, I assume that AR also
should generate
     802.11 packets, which inturn will be forwarded to stations by the
APs. If we agree to this,
     we need to add text to this effect in the specifications.
=20
 Regards
 Rama Krishna Prasad=20


________________________________________________________________________
This email has been scanned for computer viruses.
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp=20
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

From cchaplin@sj.symbol.com  Fri Jul 18 18:34:06 2003
From: cchaplin@sj.symbol.com (Clint Chaplin)
Date: Fri, 18 Jul 2003 10:34:06 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and
 validation.
Message-ID: 

There is going to be a tension to pull the standard in this direction. 
My "problem" with that is that it's going to require even more
processing power in the APs to implement some of the proposals, thus
evolving the APs away from "Light Weight"


Clint (JOATMON) Chaplin

>>> Rama krishna prasad  7/18/03 00:33:07 >>>
Hi all,
 
 I have one more thought. Here, we are talking about AP and AR
authenticating
         mutually. Also, as part of this authentication, we are also
thinking of
         generating shared key which can be used to encrypt/generate
ICV on per
         packet basis to achieve confidentiality/authentication and
anti-replay protection.
         EAP based authentication and key exchange is becoming quite
popular and
         provides extensibility in user/device authentication methods. 
802.1x uses this.
         PPP extensions do this.  IKEv2 is incorporating this.
         I think we also should think of using EAP based
         user/device mutual authentication and session key generation.

         LWAPP can have three phases and wherever possible we can think
of using
         existing protocols.

          Phase1:
                  Discovery of ARs.
          Phase2:
                  Mutual Authentication with Selected ARs (try out all
ARs)
                  Here, we can use EAP method.
                  If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then
session key
                     can be generated for ciphering and per-packet
authentication.
                  In case of EAP-MD5, static key can be used.
          Phase 3:
                  Provisioning and configuration of AP, If needed,
updating the image on AP
                        and other AP management activities.
                  Transferring data packets and management packets from
AP to AR etc..
               All phase 3 packets are secured based on session cipher
and authentication keys.


          For phase2:
                PANA seems to be defining physical/link layer
independent authentication mechanism.
                That might be suitable here. Comments?
         Regards
         Rama Krishna Prasad
         Intoto Software (India) Pvt Ltd.



Rama krishna prasad wrote:

>Hi all,
>
>Certificate exchange should happen in 'Discovery' phase for this.
>'Certificate' message element should be sent in 'Discovery' request
>by the APs and ARs should send this message element in 'Discovery'
>reply packets.
>
>lwapp-03.txt draft today sends 'Certificate' message element in
>Join phase. This should be changed in the draft.
>
>Discover phase will happen this way:
>AP sends Discover request with its certificate.
>When ARs receive the request, they check their local configuration
and
>decide on whether this AP is allowed to join this AR. If it is
allowed, AR
>sends Discover reply with its certificate.
>AP, upon receiving multiple 'Discover replies' selects the AR based
>on its local configuration and then sends Join request to the selected
AR.
>
>On a different note:
>Certificate is defined in PKCS5 format.
>Is it not simple to send certificate in DER format? Typically
certificates
>are loaded in the box  (AP or AR) in either DER/PEM form. So, it makes
it simpler
>to send these X.509 certificates in this form?  Is there any specific
>reason to select PKCS5 ( I had to admit, I don't know much about
>PKCS5)?
>
>Regards
>Rama Krishna Prasad
>Intoto Software (India) Pvt Ltd
>
>
>
> Pat R. Calhoun wrote:
>
>>>If I understand this correctly (the AP's are validating the AR's
cert), 
>>>then this implies that the AP will support RSA and/or DSA and 
>>>SHA1and/or MD5. Is this correct?
>>>    
>>>
>>That is probably a safe assumption.
>>
>>  
>>
>>>If so, this might help solve the ICV 
>>>problem except perhaps a performance issue.
>>>    
>>>
>>You mean on the data path? Yes, securing data packets does require
probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g
APs).
>>
>>PatC 
>>On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:
>>
>>  
>>
>>>My thoughts exactly. It is very easy to configure the known peers on

>>>the AP, and if the peer's name is present in the certificate, 
>>>validation can be done there. As far as certificate validation on
the 
>>>AP, this is really no different from how most browsers work today. 
>>>However, since most APs are not directly connected to the AR, they 
>>>have access to the network. So there is no reason why a particular 
>>>implementation could not validate a given AR's cert via whatever
local 
>>>means are available.
>>>
>>>PatC
>>>-----Original Message-----
>>>From:	Rama krishna prasad [mailto:rkp@intotoinc.com] 
>>>Sent:	Tue 7/15/2003 8:45 PM
>>>To:	David Molnar
>>>Cc:	Clint Chaplin; lwapp@frascone.com 
>>>Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and 
>>>validation.
>>>Hi,
>>>          x.509 certificates contain subject name (subject
alt-name).  
>>>I feel,
>>>          this subject (alt) names can be used to identify the
peer.
>>>          For example, AP can be preinstalled with X.509 certificate

>>>signed
>>>          by general CA or local CA server and also it can be 
>>>pre-programmed
>>>          with the names of ARs that it should join. Similarly, AR
can 
>>>be configured
>>>          with subject (alt) names of AP that it trusts. Validation
on 
>>>allowing the
>>>          peer can be done during the 'Discovery' phase.
>>>Regards
>>>Rama Krishna Prasad
>>>Intoto Software(I)PVT Ltd
>>>PlotNo:15 New VasaviNagar,
>>>Secundrabad.
>>>INDIA-500015
>>>
>>>
>>>
>>>David Molnar wrote:
>>>
>>>    
>>>
>>>>On Mon, 14 Jul 2003, Clint Chaplin wrote:
>>>>
>>>>
>>>>
>>>>      
>>>>
>>>>>How is the AP supposed to validate the certificate presented to it
by
>>>>>the AR?  Is a certificate fingerprint going to have to be 
>>>>>preinstalled
>>>>>in the AP, along with a certificate for the AP?
>>>>>
>>>>>
>>>>>        
>>>>>
>>>>I've been wondering the same thing. I think the issue goes even 
>>>>deeper.
>>>>Suppose every AP and AR shipped with a global CA public key, such
as
>>>>VeriSign, in them, just like browsers do. So I can go to VeriSign
and
>>>>register my AP and AR names. (N.B. I am *not* advocating we put 
>>>>VeriSign
>>>>in every AP and AR...)
>>>>
>>>>Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone

>>>>has a
>>>>properly signed CA certificate attesting to their identity. Bob
cannot
>>>>impersonate Charlie and vice versa. Every pair can create a shared

>>>>secret
>>>>without anyone else being able to listen in.
>>>>
>>>>The questions are
>>>>
>>>>	"How does Alice know she should be with Bob and not Charlie?"
>>>>	"How does Bob know Alice should be with him?"
>>>>
>>>>and in the scenario just outlined, I don't see any good way to
answer
>>>>those questions. Just having certificates, even "valid"
certificates, 
>>>>is
>>>>not enough (unless you shove the association into the name of the
>>>>certificate!). We need to think about how secure associations are
set 
>>>>up
>>>>and validated. We should also think about whether setting up
secure
>>>>associations is within the purview of LWAPP or could be broken out

>>>>into
>>>>another protocol.
>>>>
>>>>I'm talking about these issues Friday at the BOF, for those who
will 
>>>>be
>>>>there. If you won't, I'll be happy to send you slides (once they're

>>>>done).
>>>>
>>>>-David
>>>>_______________________________________________
>>>>Lwapp mailing list
>>>>Lwapp@frascone.com 
>>>>http://mail.frascone.com/mailman/listinfo/lwapp 
>>>>
>>>>
>>>>
>>>>      
>>>>
>>>
>>>_______________________________________________
>>>Lwapp mailing list
>>>Lwapp@frascone.com 
>>>http://mail.frascone.com/mailman/listinfo/lwapp 
>>>
>>>    
>>>
>>
>>
>>
>>
>>  
>>
>



________________________________________________________________________
This email has been scanned for computer viruses.

From scott@airespace.com  Fri Jul 18 18:44:18 2003
From: scott@airespace.com (Scott G. Kelly)
Date: Fri, 18 Jul 2003 10:44:18 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and	validation.
References: 
Message-ID: <3F1831F2.7010209@airespace.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I agree with Clint, and especially with respect to authentication
mechanisms. The requirements for IKEv2 are significantly different than
ours. EAP methods were included there solely for the purpose of
supporting remote access. These methods are not used for device to
device authentication (nor should they be), which is what we are
concerned with here. We need to support at most two auth methods in
lwapp: public keys and preshared keys.

Clint Chaplin wrote:
| There is going to be a tension to pull the standard in this direction.
| My "problem" with that is that it's going to require even more
| processing power in the APs to implement some of the proposals, thus
| evolving the APs away from "Light Weight"
|
|
| Clint (JOATMON) Chaplin
|
|
|>>>Rama krishna prasad  7/18/03 00:33:07 >>>
|>>
| Hi all,
|
|  I have one more thought. Here, we are talking about AP and AR
| authenticating
|          mutually. Also, as part of this authentication, we are also
| thinking of
|          generating shared key which can be used to encrypt/generate
| ICV on per
|          packet basis to achieve confidentiality/authentication and
| anti-replay protection.
|          EAP based authentication and key exchange is becoming quite
| popular and
|          provides extensibility in user/device authentication methods.
| 802.1x uses this.
|          PPP extensions do this.  IKEv2 is incorporating this.
|          I think we also should think of using EAP based
|          user/device mutual authentication and session key generation.
|
|          LWAPP can have three phases and wherever possible we can think
| of using
|          existing protocols.
|
|           Phase1:
|                   Discovery of ARs.
|           Phase2:
|                   Mutual Authentication with Selected ARs (try out all
| ARs)
|                   Here, we can use EAP method.
|                   If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then
| session key
|                      can be generated for ciphering and per-packet
| authentication.
|                   In case of EAP-MD5, static key can be used.
|           Phase 3:
|                   Provisioning and configuration of AP, If needed,
| updating the image on AP
|                         and other AP management activities.
|                   Transferring data packets and management packets from
| AP to AR etc..
|                All phase 3 packets are secured based on session cipher
| and authentication keys.
|
|
|           For phase2:
|                 PANA seems to be defining physical/link layer
| independent authentication mechanism.
|                 That might be suitable here. Comments?
|          Regards
|          Rama Krishna Prasad
|          Intoto Software (India) Pvt Ltd.
|
|
|
| Rama krishna prasad wrote:
|
|
|>Hi all,
|>
|>Certificate exchange should happen in 'Discovery' phase for this.
|>'Certificate' message element should be sent in 'Discovery' request
|>by the APs and ARs should send this message element in 'Discovery'
|>reply packets.
|>
|>lwapp-03.txt draft today sends 'Certificate' message element in
|>Join phase. This should be changed in the draft.
|>
|>Discover phase will happen this way:
|>AP sends Discover request with its certificate.
|>When ARs receive the request, they check their local configuration
|
| and
|
|>decide on whether this AP is allowed to join this AR. If it is
|
| allowed, AR
|
|>sends Discover reply with its certificate.
|>AP, upon receiving multiple 'Discover replies' selects the AR based
|>on its local configuration and then sends Join request to the selected
|
| AR.
|
|>On a different note:
|>Certificate is defined in PKCS5 format.
|>Is it not simple to send certificate in DER format? Typically
|
| certificates
|
|>are loaded in the box  (AP or AR) in either DER/PEM form. So, it makes
|
| it simpler
|
|>to send these X.509 certificates in this form?  Is there any specific
|>reason to select PKCS5 ( I had to admit, I don't know much about
|>PKCS5)?
|>
|>Regards
|>Rama Krishna Prasad
|>Intoto Software (India) Pvt Ltd
|>
|>
|>
|>Pat R. Calhoun wrote:
|>
|>
|>>>If I understand this correctly (the AP's are validating the AR's
|>>
| cert),
|
|>>>then this implies that the AP will support RSA and/or DSA and
|>>>SHA1and/or MD5. Is this correct?
|>>>
|>>>
|>>
|>>That is probably a safe assumption.
|>>
|>>
|>>
|>>
|>>>If so, this might help solve the ICV
|>>>problem except perhaps a performance issue.
|>>>
|>>>
|>>
|>>You mean on the data path? Yes, securing data packets does require
|>
| probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g
| APs).
|
|>>PatC
|>>On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:
|>>
|>>
|>>
|>>
|>>>My thoughts exactly. It is very easy to configure the known peers on
|>>
|
|>>>the AP, and if the peer's name is present in the certificate,
|>>>validation can be done there. As far as certificate validation on
|>>
| the
|
|>>>AP, this is really no different from how most browsers work today.
|>>>However, since most APs are not directly connected to the AR, they
|>>>have access to the network. So there is no reason why a particular
|>>>implementation could not validate a given AR's cert via whatever
|>>
| local
|
|>>>means are available.
|>>>
|>>>PatC
|>>>-----Original Message-----
|>>>From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
|>>>Sent:	Tue 7/15/2003 8:45 PM
|>>>To:	David Molnar
|>>>Cc:	Clint Chaplin; lwapp@frascone.com
|>>>Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and
|>>>validation.
|>>>Hi,
|>>>         x.509 certificates contain subject name (subject
|>>
| alt-name).
|
|>>>I feel,
|>>>         this subject (alt) names can be used to identify the
|>>
| peer.
|
|>>>         For example, AP can be preinstalled with X.509 certificate
|>>
|
|>>>signed
|>>>         by general CA or local CA server and also it can be
|>>>pre-programmed
|>>>         with the names of ARs that it should join. Similarly, AR
|>>
| can
|
|>>>be configured
|>>>         with subject (alt) names of AP that it trusts. Validation
|>>
| on
|
|>>>allowing the
|>>>         peer can be done during the 'Discovery' phase.
|>>>Regards
|>>>Rama Krishna Prasad
|>>>Intoto Software(I)PVT Ltd
|>>>PlotNo:15 New VasaviNagar,
|>>>Secundrabad.
|>>>INDIA-500015
|>>>
|>>>
|>>>
|>>>David Molnar wrote:
|>>>
|>>>
|>>>
|>>>
|>>>>On Mon, 14 Jul 2003, Clint Chaplin wrote:
|>>>>
|>>>>
|>>>>
|>>>>
|>>>>
|>>>>
|>>>>>How is the AP supposed to validate the certificate presented to it
|>>>>
| by
|
|>>>>>the AR?  Is a certificate fingerprint going to have to be
|>>>>>preinstalled
|>>>>>in the AP, along with a certificate for the AP?
|>>>>>
|>>>>>
|>>>>>
|>>>>>
|>>>>
|>>>>I've been wondering the same thing. I think the issue goes even
|>>>>deeper.
|>>>>Suppose every AP and AR shipped with a global CA public key, such
|>>>
| as
|
|>>>>VeriSign, in them, just like browsers do. So I can go to VeriSign
|>>>
| and
|
|>>>>register my AP and AR names. (N.B. I am *not* advocating we put
|>>>>VeriSign
|>>>>in every AP and AR...)
|>>>>
|>>>>Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone
|>>>
|
|>>>>has a
|>>>>properly signed CA certificate attesting to their identity. Bob
|>>>
| cannot
|
|>>>>impersonate Charlie and vice versa. Every pair can create a shared
|>>>
|
|>>>>secret
|>>>>without anyone else being able to listen in.
|>>>>
|>>>>The questions are
|>>>>
|>>>>	"How does Alice know she should be with Bob and not Charlie?"
|>>>>	"How does Bob know Alice should be with him?"
|>>>>
|>>>>and in the scenario just outlined, I don't see any good way to
|>>>
| answer
|
|>>>>those questions. Just having certificates, even "valid"
|>>>
| certificates,
|
|>>>>is
|>>>>not enough (unless you shove the association into the name of the
|>>>>certificate!). We need to think about how secure associations are
|>>>
| set
|
|>>>>up
|>>>>and validated. We should also think about whether setting up
|>>>
| secure
|
|>>>>associations is within the purview of LWAPP or could be broken out
|>>>
|
|>>>>into
|>>>>another protocol.
|>>>>
|>>>>I'm talking about these issues Friday at the BOF, for those who
|>>>
| will
|
|>>>>be
|>>>>there. If you won't, I'll be happy to send you slides (once they're
|>>>
|
|>>>>done).
|>>>>
|>>>>-David
|>>>>_______________________________________________
|>>>>Lwapp mailing list
|>>>>Lwapp@frascone.com
|>>>>http://mail.frascone.com/mailman/listinfo/lwapp
|>>>>
|>>>>
|>>>>
|>>>>
|>>>>
|>>>
|>>>_______________________________________________
|>>>Lwapp mailing list
|>>>Lwapp@frascone.com
|>>>http://mail.frascone.com/mailman/listinfo/lwapp
|>>>
|>>>
|>>>
|>>
|>>
|>>
|>>
|>>
|>>
|>
|
|
|
| ________________________________________________________________________
| This email has been scanned for computer viruses.
| _______________________________________________
| Lwapp mailing list
| Lwapp@frascone.com
| http://mail.frascone.com/mailman/listinfo/lwapp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/GDHxMtIdhO0pgN4RAtQAAKDgAakhucrPo7P40q6D/+KGEGq2PgCdFeWY
kkPZC5bJOYnc/MJQScvgx4I=
=L2P8
-----END PGP SIGNATURE-----


From cchaplin@sj.symbol.com  Fri Jul 18 18:46:29 2003
From: cchaplin@sj.symbol.com (Clint Chaplin)
Date: Fri, 18 Jul 2003 10:46:29 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and
 validation.
Message-ID: 

I tend to think that we may be asking too much of the AP in some of the
authentication scenarios that are being discussed.  The tendancy of the
discussion has been to apply the phrase "light weight" to "protocol"
rather than "Access Point", and I'd rather see the latter.

Clint (JOATMON) Chaplin

>>> William Arbaugh  7/18/03 04:14:48 >>>
Rama,

Not bad ideas. However, I want to ask the vendors participating in this

group a question. First, some background.

There was some discussion a few years back in TGi about adding public 
key support to the AP and including it in the authentication process 
(for those that don't know- there is no authentication between the AP 
and the STA). The rational behind this decision (one which I do not 
like) was that the vendors in TGi did not want to add public key 
support to the AP, nor did they like the idea of the AP performing an 
EAP-TLS session. They wanted a cheap and dump AP.

The goals of LWAP, as I understand them, are similar-- to make the AP 
as "dumb" and as "cheap" as possible and move the "smarts" back to the

AR. TGi thought that adding public key, ASN1, TLS, etc. was too heavy 
weight for an AP. What do the participants here think?

I ask because this is may be a fundamental difference in the thinking 
between the 802.11 group and this group (which may not be a bad
thing).

thanks, bill

p.s. My thoughts are that if these functions are ONLY used during the 
bootstrap phase (authentication with AR, and key establishment), then 
it will probably be OK. Although the bootstrap phase make take a long 
while.


On Friday, July 18, 2003, at 03:33 AM, Rama krishna prasad wrote:

> Hi all,
>  
>  I have one more thought. Here, we are talking about AP and AR 
> authenticating
>          mutually. Also, as part of this authentication, we are also

> thinking of
>          generating shared key which can be used to encrypt/generate

> ICV on per
>          packet basis to achieve confidentiality/authentication and 
> anti-replay protection.
>          EAP based authentication and key exchange is becoming quite

> popular and
>          provides extensibility in user/device authentication
methods. 
>  802.1x uses this.
>          PPP extensions do this.  IKEv2 is incorporating this.
>          I think we also should think of using EAP based
>          user/device mutual authentication and session key
generation.
>
>          LWAPP can have three phases and wherever possible we can 
> think of using
>          existing protocols.
>
>           Phase1:
>                   Discovery of ARs.
>           Phase2:
>                   Mutual Authentication with Selected ARs (try out
all 
> ARs)
>                   Here, we can use EAP method.
>                   If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then 
> session key
>                      can be generated for ciphering and per-packet 
> authentication.
>                   In case of EAP-MD5, static key can be used.
>           Phase 3:
>                   Provisioning and configuration of AP, If needed, 
> updating the image on AP
>                         and other AP management activities.
>                   Transferring data packets and management packets 
> from AP to AR etc..
>                All phase 3 packets are secured based on session
cipher 
> and authentication keys.
>
>
>           For phase2:
>                 PANA seems to be defining physical/link layer 
> independent authentication mechanism.
>                 That might be suitable here. Comments?
>          Regards
>          Rama Krishna Prasad
>          Intoto Software (India) Pvt Ltd.
>
>
>
> Rama krishna prasad wrote:
>
>
>
> Hi all,
>
> Certificate exchange should happen in 'Discovery' phase for this.
> 'Certificate' message element should be sent in 'Discovery' request
> by the APs and ARs should send this message element in 'Discovery'
> reply packets.
>
> lwapp-03.txt draft today sends 'Certificate' message element in
> Join phase. This should be changed in the draft.
>
> Discover phase will happen this way:
> AP sends Discover request with its certificate.
> When ARs receive the request, they check their local configuration
and
> decide on whether this AP is allowed to join this AR. If it is 
> allowed, AR
> sends Discover reply with its certificate.
> AP, upon receiving multiple 'Discover replies' selects the AR based
> on its local configuration and then sends Join request to the
selected 
> AR.
>
> On a different note:
> Certificate is defined in PKCS5 format.
> Is it not simple to send certificate in DER format? Typically 
> certificates
> are loaded in the box  (AP or AR) in either DER/PEM form. So, it
makes 
> it simpler
> to send these X.509 certificates in this form?  Is there any
specific
> reason to select PKCS5 ( I had to admit, I don't know much about
> PKCS5)?
>
> Regards
> Rama Krishna Prasad
> Intoto Software (India) Pvt Ltd
>
>
>
> Pat R. Calhoun wrote:
>
> If I understand this correctly (the AP's are validating the AR's
cert),
> then this implies that the AP will support RSA and/or DSA and
> SHA1and/or MD5. Is this correct?
>
>
> That is probably a safe assumption.
>
>
>
> If so, this might help solve the ICV
> problem except perhaps a performance issue.
>
>
> You mean on the data path? Yes, securing data packets does require 
> probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g 
> APs).
>
> PatC
> On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:
>
>
>
> My thoughts exactly. It is very easy to configure the known peers on
> the AP, and if the peer's name is present in the certificate,
> validation can be done there. As far as certificate validation on
the
> AP, this is really no different from how most browsers work today.
> However, since most APs are not directly connected to the AR, they
> have access to the network. So there is no reason why a particular
> implementation could not validate a given AR's cert via whatever
local
> means are available.
>
> PatC
> -----Original Message-----
> From:	Rama krishna prasad [mailto:rkp@intotoinc.com] 
> Sent:	Tue 7/15/2003 8:45 PM
> To:	David Molnar
> Cc:	Clint Chaplin; lwapp@frascone.com 
> Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and
> validation.
> Hi,
>           x.509 certificates contain subject name (subject
alt-name).
> I feel,
>           this subject (alt) names can be used to identify the peer.
>           For example, AP can be preinstalled with X.509 certificate
> signed
>           by general CA or local CA server and also it can be
> pre-programmed
>           with the names of ARs that it should join. Similarly, AR
can
> be configured
>           with subject (alt) names of AP that it trusts. Validation
on
> allowing the
>           peer can be done during the 'Discovery' phase.
> Regards
> Rama Krishna Prasad
> Intoto Software(I)PVT Ltd
> PlotNo:15 New VasaviNagar,
> Secundrabad.
> INDIA-500015
>
>
>
> David Molnar wrote:
>
>
>
> On Mon, 14 Jul 2003, Clint Chaplin wrote:
>
>
>
>
>
> How is the AP supposed to validate the certificate presented to it
by
> the AR?  Is a certificate fingerprint going to have to be
> preinstalled
> in the AP, along with a certificate for the AP?
>
>
>
>
> I've been wondering the same thing. I think the issue goes even
> deeper.
> Suppose every AP and AR shipped with a global CA public key, such as
> VeriSign, in them, just like browsers do. So I can go to VeriSign
and
> register my AP and AR names. (N.B. I am *not* advocating we put
> VeriSign
> in every AP and AR...)
>
> Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone
> has a
> properly signed CA certificate attesting to their identity. Bob
cannot
> impersonate Charlie and vice versa. Every pair can create a shared
> secret
> without anyone else being able to listen in.
>
> The questions are
>
> 	"How does Alice know she should be with Bob and not Charlie?"
> 	"How does Bob know Alice should be with him?"
>
> and in the scenario just outlined, I don't see any good way to
answer
> those questions. Just having certificates, even "valid"
certificates,
> is
> not enough (unless you shove the association into the name of the
> certificate!). We need to think about how secure associations are
set
> up
> and validated. We should also think about whether setting up secure
> associations is within the purview of LWAPP or could be broken out
> into
> another protocol.
>
> I'm talking about these issues Friday at the BOF, for those who will
> be
> there. If you won't, I'll be happy to send you slides (once they're
> done).
>
> -David
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com 
> http://mail.frascone.com/mailman/listinfo/lwapp 
>
>
>
>
>
>
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com 
> http://mail.frascone.com/mailman/listinfo/lwapp 
>
>
>
>
>
>
>
>
>
>
>

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com 
http://mail.frascone.com/mailman/listinfo/lwapp 

________________________________________________________________________
This email has been scanned for computer viruses.

From rkp@intotoinc.com  Sun Jul 20 10:32:45 2003
From: rkp@intotoinc.com (Rama krishna prasad)
Date: Sun, 20 Jul 2003 15:02:45 +0530
Subject: [Lwapp] Certificates, Discovery Request/Reply, and	validation.
References: 
Message-ID: <3F1A61BD.3030509@intotoinc.com>

--------------060800040009050400010108
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

       Please note that authentication by AP to AR does not happen frequently.
      Only during the authentication phase, public key cryptography is used.
      At end of EAP phase, symmetric keys are produced and symmetric keys
      are used for per-packet authentication/ciphering. Symmetric cryptography
      is faster. Also note that, in cases where physical security between AP and
      AR is ensured, we can have an option where per-packet security is avoided.

      I don't see any issue w.r.t performance of AP due to above.
      
 Regards
 Rama Krishna Prasad
 Intoto Software (India) pvt Ltd.


Clint Chaplin wrote:

>There is going to be a tension to pull the standard in this direction. 
>My "problem" with that is that it's going to require even more
>processing power in the APs to implement some of the proposals, thus
>evolving the APs away from "Light Weight"
>
>
>Clint (JOATMON) Chaplin
>
>  
>
>>>>Rama krishna prasad  7/18/03 00:33:07 >>>
>>>>        
>>>>
>Hi all,
> 
> I have one more thought. Here, we are talking about AP and AR
>authenticating
>         mutually. Also, as part of this authentication, we are also
>thinking of
>         generating shared key which can be used to encrypt/generate
>ICV on per
>         packet basis to achieve confidentiality/authentication and
>anti-replay protection.
>         EAP based authentication and key exchange is becoming quite
>popular and
>         provides extensibility in user/device authentication methods. 
>802.1x uses this.
>         PPP extensions do this.  IKEv2 is incorporating this.
>         I think we also should think of using EAP based
>         user/device mutual authentication and session key generation.
>
>         LWAPP can have three phases and wherever possible we can think
>of using
>         existing protocols.
>
>          Phase1:
>                  Discovery of ARs.
>          Phase2:
>                  Mutual Authentication with Selected ARs (try out all
>ARs)
>                  Here, we can use EAP method.
>                  If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then
>session key
>                     can be generated for ciphering and per-packet
>authentication.
>                  In case of EAP-MD5, static key can be used.
>          Phase 3:
>                  Provisioning and configuration of AP, If needed,
>updating the image on AP
>                        and other AP management activities.
>                  Transferring data packets and management packets from
>AP to AR etc..
>               All phase 3 packets are secured based on session cipher
>and authentication keys.
>
>
>          For phase2:
>                PANA seems to be defining physical/link layer
>independent authentication mechanism.
>                That might be suitable here. Comments?
>         Regards
>         Rama Krishna Prasad
>         Intoto Software (India) Pvt Ltd.
>
>
>
>Rama krishna prasad wrote:
>
>  
>
>>Hi all,
>>
>>Certificate exchange should happen in 'Discovery' phase for this.
>>'Certificate' message element should be sent in 'Discovery' request
>>by the APs and ARs should send this message element in 'Discovery'
>>reply packets.
>>
>>lwapp-03.txt draft today sends 'Certificate' message element in
>>Join phase. This should be changed in the draft.
>>
>>Discover phase will happen this way:
>>AP sends Discover request with its certificate.
>>When ARs receive the request, they check their local configuration
>>    
>>
>and
>  
>
>>decide on whether this AP is allowed to join this AR. If it is
>>    
>>
>allowed, AR
>  
>
>>sends Discover reply with its certificate.
>>AP, upon receiving multiple 'Discover replies' selects the AR based
>>on its local configuration and then sends Join request to the selected
>>    
>>
>AR.
>  
>
>>On a different note:
>>Certificate is defined in PKCS5 format.
>>Is it not simple to send certificate in DER format? Typically
>>    
>>
>certificates
>  
>
>>are loaded in the box  (AP or AR) in either DER/PEM form. So, it makes
>>    
>>
>it simpler
>  
>
>>to send these X.509 certificates in this form?  Is there any specific
>>reason to select PKCS5 ( I had to admit, I don't know much about
>>PKCS5)?
>>
>>Regards
>>Rama Krishna Prasad
>>Intoto Software (India) Pvt Ltd
>>
>>
>>
>>Pat R. Calhoun wrote:
>>
>>    
>>
>>>>If I understand this correctly (the AP's are validating the AR's
>>>>        
>>>>
>cert), 
>  
>
>>>>then this implies that the AP will support RSA and/or DSA and 
>>>>SHA1and/or MD5. Is this correct?
>>>>   
>>>>
>>>>        
>>>>
>>>That is probably a safe assumption.
>>>
>>> 
>>>
>>>      
>>>
>>>>If so, this might help solve the ICV 
>>>>problem except perhaps a performance issue.
>>>>   
>>>>
>>>>        
>>>>
>>>You mean on the data path? Yes, securing data packets does require
>>>      
>>>
>probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g
>APs).
>  
>
>>>PatC 
>>>On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>My thoughts exactly. It is very easy to configure the known peers on
>>>>        
>>>>
>
>  
>
>>>>the AP, and if the peer's name is present in the certificate, 
>>>>validation can be done there. As far as certificate validation on
>>>>        
>>>>
>the 
>  
>
>>>>AP, this is really no different from how most browsers work today. 
>>>>However, since most APs are not directly connected to the AR, they 
>>>>have access to the network. So there is no reason why a particular 
>>>>implementation could not validate a given AR's cert via whatever
>>>>        
>>>>
>local 
>  
>
>>>>means are available.
>>>>
>>>>PatC
>>>>-----Original Message-----
>>>>From:	Rama krishna prasad [mailto:rkp@intotoinc.com] 
>>>>Sent:	Tue 7/15/2003 8:45 PM
>>>>To:	David Molnar
>>>>Cc:	Clint Chaplin; lwapp@frascone.com 
>>>>Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and 
>>>>validation.
>>>>Hi,
>>>>         x.509 certificates contain subject name (subject
>>>>        
>>>>
>alt-name).  
>  
>
>>>>I feel,
>>>>         this subject (alt) names can be used to identify the
>>>>        
>>>>
>peer.
>  
>
>>>>         For example, AP can be preinstalled with X.509 certificate
>>>>        
>>>>
>
>  
>
>>>>signed
>>>>         by general CA or local CA server and also it can be 
>>>>pre-programmed
>>>>         with the names of ARs that it should join. Similarly, AR
>>>>        
>>>>
>can 
>  
>
>>>>be configured
>>>>         with subject (alt) names of AP that it trusts. Validation
>>>>        
>>>>
>on 
>  
>
>>>>allowing the
>>>>         peer can be done during the 'Discovery' phase.
>>>>Regards
>>>>Rama Krishna Prasad
>>>>Intoto Software(I)PVT Ltd
>>>>PlotNo:15 New VasaviNagar,
>>>>Secundrabad.
>>>>INDIA-500015
>>>>
>>>>
>>>>
>>>>David Molnar wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>On Mon, 14 Jul 2003, Clint Chaplin wrote:
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>How is the AP supposed to validate the certificate presented to it
>>>>>>            
>>>>>>
>by
>  
>
>>>>>>the AR?  Is a certificate fingerprint going to have to be 
>>>>>>preinstalled
>>>>>>in the AP, along with a certificate for the AP?
>>>>>>
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>I've been wondering the same thing. I think the issue goes even 
>>>>>deeper.
>>>>>Suppose every AP and AR shipped with a global CA public key, such
>>>>>          
>>>>>
>as
>  
>
>>>>>VeriSign, in them, just like browsers do. So I can go to VeriSign
>>>>>          
>>>>>
>and
>  
>
>>>>>register my AP and AR names. (N.B. I am *not* advocating we put 
>>>>>VeriSign
>>>>>in every AP and AR...)
>>>>>
>>>>>Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone
>>>>>          
>>>>>
>
>  
>
>>>>>has a
>>>>>properly signed CA certificate attesting to their identity. Bob
>>>>>          
>>>>>
>cannot
>  
>
>>>>>impersonate Charlie and vice versa. Every pair can create a shared
>>>>>          
>>>>>
>
>  
>
>>>>>secret
>>>>>without anyone else being able to listen in.
>>>>>
>>>>>The questions are
>>>>>
>>>>>	"How does Alice know she should be with Bob and not Charlie?"
>>>>>	"How does Bob know Alice should be with him?"
>>>>>
>>>>>and in the scenario just outlined, I don't see any good way to
>>>>>          
>>>>>
>answer
>  
>
>>>>>those questions. Just having certificates, even "valid"
>>>>>          
>>>>>
>certificates, 
>  
>
>>>>>is
>>>>>not enough (unless you shove the association into the name of the
>>>>>certificate!). We need to think about how secure associations are
>>>>>          
>>>>>
>set 
>  
>
>>>>>up
>>>>>and validated. We should also think about whether setting up
>>>>>          
>>>>>
>secure
>  
>
>>>>>associations is within the purview of LWAPP or could be broken out
>>>>>          
>>>>>
>
>  
>
>>>>>into
>>>>>another protocol.
>>>>>
>>>>>I'm talking about these issues Friday at the BOF, for those who
>>>>>          
>>>>>
>will 
>  
>
>>>>>be
>>>>>there. If you won't, I'll be happy to send you slides (once they're
>>>>>          
>>>>>
>
>  
>
>>>>>done).
>>>>>
>>>>>-David
>>>>>_______________________________________________
>>>>>Lwapp mailing list
>>>>>Lwapp@frascone.com 
>>>>>http://mail.frascone.com/mailman/listinfo/lwapp 
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>Lwapp mailing list
>>>>Lwapp@frascone.com 
>>>>http://mail.frascone.com/mailman/listinfo/lwapp 
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>
>________________________________________________________________________
>This email has been scanned for computer viruses.
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>
>  
>


--------------060800040009050400010108
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  


Hi all,


       Please note that authentication by AP to AR does not happen frequently.
      Only during the authentication phase, public key cryptography is used.
      At end of EAP phase, symmetric keys are produced and symmetric keys
      are used for per-packet authentication/ciphering. Symmetric cryptography
      is faster. Also note that, in cases where physical security between AP and
      AR is ensured, we can have an option where per-packet security is avoided.

      I don't see any issue w.r.t performance of AP due to above.
      
 Regards
 Rama Krishna Prasad
 Intoto Software (India) pvt Ltd.



Clint Chaplin wrote:



  
There is going to be a tension to pull the standard in this direction. 
My "problem" with that is that it's going to require even more
processing power in the APs to implement some of the proposals, thus
evolving the APs away from "Light Weight"


Clint (JOATMON) Chaplin

  

  

    

      

        
Rama krishna prasad <rkp@intotoinc.com> 7/18/03 00:33:07 >>>
        

      

    

  

  
Hi all,
 
 I have one more thought. Here, we are talking about AP and AR
authenticating
         mutually. Also, as part of this authentication, we are also
thinking of
         generating shared key which can be used to encrypt/generate
ICV on per
         packet basis to achieve confidentiality/authentication and
anti-replay protection.
         EAP based authentication and key exchange is becoming quite
popular and
         provides extensibility in user/device authentication methods. 
802.1x uses this.
         PPP extensions do this.  IKEv2 is incorporating this.
         I think we also should think of using EAP based
         user/device mutual authentication and session key generation.

         LWAPP can have three phases and wherever possible we can think
of using
         existing protocols.

          Phase1:
                  Discovery of ARs.
          Phase2:
                  Mutual Authentication with Selected ARs (try out all
ARs)
                  Here, we can use EAP method.
                  If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then
session key
                     can be generated for ciphering and per-packet
authentication.
                  In case of EAP-MD5, static key can be used.
          Phase 3:
                  Provisioning and configuration of AP, If needed,
updating the image on AP
                        and other AP management activities.
                  Transferring data packets and management packets from
AP to AR etc..
               All phase 3 packets are secured based on session cipher
and authentication keys.


          For phase2:
                PANA seems to be defining physical/link layer
independent authentication mechanism.
                That might be suitable here. Comments?
         Regards
         Rama Krishna Prasad
         Intoto Software (India) Pvt Ltd.



Rama krishna prasad wrote:

  

  

    
Hi all,

Certificate exchange should happen in 'Discovery' phase for this.
'Certificate' message element should be sent in 'Discovery' request
by the APs and ARs should send this message element in 'Discovery'
reply packets.

lwapp-03.txt draft today sends 'Certificate' message element in
Join phase. This should be changed in the draft.

Discover phase will happen this way:
AP sends Discover request with its certificate.
When ARs receive the request, they check their local configuration
    

  

  
and
  

  

    
decide on whether this AP is allowed to join this AR. If it is
    

  

  
allowed, AR
  

  

    
sends Discover reply with its certificate.
AP, upon receiving multiple 'Discover replies' selects the AR based
on its local configuration and then sends Join request to the selected
    

  

  
AR.
  

  

    
On a different note:
Certificate is defined in PKCS5 format.
Is it not simple to send certificate in DER format? Typically
    

  

  
certificates
  

  

    
are loaded in the box  (AP or AR) in either DER/PEM form. So, it makes
    

  

  
it simpler
  

  

    
to send these X.509 certificates in this form?  Is there any specific
reason to select PKCS5 ( I had to admit, I don't know much about
PKCS5)?

Regards
Rama Krishna Prasad
Intoto Software (India) Pvt Ltd



Pat R. Calhoun wrote:

    

    

      

        
If I understand this correctly (the AP's are validating the AR's
        

      

    

  

  
cert), 
  

  

    

      

        
then this implies that the AP will support RSA and/or DSA and 
SHA1and/or MD5. Is this correct?
   

        

      

      
That is probably a safe assumption.

 

      

      

        
If so, this might help solve the ICV 
problem except perhaps a performance issue.
   

        

      

      
You mean on the data path? Yes, securing data packets does require
      

    

  

  
probably more CPU cycles than any AP I know of (esp. tri-mode a/b/g
APs).
  

  

    

      
PatC 
On Thursday, July 17, 2003, at 04:11 AM, Pat R. Calhoun wrote:

 

      

      

        
My thoughts exactly. It is very easy to configure the known peers on
        

      

    

  

  

  

  

    

      

        
the AP, and if the peer's name is present in the certificate, 
validation can be done there. As far as certificate validation on
        

      

    

  

  
the 
  

  

    

      

        
AP, this is really no different from how most browsers work today. 
However, since most APs are not directly connected to the AR, they 
have access to the network. So there is no reason why a particular 
implementation could not validate a given AR's cert via whatever
        

      

    

  

  
local 
  

  

    

      

        
means are available.

PatC
-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com] 
Sent:	Tue 7/15/2003 8:45 PM
To:	David Molnar
Cc:	Clint Chaplin; lwapp@frascone.com 
Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and 
validation.
Hi,
         x.509 certificates contain subject name (subject
        

      

    

  

  
alt-name).  
  

  

    

      

        
I feel,
         this subject (alt) names can be used to identify the
        

      

    

  

  
peer.
  

  

    

      

        
         For example, AP can be preinstalled with X.509 certificate
        

      

    

  

  

  

  

    

      

        
signed
         by general CA or local CA server and also it can be 
pre-programmed
         with the names of ARs that it should join. Similarly, AR
        

      

    

  

  
can 
  

  

    

      

        
be configured
         with subject (alt) names of AP that it trusts. Validation
        

      

    

  

  
on 
  

  

    

      

        
allowing the
         peer can be done during the 'Discovery' phase.
Regards
Rama Krishna Prasad
Intoto Software(I)PVT Ltd
PlotNo:15 New VasaviNagar,
Secundrabad.
INDIA-500015



David Molnar wrote:

   

        

        

          
On Mon, 14 Jul 2003, Clint Chaplin wrote:



     

          

          

            
How is the AP supposed to validate the certificate presented to it
            

          

        

      

    

  

  
by
  

  

    

      

        

          

            
the AR?  Is a certificate fingerprint going to have to be 
preinstalled
in the AP, along with a certificate for the AP?


       

            

          

          
I've been wondering the same thing. I think the issue goes even 
deeper.
Suppose every AP and AR shipped with a global CA public key, such
          

        

      

    

  

  
as
  

  

    

      

        

          
VeriSign, in them, just like browsers do. So I can go to VeriSign
          

        

      

    

  

  
and
  

  

    

      

        

          
register my AP and AR names. (N.B. I am *not* advocating we put 
VeriSign
in every AP and AR...)

Now what if we have AP Alice and two ARs, Bob and Charlie. Everyone
          

        

      

    

  

  

  

  

    

      

        

          
has a
properly signed CA certificate attesting to their identity. Bob
          

        

      

    

  

  
cannot
  

  

    

      

        

          
impersonate Charlie and vice versa. Every pair can create a shared
          

        

      

    

  

  

  

  

    

      

        

          
secret
without anyone else being able to listen in.

The questions are

	"How does Alice know she should be with Bob and not Charlie?"
	"How does Bob know Alice should be with him?"

and in the scenario just outlined, I don't see any good way to
          

        

      

    

  

  
answer
  

  

    

      

        

          
those questions. Just having certificates, even "valid"
          

        

      

    

  

  
certificates, 
  

  

    

      

        

          
is
not enough (unless you shove the association into the name of the
certificate!). We need to think about how secure associations are
          

        

      

    

  

  
set 
  

  

    

      

        

          
up
and validated. We should also think about whether setting up
          

        

      

    

  

  
secure
  

  

    

      

        

          
associations is within the purview of LWAPP or could be broken out
          

        

      

    

  

  

  

  

    

      

        

          
into
another protocol.

I'm talking about these issues Friday at the BOF, for those who
          

        

      

    

  

  
will 
  

  

    

      

        

          
be
there. If you won't, I'll be happy to send you slides (once they're
          

        

      

    

  

  

  

  

    

      

        

          
done).

-David
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com 
http://mail.frascone.com/mailman/listinfo/lwapp 



     

          

        

        
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com 
http://mail.frascone.com/mailman/listinfo/lwapp 

   

        

      

      


 

      

    

  

  



________________________________________________________________________
This email has been scanned for computer viruses.
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

  








--------------060800040009050400010108--


From idir.fodil@proxy.6wind.com  Mon Jul 21 14:00:50 2003
From: idir.fodil@proxy.6wind.com (idir fodil)
Date: Mon, 21 Jul 2003 15:00:50 +0200
Subject: [Lwapp] LWAPP Implementation
Message-ID: <3F1BE402.1060501@proxy.6wind.com>

Hy every body ,
I want to know if there is APs and Routers or Switches that support 
LWAPP protocol

thank you for informations


Idir Bahaa FODIL
R&D Team


From rkp@intotoinc.com  Tue Jul 22 04:47:26 2003
From: rkp@intotoinc.com (Rama krishna prasad)
Date: Tue, 22 Jul 2003 09:17:26 +0530
Subject: [Lwapp] Broadcast/Multicast packet flow
Message-ID: <3F1CB3CE.4050409@intotoinc.com>

Hi,
          I am trying to understand the packet flow between wireless stations
          and AR with several APs in between. Appreciate your feedback.
          
          Assumptions:
               Only Layer2 wireless switching with 802.1x key management and
               authentication in this deployment.
               Given SSID (network) is supported by multiple APs.

          Unicast traffic between wireless station1 to wireless station 2 belonging to
              the same AP and SSID:
                  - AP receives the packet from station 1.
                  - AP de-ciphers it.
                  - Since it is data packet, it encapsulates with LWAPP header and 
                         apply any security on the packet and send it over to AR.
                  -  AR de-capsulate and removes LWAPP header/802.11 header and validates
                        whether this station is successfully authenticated or not.
                  - Then it finds out that this packet has to go same AP, based on the destination
                     MAC address in 802.3 packet. AR encapsulates the packet with 802.11 
                     and LWAPP header and applies any security needed between AR and AP.
                 -   AP receives it, decapsulates the LWAPP header.
                 -   AP encrypts the packet with TKIP RC4/RSN unicast key and passes it onto the
                       destination station.

           Unicast traffic between wireless stations 1 of AP 1 TO wireless station 2 of AP 2 and
                    stations belong to same SSID.
                   - AP1 receives the 802.11 encapsulated 802.3 packet from wireless station 1.
                   - AP1 de-cipher it using unicast cipher key.
                   - AP1 encapsulates the 802.11 packet with LWAPP header and sends over to the AR.
                          It applies ciphering/authentication based on AR-AP security.
                   - AR receives the packet and validates the authentication of the station.
                   - AR finds out this destination MAC address belongs to some other AP and sends
                        the packet to that AP after encapsulating with 802.11 and LWAPP headers.
                   - AP2 receives the packet and applies any unicast ciphering and sends the packet to
                      destination station.

           Broadcast traffic from a wireless station to all stations of that network (SSID):
                  -  Corresponding AP receives the broadcast packet from the station.
                  -   It decrypts using global cipher key.
                  -   Passes this packet onto AR after encapsulating with LWAPP.
                  -   AR receives the packet and validates it.
                  -  AR now should find out all APs corresponding to the same SSID.
                  -   For each AP
                           AR encapsulates the packet with 802.11 and LWAPP header
                              and send it over to the AP.
                           AP decapsulates the LWAPP header and applies global cipher key and sends
                                the packet to air.
               
          Is that the flow envisages as part of LWAPP?
 Thanks
 Rama Krishna Prasad
 Intoto Software (India) Pvt Ltd.



From Marcus Brunner   Tue Jul 22 09:38:36 2003
From: Marcus Brunner  (Marcus Brunner)
Date: Tue, 22 Jul 2003 10:38:36 +0200
Subject: [Lwapp] Charter Proposal
In-Reply-To: <007501c34cf1$95eaacc0$ab6015ac@dclkempt40>
References: <007501c34cf1$95eaacc0$ab6015ac@dclkempt40>
Message-ID: <2052821.1058870316@[10.1.1.130]>

> Develop a protocol controlling wireless access points with the following
> features:
>
> .Independent of wireless link protocol.
> .Discovery of a CAPWAP manager (AR, IP addressable switch).

I would not include this. SLP and DHCP might just work

> .Acquisition of APs by CAPWAP manager.

I am not sure I understand that functionaliy.

> .Configuration and monitoring of wireless link by CAPWAP manager.

What is the timescale for what you call Configuration and Monitoring.
For example the add/remove user configuration is something I see as 
performance critical an therefore does not fit into SNMP, but statistics 
monitoring is a task where SNMP works quite well. I proposed to use SNMP. 
(A MIB for the CapWap protocol must be designed anyway as soon as the 
protocol get further (Draft standard)

> .Partially and/or fully terminate the wireless MAC layer at the CAPWAP
> manager.
>        -Including security of host traffic.
>        -NOT intended to define changes in MAC!
> .Control of AP host load.
> .Security for CAPWAP signaling.

Marcus

> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp



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

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus





From esadot@avaya.com  Tue Jul 22 13:21:58 2003
From: esadot@avaya.com (Sadot, Emek (Emek))
Date: Tue, 22 Jul 2003 15:21:58 +0300
Subject: [Lwapp] Broadcast/Multicast packet flow
Message-ID: 

Rama,

I lack to see the difference between the first two scenarios. Besides =
the destination-MAC-to-AP-mapping stage, which takes place at the AR, =
the sequence of events should be identical regardless destination =
station position (associated to same AP as the source or not).

I am not sure what is the proposed architecture in regard to broadcast, =
however encapsulating each packet and send it as a unicast to =
corresponds AP sounds to me as unacceptable solution. That's where =
handling 802.11 packets at the AR is a disadvantage.

The case is different if the source station crossed VLAN domain while =
roamed or if destination station had crossed VLAN domain while roamed.

Emek=20

-----Original Message-----
From: Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent: Tuesday, 22 July, 2003 6:47 AM
To: lwapp@frascone.com
Subject: [Lwapp] Broadcast/Multicast packet flow

Hi,
          I am trying to understand the packet flow between wireless =
stations
          and AR with several APs in between. Appreciate your feedback.
        =20
          Assumptions:
               Only Layer2 wireless switching with 802.1x key management =
and
               authentication in this deployment.
               Given SSID (network) is supported by multiple APs.

          Unicast traffic between wireless station1 to wireless station =
2 belonging to
              the same AP and SSID:
                  - AP receives the packet from station 1.
                  - AP de-ciphers it.
                  - Since it is data packet, it encapsulates with LWAPP =
header and
                         apply any security on the packet and send it =
over to AR.
                  -  AR de-capsulate and removes LWAPP header/802.11 =
header and validates
                        whether this station is successfully =
authenticated or not.
                  - Then it finds out that this packet has to go same =
AP, based on the destination
                     MAC address in 802.3 packet. AR encapsulates the =
packet with 802.11
                     and LWAPP header and applies any security needed =
between AR and AP.
                 -   AP receives it, decapsulates the LWAPP header.
                 -   AP encrypts the packet with TKIP RC4/RSN unicast =
key and passes it onto the
                       destination station.

           Unicast traffic between wireless stations 1 of AP 1 TO =
wireless station 2 of AP 2 and
                    stations belong to same SSID.
                   - AP1 receives the 802.11 encapsulated 802.3 packet =
from wireless station 1.
                   - AP1 de-cipher it using unicast cipher key.
                   - AP1 encapsulates the 802.11 packet with LWAPP =
header and sends over to the AR.
                          It applies ciphering/authentication based on =
AR-AP security.
                   - AR receives the packet and validates the =
authentication of the station.
                   - AR finds out this destination MAC address belongs =
to some other AP and sends
                        the packet to that AP after encapsulating with =
802.11 and LWAPP headers.
                   - AP2 receives the packet and applies any unicast =
ciphering and sends the packet to
                      destination station.

           Broadcast traffic from a wireless station to all stations of =
that network (SSID):
                  -  Corresponding AP receives the broadcast packet from =
the station.
                  -   It decrypts using global cipher key.
                  -   Passes this packet onto AR after encapsulating =
with LWAPP.
                  -   AR receives the packet and validates it.
                  -  AR now should find out all APs corresponding to the =
same SSID.
                  -   For each AP
                           AR encapsulates the packet with 802.11 and =
LWAPP header
                              and send it over to the AP.
                           AP decapsulates the LWAPP header and applies =
global cipher key and sends
                                the packet to air.
             =20
          Is that the flow envisages as part of LWAPP?
 Thanks
 Rama Krishna Prasad
 Intoto Software (India) Pvt Ltd.


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

From pcalhoun@airespace.com  Tue Jul 22 14:02:14 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 06:02:14 -0700
Subject: [Lwapp] Broadcast/Multicast packet flow
Message-ID: <40301581B2962B448690A023EF16DFE1DC526E@bsn-mail-01.bstormnetworks.com>

sounds right.

PatC
-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent:	Mon 7/21/2003 8:47 PM
To:	lwapp@frascone.com
Cc:=09
Subject:	[Lwapp] Broadcast/Multicast packet flow
Hi,
          I am trying to understand the packet flow between wireless =
stations
          and AR with several APs in between. Appreciate your feedback.
         =20
          Assumptions:
               Only Layer2 wireless switching with 802.1x key management =
and
               authentication in this deployment.
               Given SSID (network) is supported by multiple APs.

          Unicast traffic between wireless station1 to wireless station =
2 belonging to
              the same AP and SSID:
                  - AP receives the packet from station 1.
                  - AP de-ciphers it.
                  - Since it is data packet, it encapsulates with LWAPP =
header and=20
                         apply any security on the packet and send it =
over to AR.
                  -  AR de-capsulate and removes LWAPP header/802.11 =
header and validates
                        whether this station is successfully =
authenticated or not.
                  - Then it finds out that this packet has to go same =
AP, based on the destination
                     MAC address in 802.3 packet. AR encapsulates the =
packet with 802.11=20
                     and LWAPP header and applies any security needed =
between AR and AP.
                 -   AP receives it, decapsulates the LWAPP header.
                 -   AP encrypts the packet with TKIP RC4/RSN unicast =
key and passes it onto the
                       destination station.

           Unicast traffic between wireless stations 1 of AP 1 TO =
wireless station 2 of AP 2 and
                    stations belong to same SSID.
                   - AP1 receives the 802.11 encapsulated 802.3 packet =
from wireless station 1.
                   - AP1 de-cipher it using unicast cipher key.
                   - AP1 encapsulates the 802.11 packet with LWAPP =
header and sends over to the AR.
                          It applies ciphering/authentication based on =
AR-AP security.
                   - AR receives the packet and validates the =
authentication of the station.
                   - AR finds out this destination MAC address belongs =
to some other AP and sends
                        the packet to that AP after encapsulating with =
802.11 and LWAPP headers.
                   - AP2 receives the packet and applies any unicast =
ciphering and sends the packet to
                      destination station.

           Broadcast traffic from a wireless station to all stations of =
that network (SSID):
                  -  Corresponding AP receives the broadcast packet from =
the station.
                  -   It decrypts using global cipher key.
                  -   Passes this packet onto AR after encapsulating =
with LWAPP.
                  -   AR receives the packet and validates it.
                  -  AR now should find out all APs corresponding to the =
same SSID.
                  -   For each AP
                           AR encapsulates the packet with 802.11 and =
LWAPP header
                              and send it over to the AP.
                           AP decapsulates the LWAPP header and applies =
global cipher key and sends
                                the packet to air.
              =20
          Is that the flow envisages as part of LWAPP?
 Thanks
 Rama Krishna Prasad
 Intoto Software (India) Pvt Ltd.


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp




From pcalhoun@airespace.com  Tue Jul 22 14:03:41 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 06:03:41 -0700
Subject: [Lwapp] Broadcast/Multicast packet flow
Message-ID: <40301581B2962B448690A023EF16DFE1DC526F@bsn-mail-01.bstormnetworks.com>

Actually, we send our broadcast packets as multicast to all APs, not =
unicast. This handles that problem, but does NOT work with a layer 3 =
interface between the switch and the APs, when across subnets. So for =
people that are looking at IP between the two peers, lots of broadcast =
replication is required :(

PatC
-----Original Message-----
From:	Sadot, Emek (Emek) [mailto:esadot@avaya.com]
Sent:	Tue 7/22/2003 5:21 AM
To:	lwapp@frascone.com
Cc:=09
Subject:	RE: [Lwapp] Broadcast/Multicast packet flow
Rama,

I lack to see the difference between the first two scenarios. Besides =
the destination-MAC-to-AP-mapping stage, which takes place at the AR, =
the sequence of events should be identical regardless destination =
station position (associated to same AP as the source or not).

I am not sure what is the proposed architecture in regard to broadcast, =
however encapsulating each packet and send it as a unicast to =
corresponds AP sounds to me as unacceptable solution. That's where =
handling 802.11 packets at the AR is a disadvantage.

The case is different if the source station crossed VLAN domain while =
roamed or if destination station had crossed VLAN domain while roamed.

Emek=20

-----Original Message-----
From: Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent: Tuesday, 22 July, 2003 6:47 AM
To: lwapp@frascone.com
Subject: [Lwapp] Broadcast/Multicast packet flow

Hi,
          I am trying to understand the packet flow between wireless =
stations
          and AR with several APs in between. Appreciate your feedback.
        =20
          Assumptions:
               Only Layer2 wireless switching with 802.1x key management =
and
               authentication in this deployment.
               Given SSID (network) is supported by multiple APs.

          Unicast traffic between wireless station1 to wireless station =
2 belonging to
              the same AP and SSID:
                  - AP receives the packet from station 1.
                  - AP de-ciphers it.
                  - Since it is data packet, it encapsulates with LWAPP =
header and
                         apply any security on the packet and send it =
over to AR.
                  -  AR de-capsulate and removes LWAPP header/802.11 =
header and validates
                        whether this station is successfully =
authenticated or not.
                  - Then it finds out that this packet has to go same =
AP, based on the destination
                     MAC address in 802.3 packet. AR encapsulates the =
packet with 802.11
                     and LWAPP header and applies any security needed =
between AR and AP.
                 -   AP receives it, decapsulates the LWAPP header.
                 -   AP encrypts the packet with TKIP RC4/RSN unicast =
key and passes it onto the
                       destination station.

           Unicast traffic between wireless stations 1 of AP 1 TO =
wireless station 2 of AP 2 and
                    stations belong to same SSID.
                   - AP1 receives the 802.11 encapsulated 802.3 packet =
from wireless station 1.
                   - AP1 de-cipher it using unicast cipher key.
                   - AP1 encapsulates the 802.11 packet with LWAPP =
header and sends over to the AR.
                          It applies ciphering/authentication based on =
AR-AP security.
                   - AR receives the packet and validates the =
authentication of the station.
                   - AR finds out this destination MAC address belongs =
to some other AP and sends
                        the packet to that AP after encapsulating with =
802.11 and LWAPP headers.
                   - AP2 receives the packet and applies any unicast =
ciphering and sends the packet to
                      destination station.

           Broadcast traffic from a wireless station to all stations of =
that network (SSID):
                  -  Corresponding AP receives the broadcast packet from =
the station.
                  -   It decrypts using global cipher key.
                  -   Passes this packet onto AR after encapsulating =
with LWAPP.
                  -   AR receives the packet and validates it.
                  -  AR now should find out all APs corresponding to the =
same SSID.
                  -   For each AP
                           AR encapsulates the packet with 802.11 and =
LWAPP header
                              and send it over to the AP.
                           AP decapsulates the LWAPP header and applies =
global cipher key and sends
                                the packet to air.
             =20
          Is that the flow envisages as part of LWAPP?
 Thanks
 Rama Krishna Prasad
 Intoto Software (India) Pvt Ltd.


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp




From dmolnar@legra.com  Tue Jul 22 16:08:42 2003
From: dmolnar@legra.com (David Molnar)
Date: Tue, 22 Jul 2003 11:08:42 -0400
Subject: [Lwapp] Security requirements for LWAPP?
References: 
Message-ID: <018b01c35063$23b2a340$b90ba8c0@student.harvard.edu>

> We've been talking about the best way to protect the LWAPP packets, and
> I just wanted to do a quick check on what people feel are the
> requirements.
>
> Here's a quick view from myself:
>
> Authentication: AP to AR and AR to AP (counters masquerading AR's and
> rogue AP's)

Yes.

> Integrity: All packets (prevents injections and modification attacks)

Yes.

> Confidentiality: Not sure if this is needed

Not necessary for user data traffic, but necessary if AR sends key material
to AP.

> Key Management: Something beyond EAPoL-key needed?

Yes.

I think of the AR-AP communication as split into three streams:

    1) Session management
    2) Radio control
    3) User data

1) and 2) need specific protection from LWAPP (and corresponding key
management), but 3) may be the reponsibility of WPA/802.11i or IPsec.

-David



From alper@docomolabs-usa.com  Tue Jul 22 17:03:24 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Tue, 22 Jul 2003 09:03:24 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <3F17A2B3.8070104@intotoinc.com>
Message-ID: 

>         Phase2:
>                 Mutual Authentication with Selected ARs (try out all ARs)
>                 Here, we can use EAP method.
>                 If EAP-TLS, EAP-TTLS or EAP-PEAP is used, then session key
>                    can be generated for ciphering and per-packet
> authentication.
>                 In case of EAP-MD5, static key can be used.

...

>         For phase2:
>               PANA seems to be defining physical/link layer independent
> authentication mechanism.
>               That might be suitable here. Comments?

In the current deployments the security between the AP and AR relies on
physical measures. As I understand, we don't want to make this assumption in
here. In that case, yes, PANA can be used for authentication and
authorization between the APs and ARs. By using an appropriate EAP method
(e.g., EAP-TLS) cryptographic keys can be produced that are used to
establish a protected channel between AP and AR. This ensures all the
signaling and data traffic is secured.

Alper


From pcalhoun@airespace.com  Tue Jul 22 19:39:46 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 11:39:46 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC527C@bsn-mail-01.bstormnetworks.com>

>>         For phase2:
>>               PANA seems to be defining physical/link layer =
independent
>> authentication mechanism.
>>               That might be suitable here. Comments?
>
>In the current deployments the security between the AP and AR relies on
>physical measures. As I understand, we don't want to make this =
assumption in
>here. In that case, yes, PANA can be used for authentication and
>authorization between the APs and ARs. By using an appropriate EAP =
method
>(e.g., EAP-TLS) cryptographic keys can be produced that are used to
>establish a protected channel between AP and AR. This ensures all the
>signaling and data traffic is secured.

So how does the AP know that 802.1x will be required for a given mobile? =
How does the AP get the 802.1x keys that it must use with the mobile? =
How does the AR handle load balancing? How does the AR handle 802.11e =
and 802.11i, or should the AP do it? What about 802.11h? What about =
802.11k?

You see, the PANA architecture really only touches the tip of the =
iceberg. Moving towards a LWAPP architecture solves these issues, and =
significantly reduces the amount of protocol work required between the =
AP and the AR (because 802.11 terminates in the AR, so 802.11 *is* the =
protocol).

We seem to be focused on EAP only, but again, I think the problem is =
much greater in scope - hence CAPWAP.

PatC

From yohba@tari.toshiba.com  Mon Jul 21 15:42:28 2003
From: yohba@tari.toshiba.com (Yoshihiro Ohba)
Date: Mon, 21 Jul 2003 07:42:28 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC527C@bsn-mail-01.bstormnetworks.com>
References: <40301581B2962B448690A023EF16DFE1DC527C@bsn-mail-01.bstormnetworks.com>
Message-ID: <20030721144228.GA3959@steelhead>

On Tue, Jul 22, 2003 at 11:39:46AM -0700, Pat R. Calhoun wrote:
> >>         For phase2:
> >>               PANA seems to be defining physical/link layer independent
> >> authentication mechanism.
> >>               That might be suitable here. Comments?
> >
> >In the current deployments the security between the AP and AR relies on
> >physical measures. As I understand, we don't want to make this assumption in
> >here. In that case, yes, PANA can be used for authentication and
> >authorization between the APs and ARs. By using an appropriate EAP method
> >(e.g., EAP-TLS) cryptographic keys can be produced that are used to
> >establish a protected channel between AP and AR. This ensures all the
> >signaling and data traffic is secured.
> 
> So how does the AP know that 802.1x will be required for a given mobile? How does the AP get the 802.1x keys that it must use with the mobile? How does the AR handle load balancing? How does the AR handle 802.11e and 802.11i, or should the AP do it? What about 802.11h? What about 802.11k?
> 
> You see, the PANA architecture really only touches the tip of the iceberg. Moving towards a LWAPP architecture solves these issues, and significantly reduces the amount of protocol work required between the AP and the AR (because 802.11 terminates in the AR, so 802.11 *is* the protocol).
> 
> We seem to be focused on EAP only, but again, I think the problem is much greater in scope - hence CAPWAP.

It is curious to see a lot of IEEE 802 specific technologies mentioned
here.  Why not discuss this issue in IEEE 802?

> 
> PatC
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp


Yoshihiro Ohba

From Basavaraj.Patil@nokia.com  Tue Jul 22 20:15:00 2003
From: Basavaraj.Patil@nokia.com (Basavaraj.Patil@nokia.com)
Date: Tue, 22 Jul 2003 14:15:00 -0500
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB44B@daebe007.americas.nokia.com>

Pat,

> So how does the AP know that 802.1x will be required for a=20
> given mobile?

Why does the AP need to know this? The AP needs to be capable
of authenticating a station irrespective of whether it is=20
802.1x capable or not (HTTP redirect).

> How does the AP get the 802.1x keys that it=20
> must use with the mobile? How does the AR handle load=20
> balancing? How does the AR handle 802.11e and 802.11i, or=20
> should the AP do it? What about 802.11h? What about 802.11k?

Hmmm... At least PANA does not have any goals or objectives of
dealing with all these issues.

>=20
> You see, the PANA architecture really only touches the tip of=20
> the iceberg. Moving towards a LWAPP architecture solves these=20
> issues, and significantly reduces the amount of protocol work=20
> required between the AP and the AR (because 802.11 terminates=20
> in the AR, so 802.11 *is* the protocol).
>=20
> We seem to be focused on EAP only, but again, I think the=20
> problem is much greater in scope - hence CAPWAP.

I missed the CAPWAP BOF at IETF57. Is there an issue w.r.t the
scope of PANA and CAPWAP? The thread seems to indicate that to be
the case. The CAPWAP objective may be to solve a greater set of
problems for 802.* networks. PANA is not a solution that is specific
to 802.* networks. There may be overlap in functionality but=20
I dont think that is necessarily a problem.

>=20
> PatC

-Basavaraj


From pcalhoun@airespace.com  Tue Jul 22 20:37:16 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 12:37:16 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC5281@bsn-mail-01.bstormnetworks.com>

>> We seem to be focused on EAP only, but again, I think the problem is =
much >>greater in scope - hence CAPWAP.

>It is curious to see a lot of IEEE 802 specific technologies mentioned
>here.  Why not discuss this issue in IEEE 802?

We talked about this at the meeting. We are NOT touching any of the =
802.11 protocols. What we do must work with ALL IEEE 802.11 standards, =
hence the LWAPP architecture.

Dorothy had lots to talk about why IEEE 802 doesn't need/want to touch =
this work, but I can let her answer since she is the IEEE liason.

PatC

From pcalhoun@airespace.com  Tue Jul 22 20:48:09 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 12:48:09 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC5282@bsn-mail-01.bstormnetworks.com>

>> So how does the AP know that 802.1x will be required for a=20
>> given mobile?
>
> Why does the AP need to know this? The AP needs to be capable
> of authenticating a station irrespective of whether it is=20
> 802.1x capable or not (HTTP redirect).

well, clearly a policy needs to be satisfied before the user is granted =
access. Further, if 802.1x is required, then the AP needs to know =
because the beacons over the air must indicate that encryption will be =
required (here I am assuming 802.11 because the AP MUST be involved in =
encryption in the PANA architecture, so there is a message required from =
the AR to the AP with the specific keys, which of course needs to be =
secured).

So if you have two SSIDs (one for 802.1x and one for HTTP redirect), you =
need two SSIDs (or one SSID advertised in two different ways), probably =
with different BSSIDs in order to really interoperate with today's =
clients.

>> How does the AP get the 802.1x keys that it=20
>> must use with the mobile? How does the AR handle load=20
>> balancing? How does the AR handle 802.11e and 802.11i, or=20
>> should the AP do it? What about 802.11h? What about 802.11k?
>
> Hmmm... At least PANA does not have any goals or objectives of
> dealing with all these issues.

correct. hence the biggest difference between PANA and LWAPP/CAPWAP.

>>=20
>> You see, the PANA architecture really only touches the tip of=20
>> the iceberg. Moving towards a LWAPP architecture solves these=20
>> issues, and significantly reduces the amount of protocol work=20
>> required between the AP and the AR (because 802.11 terminates=20
>> in the AR, so 802.11 *is* the protocol).
>>=20
>> We seem to be focused on EAP only, but again, I think the=20
>> problem is much greater in scope - hence CAPWAP.
>
> I missed the CAPWAP BOF at IETF57. Is there an issue w.r.t the
> scope of PANA and CAPWAP? The thread seems to indicate that to be
> the case.

yes, a point raised numerous times by Alper.

> The CAPWAP objective may be to solve a greater set of
> problems for 802.* networks. PANA is not a solution that is specific
> to 802.* networks. There may be overlap in functionality but=20
> I dont think that is necessarily a problem.

ok

PatC

From alper@docomolabs-usa.com  Tue Jul 22 21:38:25 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Tue, 22 Jul 2003 13:38:25 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC527C@bsn-mail-01.bstormnetworks.com>
Message-ID: 

>>>         For phase2:
>>>               PANA seems to be defining physical/link layer independent
>>> authentication mechanism.
>>>               That might be suitable here. Comments?
>> 
>> In the current deployments the security between the AP and AR relies on
>> physical measures. As I understand, we don't want to make this assumption in
>> here. In that case, yes, PANA can be used for authentication and
>> authorization between the APs and ARs. By using an appropriate EAP method
>> (e.g., EAP-TLS) cryptographic keys can be produced that are used to
>> establish a protected channel between AP and AR. This ensures all the
>> signaling and data traffic is secured.
> 
> So how does the AP know that 802.1x will be required for a given mobile? How
> does the AP get the 802.1x keys that it must use with the mobile? How does the
> AR handle load balancing? How does the AR handle 802.11e and 802.11i, or
> should the AP do it? What about 802.11h? What about 802.11k?

What does any of these have to do with what we are talking about here:
establishing trust and a secure channel between the AP and AR.


> 
> You see, the PANA architecture really only touches the tip of the iceberg.
> Moving towards a LWAPP architecture solves these issues, and significantly
> reduces the amount of protocol work required between the AP and the AR
> (because 802.11 terminates in the AR, so 802.11 *is* the protocol).

I'm not comparing PANA with LWAPP. This does not make sense. LWAPP is more
like an architecture that tackles several problems. I'm trying to understand
what each one of these problems are and see if there are alternative
solutions that should be considered.

PANA comes into the picture when we talk about the AAA between hosts and AR,
and AA_ between the AP and AR. I don't see PANA's relevance to all the other
bells and whistles LWAPP provides.

> 
> We seem to be focused on EAP only, but again, I think the problem is much
> greater in scope - hence CAPWAP.
> 

Is there a documented list of problems, like a problem statement? It is
really hard to reverse engineer the LWAPP to undertsand the problems we are
solving here.

Alper


From alper@docomolabs-usa.com  Tue Jul 22 21:45:16 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Tue, 22 Jul 2003 13:45:16 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5282@bsn-mail-01.bstormnetworks.com>
Message-ID: 

>>> So how does the AP know that 802.1x will be required for a
>>> given mobile?
>> 
>> Why does the AP need to know this? The AP needs to be capable
>> of authenticating a station irrespective of whether it is
>> 802.1x capable or not (HTTP redirect).
> 
> well, clearly a policy needs to be satisfied before the user is granted
> access. Further, if 802.1x is required, then the AP needs to know because the
> beacons over the air must indicate that encryption will be required (here I am
> assuming 802.11 because the AP MUST be involved in encryption in the PANA
> architecture, so there is a message required from the AR to the AP with the
> specific keys, which of course needs to be secured).

PANA protocol does not state that AP MUST be the encryption end point. PANA
can be used in architectures where AR is the encryption end-point.

Other things you are talking about above is related to configuring APs. Yes,
PANA does not do that. If you remember my earlier e-mails, I was asking why
not do this using SNMP.

> 
> So if you have two SSIDs (one for 802.1x and one for HTTP redirect), you need
> two SSIDs (or one SSID advertised in two different ways), probably with
> different BSSIDs in order to really interoperate with today's clients.
> 
>>> How does the AP get the 802.1x keys that it
>>> must use with the mobile? How does the AR handle load
>>> balancing? How does the AR handle 802.11e and 802.11i, or
>>> should the AP do it? What about 802.11h? What about 802.11k?
>> 
>> Hmmm... At least PANA does not have any goals or objectives of
>> dealing with all these issues.
> 
> correct. hence the biggest difference between PANA and LWAPP/CAPWAP.
> 
>>> 
>>> You see, the PANA architecture really only touches the tip of
>>> the iceberg. Moving towards a LWAPP architecture solves these
>>> issues, and significantly reduces the amount of protocol work
>>> required between the AP and the AR (because 802.11 terminates
>>> in the AR, so 802.11 *is* the protocol).
>>> 
>>> We seem to be focused on EAP only, but again, I think the
>>> problem is much greater in scope - hence CAPWAP.
>> 
>> I missed the CAPWAP BOF at IETF57. Is there an issue w.r.t the
>> scope of PANA and CAPWAP? The thread seems to indicate that to be
>> the case.
> 
> yes, a point raised numerous times by Alper.
> 
>> The CAPWAP objective may be to solve a greater set of
>> problems for 802.* networks. PANA is not a solution that is specific
>> to 802.* networks. There may be overlap in functionality but
>> I dont think that is necessarily a problem.
> 
> ok
> 

Alper


From pcalhoun@airespace.com  Tue Jul 22 21:46:35 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 13:46:35 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC5284@bsn-mail-01.bstormnetworks.com>

>>=20
>> You see, the PANA architecture really only touches the tip of the =
iceberg.
>> Moving towards a LWAPP architecture solves these issues, and =
significantly
>> reduces the amount of protocol work required between the AP and the =
AR
>> (because 802.11 terminates in the AR, so 802.11 *is* the protocol).
>
> I'm not comparing PANA with LWAPP. This does not make sense. LWAPP is =
more
> like an architecture that tackles several problems. I'm trying to =
understand
> what each one of these problems are and see if there are alternative
> solutions that should be considered.
ok, which one, specifically?

> PANA comes into the picture when we talk about the AAA between hosts =
and AR,
> and AA_ between the AP and AR. I don't see PANA's relevance to all the =
other
> bells and whistles LWAPP provides.

correct, but somehow you keep asking the question. If we agree that =
we've beaten this horse to it's full extent, then I'll gladly oblige...

>>=20
>> We seem to be focused on EAP only, but again, I think the problem is =
much
>> greater in scope - hence CAPWAP.
>>=20
>
> Is there a documented list of problems, like a problem statement? It =
is
> really hard to reverse engineer the LWAPP to undertsand the problems =
we are
> solving here.

Other than what's in the current document (which I assume you've read), =
no. However, the problems are well understood enough that many vendors =
are actively building, or shipping, products, all with the same =
architecture and a protocol that looks like LWAPP.

If the IESG believes that we need to go down the problem statement path, =
and tack on another 12 months of effort to CAPWAP, then we can consider =
it. But personally, having gone through some of this at the IETF, and =
the fact that this is a current problem that is known, I think that the =
players involve all know what we need.


PatC

From dmolnar@legra.com  Tue Jul 22 21:49:07 2003
From: dmolnar@legra.com (David Molnar)
Date: Tue, 22 Jul 2003 16:49:07 -0400 (EDT)
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: 
References: <40301581B2962B448690A023EF16DFE1DC527C@bsn-mail-01.bstormnetworks.com>
 
Message-ID: <1067.192.168.11.185.1058906947.squirrel@legra-mx-01.legra.com>

>
> Is there a documented list of problems, like a problem statement? It is
> really hard to reverse engineer the LWAPP to undertsand the problems we
> are solving here.

Well, we do have the proposed charter points for CAPWAP posted by James
Kempf. I have not seen much discussion of these on this list so far. What
do you think of them?

-David




From pcalhoun@airespace.com  Tue Jul 22 21:49:05 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 13:49:05 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC5285@bsn-mail-01.bstormnetworks.com>

> PANA protocol does not state that AP MUST be the encryption end point. =
PANA
> can be used in architectures where AR is the encryption end-point.

But one well versed in 802.11 would quickly understand that this will =
NOT work with APs, unless the AR does the 802.11 framing and therefore =
can encrypt the packets.... and then we're talking about LWAPP.

But, dead horse, moving on.

PatC

From yohba@tari.toshiba.com  Mon Jul 21 16:30:00 2003
From: yohba@tari.toshiba.com (Yoshihiro Ohba)
Date: Mon, 21 Jul 2003 08:30:00 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5281@bsn-mail-01.bstormnetworks.com>
References: <40301581B2962B448690A023EF16DFE1DC5281@bsn-mail-01.bstormnetworks.com>
Message-ID: <20030721153000.GC3959@steelhead>

On Tue, Jul 22, 2003 at 12:37:16PM -0700, Pat R. Calhoun wrote:
> >> We seem to be focused on EAP only, but again, I think the problem is much >>greater in scope - hence CAPWAP.
> 
> >It is curious to see a lot of IEEE 802 specific technologies mentioned
> >here.  Why not discuss this issue in IEEE 802?
> 
> We talked about this at the meeting. We are NOT touching any of the 802.11 protocols. What we do must work with ALL IEEE 802.11 standards, hence the LWAPP architecture.
> 
> Dorothy had lots to talk about why IEEE 802 doesn't need/want to touch this work, but I can let her answer since she is the IEEE liason.

If IEEE 802 doesn't need/want to touch this L2-specific work, the reason 
might be one of the followings:

a) The problem does not exist, or 
b) The problem exists, but the IEEE does not think it is a long-term problem.

Which is the case?  Note that if the problem exists and the IEEE
thinks it is a long-term problem, I think the IEEE should take the
responsibility to solve the problem.

> 
> PatC

Yoshihiro Ohba

From pcalhoun@airespace.com  Tue Jul 22 21:51:24 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 13:51:24 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC5287@bsn-mail-01.bstormnetworks.com>

> If IEEE 802 doesn't need/want to touch this L2-specific work, the =
reason=20
> might be one of the followings:

> a) The problem does not exist, or=20
> b) The problem exists, but the IEEE does not think it is a long-term =
problem.

> Which is the case?  Note that if the problem exists and the IEEE
> thinks it is a long-term problem, I think the IEEE should take the
> responsibility to solve the problem.

No, there is lots of interest, hence Dorothy being involved. However, we =
are not designing a MAC or a PHY, so the IEEE doesn't touch these =
problems. They tried with 802.11f with limited success. So people feel =
this is a protocol issue, not a MAC or a PHY and therefore belongs in =
IETF.

Moving on...

PatC

From lily.l.yang@intel.com  Tue Jul 22 22:00:28 2003
From: lily.l.yang@intel.com (Yang, Lily L)
Date: Tue, 22 Jul 2003 14:00:28 -0700
Subject: [Lwapp] LWAPP & IAPP
Message-ID: 

Hi,=20

I wasn't able to attend the BOF but wanted to ask one question: IEEE is =
in the process of attempting standardize Inter-AP protocol (IAPP) (11f). =
What is the intended relationship between LWAPP and IAPP then?

Lily


From sarikaya@ieee.org  Tue Jul 22 22:06:12 2003
From: sarikaya@ieee.org (Behcet Sarikaya)
Date: Tue, 22 Jul 2003 16:06:12 -0500
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
References: <40301581B2962B448690A023EF16DFE1DC5287@bsn-mail-01.bstormnetworks.com>
Message-ID: <3F1DA744.8090900@yahoo.com>

--------------070607030608060606060509
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



Pat R. Calhoun wrote:

>>If IEEE 802 doesn't need/want to touch this L2-specific work, the reason 
>>might be one of the followings:
>>    
>>
>
>  
>
>>a) The problem does not exist, or 
>>b) The problem exists, but the IEEE does not think it is a long-term problem.
>>    
>>
>
>  
>
>>Which is the case?  Note that if the problem exists and the IEEE
>>thinks it is a long-term problem, I think the IEEE should take the
>>responsibility to solve the problem.
>>    
>>
>
>No, there is lots of interest, hence Dorothy being involved. However, we are not designing a MAC or a PHY, so the IEEE doesn't touch these problems. They tried with 802.11f with limited success. So people feel this is a protocol issue, not a MAC or a PHY and therefore belongs in IETF.
>
>Moving on...
>  
>
This sounds OK, but LWAPP is discovery + configuration protocol, taking 
discovery out, as per Marcus' presentation, SNMP is IETF's protocol for 
configuration.
How are you going to deal with this?

In the run state, do AP and AR continue to communicate using LWAPP 
encapsulation, or or revert to 802.3 frame encapsulation?

>PatC
>___
>
Behcet


--------------070607030608060606060509
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit




  
  






Pat R. Calhoun wrote:



  

    
If IEEE 802 doesn't need/want to touch this L2-specific work, the reason 
might be one of the followings:
    

  

  

  

  

    
a) The problem does not exist, or 
b) The problem exists, but the IEEE does not think it is a long-term problem.
    

  

  

  

  

    
Which is the case?  Note that if the problem exists and the IEEE
thinks it is a long-term problem, I think the IEEE should take the
responsibility to solve the problem.
    

  

  

No, there is lots of interest, hence Dorothy being involved. However, we are not designing a MAC or a PHY, so the IEEE doesn't touch these problems. They tried with 802.11f with limited success. So people feel this is a protocol issue, not a MAC or a PHY and therefore belongs in IETF.

Moving on...
  



This sounds OK, but LWAPP is discovery + configuration protocol, taking discovery
out, as per Marcus' presentation, SNMP is IETF's protocol for configuration.

How are you going to deal with this?



In the run state, do AP and AR continue to communicate using LWAPP encapsulation,
or or revert to 802.3 frame encapsulation?



  
PatC
___



Behcet






--------------070607030608060606060509--


From yohba@tari.toshiba.com  Mon Jul 21 16:44:47 2003
From: yohba@tari.toshiba.com (Yoshihiro Ohba)
Date: Mon, 21 Jul 2003 08:44:47 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5287@bsn-mail-01.bstormnetworks.com>
References: <40301581B2962B448690A023EF16DFE1DC5287@bsn-mail-01.bstormnetworks.com>
Message-ID: <20030721154447.GA4148@steelhead>

On Tue, Jul 22, 2003 at 01:51:24PM -0700, Pat R. Calhoun wrote:
> > If IEEE 802 doesn't need/want to touch this L2-specific work, the reason 
> > might be one of the followings:
> 
> > a) The problem does not exist, or 
> > b) The problem exists, but the IEEE does not think it is a long-term problem.
> 
> > Which is the case?  Note that if the problem exists and the IEEE
> > thinks it is a long-term problem, I think the IEEE should take the
> > responsibility to solve the problem.
> 
> No, there is lots of interest, hence Dorothy being involved. However, we are not designing a MAC or a PHY, so the IEEE doesn't touch these problems. They tried with 802.11f with limited success. So people feel this is a protocol issue, not a MAC or a PHY and therefore belongs in IETF.

I asked the question because you previously mentioned:

   "So how does the AP know that 802.1x will be required for a given
   mobile? How +does the AP get the 802.1x keys that it must use with
   the mobile? How does the +AR handle load balancing? How does the AR
   handle 802.11e and 802.11i, or should+the AP do it? What about
   802.11h? What about 802.11k?"

Aren't those 802.11[e,h,i,k] related to IEEE 802 MAC or PHY?  Why the IETF
needs to handle all these stuff?  I think there is some inconsistency
in this discussion.

> 
> Moving on...
> 
> PatC

Yoshihiro Ohba

From pcalhoun@airespace.com  Tue Jul 22 22:26:13 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 14:26:13 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC528A@bsn-mail-01.bstormnetworks.com>

> This sounds OK, but LWAPP is discovery + configuration protocol, =
taking=20
> discovery out, as per Marcus' presentation, SNMP is IETF's protocol =
for=20
> configuration.
> How are you going to deal with this?

One can build products using a whole collection of protocols, and then =
try to determine what the interactions between each protocol should be =
handled. For instance, we followed the exact same path with L2TP (and =
PPTP, of course). would it have been possible to use SNMP to modify =
modem parameters on the access server? Sure, but it really gets ugly =
from an implementation stand-point.

So I view this as the exact same. Yes, one can use SNMP to pull/push =
information  in/out of the AP, but at what cost? If it requires that we =
now standardize the interactions between all protocols, that would be =
even more complex.

Now that you mention it, why isn't routing established using SNMP? It =
should cetainly be possible for routing peers to simply push routes =
using a well defined IP route MIB, no?

> In the run state, do AP and AR continue to communicate using LWAPP=20
> encapsulation, or or revert to 802.3 frame encapsulation?

always 802.11.

PatC

From pcalhoun@airespace.com  Tue Jul 22 22:27:23 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 14:27:23 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC528B@bsn-mail-01.bstormnetworks.com>

> I asked the question because you previously mentioned:
>=20
>    "So how does the AP know that 802.1x will be required for a given
>    mobile? How +does the AP get the 802.1x keys that it must use with
>    the mobile? How does the +AR handle load balancing? How does the AR
>    handle 802.11e and 802.11i, or should+the AP do it? What about
>    802.11h? What about 802.11k?"
>=20
> Aren't those 802.11[e,h,i,k] related to IEEE 802 MAC or PHY?  Why the =
IETF
> needs to handle all these stuff?  I think there is some inconsistency
> in this discussion.

This was in response to Alper's "why isn't PANA sufficient". We don't =
care about the above... it just works - hence the beauty of LWAPP.

PatC


From pcalhoun@airespace.com  Tue Jul 22 22:30:39 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 14:30:39 -0700
Subject: [Lwapp] LWAPP & IAPP
Message-ID: <40301581B2962B448690A023EF16DFE1DC528F@bsn-mail-01.bstormnetworks.com>

Completely different. IAPP is between 2 APs. LWAPP is used to "split the =
MAC" where the control component of 802.11 (which is real time) is in =
the AP, while the data and mac management are handled in the AR.

PatC
-----Original Message-----
From:	Yang, Lily L [mailto:lily.l.yang@intel.com]
Sent:	Tue 7/22/2003 2:00 PM
To:	lwapp@frascone.com
Cc:=09
Subject:	[Lwapp] LWAPP & IAPP
Hi,=20

I wasn't able to attend the BOF but wanted to ask one question: IEEE is =
in the process of attempting standardize Inter-AP protocol (IAPP) (11f). =
What is the intended relationship between LWAPP and IAPP then?

Lily

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp




From yohba@tari.toshiba.com  Tue Jul 22 22:43:34 2003
From: yohba@tari.toshiba.com (Yoshihiro Ohba)
Date: Tue, 22 Jul 2003 14:43:34 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC528B@bsn-mail-01.bstormnetworks.com>
References: <40301581B2962B448690A023EF16DFE1DC528B@bsn-mail-01.bstormnetworks.com>
Message-ID: <20030722214334.GA679@steelhead>

On Tue, Jul 22, 2003 at 02:27:23PM -0700, Pat R. Calhoun wrote:
> 
> > I asked the question because you previously mentioned:
> > 
> >    "So how does the AP know that 802.1x will be required for a given
> >    mobile? How +does the AP get the 802.1x keys that it must use with
> >    the mobile? How does the +AR handle load balancing? How does the AR
> >    handle 802.11e and 802.11i, or should+the AP do it? What about
> >    802.11h? What about 802.11k?"
> > 
> > Aren't those 802.11[e,h,i,k] related to IEEE 802 MAC or PHY?  Why the IETF
> > needs to handle all these stuff?  I think there is some inconsistency
> > in this discussion.
> 
> This was in response to Alper's "why isn't PANA sufficient". We don't care about the above... it just works - hence the beauty of LWAPP.

This sounds like handling 802.11[e,h,i,k,x] on AR is out of the scope
of CAPWAP.

> 
> PatC
> 

Yoshihiro Ohba

From pcalhoun@airespace.com  Tue Jul 22 22:58:27 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 14:58:27 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC5293@bsn-mail-01.bstormnetworks.com>

>> This was in response to Alper's "why isn't PANA sufficient". We don't =
care=20
>> about the above... it just works - hence the beauty of LWAPP.
>
> This sounds like handling 802.11[e,h,i,k,x] on AR is out of the scope
> of CAPWAP.

What it means is that defining or changing 802.11* is out of scope of =
LWAPP. What is in scope if defining a protocol whereby 802.11* frames =
can be forwarded from the AP to the AR. Processing of these frames is =
done as specified in the appropriate SDO document.

PatC

From lily.l.yang@intel.com  Tue Jul 22 23:07:59 2003
From: lily.l.yang@intel.com (Yang, Lily L)
Date: Tue, 22 Jul 2003 15:07:59 -0700
Subject: [Lwapp] LWAPP & IAPP
Message-ID: 

But if you have LWAPP, it seems to me that you don't really need IAPP, =
do you? Doesn't LWAPP also deal with bridging ?

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, July 22, 2003 2:31 PM
To: Yang, Lily L; lwapp@frascone.com
Subject: RE: [Lwapp] LWAPP & IAPP


Completely different. IAPP is between 2 APs. LWAPP is used to "split the =
MAC" where the control component of 802.11 (which is real time) is in =
the AP, while the data and mac management are handled in the AR.

PatC
-----Original Message-----
From:	Yang, Lily L [mailto:lily.l.yang@intel.com]
Sent:	Tue 7/22/2003 2:00 PM
To:	lwapp@frascone.com
Cc:=09
Subject:	[Lwapp] LWAPP & IAPP
Hi,=20

I wasn't able to attend the BOF but wanted to ask one question: IEEE is =
in the process of attempting standardize Inter-AP protocol (IAPP) (11f). =
What is the intended relationship between LWAPP and IAPP then?

Lily

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp




From idir.fodil@6wind.com  Mon Jul 21 13:49:06 2003
From: idir.fodil@6wind.com (idir fodil)
Date: Mon, 21 Jul 2003 14:49:06 +0200
Subject: [Lwapp] LWAPP implementation
Message-ID: <3F1BE142.5000304@6wind.com>

Hy every body
I would ask you if there are any AP and router or switch that support 
LWAPP protocol

Thank you for help

Idir FODIL
R&D Team



From idir.fodil@6wind.com  Mon Jul 21 13:56:26 2003
From: idir.fodil@6wind.com (idir fodil)
Date: Mon, 21 Jul 2003 14:56:26 +0200
Subject: [Lwapp] LWAPP Implementation
Message-ID: <3F1BE2FA.8030003@6wind.com>

Hy every body ,
I want to know if there is APs and Routers or Switches that support 
LWAPP protocol

thank you for informations


Idir Bahaa FODIL
R&D Team


From pcalhoun@airespace.com  Wed Jul 23 00:29:47 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 16:29:47 -0700
Subject: [Lwapp] LWAPP & IAPP
Message-ID: <40301581B2962B448690A023EF16DFE1DC5297@bsn-mail-01.bstormnetworks.com>

An AR could bridge, or route, depending upon the implementation. I =
believe that the need for IAPP is minimized by LWAPP.

PatC
-----Original Message-----
From:	Yang, Lily L [mailto:lily.l.yang@intel.com]
Sent:	Tue 7/22/2003 3:07 PM
To:	Pat R. Calhoun
Cc:	lwapp@frascone.com
Subject:	RE: [Lwapp] LWAPP & IAPP
But if you have LWAPP, it seems to me that you don't really need IAPP, =
do you? Doesn't LWAPP also deal with bridging ?

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, July 22, 2003 2:31 PM
To: Yang, Lily L; lwapp@frascone.com
Subject: RE: [Lwapp] LWAPP & IAPP


Completely different. IAPP is between 2 APs. LWAPP is used to "split the =
MAC" where the control component of 802.11 (which is real time) is in =
the AP, while the data and mac management are handled in the AR.

PatC
-----Original Message-----
From:	Yang, Lily L [mailto:lily.l.yang@intel.com]
Sent:	Tue 7/22/2003 2:00 PM
To:	lwapp@frascone.com
Cc:=09
Subject:	[Lwapp] LWAPP & IAPP
Hi,=20

I wasn't able to attend the BOF but wanted to ask one question: IEEE is =
in the process of attempting standardize Inter-AP protocol (IAPP) (11f). =
What is the intended relationship between LWAPP and IAPP then?

Lily

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp







From sarikaya@ieee.org  Wed Jul 23 00:44:15 2003
From: sarikaya@ieee.org (Behcet Sarikaya)
Date: Tue, 22 Jul 2003 18:44:15 -0500
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
References: <40301581B2962B448690A023EF16DFE1DC528A@bsn-mail-01.bstormnetworks.com>
Message-ID: <3F1DCC4F.2030308@yahoo.com>

--------------060508080203080308030503
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

  Sorry the sender address appeared wrong on the previous message please 
ignore it.

Pat R. Calhoun wrote:

>>This sounds OK, but LWAPP is discovery + configuration protocol, taking 
>>discovery out, as per Marcus' presentation, SNMP is IETF's protocol for 
>>configuration.
>>How are you going to deal with this?
>>    
>>
>
>One can build products using a whole collection of protocols, and then try to determine what the interactions between each protocol should be handled. For instance, we followed the exact same path with L2TP (and PPTP, of course). would it have been possible to use SNMP to modify modem parameters on the access server? Sure, but it really gets ugly from an implementation stand-point.
>
>So I view this as the exact same. Yes, one can use SNMP to pull/push information  in/out of the AP, but at what cost? If it requires that we now standardize the interactions between all protocols, that would be even more complex.
>
>Now that you mention it, why isn't routing established using SNMP? It should cetainly be possible for routing peers to simply push routes using a well defined IP route MIB, no?
>
 I glanced thru the two RFCs for L2TP and PPTP, they are basically call 
state control and management protocols, providing IP-based tunneling in 
L2 domain. I could not see how such things could be achieved, e.g. by 
defining a MIB?
However, it seems that most of what LWAPP tries to do could probably be 
achieved by way of SNMP set operations, so this should probably be the 
basis of discussion in this ML.

>  
>
>>In the run state, do AP and AR continue to communicate using LWAPP 
>>encapsulation, or or revert to 802.3 frame encapsulation?
>>    
>>
>
>always 802.11.
>
>PatC
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>
>  
>


--------------060508080203080308030503
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit




  
  




          Sorry the sender address appeared wrong on the previous message
please ignore it.

 

 Pat R. Calhoun wrote:

 

 
  
  
     
    
This sounds OK, but LWAPP is discovery + configuration protocol, taking 
discovery out, as per Marcus' presentation, SNMP is IETF's protocol for 
configuration.
How are you going to deal with this?
    

   

   
  

One can build products using a whole collection of protocols, and then try to determine what the interactions between each protocol should be handled. For instance, we followed the exact same path with L2TP (and PPTP, of course). would it have been possible to use SNMP to modify modem parameters on the access server? Sure, but it really gets ugly from an implementation stand-point.

So I view this as the exact same. Yes, one can use SNMP to pull/push information  in/out of the AP, but at what cost? If it requires that we now standardize the interactions between all protocols, that would be even more complex.

Now that you mention it, why isn't routing established using SNMP? It should cetainly be possible for routing peers to simply push routes using a well defined IP route MIB, no?

 

  I glanced thru the two RFCs for L2TP and PPTP, they are basically call
state control and management protocols, providing IP-based tunneling in L2
domain. I could not see how such things could be achieved, e.g. by defining
a MIB? 

 However, it seems that most of what LWAPP tries to do could probably be
achieved by way of SNMP set operations, so this should probably be the basis
of discussion in this ML.

 

 
  
  
  

   
  
     
    
In the run state, do AP and AR continue to communicate using LWAPP 
encapsulation, or or revert to 802.3 frame encapsulation?
    

   

   
  

always 802.11.

PatC
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

  

 

 

 



--------------060508080203080308030503--


From pcalhoun@airespace.com  Wed Jul 23 00:46:57 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 22 Jul 2003 16:46:57 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC529C@bsn-mail-01.bstormnetworks.com>

Having implemented the protocol, I feel quite comfortable stating that =
there are MANY configuration items in L2TP that are used to setup the =
configuration of the NAS. Perhaps not as many, but they are there =
nonetheless...

PatC
-----Original Message-----
From:	Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent:	Tue 7/22/2003 4:39 PM
To:	Pat R. Calhoun
Cc:	sarikaya@ieee.org; lwapp@frascone.com
Subject:	Re: [Lwapp] Certificates, Discovery Request/Reply, and =
validation.


Pat R. Calhoun wrote:

>>This sounds OK, but LWAPP is discovery + configuration protocol, =
taking=20
>>discovery out, as per Marcus' presentation, SNMP is IETF's protocol =
for=20
>>configuration.
>>How are you going to deal with this?
>>   =20
>>
>
>One can build products using a whole collection of protocols, and then =
try to determine what the interactions between each protocol should be =
handled. For instance, we followed the exact same path with L2TP (and =
PPTP, of course). would it have been possible to use SNMP to modify =
modem parameters on the access server? Sure, but it really gets ugly =
from an implementation stand-point.
>
>So I view this as the exact same. Yes, one can use SNMP to pull/push =
information  in/out of the AP, but at what cost? If it requires that we =
now standardize the interactions between all protocols, that would be =
even more complex.
>
>Now that you mention it, why isn't routing established using SNMP? It =
should cetainly be possible for routing peers to simply push routes =
using a well defined IP route MIB, no?
>
 I glanced thru the two RFCs for L2TP and PPTP, they are basically call=20
state control and management protocols, providing IP-based tunneling in=20
L2 domain. I could not see how such things could be achieved, e.g. by=20
defining a MIB?
However, it seems that most of what LWAPP tries to do could probably be=20
achieved by way of SNMP set operations, so this should probably be the=20
basis of discussion in this ML.

>
> =20
>
>>In the run state, do AP and AR continue to communicate using LWAPP=20
>>encapsulation, or or revert to 802.3 frame encapsulation?
>>   =20
>>
>
>always 802.11.
>
>PatC
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>
> =20
>





From alper@docomolabs-usa.com  Wed Jul 23 03:00:30 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Tue, 22 Jul 2003 19:00:30 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5284@bsn-mail-01.bstormnetworks.com>
Message-ID: 

>> I'm not comparing PANA with LWAPP. This does not make sense. LWAPP is more
>> like an architecture that tackles several problems. I'm trying to understand
>> what each one of these problems are and see if there are alternative
>> solutions that should be considered.
> ok, which one, specifically?

I've discussed these before, but nevertheless:
- Configuring APs: SNMP, COPS, etc.
- Migration of AAA stuff from AP to AR: PANA
- Auth/Authz between AP and AR: PANA (if physical security is not good
  enough)
- Migration of per-packet ciphering from AP to AR: Either use IPsec with AR,
  or tunnel 802.11 frames on the wired segment. Whether the latter should be
  done at IEEE vs. IETF is debatable.

Did I miss any other problems we are tackling here?

> 
>> PANA comes into the picture when we talk about the AAA between hosts and AR,
>> and AA_ between the AP and AR. I don't see PANA's relevance to all the other
>> bells and whistles LWAPP provides.
> 
> correct, but somehow you keep asking the question. If we agree that we've
> beaten this horse to it's full extent, then I'll gladly oblige...

Please see above.

> 
>>> 
>>> We seem to be focused on EAP only, but again, I think the problem is much
>>> greater in scope - hence CAPWAP.
>>> 
>> 
>> Is there a documented list of problems, like a problem statement? It is
>> really hard to reverse engineer the LWAPP to undertsand the problems we are
>> solving here.
> 
> Other than what's in the current document (which I assume you've read), no.
> However, the problems are well understood enough that many vendors are
> actively building, or shipping, products, all with the same architecture and a
> protocol that looks like LWAPP.
> 
> If the IESG believes that we need to go down the problem statement path, and
> tack on another 12 months of effort to CAPWAP, then we can consider it. But
> personally, having gone through some of this at the IETF, and the fact that
> this is a current problem that is known, I think that the players involve all
> know what we need.

I still feel like missing couple of necessary steps here if we already jump
to solution evaluation stage.

Alper

> 
> 
> PatC
> 
> 


From alper@docomolabs-usa.com  Wed Jul 23 03:05:05 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Tue, 22 Jul 2003 19:05:05 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5285@bsn-mail-01.bstormnetworks.com>
Message-ID: 

>> PANA protocol does not state that AP MUST be the encryption end point. PANA
>> can be used in architectures where AR is the encryption end-point.
> 
> But one well versed in 802.11 would quickly understand that this will NOT work
> with APs, unless the AR does the 802.11 framing and therefore can encrypt the
> packets.... and then we're talking about LWAPP.

Unless the operator is willing to use IPsec between the host and the access
router.

If the operator wants to use L2 ciphering, then yes, 802.11 frames should
reach the access router. But note that this is just one of the many things
LWAPP does. Doing this does not mean that we must use all other LWAPP
features along with that. Please see my earlier message for the problem
break-down and possible alternatives...

> 
> But, dead horse, moving on.
> 
> PatC

Alper


From alper@docomolabs-usa.com  Wed Jul 23 03:17:19 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Tue, 22 Jul 2003 19:17:19 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <1067.192.168.11.185.1058906947.squirrel@legra-mx-01.legra.com>
Message-ID: 

On 7/22/03 1:49 PM, "David Molnar"  wrote:

>> 
>> Is there a documented list of problems, like a problem statement? It is
>> really hard to reverse engineer the LWAPP to undertsand the problems we
>> are solving here.
> 
> Well, we do have the proposed charter points for CAPWAP posted by James
> Kempf. I have not seen much discussion of these on this list so far. What
> do you think of them?

Inadequate. One should expand on this. The following text does not fully
explain what the problem is, how it cannot be solved by the current
mechanisms, what does "acquisition"-"configuration"-"monitoring"-
"controlling load" entail...

    Develop a protocol controlling wireless access points with the following
    features:

    .Independent of wireless link protocol.
    .Discovery of a CAPWAP manager (AR, IP addressable switch).
    .Acquisition of APs by CAPWAP manager.
    .Configuration and monitoring of wireless link by CAPWAP manager.
    .Partially and/or fully terminate the wireless MAC layer at the CAPWAP
    manager.
       -Including security of host traffic.
       -NOT intended to define changes in MAC!
    .Control of AP host load.
    .Security for CAPWAP signaling.

Alper


From yohba@tari.toshiba.com  Wed Jul 23 03:28:24 2003
From: yohba@tari.toshiba.com (Yoshihiro Ohba)
Date: Tue, 22 Jul 2003 19:28:24 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5293@bsn-mail-01.bstormnetworks.com>
References: <40301581B2962B448690A023EF16DFE1DC5293@bsn-mail-01.bstormnetworks.com>
Message-ID: <20030723022824.GB679@steelhead>

On Tue, Jul 22, 2003 at 02:58:27PM -0700, Pat R. Calhoun wrote:
> >> This was in response to Alper's "why isn't PANA sufficient". We don't care 
> >> about the above... it just works - hence the beauty of LWAPP.
> >
> > This sounds like handling 802.11[e,h,i,k,x] on AR is out of the scope
> > of CAPWAP.
> 
> What it means is that defining or changing 802.11* is out of scope of LWAPP. What is in scope if defining a protocol whereby 802.11* frames can be forwarded from the AP to the AR. Processing of these frames is done as specified in the appropriate SDO document.
> 

OK.  On the other hand, it is still debatable whether a protocol to
forward 802.11 frames from AP to AR needs to be defined or just using
an existing protocol (e.g., L2TP) is enough.  

> PatC

Yoshihiro Ohba

From rkp@intotoinc.com  Wed Jul 23 04:52:33 2003
From: rkp@intotoinc.com (Rama krishna prasad)
Date: Wed, 23 Jul 2003 09:22:33 +0530
Subject: [Lwapp] LWAPP & IAPP
References: 
Message-ID: <3F1E0681.7000004@intotoinc.com>

Hi all,

  As I understand this IAPP and CTP might be solving the same problem.
 But, LWAPP does not address context transfer as IAPP does.

Regards
Rama Krishna Prasad
Intoto Software (India) Pvt Ltd.



Yang, Lily L wrote:

>Hi, 
>
>I wasn't able to attend the BOF but wanted to ask one question: IEEE is in the process of attempting standardize Inter-AP protocol (IAPP) (11f). What is the intended relationship between LWAPP and IAPP then?
>
>Lily
>
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>
>  
>



From rkp@intotoinc.com  Wed Jul 23 04:54:31 2003
From: rkp@intotoinc.com (Rama krishna prasad)
Date: Wed, 23 Jul 2003 09:24:31 +0530
Subject: [Lwapp] Broadcast/Multicast packet flow
References: 
Message-ID: <3F1E06F7.6090407@intotoinc.com>

Hi sadot,

Thank you for the feedback.

You are right that there is no difference between first two scenarios, except for
some simple conditions in the implementation. We are thinking of implementing this
by exposing AP+SSID number combination as bridge port. With this, L2 bridging takes
care of sending packets belonging to some other AP and also takes care of multicast
and broadcast packets. Bridge drops the packet if it needs to send the packet onto
the same port from which the packet came originally. That is why, we are thinking of
taking care of same AP mobiles in LWAPP layer and everything else in bridge layer.


You are talking about cross VLAN domain roaming. Do you mean cross-subnet roaming?
If all subnets in the same AR, then there is no issue. But, if they are across multiple ARs,
then mobile-IP can be used to avoid stateful session transfer across ARs. Do you mean
anything else?

Thanks
Rama Krishna Prasad
Intoto Software (India) Pvt. Ltd.



Sadot, Emek (Emek) wrote:

>Rama,
>
>I lack to see the difference between the first two scenarios. Besides the destination-MAC-to-AP-mapping stage, which takes place at the AR, the sequence of events should be identical regardless destination station position (associated to same AP as the source or not).
>
>I am not sure what is the proposed architecture in regard to broadcast, however encapsulating each packet and send it as a unicast to corresponds AP sounds to me as unacceptable solution. That's where handling 802.11 packets at the AR is a disadvantage.
>
>The case is different if the source station crossed VLAN domain while roamed or if destination station had crossed VLAN domain while roamed.
>
>Emek 
>
>-----Original Message-----
>From: Rama krishna prasad [mailto:rkp@intotoinc.com]
>Sent: Tuesday, 22 July, 2003 6:47 AM
>To: lwapp@frascone.com
>Subject: [Lwapp] Broadcast/Multicast packet flow
>
>Hi,
>          I am trying to understand the packet flow between wireless stations
>          and AR with several APs in between. Appreciate your feedback.
>         
>          Assumptions:
>               Only Layer2 wireless switching with 802.1x key management and
>               authentication in this deployment.
>               Given SSID (network) is supported by multiple APs.
>
>          Unicast traffic between wireless station1 to wireless station 2 belonging to
>              the same AP and SSID:
>                  - AP receives the packet from station 1.
>                  - AP de-ciphers it.
>                  - Since it is data packet, it encapsulates with LWAPP header and
>                         apply any security on the packet and send it over to AR.
>                  -  AR de-capsulate and removes LWAPP header/802.11 header and validates
>                        whether this station is successfully authenticated or not.
>                  - Then it finds out that this packet has to go same AP, based on the destination
>                     MAC address in 802.3 packet. AR encapsulates the packet with 802.11
>                     and LWAPP header and applies any security needed between AR and AP.
>                 -   AP receives it, decapsulates the LWAPP header.
>                 -   AP encrypts the packet with TKIP RC4/RSN unicast key and passes it onto the
>                       destination station.
>
>           Unicast traffic between wireless stations 1 of AP 1 TO wireless station 2 of AP 2 and
>                    stations belong to same SSID.
>                   - AP1 receives the 802.11 encapsulated 802.3 packet from wireless station 1.
>                   - AP1 de-cipher it using unicast cipher key.
>                   - AP1 encapsulates the 802.11 packet with LWAPP header and sends over to the AR.
>                          It applies ciphering/authentication based on AR-AP security.
>                   - AR receives the packet and validates the authentication of the station.
>                   - AR finds out this destination MAC address belongs to some other AP and sends
>                        the packet to that AP after encapsulating with 802.11 and LWAPP headers.
>                   - AP2 receives the packet and applies any unicast ciphering and sends the packet to
>                      destination station.
>
>           Broadcast traffic from a wireless station to all stations of that network (SSID):
>                  -  Corresponding AP receives the broadcast packet from the station.
>                  -   It decrypts using global cipher key.
>                  -   Passes this packet onto AR after encapsulating with LWAPP.
>                  -   AR receives the packet and validates it.
>                  -  AR now should find out all APs corresponding to the same SSID.
>                  -   For each AP
>                           AR encapsulates the packet with 802.11 and LWAPP header
>                              and send it over to the AP.
>                           AP decapsulates the LWAPP header and applies global cipher key and sends
>                                the packet to air.
>              
>          Is that the flow envisages as part of LWAPP?
> Thanks
> Rama Krishna Prasad
> Intoto Software (India) Pvt Ltd.
>
>
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>
>  
>



From Marcus Brunner   Wed Jul 23 11:41:44 2003
From: Marcus Brunner  (Marcus Brunner)
Date: Wed, 23 Jul 2003 12:41:44 +0200
Subject: [Lwapp] LWAPP & IAPP
In-Reply-To: 
References: 
Message-ID: <8948126.1058964104@[10.1.1.130]>

I don't know IAPP in detail, but I assume the functions provided by IAPP 
are centralized into the AR using LWAPP and therefore do not need 
standardization.

To what degree IAPP is used in such an approach is open for me.

Marcus

--On Dienstag, 22. Juli 2003 14:00 -0700 "Yang, Lily L" 
 wrote:

> Hi,
>
> I wasn't able to attend the BOF but wanted to ask one question: IEEE is
> in the process of attempting standardize Inter-AP protocol (IAPP) (11f).
> What is the intended relationship between LWAPP and IAPP then?
>
> Lily
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp



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

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus





From pcalhoun@airespace.com  Wed Jul 23 14:25:31 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 23 Jul 2003 06:25:31 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC52A0@bsn-mail-01.bstormnetworks.com>

> I've discussed these before, but nevertheless:
> - Configuring APs: SNMP, COPS, etc.
> - Migration of AAA stuff from AP to AR: PANA
> - Auth/Authz between AP and AR: PANA (if physical security is not good
>   enough)
> - Migration of per-packet ciphering from AP to AR: Either use IPsec =
with AR,
>   or tunnel 802.11 frames on the wired segment. Whether the latter =
should be
>   done at IEEE vs. IETF is debatable.
>=20
> Did I miss any other problems we are tackling here?

Apparently. I think the key point that you are missing here is the 'LW' =
in LWAPP. Specifically, the goal is to reduce the complexity of the AP, =
which is something that we are hearing both customers and AP =
manufacturers want. The proposal above requires so much code in the AP =
that one has to question what the advantages are.

I think we've already had the IEEE vs. IETF discussion, so unless you =
have a clear explanation of why this is a MAC or PHY problem, please =
state it.

>> correct, but somehow you keep asking the question. If we agree that =
we've
>> beaten this horse to it's full extent, then I'll gladly oblige...
>
> Please see above.

I see, so the horse isn't dead....

> I still feel like missing couple of necessary steps here if we already =
jump
> to solution evaluation stage.

Correct. I think the part that's missing here is that unlike other =
topics in the IETF that are mostly around research topics (build it and =
they will come), this is the inverse. Products are shipping, and many =
vendors in this space wish to ensure some form of interoperability =
between their devices.

I understand that you're trying to find some market for the PANA =
architecture, and I'm sure there are customers, but I think that the =
vendors in this particular space have already made an architectural =
decision. If the IETF wishes to standardize on an architecture the =
players in the 802.11 space are not interested in, then I think it's =
missed its mark.

Further, I think that your proposal does not benefit the Internet =
Community, which is looking for lowering the cost of AP deployments and =
operation. What you proposal does is drive the standards process much =
longer with dubious advantages.

PatC

From pcalhoun@airespace.com  Wed Jul 23 14:31:02 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 23 Jul 2003 06:31:02 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC52A1@bsn-mail-01.bstormnetworks.com>

>> But one well versed in 802.11 would quickly understand that this will =
NOT=20
>> work with APs, unless the AR does the 802.11 framing and therefore =
can=20
>> encrypt the
>> packets.... and then we're talking about LWAPP.
>
>Unless the operator is willing to use IPsec between the host and the =
access
>router.

 Alper, please point me to =
one service provider that is even considering using IPSec to secure the =
session in a *hot spot environment*. Please show me one operator that is =
willing to assume that IPSec is readily available on all devices, and =
will build a business around this. Frankly, all services providers that =
I've talked to are rather disappointed in the PANA architecture because =
they were hoping for an auth mechanism that did not require any special =
software on the client (e.g. http).=20

(FWIW, I think the above would have been a fine problem to solve - see =
IPass' auth protocol for example).

anyhow, these are discussions for the PANA list, not this one.

> If the operator wants to use L2 ciphering, then yes, 802.11 frames =
should
> reach the access router. But note that this is just one of the many =
things
> LWAPP does. Doing this does not mean that we must use all other LWAPP
> features along with that. Please see my earlier message for the =
problem
> break-down and possible alternatives...

Ah - so change the PANA charter to solve the CAPWAP problem? If this is =
the PANA architecture, then it should be clear, because so far, it has =
not been. How would you tunnel the frames? How would you coordinate the =
session keys between the devices? etc, etc, etc.

PatC

From pcalhoun@airespace.com  Wed Jul 23 14:35:00 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 23 Jul 2003 06:35:00 -0700
Subject: [Lwapp] LWAPP & IAPP
Message-ID: <40301581B2962B448690A023EF16DFE1DC52A3@bsn-mail-01.bstormnetworks.com>

Correct, they solve different problems. I would see the AR implementing =
CTP or IAPP for inter-AR communication.

PatC
-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent:	Tue 7/22/2003 8:52 PM
To:	Yang, Lily L
Cc:	lwapp@frascone.com
Subject:	Re: [Lwapp] LWAPP & IAPP
Hi all,

  As I understand this IAPP and CTP might be solving the same problem.
 But, LWAPP does not address context transfer as IAPP does.

Regards
Rama Krishna Prasad
Intoto Software (India) Pvt Ltd.



Yang, Lily L wrote:

>Hi,=20
>
>I wasn't able to attend the BOF but wanted to ask one question: IEEE is =
in the process of attempting standardize Inter-AP protocol (IAPP) (11f). =
What is the intended relationship between LWAPP and IAPP then?
>
>Lily
>
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>
> =20
>


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp




From Mike.Moreton@Synad.com  Wed Jul 23 17:01:33 2003
From: Mike.Moreton@Synad.com (Mike Moreton)
Date: Wed, 23 Jul 2003 17:01:33 +0100
Subject: [Lwapp] LWAPP & IAPP
Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA751@paris.synad.com>

Maybe IAPP could be used between the ARs...

Mike Moreton
Synad Technologies Ltd.
=20

-----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]=20
Sent: 23 July 2003 11:42
To: Yang, Lily L; lwapp@frascone.com
Subject: Re: [Lwapp] LWAPP & IAPP

I don't know IAPP in detail, but I assume the functions provided by IAPP

are centralized into the AR using LWAPP and therefore do not need=20
standardization.

To what degree IAPP is used in such an approach is open for me.

Marcus

--On Dienstag, 22. Juli 2003 14:00 -0700 "Yang, Lily L"=20
 wrote:

> Hi,
>
> I wasn't able to attend the BOF but wanted to ask one question: IEEE
is
> in the process of attempting standardize Inter-AP protocol (IAPP)
(11f).
> What is the intended relationship between LWAPP and IAPP then?
>
> Lily
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp



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

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus




_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

From alper@docomolabs-usa.com  Wed Jul 23 17:11:43 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Wed, 23 Jul 2003 09:11:43 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC52A0@bsn-mail-01.bstormnetworks.com>
Message-ID: 

>> I've discussed these before, but nevertheless:
>> [a] - Configuring APs: SNMP, COPS, etc.
>> [b] - Migration of AAA stuff from AP to AR: PANA
>> [c] - Auth/Authz between AP and AR: PANA (if physical security is not good
>>   enough)
>> [d] - Migration of per-packet ciphering from AP to AR: Either use IPsec with
AR,
>>   or tunnel 802.11 frames on the wired segment. Whether the latter should be
>>   done at IEEE vs. IETF is debatable.
>> 
>> Did I miss any other problems we are tackling here?
> 
> Apparently. I think the key point that you are missing here is the 'LW' in
> LWAPP. Specifically, the goal is to reduce the complexity of the AP, which is
> something that we are hearing both customers and AP manufacturers want. The
> proposal above requires so much code in the AP that one has to question what
> the advantages are.

Let's put LWAPP and the above framework on scale. For the above framework,
[b] and [d] has 0 cost on AP. Are you saying LWAPP is light-weight because
it has a lw-SNMP (for [a]) and lw-802.1X/lw-PANA (for [c])? If you come up
with the lw versions of these, I'm sure they'd be useful as standalone as
well.

> 
> I think we've already had the IEEE vs. IETF discussion, so unless you have a
> clear explanation of why this is a MAC or PHY problem, please state it.

This is about tunneling 802.11 frames to AR. All you said was IETF could do
this, I agree. That does not mean that IETF should do it. I'm still waiting
for the explanation why IEEE shouldn't/couldn't do this. Any response to
that?

> 
>>> correct, but somehow you keep asking the question. If we agree that we've
>>> beaten this horse to it's full extent, then I'll gladly oblige...
>> 
>> Please see above.
> 
> I see, so the horse isn't dead....
> 
>> I still feel like missing couple of necessary steps here if we already jump
>> to solution evaluation stage.
> 
> Correct. I think the part that's missing here is that unlike other topics in
> the IETF that are mostly around research topics (build it and they will come),
> this is the inverse. Products are shipping, and many vendors in this space
> wish to ensure some form of interoperability between their devices.

What are the products shipping LWAPP and alikes?

> 
> I understand that you're trying to find some market for the PANA architecture,
> and I'm sure there are customers, but I think that the vendors in this
> particular space have already made an architectural decision. If the IETF
> wishes to standardize on an architecture the players in the 802.11 space are
> not interested in, then I think it's missed its mark.

Well, this BoF comes with a problem and I'm trying to show how we can reuse
existing/ongoing work. I think this is a good IETF practice :)

> 
> Further, I think that your proposal does not benefit the Internet Community,
> which is looking for lowering the cost of AP deployments and operation. What
> you proposal does is drive the standards process much longer with dubious
> advantages.

Yes it does. Don't you see how it moves processing from AP to AR?

Alper


From alper@docomolabs-usa.com  Wed Jul 23 17:23:53 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Wed, 23 Jul 2003 09:23:53 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC52A1@bsn-mail-01.bstormnetworks.com>
Message-ID: 

>>> But one well versed in 802.11 would quickly understand that this will NOT
>>> work with APs, unless the AR does the 802.11 framing and therefore can
>>> encrypt the
>>> packets.... and then we're talking about LWAPP.
>> 
>> Unless the operator is willing to use IPsec between the host and the access
>> router.
> 
>  Alper, please point me to one
> service provider that is even considering using IPSec to secure the session in
> a *hot spot environment*. Please show me one operator that is willing to
> assume that IPSec is readily available on all devices, and will build a
> business around this. Frankly, all services providers that I've talked to are
> rather disappointed in the PANA architecture because they were hoping for an
> auth mechanism that did not require any special software on the client (e.g.
> http). 

If the operators want a client-less solution, they can stay with web-based
login hackery (is there any alternative??). Obviously this is not adequately
secure, and they will have to move on. Any reasonable wireless security
requires client support.

As for IPsec and PANA, one more time, PANA does not mandate you to use the
keys with IPsec. You can use them with link-layer ciphering. For example,
you can bootstrap your WEP keys (legacy network) using PANA.

> 
> (FWIW, I think the above would have been a fine problem to solve - see IPass'
> auth protocol for example).
> 
> anyhow, these are discussions for the PANA list, not this one.
> 
>> If the operator wants to use L2 ciphering, then yes, 802.11 frames should
>> reach the access router. But note that this is just one of the many things
>> LWAPP does. Doing this does not mean that we must use all other LWAPP
>> features along with that. Please see my earlier message for the problem
>> break-down and possible alternatives...
> 
> Ah - so change the PANA charter to solve the CAPWAP problem?

Why? We are not going to update the charter each time we realize where PANA
can be used.

> If this is the 
> PANA architecture, then it should be clear, because so far, it has not been.

PANA is a protocol, not an architecture. You can use it in any architecture
you like, as long as you follow the protocol design. If you want to see
mention of using keys with L2 ciphers, please read the latest Problem
Statement and Usage Scenarios draft.

> How would you tunnel the frames?

Again, this is not for PANA - obviously. Some tunneling scheme is needed
(OK, this can be CAPWAP modulo where the work should take place)

> How would you coordinate the session keys
> between the devices? etc, etc, etc.

Please explain what keys, what devices, what is the problem ???

Alper



From Madjid.Nakhjiri@motorola.com  Wed Jul 23 20:43:08 2003
From: Madjid.Nakhjiri@motorola.com (Nakhjiri Madjid-MNAKHJI1)
Date: Wed, 23 Jul 2003 14:43:08 -0500
Subject: [Lwapp] Broadcast/Multicast packet flow
Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD60C8@IL27EXM10.cig.mot.com>

If this procedure is what we envision for 802.11 data handling, then the AP is responsible
for handling the encryption/ decryption of over the air packets. Now, if such a heavy operation is done at the AP, why not handle the traffic right there and then, why
encapsulte it to AR?
I am not quite sure if I buy the antenna diversity argument that
 Marcus brought up at the meeting. 
That would only be useful, if the standards allow a STA send packets
to multiple APs on the same frequency. CDMA soft handover procedure works because the
adjacent base station frequencies are the same, I thought WLAN has a serious frequency
planning schema.
In the same way I am hesitant, if encapsulating packets to AR, allows the AR to know RSSIs (I am not sure what 802.11K or the RRM group is up to). 
Policy enforcment also should be done right when the packets hit the network, if
the AP can handle encryption, it can definitely handle security policy and it should be able to handle a few token bucket filters as well.

Puzzled,

Madjid

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, July 22, 2003 8:02 AM
To: rkp@intotoinc.com; lwapp@frascone.com
Subject: RE: [Lwapp] Broadcast/Multicast packet flow


sounds right.

PatC
-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent:	Mon 7/21/2003 8:47 PM
To:	lwapp@frascone.com
Cc:	
Subject:	[Lwapp] Broadcast/Multicast packet flow
Hi,
          I am trying to understand the packet flow between wireless stations
          and AR with several APs in between. Appreciate your feedback.
          
          Assumptions:
               Only Layer2 wireless switching with 802.1x key management and
               authentication in this deployment.
               Given SSID (network) is supported by multiple APs.

          Unicast traffic between wireless station1 to wireless station 2 belonging to
              the same AP and SSID:
                  - AP receives the packet from station 1.
                  - AP de-ciphers it.
                  - Since it is data packet, it encapsulates with LWAPP header and 
                         apply any security on the packet and send it over to AR.
                  -  AR de-capsulate and removes LWAPP header/802.11 header and validates
                        whether this station is successfully authenticated or not.
                  - Then it finds out that this packet has to go same AP, based on the destination
                     MAC address in 802.3 packet. AR encapsulates the packet with 802.11 
                     and LWAPP header and applies any security needed between AR and AP.
                 -   AP receives it, decapsulates the LWAPP header.
                 -   AP encrypts the packet with TKIP RC4/RSN unicast key and passes it onto the
                       destination station.

           Unicast traffic between wireless stations 1 of AP 1 TO wireless station 2 of AP 2 and
                    stations belong to same SSID.
                   - AP1 receives the 802.11 encapsulated 802.3 packet from wireless station 1.
                   - AP1 de-cipher it using unicast cipher key.
                   - AP1 encapsulates the 802.11 packet with LWAPP header and sends over to the AR.
                          It applies ciphering/authentication based on AR-AP security.
                   - AR receives the packet and validates the authentication of the station.
                   - AR finds out this destination MAC address belongs to some other AP and sends
                        the packet to that AP after encapsulating with 802.11 and LWAPP headers.
                   - AP2 receives the packet and applies any unicast ciphering and sends the packet to
                      destination station.

           Broadcast traffic from a wireless station to all stations of that network (SSID):
                  -  Corresponding AP receives the broadcast packet from the station.
                  -   It decrypts using global cipher key.
                  -   Passes this packet onto AR after encapsulating with LWAPP.
                  -   AR receives the packet and validates it.
                  -  AR now should find out all APs corresponding to the same SSID.
                  -   For each AP
                           AR encapsulates the packet with 802.11 and LWAPP header
                              and send it over to the AP.
                           AP decapsulates the LWAPP header and applies global cipher key and sends
                                the packet to air.
               
          Is that the flow envisages as part of LWAPP?
 Thanks
 Rama Krishna Prasad
 Intoto Software (India) Pvt Ltd.


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp



_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

From pcalhoun@airespace.com  Wed Jul 23 21:04:54 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 23 Jul 2003 13:04:54 -0700
Subject: [Lwapp] Broadcast/Multicast packet flow
Message-ID: <40301581B2962B448690A023EF16DFE1DC52C6@bsn-mail-01.bstormnetworks.com>

All 802.11 MACs that I am aware of handle encryption in hardware. It is =
part of standard MACs, but for other encryption algorithms that will be =
employed in the future where the MACs do not have hardware support, then =
it would make sense to terminate this in the AR.

btw, policy enforcement in the AR is better because you have a broader =
view of the network (many cells vs. single cell), so you can identify =
certain forms of attacks much better.

PatC
-----Original Message-----
From:	Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent:	Wed 7/23/2003 12:43 PM
To:	Pat R. Calhoun; rkp@intotoinc.com; lwapp@frascone.com
Cc:=09
Subject:	RE: [Lwapp] Broadcast/Multicast packet flow
If this procedure is what we envision for 802.11 data handling, then the =
AP is responsible
for handling the encryption/ decryption of over the air packets. Now, if =
such a heavy operation is done at the AP, why not handle the traffic =
right there and then, why
encapsulte it to AR?
I am not quite sure if I buy the antenna diversity argument that
 Marcus brought up at the meeting.=20
That would only be useful, if the standards allow a STA send packets
to multiple APs on the same frequency. CDMA soft handover procedure =
works because the
adjacent base station frequencies are the same, I thought WLAN has a =
serious frequency
planning schema.
In the same way I am hesitant, if encapsulating packets to AR, allows =
the AR to know RSSIs (I am not sure what 802.11K or the RRM group is up =
to).=20
Policy enforcment also should be done right when the packets hit the =
network, if
the AP can handle encryption, it can definitely handle security policy =
and it should be able to handle a few token bucket filters as well.

Puzzled,

Madjid

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, July 22, 2003 8:02 AM
To: rkp@intotoinc.com; lwapp@frascone.com
Subject: RE: [Lwapp] Broadcast/Multicast packet flow


sounds right.

PatC
-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent:	Mon 7/21/2003 8:47 PM
To:	lwapp@frascone.com
Cc:=09
Subject:	[Lwapp] Broadcast/Multicast packet flow
Hi,
          I am trying to understand the packet flow between wireless =
stations
          and AR with several APs in between. Appreciate your feedback.
         =20
          Assumptions:
               Only Layer2 wireless switching with 802.1x key management =
and
               authentication in this deployment.
               Given SSID (network) is supported by multiple APs.

          Unicast traffic between wireless station1 to wireless station =
2 belonging to
              the same AP and SSID:
                  - AP receives the packet from station 1.
                  - AP de-ciphers it.
                  - Since it is data packet, it encapsulates with LWAPP =
header and=20
                         apply any security on the packet and send it =
over to AR.
                  -  AR de-capsulate and removes LWAPP header/802.11 =
header and validates
                        whether this station is successfully =
authenticated or not.
                  - Then it finds out that this packet has to go same =
AP, based on the destination
                     MAC address in 802.3 packet. AR encapsulates the =
packet with 802.11=20
                     and LWAPP header and applies any security needed =
between AR and AP.
                 -   AP receives it, decapsulates the LWAPP header.
                 -   AP encrypts the packet with TKIP RC4/RSN unicast =
key and passes it onto the
                       destination station.

           Unicast traffic between wireless stations 1 of AP 1 TO =
wireless station 2 of AP 2 and
                    stations belong to same SSID.
                   - AP1 receives the 802.11 encapsulated 802.3 packet =
from wireless station 1.
                   - AP1 de-cipher it using unicast cipher key.
                   - AP1 encapsulates the 802.11 packet with LWAPP =
header and sends over to the AR.
                          It applies ciphering/authentication based on =
AR-AP security.
                   - AR receives the packet and validates the =
authentication of the station.
                   - AR finds out this destination MAC address belongs =
to some other AP and sends
                        the packet to that AP after encapsulating with =
802.11 and LWAPP headers.
                   - AP2 receives the packet and applies any unicast =
ciphering and sends the packet to
                      destination station.

           Broadcast traffic from a wireless station to all stations of =
that network (SSID):
                  -  Corresponding AP receives the broadcast packet from =
the station.
                  -   It decrypts using global cipher key.
                  -   Passes this packet onto AR after encapsulating =
with LWAPP.
                  -   AR receives the packet and validates it.
                  -  AR now should find out all APs corresponding to the =
same SSID.
                  -   For each AP
                           AR encapsulates the packet with 802.11 and =
LWAPP header
                              and send it over to the AP.
                           AP decapsulates the LWAPP header and applies =
global cipher key and sends
                                the packet to air.
              =20
          Is that the flow envisages as part of LWAPP?
 Thanks
 Rama Krishna Prasad
 Intoto Software (India) Pvt Ltd.


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp



_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp




From pcalhoun@airespace.com  Wed Jul 23 23:47:06 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 23 Jul 2003 15:47:06 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC52D6@bsn-mail-01.bstormnetworks.com>

> If the operators want a client-less solution, they can stay with =
web-based
> login hackery (is there any alternative??). Obviously this is not =
adequately
> secure, and they will have to move on. Any reasonable wireless =
security
> requires client support.
>=20
> As for IPsec and PANA, one more time, PANA does not mandate you to use =
the
> keys with IPsec. You can use them with link-layer ciphering. For =
example,
> you can bootstrap your WEP keys (legacy network) using PANA.

These are PANA discussions and belong in the PANA mailing list. Let's =
stop this please.
=20
>> Ah - so change the PANA charter to solve the CAPWAP problem?
>
> Why? We are not going to update the charter each time we realize where =
PANA
> can be used.

Unfortunately (or fortunately) that's the way things work in the IETF. =
You can't just change your WG direction (or start tackling new problems) =
without a charter change, but again, this is a topic for the PANA WG so =
let's leave this alone.

> If this is the=20
> PANA architecture, then it should be clear, because so far, it has not =
been.

> PANA is a protocol, not an architecture. You can use it in any =
architecture
> you like, as long as you follow the protocol design. If you want to =
see
> mention of using keys with L2 ciphers, please read the latest Problem
> Statement and Usage Scenarios draft.

I did (just now) and CAPWAP & PANA are two COMPLETELY different problem =
spaces. So let's let this one die too.


>> How would you coordinate the session keys
>> between the devices? etc, etc, etc.
>
> Please explain what keys, what devices, what is the problem ???

I think it may be a good idea to read the draft.

PatC


From dromasca@avaya.com  Thu Jul 24 00:07:12 2003
From: dromasca@avaya.com (Romascanu, Dan (Dan))
Date: Thu, 24 Jul 2003 02:07:12 +0300
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: 


> -----Original Message-----
> From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
> Sent: 23 July, 2003 12:26 AM
> To: sarikaya@ieee.org
> Cc: lwapp@frascone.com
> Subject: RE: [Lwapp] Certificates, Discovery Request/Reply,=20
> and validation.
>=20
>=20
> > This sounds OK, but LWAPP is discovery + configuration=20
> protocol, taking=20
> > discovery out, as per Marcus' presentation, SNMP is IETF's=20
> protocol for=20
> > configuration.
> > How are you going to deal with this?
>=20
> One can build products using a whole collection of protocols,=20
> and then try to determine what the interactions between each=20
> protocol should be handled. For instance, we followed the=20
> exact same path with L2TP (and PPTP, of course). would it=20
> have been possible to use SNMP to modify modem parameters on=20
> the access server? Sure, but it really gets ugly from an=20
> implementation stand-point.
>=20
> So I view this as the exact same. Yes, one can use SNMP to=20
> pull/push information  in/out of the AP, but at what cost? If=20
> it requires that we now standardize the interactions between=20
> all protocols, that would be even more complex.
>=20
> Now that you mention it, why isn't routing established using=20
> SNMP? It should cetainly be possible for routing peers to=20
> simply push routes using a well defined IP route MIB, no?
>=20

To add to this, SNMP is NOT the 'IETF's protocol for configuration'. See =
RFC 3535 and the Netconf WG charter.=20

Regards,

Dan

>=20

From rkp@intotoinc.com  Thu Jul 24 04:33:06 2003
From: rkp@intotoinc.com (Rama krishna prasad)
Date: Thu, 24 Jul 2003 09:03:06 +0530
Subject: [Lwapp] LWAPP
Message-ID: <3F1F5372.2020803@intotoinc.com>

Hi,
    Can I assume that SSID and WLANID have one-to-one correspondence?
    OR does RADIO-ID+WLANID combination correspond to one SSID?
Thanks
Rama Krishna Prasad
Intoto Software (India) Pvt. Ltd.



From pcalhoun@airespace.com  Thu Jul 24 13:48:40 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Thu, 24 Jul 2003 05:48:40 -0700
Subject: [Lwapp] LWAPP
Message-ID: <40301581B2962B448690A023EF16DFE1DC52DF@bsn-mail-01.bstormnetworks.com>

The former, but since was ambiguous to you, it should be cleaned up in =
the document.

Thanks,

PatC


-----Original Message-----
From:	Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent:	Wed 7/23/2003 8:33 PM
To:	lwapp@frascone.com
Cc:=09
Subject:	[Lwapp] LWAPP
Hi,
    Can I assume that SSID and WLANID have one-to-one correspondence?
    OR does RADIO-ID+WLANID combination correspond to one SSID?
Thanks
Rama Krishna Prasad
Intoto Software (India) Pvt. Ltd.


_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp




From esadot@avaya.com  Thu Jul 24 14:43:52 2003
From: esadot@avaya.com (Sadot, Emek (Emek))
Date: Thu, 24 Jul 2003 16:43:52 +0300
Subject: [Lwapp] Broadcast/Multicast packet flow
Message-ID: 


-----Original Message-----
From: Rama krishna prasad [mailto:rkp@intotoinc.com]
Sent: Wednesday, 23 July, 2003 6:55 AM
To: Sadot, Emek (Emek)
Cc: lwapp@frascone.com
Subject: Re: [Lwapp] Broadcast/Multicast packet flow

Hi sadot,

Thank you for the feedback.

You are right that there is no difference between first two scenarios, =
except for
some simple conditions in the implementation. We are thinking of =
implementing this
by exposing AP+SSID number combination as bridge port. With this, L2 =
bridging takes
care of sending packets belonging to some other AP and also takes care =
of multicast
and broadcast packets. Bridge drops the packet if it needs to send the =
packet onto
the same port from which the packet came originally. That is why, we are =
thinking of
taking care of same AP mobiles in LWAPP layer and everything else in =
bridge layer.
[Emek] AR to AP downstream packets can simply be an Ethernet packet. =
Downstream direction doesn't call for any encapsulation.
You are talking about cross VLAN domain roaming. Do you mean =
cross-subnet roaming?
[Emek] yes, though I believe cross-subnet it's a wrong term. The rule of =
thumb is whether or not a STA can reach its default router after =
roaming, and that has nothing to do with cross-subnet only with cross =
VLAN domain.=20
If all subnets in the same AR, then there is no issue. But, if they are =
across multiple ARs,
then mobile-IP can be used to avoid stateful session transfer across =
ARs. Do you mean
anything else?

Thanks
Rama Krishna Prasad
Intoto Software (India) Pvt. Ltd.



Sadot, Emek (Emek) wrote:

>Rama,
>
>I lack to see the difference between the first two scenarios. Besides =
the destination-MAC-to-AP-mapping stage, which takes place at the AR, =
the sequence of events should be identical regardless destination =
station position (associated to same AP as the source or not).
>
>I am not sure what is the proposed architecture in regard to broadcast, =
however encapsulating each packet and send it as a unicast to =
corresponds AP sounds to me as unacceptable solution. That's where =
handling 802.11 packets at the AR is a disadvantage.
>
>The case is different if the source station crossed VLAN domain while =
roamed or if destination station had crossed VLAN domain while roamed.
>
>Emek
>
>-----Original Message-----
>From: Rama krishna prasad [mailto:rkp@intotoinc.com]
>Sent: Tuesday, 22 July, 2003 6:47 AM
>To: lwapp@frascone.com
>Subject: [Lwapp] Broadcast/Multicast packet flow
>
>Hi,
>          I am trying to understand the packet flow between wireless =
stations
>          and AR with several APs in between. Appreciate your feedback.
>       =20
>          Assumptions:
>               Only Layer2 wireless switching with 802.1x key =
management and
>               authentication in this deployment.
>               Given SSID (network) is supported by multiple APs.
>
>          Unicast traffic between wireless station1 to wireless station =
2 belonging to
>              the same AP and SSID:
>                  - AP receives the packet from station 1.
>                  - AP de-ciphers it.
>                  - Since it is data packet, it encapsulates with LWAPP =
header and
>                         apply any security on the packet and send it =
over to AR.
>                  -  AR de-capsulate and removes LWAPP header/802.11 =
header and validates
>                        whether this station is successfully =
authenticated or not.
>                  - Then it finds out that this packet has to go same =
AP, based on the destination
>                     MAC address in 802.3 packet. AR encapsulates the =
packet with 802.11
>                     and LWAPP header and applies any security needed =
between AR and AP.
>                 -   AP receives it, decapsulates the LWAPP header.
>                 -   AP encrypts the packet with TKIP RC4/RSN unicast =
key and passes it onto the
>                       destination station.
>
>           Unicast traffic between wireless stations 1 of AP 1 TO =
wireless station 2 of AP 2 and
>                    stations belong to same SSID.
>                   - AP1 receives the 802.11 encapsulated 802.3 packet =
from wireless station 1.
>                   - AP1 de-cipher it using unicast cipher key.
>                   - AP1 encapsulates the 802.11 packet with LWAPP =
header and sends over to the AR.
>                          It applies ciphering/authentication based on =
AR-AP security.
>                   - AR receives the packet and validates the =
authentication of the station.
>                   - AR finds out this destination MAC address belongs =
to some other AP and sends
>                        the packet to that AP after encapsulating with =
802.11 and LWAPP headers.
>                   - AP2 receives the packet and applies any unicast =
ciphering and sends the packet to
>                      destination station.
>
>           Broadcast traffic from a wireless station to all stations of =
that network (SSID):
>                  -  Corresponding AP receives the broadcast packet =
from the station.
>                  -   It decrypts using global cipher key.
>                  -   Passes this packet onto AR after encapsulating =
with LWAPP.
>                  -   AR receives the packet and validates it.
>                  -  AR now should find out all APs corresponding to =
the same SSID.
>                  -   For each AP
>                           AR encapsulates the packet with 802.11 and =
LWAPP header
>                              and send it over to the AP.
>                           AP decapsulates the LWAPP header and applies =
global cipher key and sends
>                                the packet to air.
>            =20
>          Is that the flow envisages as part of LWAPP?
> Thanks
> Rama Krishna Prasad
> Intoto Software (India) Pvt Ltd.
>
>
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>
>=20
>


From behcet.sarikaya@alcatel.com  Wed Jul 23 00:39:25 2003
From: behcet.sarikaya@alcatel.com (Behcet Sarikaya)
Date: Tue, 22 Jul 2003 18:39:25 -0500
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
References: <40301581B2962B448690A023EF16DFE1DC528A@bsn-mail-01.bstormnetworks.com>
Message-ID: <3F1DCB2D.5030901@alcatel.com>

--------------040601060006050905090209
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



Pat R. Calhoun wrote:

>>This sounds OK, but LWAPP is discovery + configuration protocol, taking 
>>discovery out, as per Marcus' presentation, SNMP is IETF's protocol for 
>>configuration.
>>How are you going to deal with this?
>>    
>>
>
>One can build products using a whole collection of protocols, and then try to determine what the interactions between each protocol should be handled. For instance, we followed the exact same path with L2TP (and PPTP, of course). would it have been possible to use SNMP to modify modem parameters on the access server? Sure, but it really gets ugly from an implementation stand-point.
>
>So I view this as the exact same. Yes, one can use SNMP to pull/push information  in/out of the AP, but at what cost? If it requires that we now standardize the interactions between all protocols, that would be even more complex.
>
>Now that you mention it, why isn't routing established using SNMP? It should cetainly be possible for routing peers to simply push routes using a well defined IP route MIB, no?
>
 I glanced thru the two RFCs for L2TP and PPTP, they are basically call 
state control and management protocols, providing IP-based tunneling in 
L2 domain. I could not see how such things could be achieved, e.g. by 
defining a MIB?
However, it seems that most of what LWAPP tries to do could probably be 
achieved by way of SNMP set operations, so this should probably be the 
basis of discussion in this ML.

>
>  
>
>>In the run state, do AP and AR continue to communicate using LWAPP 
>>encapsulation, or or revert to 802.3 frame encapsulation?
>>    
>>
>
>always 802.11.
>
>PatC
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>
>  
>


--------------040601060006050905090209
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit




  
  






Pat R. Calhoun wrote:



  

    
This sounds OK, but LWAPP is discovery + configuration protocol, taking 
discovery out, as per Marcus' presentation, SNMP is IETF's protocol for 
configuration.
How are you going to deal with this?
    

  

  

One can build products using a whole collection of protocols, and then try to determine what the interactions between each protocol should be handled. For instance, we followed the exact same path with L2TP (and PPTP, of course). would it have been possible to use SNMP to modify modem parameters on the access server? Sure, but it really gets ugly from an implementation stand-point.

So I view this as the exact same. Yes, one can use SNMP to pull/push information  in/out of the AP, but at what cost? If it requires that we now standardize the interactions between all protocols, that would be even more complex.

Now that you mention it, why isn't routing established using SNMP? It should cetainly be possible for routing peers to simply push routes using a well defined IP route MIB, no?



 I glanced thru the two RFCs for L2TP and PPTP, they are basically call state
control and management protocols, providing IP-based tunneling in L2 domain.
I could not see how such things could be achieved, e.g. by defining a MIB?


However, it seems that most of what LWAPP tries to do could probably be achieved
by way of SNMP set operations, so this should probably be the basis of discussion
in this ML.



  

  

  

    
In the run state, do AP and AR continue to communicate using LWAPP 
encapsulation, or or revert to 802.3 frame encapsulation?
    

  

  

always 802.11.

PatC
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

  








--------------040601060006050905090209--


From pcalhoun@airespace.com  Fri Jul 25 01:24:35 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Thu, 24 Jul 2003 17:24:35 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC532B@bsn-mail-01.bstormnetworks.com>

>  I glanced thru the two RFCs for L2TP and PPTP, they are basically =
call=20
> state control and management protocols, providing IP-based tunneling =
in=20
> L2 domain. I could not see how such things could be achieved, e.g. by=20
> defining a MIB?

Having more than just glanced at the protocol (I was one of the authors =
of the original PPTP protocol way back), and having implemented L2TP, I =
frankly disagree.

The LWAPP protocol *does* tunneling. It has a protocol to setup tunnels, =
and to "configure" the endpoint, much in the same way that L2TP can send =
MTU and framing information from the PNS to the PAC (well, the L2TP =
equivalents anyways).

So, please, explain how this is different? I can cut and paste from the =
L2TP RFC if this makes it easier, but I'm sure you can find that info as =
well.

> However, it seems that most of what LWAPP tries to do could probably =
be=20
> achieved by way of SNMP set operations, so this should probably be the =

> basis of discussion in this ML.

ok, let's tunnels packets within SNMP. Great idea.

PatC

From sarikaya@ieee.org  Fri Jul 25 16:08:23 2003
From: sarikaya@ieee.org (Behcet Sarikaya)
Date: Fri, 25 Jul 2003 10:08:23 -0500
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
References: <40301581B2962B448690A023EF16DFE1DC532B@bsn-mail-01.bstormnetworks.com>
Message-ID: <3F2147E7.4020400@yahoo.com>

--------------060403000009050008060509
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Sorry again the sender address was wrong in the previous message.

Pat R. Calhoun wrote:

>> I glanced thru the two RFCs for L2TP and PPTP, they are basically call 
>>state control and management protocols, providing IP-based tunneling in 
>>L2 domain. I could not see how such things could be achieved, e.g. by 
>>defining a MIB?
>>    
>>
>
>Having more than just glanced at the protocol (I was one of the authors of the original PPTP protocol way back), and having implemented L2TP, I frankly disagree.
>
>The LWAPP protocol *does* tunneling. It has a protocol to setup tunnels, and to "configure" the endpoint, much in the same way that L2TP can send MTU and framing information from the PNS to the PAC (well, the L2TP equivalents anyways).
>
>So, please, explain how this is different? I can cut and paste from the L2TP RFC if this makes it easier, but I'm sure you can find that info as well.
>
>  
>
>>However, it seems that most of what LWAPP tries to do could probably be 
>>achieved by way of SNMP set operations, so this should probably be the 
>>basis of discussion in this ML.
>>    
>>
>
>ok, let's tunnels packets within SNMP. Great idea.
>
>PatC
>_______________________________________________
>  
>
I think that you are misinterpreting my comments. The comparison is SNMP 
+ LWAPP MIB with LWAPP taken the discovery part out.
However, CAPWAP activity is an interesting one, it may succeed, 
especially with so many good experts like yourself on board.
--behcet

--------------060403000009050008060509
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit




  


Sorry again the sender address was wrong in the previous message.



Pat R. Calhoun wrote:



  

    
 I glanced thru the two RFCs for L2TP and PPTP, they are basically call 
state control and management protocols, providing IP-based tunneling in 
L2 domain. I could not see how such things could be achieved, e.g. by 
defining a MIB?
    

  

  

Having more than just glanced at the protocol (I was one of the authors of the original PPTP protocol way back), and having implemented L2TP, I frankly disagree.

The LWAPP protocol *does* tunneling. It has a protocol to setup tunnels, and to "configure" the endpoint, much in the same way that L2TP can send MTU and framing information from the PNS to the PAC (well, the L2TP equivalents anyways).

So, please, explain how this is different? I can cut and paste from the L2TP RFC if this makes it easier, but I'm sure you can find that info as well.

  

  

    
However, it seems that most of what LWAPP tries to do could probably be 
achieved by way of SNMP set operations, so this should probably be the 
basis of discussion in this ML.
    

  

  

ok, let's tunnels packets within SNMP. Great idea.

PatC
_______________________________________________
  



I think that you are misinterpreting my comments. The comparison is SNMP
+ LWAPP MIB with LWAPP taken the discovery part out.

However, CAPWAP activity is an interesting one, it may succeed, especially
with so many good experts like yourself on board.

--behcet




--------------060403000009050008060509--


From behcet.sarikaya@alcatel.com  Fri Jul 25 16:07:22 2003
From: behcet.sarikaya@alcatel.com (Behcet Sarikaya)
Date: Fri, 25 Jul 2003 10:07:22 -0500
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
References: <40301581B2962B448690A023EF16DFE1DC532B@bsn-mail-01.bstormnetworks.com>
Message-ID: <3F2147AA.9030005@alcatel.com>

--------------040309020003000401060508
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



Pat R. Calhoun wrote:

>> I glanced thru the two RFCs for L2TP and PPTP, they are basically call 
>>state control and management protocols, providing IP-based tunneling in 
>>L2 domain. I could not see how such things could be achieved, e.g. by 
>>defining a MIB?
>>    
>>
>
>Having more than just glanced at the protocol (I was one of the authors of the original PPTP protocol way back), and having implemented L2TP, I frankly disagree.
>
>The LWAPP protocol *does* tunneling. It has a protocol to setup tunnels, and to "configure" the endpoint, much in the same way that L2TP can send MTU and framing information from the PNS to the PAC (well, the L2TP equivalents anyways).
>
>So, please, explain how this is different? I can cut and paste from the L2TP RFC if this makes it easier, but I'm sure you can find that info as well.
>
>  
>
>>However, it seems that most of what LWAPP tries to do could probably be 
>>achieved by way of SNMP set operations, so this should probably be the 
>>basis of discussion in this ML.
>>    
>>
>
>ok, let's tunnels packets within SNMP. Great idea.
>
>PatC
>_______________________________________________
>  
>
I think that you are misinterpreting my comments. The comparison is SNMP 
+ LWAPP MIB with LWAPP taken the discovery part out.
However, CAPWAP activity is an interesting one, it may succeed, 
especially with so many good experts like yourself on board.
--behcet

--------------040309020003000401060508
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit




  






Pat R. Calhoun wrote:



  

    
 I glanced thru the two RFCs for L2TP and PPTP, they are basically call 
state control and management protocols, providing IP-based tunneling in 
L2 domain. I could not see how such things could be achieved, e.g. by 
defining a MIB?
    

  

  

Having more than just glanced at the protocol (I was one of the authors of the original PPTP protocol way back), and having implemented L2TP, I frankly disagree.

The LWAPP protocol *does* tunneling. It has a protocol to setup tunnels, and to "configure" the endpoint, much in the same way that L2TP can send MTU and framing information from the PNS to the PAC (well, the L2TP equivalents anyways).

So, please, explain how this is different? I can cut and paste from the L2TP RFC if this makes it easier, but I'm sure you can find that info as well.

  

  

    
However, it seems that most of what LWAPP tries to do could probably be 
achieved by way of SNMP set operations, so this should probably be the 
basis of discussion in this ML.
    

  

  

ok, let's tunnels packets within SNMP. Great idea.

PatC
_______________________________________________
  



I think that you are misinterpreting my comments. The comparison is SNMP
+ LWAPP MIB with LWAPP taken the discovery part out.

However, CAPWAP activity is an interesting one, it may succeed, especially
with so many good experts like yourself on board.

--behcet




--------------040309020003000401060508--


From kempf@docomolabs-usa.com  Sat Jul 26 14:12:27 2003
From: kempf@docomolabs-usa.com (James Kempf)
Date: Sat, 26 Jul 2003 15:12:27 +0200
Subject: [Lwapp] Charter Proposal
References: <007501c34cf1$95eaacc0$ab6015ac@dclkempt40> <2052821.1058870316@[10.1.1.130]>
Message-ID: <017201c353a8$64c30760$2a6015ac@dclkempt40>

Marcus,


> > Develop a protocol controlling wireless access points with the following
> > features:
> >
> > .Independent of wireless link protocol.
> > .Discovery of a CAPWAP manager (AR, IP addressable switch).
>
> I would not include this. SLP and DHCP might just work
>

SLP requires a service type template. This would need to be developed. Also,
a DHCP option of some type might be needed. Wouldn't these be appropriate
work items if the WG decided to go with (preferably) one or (possibly) more
standardized discovery mechanisms?

                jak


From kempf@docomolabs-usa.com  Sat Jul 26 19:53:05 2003
From: kempf@docomolabs-usa.com (James Kempf)
Date: Sat, 26 Jul 2003 20:53:05 +0200
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
Message-ID: <017601c353a8$7a1259e0$2a6015ac@dclkempt40>

Alper, Behcet & Yoshi,

The intent here is to do something like iSCSI. As in that case, there are a
group of companies (one of which is DoCoMo Labs USA) that would like a
standard. They are requesting IETF help in doing it. Concensus at the BOF
was to move forward with a Working Group, we are discussing the charter. The
charter is to be focussed on designing a protocol, i.e. a solution, not
requirements, problem statement or anything of the sort.  If you have
something constructive to say about what should be in the charter, please do
so, but that should be the scope of the discussion. The bullet points for
the charter I sent a week ago, which Marcus Brunner commented on, are a good
starting point.


            jak

----- Original Message ----- 
From: "Alper Yegin" 
To: "Pat R. Calhoun" ; 
Cc: 
Sent: Wednesday, July 23, 2003 4:00 AM
Subject: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.


> >> I'm not comparing PANA with LWAPP. This does not make sense. LWAPP is
more
> >> like an architecture that tackles several problems. I'm trying to
understand
> >> what each one of these problems are and see if there are alternative
> >> solutions that should be considered.
> > ok, which one, specifically?
>
> I've discussed these before, but nevertheless:
> - Configuring APs: SNMP, COPS, etc.
> - Migration of AAA stuff from AP to AR: PANA
> - Auth/Authz between AP and AR: PANA (if physical security is not good
>   enough)
> - Migration of per-packet ciphering from AP to AR: Either use IPsec with
AR,
>   or tunnel 802.11 frames on the wired segment. Whether the latter should
be
>   done at IEEE vs. IETF is debatable.
>
> Did I miss any other problems we are tackling here?
>
> >
> >> PANA comes into the picture when we talk about the AAA between hosts
and AR,
> >> and AA_ between the AP and AR. I don't see PANA's relevance to all the
other
> >> bells and whistles LWAPP provides.
> >
> > correct, but somehow you keep asking the question. If we agree that
we've
> > beaten this horse to it's full extent, then I'll gladly oblige...
>
> Please see above.
>
> >
> >>>
> >>> We seem to be focused on EAP only, but again, I think the problem is
much
> >>> greater in scope - hence CAPWAP.
> >>>
> >>
> >> Is there a documented list of problems, like a problem statement? It is
> >> really hard to reverse engineer the LWAPP to undertsand the problems we
are
> >> solving here.
> >
> > Other than what's in the current document (which I assume you've read),
no.
> > However, the problems are well understood enough that many vendors are
> > actively building, or shipping, products, all with the same architecture
and a
> > protocol that looks like LWAPP.
> >
> > If the IESG believes that we need to go down the problem statement path,
and
> > tack on another 12 months of effort to CAPWAP, then we can consider it.
But
> > personally, having gone through some of this at the IETF, and the fact
that
> > this is a current problem that is known, I think that the players
involve all
> > know what we need.
>
> I still feel like missing couple of necessary steps here if we already
jump
> to solution evaluation stage.
>
> Alper
>
> >
> >
> > PatC
> >
> >
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>


From kempf@docomolabs-usa.com  Sat Jul 26 19:55:51 2003
From: kempf@docomolabs-usa.com (James Kempf)
Date: Sat, 26 Jul 2003 20:55:51 +0200
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
References: 
Message-ID: <017701c353a8$7d03ad70$2a6015ac@dclkempt40>

Please send text.

            jak

----- Original Message ----- 
From: "Alper Yegin" 
To: "David Molnar" 
Cc: 
Sent: Wednesday, July 23, 2003 4:17 AM
Subject: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.


> On 7/22/03 1:49 PM, "David Molnar"  wrote:
>
> >>
> >> Is there a documented list of problems, like a problem statement? It is
> >> really hard to reverse engineer the LWAPP to undertsand the problems we
> >> are solving here.
> >
> > Well, we do have the proposed charter points for CAPWAP posted by James
> > Kempf. I have not seen much discussion of these on this list so far.
What
> > do you think of them?
>
> Inadequate. One should expand on this. The following text does not fully
> explain what the problem is, how it cannot be solved by the current
> mechanisms, what does "acquisition"-"configuration"-"monitoring"-
> "controlling load" entail...
>
>     Develop a protocol controlling wireless access points with the
following
>     features:
>
>     .Independent of wireless link protocol.
>     .Discovery of a CAPWAP manager (AR, IP addressable switch).
>     .Acquisition of APs by CAPWAP manager.
>     .Configuration and monitoring of wireless link by CAPWAP manager.
>     .Partially and/or fully terminate the wireless MAC layer at the CAPWAP
>     manager.
>        -Including security of host traffic.
>        -NOT intended to define changes in MAC!
>     .Control of AP host load.
>     .Security for CAPWAP signaling.
>
> Alper
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>


From kempf@docomolabs-usa.com  Sat Jul 26 20:23:07 2003
From: kempf@docomolabs-usa.com (James Kempf)
Date: Sat, 26 Jul 2003 21:23:07 +0200
Subject: PANA v.s. LWAPP: a false dichotomy (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <40301581B2962B448690A023EF16DFE1DC52A0@bsn-mail-01.bstormnetworks.com>
Message-ID: <01ac01c353ab$5c9aaea0$2a6015ac@dclkempt40>

Pat,

Let's try to avoid an argument on the list about the relative merits of one
architecture v.s. another. There is plenty of room for both these approachs
in the IETF. The intent of LWAPP is to do something quickly to satisfy
vendor requests. The intent of PANA is more long term, as you point out.
There is no reason why these two approaches can't co-exist. After all, the
IETF currently has no less than 3 working groups doing work on instant
messaging protocols, and the architectural territory covered by these
protocols is much closer than that covered by PANA and LWAPP.

Let's stick to discussing the charter, around the bullet points I sent out.
We need to get some text around those.

            jak


----- Original Message ----- 
From: "Pat R. Calhoun" 
To: "Alper Yegin" ; 
Cc: 
Sent: Wednesday, July 23, 2003 3:25 PM
Subject: RE: [Lwapp] Certificates, Discovery Request/Reply, and validation.


> > I've discussed these before, but nevertheless:
> > - Configuring APs: SNMP, COPS, etc.
> > - Migration of AAA stuff from AP to AR: PANA
> > - Auth/Authz between AP and AR: PANA (if physical security is not good
> >   enough)
> > - Migration of per-packet ciphering from AP to AR: Either use IPsec with
AR,
> >   or tunnel 802.11 frames on the wired segment. Whether the latter
should be
> >   done at IEEE vs. IETF is debatable.
> >
> > Did I miss any other problems we are tackling here?
>
> Apparently. I think the key point that you are missing here is the 'LW' in
LWAPP. Specifically, the goal is to reduce the complexity of the AP, which
is something that we are hearing both customers and AP manufacturers want.
The proposal above requires so much code in the AP that one has to question
what the advantages are.
>
> I think we've already had the IEEE vs. IETF discussion, so unless you have
a clear explanation of why this is a MAC or PHY problem, please state it.
>
> >> correct, but somehow you keep asking the question. If we agree that
we've
> >> beaten this horse to it's full extent, then I'll gladly oblige...
> >
> > Please see above.
>
> I see, so the horse isn't dead....
>
> > I still feel like missing couple of necessary steps here if we already
jump
> > to solution evaluation stage.
>
> Correct. I think the part that's missing here is that unlike other topics
in the IETF that are mostly around research topics (build it and they will
come), this is the inverse. Products are shipping, and many vendors in this
space wish to ensure some form of interoperability between their devices.
>
> I understand that you're trying to find some market for the PANA
architecture, and I'm sure there are customers, but I think that the vendors
in this particular space have already made an architectural decision. If the
IETF wishes to standardize on an architecture the players in the 802.11
space are not interested in, then I think it's missed its mark.
>
> Further, I think that your proposal does not benefit the Internet
Community, which is looking for lowering the cost of AP deployments and
operation. What you proposal does is drive the standards process much longer
with dubious advantages.
>
> PatC
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>
>


From alper@docomolabs-usa.com  Sat Jul 26 20:40:29 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Sat, 26 Jul 2003 12:40:29 -0700
Subject: [Lwapp] Re: PANA v.s. LWAPP: a false dichotomy (was: Re: [Lwapp]
 Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: <01ac01c353ab$5c9aaea0$2a6015ac@dclkempt40>
Message-ID: 

Hi James,

> Pat,
> 
> Let's try to avoid an argument on the list about the relative merits of one
> architecture v.s. another. There is plenty of room for both these approachs
> in the IETF. The intent of LWAPP is to do something quickly to satisfy
> vendor requests. The intent of PANA is more long term, as you point out.
> There is no reason why these two approaches can't co-exist. After all, the
> IETF currently has no less than 3 working groups doing work on instant
> messaging protocols, and the architectural territory covered by these
> protocols is much closer than that covered by PANA and LWAPP.

This is an incorrect characterization of this discussion. Nobody is
proposing to use PANA instead of LWAPP. As I said several times by now, this
is not possible as LWAPP attempts solving several problems at the same time.
Whether this is a good idea or not is a separate discussion. All I'm
pointing is that some of the problems raised in this forum can already be
solved by PANA. 

It is not true that intent of PANA is long-term. And I'm still looking for
some technical clues on what architectural difference people are referring
to. (I heard that they are different enough many times, but no one has
explained how they are different.....)

Alper


> 
> Let's stick to discussing the charter, around the bullet points I sent out.
> We need to get some text around those.
> 
>           jak
> 
> 
> ----- Original Message -----
> From: "Pat R. Calhoun" 
> To: "Alper Yegin" ; 
> Cc: 
> Sent: Wednesday, July 23, 2003 3:25 PM
> Subject: RE: [Lwapp] Certificates, Discovery Request/Reply, and validation.
> 
> 
>>> I've discussed these before, but nevertheless:
>>> - Configuring APs: SNMP, COPS, etc.
>>> - Migration of AAA stuff from AP to AR: PANA
>>> - Auth/Authz between AP and AR: PANA (if physical security is not good
>>>   enough)
>>> - Migration of per-packet ciphering from AP to AR: Either use IPsec with
> AR,
>>>   or tunnel 802.11 frames on the wired segment. Whether the latter
> should be
>>>   done at IEEE vs. IETF is debatable.
>>> 
>>> Did I miss any other problems we are tackling here?
>> 
>> Apparently. I think the key point that you are missing here is the 'LW' in
> LWAPP. Specifically, the goal is to reduce the complexity of the AP, which
> is something that we are hearing both customers and AP manufacturers want.
> The proposal above requires so much code in the AP that one has to question
> what the advantages are.
>> 
>> I think we've already had the IEEE vs. IETF discussion, so unless you have
> a clear explanation of why this is a MAC or PHY problem, please state it.
>> 
>>>> correct, but somehow you keep asking the question. If we agree that
> we've
>>>> beaten this horse to it's full extent, then I'll gladly oblige...
>>> 
>>> Please see above.
>> 
>> I see, so the horse isn't dead....
>> 
>>> I still feel like missing couple of necessary steps here if we already
> jump
>>> to solution evaluation stage.
>> 
>> Correct. I think the part that's missing here is that unlike other topics
> in the IETF that are mostly around research topics (build it and they will
> come), this is the inverse. Products are shipping, and many vendors in this
> space wish to ensure some form of interoperability between their devices.
>> 
>> I understand that you're trying to find some market for the PANA
> architecture, and I'm sure there are customers, but I think that the vendors
> in this particular space have already made an architectural decision. If the
> IETF wishes to standardize on an architecture the players in the 802.11
> space are not interested in, then I think it's missed its mark.
>> 
>> Further, I think that your proposal does not benefit the Internet
> Community, which is looking for lowering the cost of AP deployments and
> operation. What you proposal does is drive the standards process much longer
> with dubious advantages.
>> 
>> PatC
>> _______________________________________________
>> Lwapp mailing list
>> Lwapp@frascone.com
>> http://mail.frascone.com/mailman/listinfo/lwapp
>> 
>> 
> 
> 


From carlw@mcsr-labs.org  Sun Jul 27 01:52:04 2003
From: carlw@mcsr-labs.org (carlw@mcsr-labs.org)
Date: Sat, 26 Jul 2003 20:52:04 -0400
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <232810-2200370270524394@M2W096.mail2web.com>

>> Concensus at the BOF
>> was to move forward with a Working Group, we=20
>> are discussing the charter=2E The
>> charter is to be focussed on designing a protocol, i=2Ee=2E=20
>> a solution, not requirements, problem statement or=20
>> anything of the sort=2E  If you have something constructive=20
>> to say about what should be in the charter,=20
>> please do so, but that should be the scope of the=20
>> discussion=2E The bullet points for
>> the charter I sent a week ago, which Marcus Brunner=20
>> commented on, are a good starting point=2E

Hi James,

   I agree we should focus the discussion on the charter=2E
   However, this may include the need for defining the
   problem space in a document so that all is clear and agreed=2E
   Discussion of the need for requirement specification
   is ok at this point of time as well=2E  Just because
   it was agreed to move from BOF to working group doesn't
   preclude the need for a post-bof discussion that may
   include scope and requirements debate=2E  I consider such
   discussion with in the scope of this charter discussion=2E

   This is not to say that we should get bogged down in
   such a discussion but only that I see that it is=20
   within the scope of the post-bof discusion in defining
   the charter=2E

   Thanks=2E

   Carl












--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E



From randy@psg.com  Sun Jul 27 19:17:37 2003
From: randy@psg.com (Randy Bush)
Date: Sun, 27 Jul 2003 11:17:37 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <232810-2200370270524394@M2W096.mail2web.com>
Message-ID: 



> I agree we should focus the discussion on the charter.  However,
> this may include the need for defining the problem space in a
> document so that all is clear and agreed.

i, for one, would appreciate a simple statement of what this work
is to accomplish and what it is not to accomplish.  as i said in
another forum

    let's think of it as requirements and road map, where are we
    going, why, and how are we going to get there.  and maybe
    where are we NOT going, why, and how do we plan to not get
    there.  and keep it simple.  if the requirements and road map
    can not be simple and done in a few weeks, then how will the
    results of the wg be simple enough to be achievable?

fyi, 'simple' means a page, two at most, of *very* targetted text.

and you should know that my instinctive reaction to "if the ietf
doesn't do it then X will do it," is "wonderful, we're doing too
much already.  let X screw it up and we can come back to it next
year if it is important."

randy


From dmolnar@eecs.harvard.edu  Sun Jul 27 19:38:13 2003
From: dmolnar@eecs.harvard.edu (David Molnar)
Date: Sun, 27 Jul 2003 14:38:13 -0400 (EDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
In-Reply-To: 
References: <232810-2200370270524394@M2W096.mail2web.com> 
Message-ID: 


On Sun, 27 Jul 2003, Randy Bush wrote:

> i, for one, would appreciate a simple statement of what this work
> is to accomplish and what it is not to accomplish.  as i said in
> another forum

As I understand it, the first main goal is this:

	Buy AP from vendor A and AR from vendor B and have them
	"just work" together.

This is of course really vague, but it seems to me this is the vision
driving LWAPP and part of the reason why so many people are interested in
the work. One way to proceed might be to define some minimal-as-possible
standard of what it means to have an AP and AR "just work" together and
then pare away any requirement not necessary to meet this service
standard.

For instance, we might say that station mobility and context transfer is
*not* part of the minimal service standard. Then we defer those issues
until after the initial work is done.

I recognize that this is the CAPWAP WG and so the scope is larger than
"light-weight"/split-MAC access points. At the same time, AR-AP protocol
standardization is a real, pressing problem in WG scope with great
interest and so serves as a useful focus for charter discussion.

-David

From randy@psg.com  Sun Jul 27 19:51:53 2003
From: randy@psg.com (Randy Bush)
Date: Sun, 27 Jul 2003 11:51:53 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
References: <232810-2200370270524394@M2W096.mail2web.com>
 
 
Message-ID: 

> I recognize that this is the CAPWAP WG

not yet, it ain't.

> so the scope is larger than "light-weight"/split-MAC access
> points.

i have yet to understand its scope.  others seem to be having a
similar problem.  perhaps someone should propose a simple
minimalist statement of purpose (with a bit more flesh than "just
work":-), and then we can let others justify expansions to it.

randy


From dmolnar@eecs.harvard.edu  Sun Jul 27 20:05:46 2003
From: dmolnar@eecs.harvard.edu (David Molnar)
Date: Sun, 27 Jul 2003 15:05:46 -0400 (EDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
In-Reply-To: 
References: <232810-2200370270524394@M2W096.mail2web.com> 
 
 
Message-ID: 


On Sun, 27 Jul 2003, Randy Bush wrote:

> > I recognize that this is the CAPWAP WG
>
> not yet, it ain't.

I'm sorry. I didn't mean to overstep any boundaries. I should have said
something like "discussion for the charter of a proposed CAPWAP WG."

-David

From randy@psg.com  Sun Jul 27 20:33:35 2003
From: randy@psg.com (Randy Bush)
Date: Sun, 27 Jul 2003 12:33:35 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
References: <232810-2200370270524394@M2W096.mail2web.com>
 
 
 
 
Message-ID: 

>>> I recognize that this is the CAPWAP WG
>> not yet, it ain't.
> I'm sorry. I didn't mean to overstep any boundaries.

nah.  not a problem.  i was just tryin' to say that there are some
very important steps between here and there, namely a very clear
and simple statement of goals and a road map of how to achieve
them.  given that, a charter should be a simple matter of normal
process.  but, from reading this mailing list, i really do not
have a firm understanding of this work, and that worries me.

randy


From cchaplin@sj.symbol.com  Tue Jul 29 01:30:10 2003
From: cchaplin@sj.symbol.com (Clint Chaplin)
Date: Mon, 28 Jul 2003 17:30:10 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and
 validation.
Message-ID: 

Well, I've got my own dead horse to flog....

The use of EAP/TLS to authenticate the AP to the AR will, I think, bloat =
up the AP to the point where it will be very difficult to call it "LW".  =
So far as I can tell, there are no Wi-Fi chipsets out there that implement =
PK, and standalone crypto chips that support PK are not cheap.  In either =
case, you will probably end up with an AP that is >more< complex than a =
standalone AP today.

And yes, I know about the efforts to have 802.1X mediated authentication =
between units in a network, including the AP to the switch it is connected =
to, but in no case have I heard of anybody using EAP/TLS authentication; =
it tends to be some sort of shared secret EAP method.

Clint (JOATMON) Chaplin

>>> "Pat R. Calhoun"  7/23/03 06:25:31 >>>

Apparently. I think the key point that you are missing here is the 'LW' in =
LWAPP. Specifically, the goal is to reduce the complexity of the AP, which =
is something that we are hearing both customers and AP manufacturers want. =
The proposal above requires so much code in the AP that one has to =
question what the advantages are.




From cchaplin@sj.symbol.com  Tue Jul 29 01:31:43 2003
From: cchaplin@sj.symbol.com (Clint Chaplin)
Date: Mon, 28 Jul 2003 17:31:43 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, and
 validation.
Message-ID: 

You talk about the architecture of LWAPP "splitting the MAC" between the =
AP and the AR, and yet you state that this is not a MAC problem.  I don't =
think you can have it both ways...

Clint (JOATMON) Chaplin

>>> "Pat R. Calhoun"  7/23/03 06:25:31 >>>

I think we've already had the IEEE vs. IETF discussion, so unless you have =
a clear explanation of why this is a MAC or PHY problem, please state it.




From dstanley@agere.com  Tue Jul 29 01:46:37 2003
From: dstanley@agere.com (Dorothy Stanley)
Date: Mon, 28 Jul 2003 19:46:37 -0500
Subject: [Lwapp] Certificates, Discovery Request/Reply, and	validation.
References: 
Message-ID: <3F25C3ED.1070705@agere.com>

--------------020807000207000900040306
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Clint,

I think one distinction is that "splitting" MAC functionality between 
processors,
or devices is an implementation decision on placement of functionality. 
 The definition
of what functions must be performed or supported is a MAC definition 
problem.
LWAPP concerns itself with the former, rather than the latter.

Discussion of partitioning of functionalty is not new. JEDEC-JC61 looked 
at partitioning
of PHY and MAC functionalty across radio components. At a number of public
forums, Microsoft had promoted its software partitioning proposals- 
enabling the split of
MAC functionality between the traditional MAC and PC host processors.

In LWAPP, no new MAC functionalty is being proposed. The discussion is 
around defining
a standard protocol which will enable placement of functionality in 
implementations - either in the AP or AR.

Dorothy

Clint Chaplin wrote:

>You talk about the architecture of LWAPP "splitting the MAC" between the AP and the AR, and yet you state that this is not a MAC problem.  I don't think you can have it both ways...
>
>Clint (JOATMON) Chaplin
>
>  
>
>>>>"Pat R. Calhoun"  7/23/03 06:25:31 >>>
>>>>        
>>>>
>
>I think we've already had the IEEE vs. IETF discussion, so unless you have a clear explanation of why this is a MAC or PHY problem, please state it.
>
>
>
>_______________________________________________
>Lwapp mailing list
>Lwapp@frascone.com
>http://mail.frascone.com/mailman/listinfo/lwapp
>  
>

-- 
----------------
Dorothy Stanley
Agere Systems
2000 North Naperville Rd. 
Naperville, IL 60566
630-979-1572 (Phone, Fax)
630-222-6753 (Cell)



--------------020807000207000900040306
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Clint,



I think one distinction is that "splitting" MAC functionality between processors,

or devices is an implementation decision on placement of functionality.  The
definition

of what functions must be performed or supported is a MAC definition problem.


LWAPP concerns itself with the former, rather than the latter.



Discussion of partitioning of functionalty is not new. JEDEC-JC61 looked
at partitioning

of PHY and MAC functionalty across radio components. At a number of public

forums, Microsoft had promoted its software partitioning proposals- enabling
the split of 

MAC functionality between the traditional MAC and PC host processors.



In LWAPP, no new MAC functionalty is being proposed. The discussion is around
defining

a standard protocol which will enable placement of functionality in implementations
- either in the AP or AR.



Dorothy



Clint Chaplin wrote:



  
You talk about the architecture of LWAPP "splitting the MAC" between the AP and the AR, and yet you state that this is not a MAC problem.  I don't think you can have it both ways...

Clint (JOATMON) Chaplin

  

  

    

      

        
"Pat R. Calhoun" <pcalhoun@airespace.com> 7/23/03 06:25:31 >>>
        

      

    

  

  

I think we've already had the IEEE vs. IETF discussion, so unless you have a clear explanation of why this is a MAC or PHY problem, please state it.



_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp
  






-- 
----------------
Dorothy Stanley
Agere Systems
2000 North Naperville Rd. 
Naperville, IL 60566
630-979-1572 (Phone, Fax)
630-222-6753 (Cell)






--------------020807000207000900040306--


From aframe@trapezenetworks.com  Tue Jul 29 02:37:44 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Mon, 28 Jul 2003 18:37:44 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

I agree with you that it's just as important to say what should
be in the charter as what should be out of it. The simpler and=20
more constrained the charter is, the more likely any WG that=20
gets formed would succeed.

With that in mind, how about the following as a foundation
on which to build a charter, a 1000' view:

  - discovery: the AP and controller must have some standard
    way of discovering each other=20

  - assertion and control: the controller should be able to
    conditionally assert control of the AP and the AP should
    be able to submit to that control. Note: security
    considerations here.

  - image download: a way for the controller to provide a
    controlled AP with an image to run.

  - maintainance and keepalive: there should be some way for
    the controller and AP to realize that the connection they
    share has gone away. How they react to that is TBD.

  - redundancy and failover: some mechanism to provide a backup
    controller in case the initial one fails.

Now let's propose what should NOT be in the charter.=20

All services provided-- rogue AP detection, context transfers,
QoS, data encryption and authentication, filtering-- are all
expressly out of scope. These can all be provided by the image
that is downloaded by the controller to the AP. Any service that
should be provided is provided in the image. That way there are
no interoperability implications on any services provided, the
controller and AP will, by definition, know how to communicate
any service supported.

  The alternative, if services are in the scope of any chartered=20
WG, is that a slippery slope will be embarked upon where every=20
service-- pick your favorite IEEE Task Group, e, i, k, whatever,=20
etc-- will be included and nothing will ever get finished. It
would be a perpetual task to stay in sync with every feature
and protocol.

Andrew


-----Original Message-----
From: Randy Bush [mailto:randy@psg.com]=20
Sent: Sunday, July 27, 2003 11:18 AM
To: carlw@mcsr-labs.org
Cc: lwapp@frascone.com
Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
Discovery Request/Reply, and validation.)=20



> I agree we should focus the discussion on the charter.  However,
> this may include the need for defining the problem space in a
> document so that all is clear and agreed.

i, for one, would appreciate a simple statement of what this work
is to accomplish and what it is not to accomplish.  as i said in
another forum

    let's think of it as requirements and road map, where are we
    going, why, and how are we going to get there.  and maybe
    where are we NOT going, why, and how do we plan to not get
    there.  and keep it simple.  if the requirements and road map
    can not be simple and done in a few weeks, then how will the
    results of the wg be simple enough to be achievable?

fyi, 'simple' means a page, two at most, of *very* targetted text.

and you should know that my instinctive reaction to "if the ietf
doesn't do it then X will do it," is "wonderful, we're doing too
much already.  let X screw it up and we can come back to it next
year if it is important."

randy

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

From randy@psg.com  Tue Jul 29 02:47:43 2003
From: randy@psg.com (Randy Bush)
Date: Mon, 28 Jul 2003 18:47:43 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
Message-ID: 

i am easily confused, so let me poke to see if i understand
anything about this.

>   - discovery: the AP and controller must have some standard
>     way of discovering each other 

is this at layer three and only layer three?

>   - assertion and control: the controller should be able to
>     conditionally assert control of the AP and the AP should
>     be able to submit to that control. Note: security
>     considerations here.

other then being able to send it an image, what internet services
is the controller controlling in the AP?

>   - image download: a way for the controller to provide a
>     controlled AP with an image to run.
> 
>   - maintainance and keepalive: there should be some way for
>     the controller and AP to realize that the connection they
>     share has gone away. How they react to that is TBD.

this is at layer three?

>   - redundancy and failover: some mechanism to provide a backup
>     controller in case the initial one fails.

you can send it an image but not configure it?  you can't even
configure the characteristics of the (presumably layer three)
keepalives?

randy


From aframe@trapezenetworks.com  Tue Jul 29 03:11:20 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Mon, 28 Jul 2003 19:11:20 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Monday, July 28, 2003 6:48 PM
> To: Andrew Frame
> Cc: lwapp@frascone.com
> Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp]
Certificates,
> Discovery Request/Reply, and validation.)
>=20
> i am easily confused, so let me poke to see if i understand
> anything about this.
>=20
> >   - discovery: the AP and controller must have some standard
> >     way of discovering each other
>=20
> is this at layer three and only layer three?

It is clearly L3, the question is whether or not we should include L2.
Lets focus on L3 first and then see if there are simplifying assumptions
we can make to accommodate L2.

>=20
> >   - assertion and control: the controller should be able to
> >     conditionally assert control of the AP and the AP should
> >     be able to submit to that control. Note: security
> >     considerations here.
>=20
> other then being able to send it an image, what internet services
> is the controller controlling in the AP?

There's an agreement between the AP and the controller to enter into an
exclusive relationship, a wedding if you will. Who wears the pants,
balances the checkbook, cooks, cleans, etc comes after the relationship
is consummated.=20
=20
> >   - image download: a way for the controller to provide a
> >     controlled AP with an image to run.
> >
> >   - maintainance and keepalive: there should be some way for
> >     the controller and AP to realize that the connection they
> >     share has gone away. How they react to that is TBD.
>=20
> this is at layer three?

Same as with discovery, see above.
=20
> >   - redundancy and failover: some mechanism to provide a backup
> >     controller in case the initial one fails.
>=20
> you can send it an image but not configure it?  you can't even
> configure the characteristics of the (presumably layer three)
> keepalives?

Configuration of the keepalives can be done in the assertion and control
portion of the protocol. Configuration of the services provided by the
AP to end users is encapsulated within the image. Keep in mind that if
the controller is going to provide an image to the AP it is in complete
control of what mechanisms the AP will use, and how the controller will
manage them.

Andrew

>=20
> randy


From puneetb@myway.com  Tue Jul 29 07:24:01 2003
From: puneetb@myway.com (Puneet B)
Date: Tue, 29 Jul 2003 02:24:01 -0400 (EDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <20030729062401.B3EB73A00@xmxpita.myway.com>

> Now let's propose what should NOT be in the charter. 
>
> All services provided-- rogue AP detection, context transfers,
> QoS, data encryption and authentication, filtering-- are all
> expressly out of scope. These can all be provided by the image
> that is downloaded by the controller to the AP. Any service that
> should be provided is provided in the image. That way there are
> no interoperability implications on any services provided, the
> controller and AP will, by definition, know how to communicate
> any service supported.

I am not sure if I understand this: By 'image' do you mean
the software/firmware that controls the AP? Would'nt that be opaque
to the AR? How would the AR and AP then know what services are 
supported by each other? 

Also, in what you are proposing, each time an AP boots up or 
discovers an AR is there a way/need for the AP and AR to exchange 
information about their respective capabilities (what services 
are supported)? Are there services that need support in both 
AP & AR? How are they handled?

Thanks,
Puneet

_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com

From aframe@trapezenetworks.com  Tue Jul 29 07:53:06 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Mon, 28 Jul 2003 23:53:06 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

PiBJIGFtIG5vdCBzdXJlIGlmIEkgdW5kZXJzdGFuZCB0aGlzOiBCeSAnaW1hZ2UnIGRvIHlvdSBt
ZWFuDQo+IHRoZSBzb2Z0d2FyZS9maXJtd2FyZSB0aGF0IGNvbnRyb2xzIHRoZSBBUD8gV291bGQn
bnQgdGhhdCBiZSBvcGFxdWUNCj4gdG8gdGhlIEFSPyBIb3cgd291bGQgdGhlIEFSIGFuZCBBUCB0
aGVuIGtub3cgd2hhdCBzZXJ2aWNlcyBhcmUNCj4gc3VwcG9ydGVkIGJ5IGVhY2ggb3RoZXI/DQoN
Ckl0IGlzIHRoZSBDb250cm9sbGVyIHdobyBpcyBwcm92aWRpbmcgdGhlIGltYWdlIHRvIGFuIEFQ
IGl0IGtub3dzIHRoZSBjYXBhYmlsaXRpZXMgb2YsIGFzIHRoZXNlIHdpbGwgYmUgYWR2ZXJ0aXNl
ZCBpbiB0aGUgRGlzY292ZXJ5IHByb2Nlc3MuIEFzc2VydGlvbiBhbmQgY29udHJvbCBpcyBjb25k
aXRpb25hbCwgdGhpcyBhbGxvd3MgZm9yIHRoZSBzcGVjIG5vdCB0byBjb21taXQgdG8gYSB0ZWNo
bm9sb2d5IGxpa2UgODAyLjExLCBpdCBjYW4gZWFzaWx5IHN1cHBvcnQgODAyLjE2IG9yIEJsdWV0
b290aCB3aXRoIG5vIGNoYW5nZXMuLi4NCg0KDQo+IEFsc28sIGluIHdoYXQgeW91IGFyZSBwcm9w
b3NpbmcsIGVhY2ggdGltZSBhbiBBUCBib290cyB1cCBvcg0KPiBkaXNjb3ZlcnMgYW4gQVIgaXMg
dGhlcmUgYSB3YXkvbmVlZCBmb3IgdGhlIEFQIGFuZCBBUiB0byBleGNoYW5nZQ0KPiBpbmZvcm1h
dGlvbiBhYm91dCB0aGVpciByZXNwZWN0aXZlIGNhcGFiaWxpdGllcyAod2hhdCBzZXJ2aWNlcw0K
PiBhcmUgc3VwcG9ydGVkKT8gQXJlIHRoZXJlIHNlcnZpY2VzIHRoYXQgbmVlZCBzdXBwb3J0IGlu
IGJvdGgNCj4gQVAgJiBBUj8gSG93IGFyZSB0aGV5IGhhbmRsZWQ/DQoNCk5vIGNhcGFiaWxpdHkg
ZXhjaGFuZ2UgaXMgbmVjY2Vzc2FyeSwgYXNzZXJ0aW9uIGFuZCBjb250cm9sIHdpbGwgb25seSBi
ZSBhc3N1bWVkIGJ5IHF1YWxpZmllZCBjb250cm9sbGVycyBiYXNlZCBvbiB0aGUgQVAncyBhZHZl
cnRpc2VkIGNhcGFiaWxpdGllcywgYSBoYXJkd2FyZSBkZXNjcmlwdG9yIGlmIHlvdSB3aWxsLiBU
aGUgZ29hbCBvZiB0aGUgV0cgc2hvdWxkIGJlIHRvIHJlc3BlY3QgdGhlIHRlcm0gJ2xpZ2h0LXdl
aWdodCcuLi4uLg0KDQpBbmRyZXcNCg0K

From Mike.Moreton@Synad.com  Tue Jul 29 08:02:23 2003
From: Mike.Moreton@Synad.com (Mike Moreton)
Date: Tue, 29 Jul 2003 08:02:23 +0100
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA894@paris.synad.com>

Andrew

> There's an agreement between the AP and the controller to enter into
an
> exclusive relationship, a wedding if you will. Who wears the pants,
> balances the checkbook, cooks, cleans, etc comes after the
relationship
> is consummated.

This is somewhat akin to the approach that 802.11f took, in that they
defined a protocol for context transfer, without defining the context
that would be transferred.

The problem is that no other group has yet defined any context to be
transferred, so TGf is currently useless.  That may well change in the
future, but it's the way things are at the moment.

I think if you define LWAPP without defining the way the MAC is split,
then you really haven't done anything to encourage interoperability, and
surely that's the whole point of a standard. =20

I would suggest that an IEEE task group be formed to look at how the MAC
could be split (which I'm more than willing to support).  Once this new
task group is in place would seem a better time to come back to the IETF
and ask for the appropriate supporting work to be carried out.  Until
you do that you're going to carry on getting floods of questions along
the lines of "but why???".

Mike Moreton
Synad Technologies Ltd.
=20



From kempf@docomolabs-usa.com  Tue Jul 29 09:29:33 2003
From: kempf@docomolabs-usa.com (James Kempf)
Date: Tue, 29 Jul 2003 10:29:33 +0200
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <232810-2200370270524394@M2W096.mail2web.com> 
Message-ID: <00dd01c355ad$cfdd0ee0$036015ac@dclkempt40>

As a followup to Randy's note, since CAPWAP is a new and potentially complex
area of work that IETF would be taking on, there has been some discussion
between IAB and IESG about how to get the work scoped properly and make sure
the right people are involved so that it has a chance of succeeding in a
reasonable amount of time. The intent is to avoid situations in which vendor
interest evaporates because the original design is so complex that it takes
years to standardize.

Randy and Bert would like a short (not more than two pages, and one is
better) problem statement that clearly describes what CAPWAP would do and,
perhaps more importantly, what it will NOT do. Ideally, the problem
statement would partition the problem into areas that IETF would take on in
OPS, areas that might be appropriate for other IETF areas and a different
working group (if any), and areas that are not really in IETF's scope and
are better left to IEEE. In the areas that would be appropriate for a WG in
the OPS area might include work with existing protocols (like, for example,
SNMP), or they might include new work (in other words, the existence of a
protocol that can supply a solution is not sufficient grounds in and of
itself to not form a WG in OPS). This problem statement would then evolve
into the charter.

As a suggestion (and summarizing I* discussion), the current LWAPP protocol
contains a lot of functionality and is somewhat complex (thus the concern
about long standardization times). Some suggestions are:

- the encapsulation and data management function of the split MAC model
seems separable from the AP control function. The encapsulation and data
management function could be implemented in a variety of ways (over IP, over
802, encrypted or not, etc.). Separating these two might be a good way to
simplify.

- dynamic power control is something that IEEE is not currently working on
and might be an area where IETF might contribute value added. Channel
provisioning between APs might be another possibility. These are specific
instances of the general problem involving interactions between access
points that today need to be provisioned by hand in order to deploy and
manage a network, but could be automated relatively simply.

- anything involving handover control and load balancing would require close
co-operation with 802.11k, which is currently working on designing
management frames for sending metrics to the host that the host would use
for making a handover decision, and so might be best left to IEEE. This
would be more consistent with the 802.11 host controlled handover model.
There might still be some role for handover control for management purposes
(i.e. an AP is about to be shut down for maintenance).

- there clearly is a security issue of how an AR recognizes authorized APs,
but whether this is a task for an OPS-based WG is not clear. There was a BOF
at the last IETF on credential provisioning that might provide part of the
solution, but there might also be some work required specifically for this
application (certificate profiles, etc.). However, chances for quick success
are improved if existing IETF security solutions are built-upon, rather that
trying to invent new ones.

                jak









From pcalhoun@airespace.com  Tue Jul 29 12:13:47 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 29 Jul 2003 04:13:47 -0700
Subject: [Lwapp] Certificates, Discovery Request/Reply, andvalidation.
Message-ID: <40301581B2962B448690A023EF16DFE1DC5375@bsn-mail-01.bstormnetworks.com>

The MAC is left intact.

PatC


-----Original Message-----
From:	Clint Chaplin [mailto:cchaplin@sj.symbol.com]
Sent:	Mon 7/28/2003 5:31 PM
To:	Pat R. Calhoun; alper@docomolabs-usa.com; rkp@intotoinc.com
Cc:	lwapp@frascone.com
Subject:	RE: [Lwapp] Certificates, Discovery Request/Reply, =
andvalidation.
You talk about the architecture of LWAPP "splitting the MAC" between the =
AP and the AR, and yet you state that this is not a MAC problem.  I =
don't think you can have it both ways...

Clint (JOATMON) Chaplin

>>> "Pat R. Calhoun"  7/23/03 06:25:31 >>>

I think we've already had the IEEE vs. IETF discussion, so unless you =
have a clear explanation of why this is a MAC or PHY problem, please =
state it.







From pcalhoun@airespace.com  Tue Jul 29 12:20:11 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 29 Jul 2003 04:20:11 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC5378@bsn-mail-01.bstormnetworks.com>

Sounds like just the "AP Brain Transplant Protocol", or am I missing =
something?

patC


-----Original Message-----
From:	Andrew Frame [mailto:aframe@trapezenetworks.com]
Sent:	Mon 7/28/2003 11:53 PM
To:	puneetb@myway.com; randy@psg.com; carlw@mcsr-labs.org
Cc:	lwapp@frascone.com
Subject:	RE: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, =
Discovery Request/Reply, and validation.)
> I am not sure if I understand this: By 'image' do you mean
> the software/firmware that controls the AP? Would'nt that be opaque
> to the AR? How would the AR and AP then know what services are
> supported by each other?

It is the Controller who is providing the image to an AP it knows the =
capabilities of, as these will be advertised in the Discovery process. =
Assertion and control is conditional, this allows for the spec not to =
commit to a technology like 802.11, it can easily support 802.16 or =
Bluetooth with no changes...


> Also, in what you are proposing, each time an AP boots up or
> discovers an AR is there a way/need for the AP and AR to exchange
> information about their respective capabilities (what services
> are supported)? Are there services that need support in both
> AP & AR? How are they handled?

No capability exchange is neccessary, assertion and control will only be =
assumed by qualified controllers based on the AP's advertised =
capabilities, a hardware descriptor if you will. The goal of the WG =
should be to respect the term 'light-weight'.....

Andrew

/=06f)+-/=06?'y&iWj((Yb?~i



From pcalhoun@airespace.com  Tue Jul 29 12:21:55 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Tue, 29 Jul 2003 04:21:55 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC5379@bsn-mail-01.bstormnetworks.com>

> I think if you define LWAPP without defining the way the MAC is split,
> then you really haven't done anything to encourage interoperability, =
and
> surely that's the whole point of a standard. =20
So this is required (and thought it was in the spec....)

> I would suggest that an IEEE task group be formed to look at how the =
MAC
> could be split (which I'm more than willing to support).  Once this =
new
> task group is in place would seem a better time to come back to the =
IETF
> and ask for the appropriate supporting work to be carried out.  Until
> you do that you're going to carry on getting floods of questions along
> the lines of "but why???".

Centralizing the MAC allows for much better load balancing, better =
policy enforcement, allows a centralized view of the network to detect =
attacks, etc. The list goes on and some of it is in the spec.

PatC

From Marcus Brunner   Tue Jul 29 13:26:23 2003
From: Marcus Brunner  (Marcus Brunner)
Date: Tue, 29 Jul 2003 14:26:23 +0200
Subject: [Lwapp] Re: PANA v.s. LWAPP: a false dichotomy (was: Re: [Lwapp]
 Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: <01ac01c353ab$5c9aaea0$2a6015ac@dclkempt40>
References: <40301581B2962B448690A023EF16DFE1DC52A0@bsn-mail-01.bstormnetwork
 s.com> <01ac01c353ab$5c9aaea0$2a6015ac@dclkempt40>
Message-ID: <14763208.1059488783@[10.1.1.130]>

I agree that the 2 approaches might have some overlap, but this should 
really not be a problem to let both of them proceed.

Marcus

--On Samstag, 26. Juli 2003 21:23 +0200 James Kempf 
 wrote:

> Pat,
>
> Let's try to avoid an argument on the list about the relative merits of
> one architecture v.s. another. There is plenty of room for both these
> approachs in the IETF. The intent of LWAPP is to do something quickly to
> satisfy vendor requests. The intent of PANA is more long term, as you
> point out. There is no reason why these two approaches can't co-exist.
> After all, the IETF currently has no less than 3 working groups doing
> work on instant messaging protocols, and the architectural territory
> covered by these protocols is much closer than that covered by PANA and
> LWAPP.
>
> Let's stick to discussing the charter, around the bullet points I sent
> out. We need to get some text around those.
>
>             jak
>
>
> ----- Original Message -----
> From: "Pat R. Calhoun" 
> To: "Alper Yegin" ; 
> Cc: 
> Sent: Wednesday, July 23, 2003 3:25 PM
> Subject: RE: [Lwapp] Certificates, Discovery Request/Reply, and
> validation.
>
>
>> > I've discussed these before, but nevertheless:
>> > - Configuring APs: SNMP, COPS, etc.
>> > - Migration of AAA stuff from AP to AR: PANA
>> > - Auth/Authz between AP and AR: PANA (if physical security is not good
>> >   enough)
>> > - Migration of per-packet ciphering from AP to AR: Either use IPsec
>> > with
> AR,
>> >   or tunnel 802.11 frames on the wired segment. Whether the latter
> should be
>> >   done at IEEE vs. IETF is debatable.
>> >
>> > Did I miss any other problems we are tackling here?
>>
>> Apparently. I think the key point that you are missing here is the 'LW'
>> in
> LWAPP. Specifically, the goal is to reduce the complexity of the AP, which
> is something that we are hearing both customers and AP manufacturers want.
> The proposal above requires so much code in the AP that one has to
> question what the advantages are.
>>
>> I think we've already had the IEEE vs. IETF discussion, so unless you
>> have
> a clear explanation of why this is a MAC or PHY problem, please state it.
>>
>> >> correct, but somehow you keep asking the question. If we agree that
> we've
>> >> beaten this horse to it's full extent, then I'll gladly oblige...
>> >
>> > Please see above.
>>
>> I see, so the horse isn't dead....
>>
>> > I still feel like missing couple of necessary steps here if we already
> jump
>> > to solution evaluation stage.
>>
>> Correct. I think the part that's missing here is that unlike other topics
> in the IETF that are mostly around research topics (build it and they will
> come), this is the inverse. Products are shipping, and many vendors in
> this space wish to ensure some form of interoperability between their
> devices.
>>
>> I understand that you're trying to find some market for the PANA
> architecture, and I'm sure there are customers, but I think that the
> vendors in this particular space have already made an architectural
> decision. If the IETF wishes to standardize on an architecture the
> players in the 802.11 space are not interested in, then I think it's
> missed its mark.
>>
>> Further, I think that your proposal does not benefit the Internet
> Community, which is looking for lowering the cost of AP deployments and
> operation. What you proposal does is drive the standards process much
> longer with dubious advantages.
>>
>> PatC
>> _______________________________________________
>> Lwapp mailing list
>> Lwapp@frascone.com
>> http://mail.frascone.com/mailman/listinfo/lwapp
>>
>>
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp



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

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus





From Marcus Brunner   Tue Jul 29 13:31:23 2003
From: Marcus Brunner  (Marcus Brunner)
Date: Tue, 29 Jul 2003 14:31:23 +0200
Subject: [Lwapp] Certificates, Discovery Request/Reply, and validation.
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC532B@bsn-mail-01.bstormnetworks.com>
References: <40301581B2962B448690A023EF16DFE1DC532B@bsn-mail-01.bstormnetwor
 ks.com>
Message-ID: <15063369.1059489083@[10.1.1.130]>

>> However, it seems that most of what LWAPP tries to do could probably be
>> achieved by way of SNMP set operations, so this should probably be the
>> basis of discussion in this ML.
>
> ok, let's tunnels packets within SNMP. Great idea.

Sure, IP over http seams to work quite well :-)

The question is whether to integrate the tunnel setup and the tunneling 
protocol into the protocol is a good idea or not.
MArcus

From Marcus Brunner   Tue Jul 29 14:55:20 2003
From: Marcus Brunner  (Marcus Brunner)
Date: Tue, 29 Jul 2003 15:55:20 +0200
Subject: [Lwapp] Charter Proposal
In-Reply-To: <017201c353a8$64c30760$2a6015ac@dclkempt40>
References: <007501c34cf1$95eaacc0$ab6015ac@dclkempt40>
 <2052821.1058870316@[10.1.1.130]>
 <017201c353a8$64c30760$2a6015ac@dclkempt40>
Message-ID: <20100492.1059494120@[10.1.1.130]>


--On Samstag, 26. Juli 2003 15:12 +0200 James Kempf 
 wrote:

> Marcus,
>
>
>> > Develop a protocol controlling wireless access points with the
>> > following features:
>> >
>> > .Independent of wireless link protocol.
>> > .Discovery of a CAPWAP manager (AR, IP addressable switch).
>>
>> I would not include this. SLP and DHCP might just work
>>
>
> SLP requires a service type template. This would need to be developed.
> Also, a DHCP option of some type might be needed. Wouldn't these be
> appropriate work items if the WG decided to go with (preferably) one or
> (possibly) more standardized discovery mechanisms?
>
>                 jak
>

Yes, you are right. And I think this is very focuses work. (Definition of 
DHCP options for discovery of CAPWAP Manager)

I am not that sure about SLP anymore. At the BoF I thought it is good idea 
what Inderpreet has presented. Now I regard it to be far too flexible for a 
first step.

Marcus

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

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus





From randy@psg.com  Tue Jul 29 15:29:31 2003
From: randy@psg.com (Randy Bush)
Date: Tue, 29 Jul 2003 07:29:31 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
Message-ID: 

i do not understand your no capability exchange necessary.  is it that
you intend to load the image with the right capabilities every time?

randy


From randy@psg.com  Tue Jul 29 15:46:06 2003
From: randy@psg.com (Randy Bush)
Date: Tue, 29 Jul 2003 07:46:06 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <232810-2200370270524394@M2W096.mail2web.com>
 
 <00dd01c355ad$cfdd0ee0$036015ac@dclkempt40>
Message-ID: 

> As a followup to Randy's note, since CAPWAP is a new and
> potentially complex area of work that IETF would be taking on,
> there has been some discussion between IAB and IESG about how to
> get the work scoped properly and make sure the right people are
> involved so that it has a chance of succeeding in a reasonable
> amount of time.

lest we create the sound of black helicopters, let's be a bit more
clear.  there have been no iesg/iab back room discussions of which
i am aware of 'who', or 'scoping' of this work.  i have worked very
hard, and have stuck my nose and prodded in this mailing list to a
level that perhaps an area director (with hat on) should not,
specifically to ensure that discussion of goals and means was
completely open.

there has been iesg/iab discussion of issues such as how to tell if
there really is serious overlap with other existing work within the
ietf and between the ietf and the ieee (and i have taken the
position that i have no way of telling unless it is clear what this
work is, darn it).  there has also been philosophic discussion of
how to avoid the complexity explosion which made diameter into a
many year effort.

so please please focus on a simple and clear statement of goals and
means.  we users really want interoperability, and that is what
standards are about.

randy


From dmolnar@legra.com  Tue Jul 29 15:49:54 2003
From: dmolnar@legra.com (David Molnar)
Date: Tue, 29 Jul 2003 10:49:54 -0400
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <232810-2200370270524394@M2W096.mail2web.com>  <00dd01c355ad$cfdd0ee0$036015ac@dclkempt40>
Message-ID: <006201c355e0$ac5fca60$b90ba8c0@student.harvard.edu>

> - there clearly is a security issue of how an AR recognizes authorized
APs,
> but whether this is a task for an OPS-based WG is not clear. There was a
BOF
> at the last IETF on credential provisioning that might provide part of the
> solution, but there might also be some work required specifically for this
> application (certificate profiles, etc.). However, chances for quick
success
> are improved if existing IETF security solutions are built-upon, rather
that
> trying to invent new ones.

Did anyone on this list make it to the enroll BOF and want to share
impressions of how it might apply to this work? I unfortunately had a
conflict  with part of ietf and missed it.

-David


From aframe@trapezenetworks.com  Tue Jul 29 16:20:00 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Tue, 29 Jul 2003 08:20:00 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

V2hpY2ggaXMgZ3JlYXQsIFBsdWcgQVAgWCBpbnRvIENvbnRyb2xsZXIgWSBhbmQgZ2V0IFogZnVu
Y3Rpb25hbGl0eS4gUGx1ZyBBUCBYIGludG8gQ29udHJvbGxlciBBIGFuZCBnZXQgQiBmdW5jdGlv
bmFsaXR5LiBTb3VuZHMgbGlrZSBhIHBlcmZlY3QgbW9kZWwgdG8gcHJlc2VydmUgZGlmZmVyZW50
aWF0aW9uIGluIHRoZSBtYXJrZXRwbGFjZSB3aGlsZSBub3QgbG9hZGluZyB1cCB0aGUgSUVURiB3
aXRoIGV4Y2Vzc2l2ZSB3b3JrLi4uLg0KIA0KQW5kcmV3DQoNCgktLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLSANCglGcm9tOiBQYXQgUi4gQ2FsaG91biBbbWFpbHRvOnBjYWxob3VuQGFpcmVzcGFj
ZS5jb21dIA0KCVNlbnQ6IFR1ZSA3LzI5LzIwMDMgNDoyMCBBTSANCglUbzogQW5kcmV3IEZyYW1l
OyBwdW5lZXRiQG15d2F5LmNvbTsgcmFuZHlAcHNnLmNvbTsgY2FybHdAbWNzci1sYWJzLm9yZyAN
CglDYzogbHdhcHBAZnJhc2NvbmUuY29tIA0KCVN1YmplY3Q6IFJFOiBTY29wZSBvZiBDaGFydGVy
IERpc2N1c3Npb24gKHdhczogUmU6IFtMd2FwcF0gQ2VydGlmaWNhdGVzLCBEaXNjb3ZlcnkgUmVx
dWVzdC9SZXBseSwgYW5kIHZhbGlkYXRpb24uKQ0KCQ0KCQ0KDQoJU291bmRzIGxpa2UganVzdCB0
aGUgIkFQIEJyYWluIFRyYW5zcGxhbnQgUHJvdG9jb2wiLCBvciBhbSBJIG1pc3Npbmcgc29tZXRo
aW5nPw0KCQ0KCXBhdEMNCgkNCgkNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCUZyb206
ICAgQW5kcmV3IEZyYW1lIFttYWlsdG86YWZyYW1lQHRyYXBlemVuZXR3b3Jrcy5jb21dDQoJU2Vu
dDogICBNb24gNy8yOC8yMDAzIDExOjUzIFBNDQoJVG86ICAgICBwdW5lZXRiQG15d2F5LmNvbTsg
cmFuZHlAcHNnLmNvbTsgY2FybHdAbWNzci1sYWJzLm9yZw0KCUNjOiAgICAgbHdhcHBAZnJhc2Nv
bmUuY29tDQoJU3ViamVjdDogICAgICAgIFJFOiBTY29wZSBvZiBDaGFydGVyIERpc2N1c3Npb24g
KHdhczogUmU6IFtMd2FwcF0gQ2VydGlmaWNhdGVzLCBEaXNjb3ZlcnkgUmVxdWVzdC9SZXBseSwg
YW5kIHZhbGlkYXRpb24uKQ0KCT4gSSBhbSBub3Qgc3VyZSBpZiBJIHVuZGVyc3RhbmQgdGhpczog
QnkgJ2ltYWdlJyBkbyB5b3UgbWVhbg0KCT4gdGhlIHNvZnR3YXJlL2Zpcm13YXJlIHRoYXQgY29u
dHJvbHMgdGhlIEFQPyBXb3VsZCdudCB0aGF0IGJlIG9wYXF1ZQ0KCT4gdG8gdGhlIEFSPyBIb3cg
d291bGQgdGhlIEFSIGFuZCBBUCB0aGVuIGtub3cgd2hhdCBzZXJ2aWNlcyBhcmUNCgk+IHN1cHBv
cnRlZCBieSBlYWNoIG90aGVyPw0KCQ0KCUl0IGlzIHRoZSBDb250cm9sbGVyIHdobyBpcyBwcm92
aWRpbmcgdGhlIGltYWdlIHRvIGFuIEFQIGl0IGtub3dzIHRoZSBjYXBhYmlsaXRpZXMgb2YsIGFz
IHRoZXNlIHdpbGwgYmUgYWR2ZXJ0aXNlZCBpbiB0aGUgRGlzY292ZXJ5IHByb2Nlc3MuIEFzc2Vy
dGlvbiBhbmQgY29udHJvbCBpcyBjb25kaXRpb25hbCwgdGhpcyBhbGxvd3MgZm9yIHRoZSBzcGVj
IG5vdCB0byBjb21taXQgdG8gYSB0ZWNobm9sb2d5IGxpa2UgODAyLjExLCBpdCBjYW4gZWFzaWx5
IHN1cHBvcnQgODAyLjE2IG9yIEJsdWV0b290aCB3aXRoIG5vIGNoYW5nZXMuLi4NCgkNCgkNCgk+
IEFsc28sIGluIHdoYXQgeW91IGFyZSBwcm9wb3NpbmcsIGVhY2ggdGltZSBhbiBBUCBib290cyB1
cCBvcg0KCT4gZGlzY292ZXJzIGFuIEFSIGlzIHRoZXJlIGEgd2F5L25lZWQgZm9yIHRoZSBBUCBh
bmQgQVIgdG8gZXhjaGFuZ2UNCgk+IGluZm9ybWF0aW9uIGFib3V0IHRoZWlyIHJlc3BlY3RpdmUg
Y2FwYWJpbGl0aWVzICh3aGF0IHNlcnZpY2VzDQoJPiBhcmUgc3VwcG9ydGVkKT8gQXJlIHRoZXJl
IHNlcnZpY2VzIHRoYXQgbmVlZCBzdXBwb3J0IGluIGJvdGgNCgk+IEFQICYgQVI/IEhvdyBhcmUg
dGhleSBoYW5kbGVkPw0KCQ0KCU5vIGNhcGFiaWxpdHkgZXhjaGFuZ2UgaXMgbmVjY2Vzc2FyeSwg
YXNzZXJ0aW9uIGFuZCBjb250cm9sIHdpbGwgb25seSBiZSBhc3N1bWVkIGJ5IHF1YWxpZmllZCBj
b250cm9sbGVycyBiYXNlZCBvbiB0aGUgQVAncyBhZHZlcnRpc2VkIGNhcGFiaWxpdGllcywgYSBo
YXJkd2FyZSBkZXNjcmlwdG9yIGlmIHlvdSB3aWxsLiBUaGUgZ29hbCBvZiB0aGUgV0cgc2hvdWxk
IGJlIHRvIHJlc3BlY3QgdGhlIHRlcm0gJ2xpZ2h0LXdlaWdodCcuLi4uLg0KCQ0KCUFuZHJldw0K
CQ0KCS8GZikrLS8GPyd5JmlXaigoWWI/fmkNCgkNCgkNCgkNCg0K

From aframe@trapezenetworks.com  Tue Jul 29 16:21:43 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Tue, 29 Jul 2003 08:21:43 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

QXNzZXJ0aW9uIGFuZCBjb250cm9sIHdpbGwgb25seSBvY2N1ciBpZiB0aGUgQ29udHJvbGxlciBj
YW4gYWNjb21kYXRlIHRoZSBBUCdzIGNhcGFiaWxpdGllcy4gSWYgdGhlcmUgaXMgc3VmZmljaWVu
dCByZWFzb24gZm9yIGEgY2FwYWJpbGl0aWVzIGV4Y2hhbmdlIEkgYW0gbm90IGFnYWluc3QgdGhp
cy4uLi4NCiANCkFuZHJldw0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTog
UmFuZHkgQnVzaCBbbWFpbHRvOnJhbmR5QHBzZy5jb21dIA0KCVNlbnQ6IFR1ZSA3LzI5LzIwMDMg
NzoyOSBBTSANCglUbzogQW5kcmV3IEZyYW1lIA0KCUNjOiBsd2FwcEBmcmFzY29uZS5jb20gDQoJ
U3ViamVjdDogUkU6IFNjb3BlIG9mIENoYXJ0ZXIgRGlzY3Vzc2lvbiAod2FzOiBSZTogW0x3YXBw
XSBDZXJ0aWZpY2F0ZXMsIERpc2NvdmVyeSBSZXF1ZXN0L1JlcGx5LCBhbmQgdmFsaWRhdGlvbi4p
DQoJDQoJDQoNCglpIGRvIG5vdCB1bmRlcnN0YW5kIHlvdXIgbm8gY2FwYWJpbGl0eSBleGNoYW5n
ZSBuZWNlc3NhcnkuICBpcyBpdCB0aGF0DQoJeW91IGludGVuZCB0byBsb2FkIHRoZSBpbWFnZSB3
aXRoIHRoZSByaWdodCBjYXBhYmlsaXRpZXMgZXZlcnkgdGltZT8NCgkNCglyYW5keQ0KCQ0KCQ0K
DQo=

From aframe@trapezenetworks.com  Tue Jul 29 17:08:46 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Tue, 29 Jul 2003 09:08:46 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

T2ssIGhvdyBkbyBJIHBocmFzZSB0aGlzIGdlbnRseSwgSSB3aWxsIGhvbGQgbXlzZWxmIGJhY2sg
ZnJvbSBzYXlpbmcgJ29uZSBmb290IG9uIHRoZSBiYW5hbmEgcGVlbCBhbmQgdGhlIG90aGVyIG9u
IHRoZSBlZGdlIG9mIHRoZSBzbGlwcGVyeSBzbG9wZScuLi4gOy0pDQogDQpBcyBJIHN0YXRlZCBp
biBhbiBlYXJsaWVyIGVtYWlsLCB0aGlzIHVuZG91YnRlZGx5IHdpbGwgYmVjb21lIGEgcGVycGV0
dWFsIFdHIGlmIHdlIGRlY2lkZSB0byBzdGF5IGluIHN5bmMgd2lsbCBhbGwgaW5kdXN0cnkgc3Rh
bmRhcmRpemF0aW9uIGVmZm9ydHMuIA0KIA0KRm9jdXNpbmcgb24gc3RhbmRhcmRpemluZyBhIGJv
b3R1cC1zdHJhcC9kaXNjb3ZlcnkvaW1hZ2UtZG93bmxvYWQgcHJvdG9jb2wgZm9yIEFQcyB3aXRo
b3V0IGRpY3RhdGluZyB3aGF0IHRoZSBpbWFnZSBkb2VzIG9yIGhvdyBpdCBkb2VzIGl0IGFsbG93
cyB2ZW5kb3JzIHRvIHRyYWNrIGFsbCBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cyB3aXRoaW4gdGhl
IGltYWdlIGlmIHRoZXkgZW5qb3kgZW5kdXJpbmcgcGFpbiwgd2l0aG91dCBmb3JjaW5nIHRoYXQg
cGFpbiB1cG9uIHRoZSBJRVRGLg0KIA0KQW5kcmV3DQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLSANCglGcm9tOiBKYW1lcyBLZW1wZiBbbWFpbHRvOmtlbXBmQGRvY29tb2xhYnMtdXNh
LmNvbV0gDQoJU2VudDogVHVlIDcvMjkvMjAwMyAxOjI5IEFNIA0KCVRvOiBSYW5keSBCdXNoOyBj
YXJsd0BtY3NyLWxhYnMub3JnIA0KCUNjOiBsd2FwcEBmcmFzY29uZS5jb207IEJlcm5hcmQgQWJv
YmEgDQoJU3ViamVjdDogUmU6IFNjb3BlIG9mIENoYXJ0ZXIgRGlzY3Vzc2lvbiAod2FzOiBSZTog
W0x3YXBwXSBDZXJ0aWZpY2F0ZXMsIERpc2NvdmVyeSBSZXF1ZXN0L1JlcGx5LCBhbmQgdmFsaWRh
dGlvbi4pIA0KCQ0KCQ0KDQoJQXMgYSBmb2xsb3d1cCB0byBSYW5keSdzIG5vdGUsIHNpbmNlIENB
UFdBUCBpcyBhIG5ldyBhbmQgcG90ZW50aWFsbHkgY29tcGxleA0KCWFyZWEgb2Ygd29yayB0aGF0
IElFVEYgd291bGQgYmUgdGFraW5nIG9uLCB0aGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24N
CgliZXR3ZWVuIElBQiBhbmQgSUVTRyBhYm91dCBob3cgdG8gZ2V0IHRoZSB3b3JrIHNjb3BlZCBw
cm9wZXJseSBhbmQgbWFrZSBzdXJlDQoJdGhlIHJpZ2h0IHBlb3BsZSBhcmUgaW52b2x2ZWQgc28g
dGhhdCBpdCBoYXMgYSBjaGFuY2Ugb2Ygc3VjY2VlZGluZyBpbiBhDQoJcmVhc29uYWJsZSBhbW91
bnQgb2YgdGltZS4gVGhlIGludGVudCBpcyB0byBhdm9pZCBzaXR1YXRpb25zIGluIHdoaWNoIHZl
bmRvcg0KCWludGVyZXN0IGV2YXBvcmF0ZXMgYmVjYXVzZSB0aGUgb3JpZ2luYWwgZGVzaWduIGlz
IHNvIGNvbXBsZXggdGhhdCBpdCB0YWtlcw0KCXllYXJzIHRvIHN0YW5kYXJkaXplLg0KCQ0KCVJh
bmR5IGFuZCBCZXJ0IHdvdWxkIGxpa2UgYSBzaG9ydCAobm90IG1vcmUgdGhhbiB0d28gcGFnZXMs
IGFuZCBvbmUgaXMNCgliZXR0ZXIpIHByb2JsZW0gc3RhdGVtZW50IHRoYXQgY2xlYXJseSBkZXNj
cmliZXMgd2hhdCBDQVBXQVAgd291bGQgZG8gYW5kLA0KCXBlcmhhcHMgbW9yZSBpbXBvcnRhbnRs
eSwgd2hhdCBpdCB3aWxsIE5PVCBkby4gSWRlYWxseSwgdGhlIHByb2JsZW0NCglzdGF0ZW1lbnQg
d291bGQgcGFydGl0aW9uIHRoZSBwcm9ibGVtIGludG8gYXJlYXMgdGhhdCBJRVRGIHdvdWxkIHRh
a2Ugb24gaW4NCglPUFMsIGFyZWFzIHRoYXQgbWlnaHQgYmUgYXBwcm9wcmlhdGUgZm9yIG90aGVy
IElFVEYgYXJlYXMgYW5kIGEgZGlmZmVyZW50DQoJd29ya2luZyBncm91cCAoaWYgYW55KSwgYW5k
IGFyZWFzIHRoYXQgYXJlIG5vdCByZWFsbHkgaW4gSUVURidzIHNjb3BlIGFuZA0KCWFyZSBiZXR0
ZXIgbGVmdCB0byBJRUVFLiBJbiB0aGUgYXJlYXMgdGhhdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSBm
b3IgYSBXRyBpbg0KCXRoZSBPUFMgYXJlYSBtaWdodCBpbmNsdWRlIHdvcmsgd2l0aCBleGlzdGlu
ZyBwcm90b2NvbHMgKGxpa2UsIGZvciBleGFtcGxlLA0KCVNOTVApLCBvciB0aGV5IG1pZ2h0IGlu
Y2x1ZGUgbmV3IHdvcmsgKGluIG90aGVyIHdvcmRzLCB0aGUgZXhpc3RlbmNlIG9mIGENCglwcm90
b2NvbCB0aGF0IGNhbiBzdXBwbHkgYSBzb2x1dGlvbiBpcyBub3Qgc3VmZmljaWVudCBncm91bmRz
IGluIGFuZCBvZg0KCWl0c2VsZiB0byBub3QgZm9ybSBhIFdHIGluIE9QUykuIFRoaXMgcHJvYmxl
bSBzdGF0ZW1lbnQgd291bGQgdGhlbiBldm9sdmUNCglpbnRvIHRoZSBjaGFydGVyLg0KCQ0KCUFz
IGEgc3VnZ2VzdGlvbiAoYW5kIHN1bW1hcml6aW5nIEkqIGRpc2N1c3Npb24pLCB0aGUgY3VycmVu
dCBMV0FQUCBwcm90b2NvbA0KCWNvbnRhaW5zIGEgbG90IG9mIGZ1bmN0aW9uYWxpdHkgYW5kIGlz
IHNvbWV3aGF0IGNvbXBsZXggKHRodXMgdGhlIGNvbmNlcm4NCglhYm91dCBsb25nIHN0YW5kYXJk
aXphdGlvbiB0aW1lcykuIFNvbWUgc3VnZ2VzdGlvbnMgYXJlOg0KCQ0KCS0gdGhlIGVuY2Fwc3Vs
YXRpb24gYW5kIGRhdGEgbWFuYWdlbWVudCBmdW5jdGlvbiBvZiB0aGUgc3BsaXQgTUFDIG1vZGVs
DQoJc2VlbXMgc2VwYXJhYmxlIGZyb20gdGhlIEFQIGNvbnRyb2wgZnVuY3Rpb24uIFRoZSBlbmNh
cHN1bGF0aW9uIGFuZCBkYXRhDQoJbWFuYWdlbWVudCBmdW5jdGlvbiBjb3VsZCBiZSBpbXBsZW1l
bnRlZCBpbiBhIHZhcmlldHkgb2Ygd2F5cyAob3ZlciBJUCwgb3Zlcg0KCTgwMiwgZW5jcnlwdGVk
IG9yIG5vdCwgZXRjLikuIFNlcGFyYXRpbmcgdGhlc2UgdHdvIG1pZ2h0IGJlIGEgZ29vZCB3YXkg
dG8NCglzaW1wbGlmeS4NCgkNCgktIGR5bmFtaWMgcG93ZXIgY29udHJvbCBpcyBzb21ldGhpbmcg
dGhhdCBJRUVFIGlzIG5vdCBjdXJyZW50bHkgd29ya2luZyBvbg0KCWFuZCBtaWdodCBiZSBhbiBh
cmVhIHdoZXJlIElFVEYgbWlnaHQgY29udHJpYnV0ZSB2YWx1ZSBhZGRlZC4gQ2hhbm5lbA0KCXBy
b3Zpc2lvbmluZyBiZXR3ZWVuIEFQcyBtaWdodCBiZSBhbm90aGVyIHBvc3NpYmlsaXR5LiBUaGVz
ZSBhcmUgc3BlY2lmaWMNCglpbnN0YW5jZXMgb2YgdGhlIGdlbmVyYWwgcHJvYmxlbSBpbnZvbHZp
bmcgaW50ZXJhY3Rpb25zIGJldHdlZW4gYWNjZXNzDQoJcG9pbnRzIHRoYXQgdG9kYXkgbmVlZCB0
byBiZSBwcm92aXNpb25lZCBieSBoYW5kIGluIG9yZGVyIHRvIGRlcGxveSBhbmQNCgltYW5hZ2Ug
YSBuZXR3b3JrLCBidXQgY291bGQgYmUgYXV0b21hdGVkIHJlbGF0aXZlbHkgc2ltcGx5Lg0KCQ0K
CS0gYW55dGhpbmcgaW52b2x2aW5nIGhhbmRvdmVyIGNvbnRyb2wgYW5kIGxvYWQgYmFsYW5jaW5n
IHdvdWxkIHJlcXVpcmUgY2xvc2UNCgljby1vcGVyYXRpb24gd2l0aCA4MDIuMTFrLCB3aGljaCBp
cyBjdXJyZW50bHkgd29ya2luZyBvbiBkZXNpZ25pbmcNCgltYW5hZ2VtZW50IGZyYW1lcyBmb3Ig
c2VuZGluZyBtZXRyaWNzIHRvIHRoZSBob3N0IHRoYXQgdGhlIGhvc3Qgd291bGQgdXNlDQoJZm9y
IG1ha2luZyBhIGhhbmRvdmVyIGRlY2lzaW9uLCBhbmQgc28gbWlnaHQgYmUgYmVzdCBsZWZ0IHRv
IElFRUUuIFRoaXMNCgl3b3VsZCBiZSBtb3JlIGNvbnNpc3RlbnQgd2l0aCB0aGUgODAyLjExIGhv
c3QgY29udHJvbGxlZCBoYW5kb3ZlciBtb2RlbC4NCglUaGVyZSBtaWdodCBzdGlsbCBiZSBzb21l
IHJvbGUgZm9yIGhhbmRvdmVyIGNvbnRyb2wgZm9yIG1hbmFnZW1lbnQgcHVycG9zZXMNCgkoaS5l
LiBhbiBBUCBpcyBhYm91dCB0byBiZSBzaHV0IGRvd24gZm9yIG1haW50ZW5hbmNlKS4NCgkNCgkt
IHRoZXJlIGNsZWFybHkgaXMgYSBzZWN1cml0eSBpc3N1ZSBvZiBob3cgYW4gQVIgcmVjb2duaXpl
cyBhdXRob3JpemVkIEFQcywNCglidXQgd2hldGhlciB0aGlzIGlzIGEgdGFzayBmb3IgYW4gT1BT
LWJhc2VkIFdHIGlzIG5vdCBjbGVhci4gVGhlcmUgd2FzIGEgQk9GDQoJYXQgdGhlIGxhc3QgSUVU
RiBvbiBjcmVkZW50aWFsIHByb3Zpc2lvbmluZyB0aGF0IG1pZ2h0IHByb3ZpZGUgcGFydCBvZiB0
aGUNCglzb2x1dGlvbiwgYnV0IHRoZXJlIG1pZ2h0IGFsc28gYmUgc29tZSB3b3JrIHJlcXVpcmVk
IHNwZWNpZmljYWxseSBmb3IgdGhpcw0KCWFwcGxpY2F0aW9uIChjZXJ0aWZpY2F0ZSBwcm9maWxl
cywgZXRjLikuIEhvd2V2ZXIsIGNoYW5jZXMgZm9yIHF1aWNrIHN1Y2Nlc3MNCglhcmUgaW1wcm92
ZWQgaWYgZXhpc3RpbmcgSUVURiBzZWN1cml0eSBzb2x1dGlvbnMgYXJlIGJ1aWx0LXVwb24sIHJh
dGhlciB0aGF0DQoJdHJ5aW5nIHRvIGludmVudCBuZXcgb25lcy4NCgkNCgkgICAgICAgICAgICAg
ICAgamFrDQoJDQoJDQoJDQoJDQoJDQoJDQoJDQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCglMd2FwcCBtYWlsaW5nIGxpc3QNCglMd2FwcEBmcmFz
Y29uZS5jb20NCglodHRwOi8vbWFpbC5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9sd2Fw
cA0KCQ0KDQo=

From simon.chung@s3group.com  Tue Jul 29 17:26:47 2003
From: simon.chung@s3group.com (Simon Chung)
Date: Tue, 29 Jul 2003 17:26:47 +0100
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
In-Reply-To: 
References: 
Message-ID: <3F26A047.9060605@s3group.com>

Not sure I understand correctly. Please correct me if I am wrong.

I presume we are talking about software / firmware images and specifying 
a software download protocol.

However since these images are machine dependent, then how does 
interoperability achieved between AR and AP from different vendors? e.g. 
AR Vendor A sends its proprietary AP image to Vendor B's AP, but Vendor 
B's AP has a totally different hardware platform, with different 
microprocessor, memory, peripherals, etc. compared to Verndor A's AP.

Are you suggesting to specify some sort of machine independent code for 
the image, with something like a Java VM in the AP?

Cheers,
Simon.


Andrew Frame wrote:

>Ok, how do I phrase this gently, I will hold myself back from saying 'one foot on the banana peel and the other on the edge of the slippery slope'... ;-)
> 
>As I stated in an earlier email, this undoubtedly will become a perpetual WG if we decide to stay in sync will all industry standardization efforts. 
> 
>Focusing on standardizing a bootup-strap/discovery/image-download protocol for APs without dictating what the image does or how it does it allows vendors to track all standardization efforts within the image if they enjoy enduring pain, without forcing that pain upon the IETF.
> 
>Andrew
> 
>
>	-----Original Message----- 
>	From: James Kempf [mailto:kempf@docomolabs-usa.com] 
>	Sent: Tue 7/29/2003 1:29 AM 
>	To: Randy Bush; carlw@mcsr-labs.org 
>	Cc: lwapp@frascone.com; Bernard Aboba 
>	Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) 
>	
>	
>
>	As a followup to Randy's note, since CAPWAP is a new and potentially complex
>	area of work that IETF would be taking on, there has been some discussion
>	between IAB and IESG about how to get the work scoped properly and make sure
>	the right people are involved so that it has a chance of succeeding in a
>	reasonable amount of time. The intent is to avoid situations in which vendor
>	interest evaporates because the original design is so complex that it takes
>	years to standardize.
>	
>	Randy and Bert would like a short (not more than two pages, and one is
>	better) problem statement that clearly describes what CAPWAP would do and,
>	perhaps more importantly, what it will NOT do. Ideally, the problem
>	statement would partition the problem into areas that IETF would take on in
>	OPS, areas that might be appropriate for other IETF areas and a different
>	working group (if any), and areas that are not really in IETF's scope and
>	are better left to IEEE. In the areas that would be appropriate for a WG in
>	the OPS area might include work with existing protocols (like, for example,
>	SNMP), or they might include new work (in other words, the existence of a
>	protocol that can supply a solution is not sufficient grounds in and of
>	itself to not form a WG in OPS). This problem statement would then evolve
>	into the charter.
>	
>	As a suggestion (and summarizing I* discussion), the current LWAPP protocol
>	contains a lot of functionality and is somewhat complex (thus the concern
>	about long standardization times). Some suggestions are:
>	
>	- the encapsulation and data management function of the split MAC model
>	seems separable from the AP control function. The encapsulation and data
>	management function could be implemented in a variety of ways (over IP, over
>	802, encrypted or not, etc.). Separating these two might be a good way to
>	simplify.
>	
>	- dynamic power control is something that IEEE is not currently working on
>	and might be an area where IETF might contribute value added. Channel
>	provisioning between APs might be another possibility. These are specific
>	instances of the general problem involving interactions between access
>	points that today need to be provisioned by hand in order to deploy and
>	manage a network, but could be automated relatively simply.
>	
>	- anything involving handover control and load balancing would require close
>	co-operation with 802.11k, which is currently working on designing
>	management frames for sending metrics to the host that the host would use
>	for making a handover decision, and so might be best left to IEEE. This
>	would be more consistent with the 802.11 host controlled handover model.
>	There might still be some role for handover control for management purposes
>	(i.e. an AP is about to be shut down for maintenance).
>	
>	- there clearly is a security issue of how an AR recognizes authorized APs,
>	but whether this is a task for an OPS-based WG is not clear. There was a BOF
>	at the last IETF on credential provisioning that might provide part of the
>	solution, but there might also be some work required specifically for this
>	application (certificate profiles, etc.). However, chances for quick success
>	are improved if existing IETF security solutions are built-upon, rather that
>	trying to invent new ones.
>	
>	                jak
>	
>	
>	
>	
>	
>	
>	
>	
>	_______________________________________________
>	Lwapp mailing list
>	Lwapp@frascone.com
>	http://mail.frascone.com/mailman/listinfo/lwapp
>	
>
>/??f??)?+-/???ڱ?'y?&??i??W?j?(??(??Y???b?ا~???i
>

-- 
----------------------------------------------------------------------
Simon Chung                            mailto:simon.chung@S3group.com
Senior Software Engineer                 http://www.s3group.com
Wireless Systems

 Silicon & Software Systems (S3)   Tel Direct: +353 1 291 1705
  Whelan House                     Tel Switch: +353 1 291 1000
   South County Business Park      FAX Direct: +353 1 291 1001
    Leopardstown, Dublin 18
----------------------------------------------------------------------



The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.

From Marcus Brunner   Tue Jul 29 18:04:43 2003
From: Marcus Brunner  (Marcus Brunner)
Date: Tue, 29 Jul 2003 19:04:43 +0200
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
In-Reply-To: <3F26A047.9060605@s3group.com>
References: 
 <3F26A047.9060605@s3group.com>
Message-ID: <31464753.1059505483@[10.1.1.130]>

I presume as well we are talking about "software / firmware images and 
specifying a software download protocol"

Given that we need would need to deal several vendors AP connected to one 
AR, I see a problem of automation of this task.

Therefore, I propose to declare the fireware download out of scope for that 
potential group.

Marcus

--On Dienstag, 29. Juli 2003 17:26 +0100 Simon Chung 
 wrote:

> Not sure I understand correctly. Please correct me if I am wrong.
>
> I presume we are talking about software / firmware images and specifying
> a software download protocol.
>
> However since these images are machine dependent, then how does
> interoperability achieved between AR and AP from different vendors? e.g.
> AR Vendor A sends its proprietary AP image to Vendor B's AP, but Vendor
> B's AP has a totally different hardware platform, with different
> microprocessor, memory, peripherals, etc. compared to Verndor A's AP.
>
> Are you suggesting to specify some sort of machine independent code for
> the image, with something like a Java VM in the AP?
>
> Cheers,
> Simon.
>
>
> Andrew Frame wrote:
>
>> Ok, how do I phrase this gently, I will hold myself back from saying
>> 'one foot on the banana peel and the other on the edge of the slippery
>> slope'... ;-)
>>
>> As I stated in an earlier email, this undoubtedly will become a
>> perpetual WG if we decide to stay in sync will all industry
>> standardization efforts.
>>
>> Focusing on standardizing a bootup-strap/discovery/image-download
>> protocol for APs without dictating what the image does or how it does it
>> allows vendors to track all standardization efforts within the image if
>> they enjoy enduring pain, without forcing that pain upon the IETF.
>>
>> Andrew
>>
>>
>>	-----Original Message-----
>>	From: James Kempf [mailto:kempf@docomolabs-usa.com]
>>	Sent: Tue 7/29/2003 1:29 AM
>>	To: Randy Bush; carlw@mcsr-labs.org
>>	Cc: lwapp@frascone.com; Bernard Aboba
>>	Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
>>	Discovery Request/Reply, and validation.)
>>	
>>	
>>
>>	As a followup to Randy's note, since CAPWAP is a new and potentially
>>	complex area of work that IETF would be taking on, there has been some
>>	discussion between IAB and IESG about how to get the work scoped
>>	properly and make sure the right people are involved so that it has a
>>	chance of succeeding in a reasonable amount of time. The intent is to
>>	avoid situations in which vendor interest evaporates because the
>>	original design is so complex that it takes years to standardize.
>>	
>>	Randy and Bert would like a short (not more than two pages, and one is
>>	better) problem statement that clearly describes what CAPWAP would do
>>	and, perhaps more importantly, what it will NOT do. Ideally, the problem
>>	statement would partition the problem into areas that IETF would take on
>>	in OPS, areas that might be appropriate for other IETF areas and a
>>	different working group (if any), and areas that are not really in
>>	IETF's scope and are better left to IEEE. In the areas that would be
>>	appropriate for a WG in the OPS area might include work with existing
>>	protocols (like, for example, SNMP), or they might include new work (in
>>	other words, the existence of a protocol that can supply a solution is
>>	not sufficient grounds in and of itself to not form a WG in OPS). This
>>	problem statement would then evolve into the charter.
>>	
>>	As a suggestion (and summarizing I* discussion), the current LWAPP
>>	protocol contains a lot of functionality and is somewhat complex (thus
>>	the concern about long standardization times). Some suggestions are:
>>	
>>	- the encapsulation and data management function of the split MAC model
>>	seems separable from the AP control function. The encapsulation and data
>>	management function could be implemented in a variety of ways (over IP,
>>	over 802, encrypted or not, etc.). Separating these two might be a good
>>	way to simplify.
>>	
>>	- dynamic power control is something that IEEE is not currently working
>>	on and might be an area where IETF might contribute value added. Channel
>>	provisioning between APs might be another possibility. These are specific
>>	instances of the general problem involving interactions between access
>>	points that today need to be provisioned by hand in order to deploy and
>>	manage a network, but could be automated relatively simply.
>>	
>>	- anything involving handover control and load balancing would require
>>	close co-operation with 802.11k, which is currently working on designing
>>	management frames for sending metrics to the host that the host would use
>>	for making a handover decision, and so might be best left to IEEE. This
>>	would be more consistent with the 802.11 host controlled handover model.
>>	There might still be some role for handover control for management
>>	purposes (i.e. an AP is about to be shut down for maintenance).
>>	
>>	- there clearly is a security issue of how an AR recognizes authorized
>>	APs, but whether this is a task for an OPS-based WG is not clear. There
>>	was a BOF at the last IETF on credential provisioning that might provide
>>	part of the solution, but there might also be some work required
>>	specifically for this application (certificate profiles, etc.). However,
>>	chances for quick success are improved if existing IETF security
>>	solutions are built-upon, rather that trying to invent new ones.
>>	
>>	                jak
>>	
>>	
>>	
>>	
>>	
>>	
>>	
>>	
>>	_______________________________________________
>>	Lwapp mailing list
>>	Lwapp@frascone.com
>>	http://mail.frascone.com/mailman/listinfo/lwapp
>>	
>>
>> /??f??)?+-/?????'y?&??i??W?j?(??(??Y???b??~???i
>>
>
> --
> ----------------------------------------------------------------------
> Simon Chung                            mailto:simon.chung@S3group.com
> Senior Software Engineer                 http://www.s3group.com
> Wireless Systems
>
>  Silicon & Software Systems (S3)   Tel Direct: +353 1 291 1705
>   Whelan House                     Tel Switch: +353 1 291 1000
>    South County Business Park      FAX Direct: +353 1 291 1001
>     Leopardstown, Dublin 18
> ----------------------------------------------------------------------
>
>
>
> The information contained in this e-mail and in any attachments is
> confidential and is designated solely for the attention of the intended
> recipient(s). If you are not an intended recipient, you must not use,
> disclose, copy, distribute or retain this e-mail or any part thereof. If
> you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer
> system(s). Please direct any additional queries to:
> communications@s3group.com. Thank You.
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp








From puneetb@myway.com  Tue Jul 29 18:37:30 2003
From: puneetb@myway.com (Puneet B)
Date: Tue, 29 Jul 2003 13:37:30 -0400 (EDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <20030729173730.8DEC33A06@xmxpita.myway.com>

> Which is great, Plug AP X into Controller Y and get Z functionality. 
> Plug AP X into Controller A and get B functionality. Sounds like a 
> perfect model to preserve differentiation in the marketplace while 
> not loading up the IETF with excessive work....

Does'nt this require that the AP and AR support the functionality or
service Z in exactly the same manner? Unless the service is also
described and standardized, how would the AP & AR interop? What
happens when an AP with capability Y is plugged into an AR that
implements the same functionality in a different manner (expects
a message in a different format from the AP)?

Perhaps some basic services or atleast a framework for negotiating
them should be defined in the protocol between AP & AR.

> > I am not sure if I understand this: By 'image' do you mean
> > the software/firmware that controls the AP? Would'nt that be opaque
> > to the AR? How would the AR and AP then know what services are
> > supported by each other?
>     
> It is the Controller who is providing the image to an AP it knows 
> the capabilities of, as these will be advertised in the Discovery 
> process. Assertion and control is conditional, this allows for the
> spec not to commit to a technology like 802.11, it can easily support
> 802.16 or Bluetooth with no changes...

So the AR sends an image to the AP based on the capabilities that
the AP advertises? Should'nt that be the other way around? The AP 
should advertise its capability based on the image that has been 
downloaded to it. The AR need not worry about the image and its 
contents for every AP of every vendor. It can just use messages 
during the discovery process to find out the capabilities of the
AP and the services supported. 

Puneet

_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com

From puneetb@myway.com  Tue Jul 29 18:59:24 2003
From: puneetb@myway.com (Puneet B)
Date: Tue, 29 Jul 2003 13:59:24 -0400 (EDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <20030729175924.3A2923A06@xmxpita.myway.com>

> I presume as well we are talking about "software / firmware images 
> and specifying a software download protocol"
>
> Given that we need would need to deal several vendors AP connected
> to one AR, I see a problem of automation of this task.
>
> Therefore, I propose to declare the fireware download out of scope
> for that potential group.

The protocol could perhaps support firmware download, but without the
AR having to know what capabilities are included in each image
that it is downloading. Does the AR need to know anything other than
the AP vendor ID and perhaps a hardware-ID of the AP to know what image
to download? If its just these two parameters, the AR can get this
from the AP during discovery.

This might be a very useful mgmt/config feature (support for image 
download in a multi-vendor AP environment) and would be a lot 
easier to implement if it could be standardized.

Puneet

_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com

From randy@psg.com  Tue Jul 29 19:11:59 2003
From: randy@psg.com (Randy Bush)
Date: Tue, 29 Jul 2003 11:11:59 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
Message-ID: 

> Focusing on standardizing a bootup-strap/discovery/image-download protocol
> for APs without dictating what the image does or how it does it allows
> vendors to track all standardization efforts within the image if they
> enjoy enduring pain, without forcing that pain upon the IETF.

does it allow users to have interoperable mixed-vendor installations?

randy


From dharkins@trpz.com  Tue Jul 29 19:56:02 2003
From: dharkins@trpz.com (Dan Harkins)
Date: Tue, 29 Jul 2003 11:56:02 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: Your message of "Tue, 29 Jul 2003 13:37:30 EDT."
 <20030729173730.8DEC33A06@xmxpita.myway.com>
Message-ID: <200307291856.h6TIu2n44920@homebrew.trpz.com>

  Puneet,

On Tue, 29 Jul 2003 13:37:30 EDT you wrote
> 
> > Which is great, Plug AP X into Controller Y and get Z functionality. 
> > Plug AP X into Controller A and get B functionality. Sounds like a 
> > perfect model to preserve differentiation in the marketplace while 
> > not loading up the IETF with excessive work....
> 
> Does'nt this require that the AP and AR support the functionality or
> service Z in exactly the same manner? Unless the service is also
> described and standardized, how would the AP & AR interop? What
> happens when an AP with capability Y is plugged into an AR that
> implements the same functionality in a different manner (expects
> a message in a different format from the AP)?
> 
> Perhaps some basic services or atleast a framework for negotiating
> them should be defined in the protocol between AP & AR.

The functionality to provide a service is embedded in the image
that is provided to the AP by the controller. So by definition
they will support the service in "exactly the same manner".

For instance, the vendor of controller Y thinks (IEEE TGi defined)
pre-authentication is very valuable. The image downloaded to
AP X when it agrees to be controlled by controller Y would include
code to support it. It doesn't matter how that gets configured
because the controller speaks to the AP using a protocol that is
defined in the image the AP is now running. The vendor for 
controller Z may think pre-auth is valuable too and the image it
downloads to the AP supports it. Externally, the AP looks the same
but the protocol the AP now uses to configure pre-auth is different.
There is no reason to insist on the particular configuration
and management of the AP between vendors Y and Z be the same.

> > > I am not sure if I understand this: By 'image' do you mean
> > > the software/firmware that controls the AP? Would'nt that be opaque
> > > to the AR? How would the AR and AP then know what services are
> > > supported by each other?
> >     
> > It is the Controller who is providing the image to an AP it knows 
> > the capabilities of, as these will be advertised in the Discovery 
> > process. Assertion and control is conditional, this allows for the
> > spec not to commit to a technology like 802.11, it can easily support
> > 802.16 or Bluetooth with no changes...
> 
> So the AR sends an image to the AP based on the capabilities that
> the AP advertises? Should'nt that be the other way around? The AP 
> should advertise its capability based on the image that has been 
> downloaded to it. The AR need not worry about the image and its 
> contents for every AP of every vendor. It can just use messages 
> during the discovery process to find out the capabilities of the
> AP and the services supported. 

No, what the AP "advertises" is, for instance, the particular radio
and chipset it has. The controller may have a diverse set of images
it can give to an AP. It doesn't want to send an image to drive a
radio that the AP does not have. Once the appropriate image has been
booted on the AP it can now "advertise" all sorts of services-- 
filtering, pre-auth, fast context handoff, etc.

  regards,

  Dan.


From jhw@apple.com  Tue Jul 29 20:18:23 2003
From: jhw@apple.com (james woodyatt)
Date: Tue, 29 Jul 2003 12:18:23 -0700
Subject: [Lwapp] Re: Scope of Charter Discussion
In-Reply-To: <200307291856.h6TIu2n44920@homebrew.trpz.com>
Message-ID: <6BD97A7F-C1F9-11D7-8085-0030657BB80E@apple.com>

everyone--

Why is this discussion reminding me of the MEGACO effort?

Perhaps it would be wise to review RFC 2805 and think hard about the 
similarities and differences between telephony signaling and wireless 
network access signaling.

Then it might help to notice just how long it took for MEGACO to 
deliver results, and wonder about whether there are any lessons to 
learn from their experience.  Maybe the first lesson is to decide early 
on-- and with extreme prejudice-- what problems the group is explicitly 
*NOT* trying to solve.

Just a thought.


-- 
james woodyatt 


From dharkins@trpz.com  Tue Jul 29 20:27:32 2003
From: dharkins@trpz.com (Dan Harkins)
Date: Tue, 29 Jul 2003 12:27:32 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: Your message of "Tue, 29 Jul 2003 04:20:11 PDT."
 <40301581B2962B448690A023EF16DFE1DC5378@bsn-mail-01.bstormnetworks.com>
Message-ID: <200307291927.h6TJRWn45019@homebrew.trpz.com>

  That's exactly right! The AP says what kind of brain it can run and
the controller gives it the right kind of brain. What that brain does
is up to the vendor. APs become commoditized and it lets the marketplace
decide whose brain is abby-normal and whose is not. 

  The alternative is to tie people down to a particular architecture
(is the AP "thin", "fat", "svelte", or "pleasantly plump"?) and the
resulting protocol will be a complex mess of every whizbang feature, 
gimmick, and standard-- some mandatory, some optional, all very complex.

  The "AP Brain Transplant Protocol" is something that can be easily
bitten off and chewed up, the alternative would be so large it would 
cause gagging and vomitting. We could define a solution and close up the
WG in a reasonable amount of time or we can form another endless working
group (we all know which ones those are) that will be overtaken by 
circumstances and end up defining something that is no longer useful 
because people got tired of waiting for the standard, had others willing
to give them $$$$ for a solution, and went off and did their own 
proprietary thing.

  Dan.

On Tue, 29 Jul 2003 04:20:11 PDT you wrote
> Sounds like just the "AP Brain Transplant Protocol", or am I missing somethin
>g?
> 
> patC
> 
> 
> -----Original Message-----
> From:	Andrew Frame [mailto:aframe@trapezenetworks.com]
> Sent:	Mon 7/28/2003 11:53 PM
> To:	puneetb@myway.com; randy@psg.com; carlw@mcsr-labs.org
> Cc:	lwapp@frascone.com
> Subject:	RE: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
> Discovery Request/Reply, and validation.)
> > I am not sure if I understand this: By 'image' do you mean
> > the software/firmware that controls the AP? Would'nt that be opaque
> > to the AR? How would the AR and AP then know what services are
> > supported by each other?
> 
> It is the Controller who is providing the image to an AP it knows the capabil
>ities of, as these will be advertised in the Discovery process. Assertion and 
>control is conditional, this allows for the spec not to commit to a technology
> like 802.11, it can easily support 802.16 or Bluetooth with no changes...
> 
> 
> > Also, in what you are proposing, each time an AP boots up or
> > discovers an AR is there a way/need for the AP and AR to exchange
> > information about their respective capabilities (what services
> > are supported)? Are there services that need support in both
> > AP & AR? How are they handled?
> 
> No capability exchange is neccessary, assertion and control will only be assu
>med by qualified controllers based on the AP's advertised capabilities, a hard
>ware descriptor if you will. The goal of the WG should be to respect the term 
>'light-weight'.....
> 
> Andrew
> 
> /f)+-/?'y&iWj((Yb?~i
> 
> 
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp

From randy@psg.com  Tue Jul 29 20:27:45 2003
From: randy@psg.com (Randy Bush)
Date: Tue, 29 Jul 2003 12:27:45 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <40301581B2962B448690A023EF16DFE1DC5378@bsn-mail-01.bstormnetworks.com>
 <200307291927.h6TJRWn45019@homebrew.trpz.com>
Message-ID: 

> The AP says what kind of brain it can run and the controller
> gives it the right kind of brain. What that brain does is up to
> the vendor.

so vendor A's controller will load the appropriate images into
vendor B's and C's APs?  and that controller will know what
capabilities each of B's and C's images have, and how they will
interface with the A controller's capabilities?

sounds way cool.  

but somehow i think there's a bit of a missing piece here.  i
suspect that an effective brain transplant requires hooking up all
the nerves to the existing senses and making sense of them.  and,
to be effective, that brain needs to be able to make the local
mouth and ears discuss with the rest of the brains in the room,
what it is sensing and what it should do about it.

randy


From bhandaru@legra.com  Tue Jul 29 20:55:13 2003
From: bhandaru@legra.com (Nehru Bhandaru)
Date: Tue, 29 Jul 2003 15:55:13 -0400
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: 
Message-ID: <000401c3560b$52ebf410$ea0ba8c0@legra.com>

I may be naive, but I would think a vendor's image only needs
to specify which version of protocol (lwapp) it supports. The 
capabilities would be negotiated as part of the protocol. These
include radio characteristics, encryption algorithms etc...

- Nehru

-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf
Of Randy Bush
Sent: Tuesday, July 29, 2003 3:28 PM
To: Dan Harkins
Cc: lwapp@frascone.com
Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
Discovery Request/Reply, and validation.) 


> The AP says what kind of brain it can run and the controller gives it 
> the right kind of brain. What that brain does is up to the vendor.

so vendor A's controller will load the appropriate images into vendor B's
and C's APs?  and that controller will know what capabilities each of B's
and C's images have, and how they will interface with the A controller's
capabilities?

sounds way cool.  

but somehow i think there's a bit of a missing piece here.  i suspect that
an effective brain transplant requires hooking up all the nerves to the
existing senses and making sense of them.  and, to be effective, that brain
needs to be able to make the local mouth and ears discuss with the rest of
the brains in the room, what it is sensing and what it should do about it.

randy

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp


From puneetb@myway.com  Tue Jul 29 21:12:53 2003
From: puneetb@myway.com (Puneet B)
Date: Tue, 29 Jul 2003 16:12:53 -0400 (EDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <20030729201253.C9AFD3A01@xmxpita.myway.com>

> The functionality to provide a service is embedded in the image
> that is provided to the AP by the controller. So by definition
> they will support the service in "exactly the same manner".
> 
> For instance, the vendor of controller Y thinks (IEEE TGi defined)
> pre-authentication is very valuable. The image downloaded to
> AP X when it agrees to be controlled by controller Y would include
> code to support it. It doesn't matter how that gets configured
> because the controller speaks to the AP using a protocol that is
> defined in the image the AP is now running. The vendor for 
> controller Z may think pre-auth is valuable too and the image it
> downloads to the AP supports it. Externally, the AP looks the same
> but the protocol the AP now uses to configure pre-auth is different.

Point taken: as long as the services are standard, then those 
message formats would be standard. Non-standard services would'nt
be interoperable.

My concern is regarding the way the AR and AP understand each others 
capabilities. Given an image (a binary file) how does the AR know
what hardware and services are included in that image? Will this be 
be automagically derived from the image when its stored on the AR,
or does an operator select/deselect from a list of services
corresponding to every image? Is'nt it easier/flexible/automatic
if the AP-AR negotiate this as part of LWAPP with message exchanges?

> There is no reason to insist on the particular configuration
> and management of the AP between vendors Y and Z be the same.

But then how would an AR from vendor X turn off feature Z in an 
AP from vendor Y?

On a related note, would SNMP and LWAPP between AP & AR co-exist? If 
not, how do you update parameters, or read parameters from an AP in 
a standard/interoperable manner for this service Z? Can we assume that
the standard/WG that defines Z would provide those messages? How do
those configuration messages fit in with the LWAPP "AR Configuration"
messages?

> > So the AR sends an image to the AP based on the capabilities that
> > the AP advertises? Should'nt that be the other way around? The AP 
> > should advertise its capability based on the image that has been 
> > downloaded to it. The AR need not worry about the image and its 
> > contents for every AP of every vendor. It can just use messages 
> > during the discovery process to find out the capabilities of the
> > AP and the services supported. 
>
> No, what the AP "advertises" is, for instance, the particular radio
> and chipset it has. The controller may have a diverse set of images
> it can give to an AP. It doesn't want to send an image to drive a
> radio that the AP does not have. Once the appropriate image has been
> booted on the AP it can now "advertise" all sorts of services-- 
> filtering, pre-auth, fast context handoff, etc.

ok, so we have two different things the AP advertises:
 1. its hardware capabilities
 2. its service capabilities
The AR needs to link #1 with the list of images it has. This can be
with operator intervention or automated. For #2 dont we need a protocol
for sending advertisements and acknowledgements for these services 
between the AP and AR? This seems to contradict the proposal of the AR
using the image it downloaded to find out what services the AP supports.
If the AP advertises its services, then the AR need not care about
the contents of the image it downloaded to the AR.

Thanks,
Puneet

_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com

From dharkins@trpz.com  Tue Jul 29 21:27:24 2003
From: dharkins@trpz.com (Dan Harkins)
Date: Tue, 29 Jul 2003 13:27:24 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: Your message of "Tue, 29 Jul 2003 15:55:13 EDT."
 <000401c3560b$52ebf410$ea0ba8c0@legra.com>
Message-ID: <200307292027.h6TKROn45199@homebrew.trpz.com>

  Nehru, 

  It's not naivity. It's just a different way of looking at what
the protocol is supposed to do. Does it allow for an AP and
controller to agree on what the AP can do and define how to
configure and manage that? Or does it merely allow for an AP to
define what sort of image it can run and then let that image
provide for the configuration and management of services that
are encapsulated inside the image? I tend to believe in the latter.

  I just don't think it'll be a good idea to define a protocol 
that allows for everything under the sun to be configured and if
you don't think that it would grow to include everything under
the sun then that's what's naive. There would be hour+ long
arguments at meetings on whether one clique's favorite feature
was a MUST or a SHOULD. Inboxes would fill up over whether to
include support for some other group's favorite feature. And
it would require constant updating to keep up with the ever-growing
number of features possible.

  And it locks people into an architecture. For instance, you said
that the capabilities negotiated would include "encryption algorithms".
Who says that the AP is doing encryption and decryption? I know
of at least one system in which the AP just encapsulates encrypted 
802.11 packets and sends them up the wire to the controller to
process. In that architecture it doesn't matter if the AP supports
any encryption algorithms at all! But is that a One Size Fits All
Architecture? No, absolutely not, but neither is the opposite.
There is no One Size Fits All so let's not paint ourselves into a
box by architecting one.

  Dan.

On Tue, 29 Jul 2003 15:55:13 EDT you wrote
> 
> I may be naive, but I would think a vendor's image only needs
> to specify which version of protocol (lwapp) it supports. The 
> capabilities would be negotiated as part of the protocol. These
> include radio characteristics, encryption algorithms etc...
> 
> - Nehru
> 
> -----Original Message-----
> From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf
> Of Randy Bush
> Sent: Tuesday, July 29, 2003 3:28 PM
> To: Dan Harkins
> Cc: lwapp@frascone.com
> Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
> Discovery Request/Reply, and validation.) 
> 
> 
> > The AP says what kind of brain it can run and the controller gives it 
> > the right kind of brain. What that brain does is up to the vendor.
> 
> so vendor A's controller will load the appropriate images into vendor B's
> and C's APs?  and that controller will know what capabilities each of B's
> and C's images have, and how they will interface with the A controller's
> capabilities?
> 
> sounds way cool.  
> 
> but somehow i think there's a bit of a missing piece here.  i suspect that
> an effective brain transplant requires hooking up all the nerves to the
> existing senses and making sense of them.  and, to be effective, that brain
> needs to be able to make the local mouth and ears discuss with the rest of
> the brains in the room, what it is sensing and what it should do about it.
> 
> randy
> 
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp
> 
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp

From bhandaru@legra.com  Tue Jul 29 23:27:05 2003
From: bhandaru@legra.com (Nehru Bhandaru)
Date: Tue, 29 Jul 2003 18:27:05 -0400
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: <200307292027.h6TKROn45199@homebrew.trpz.com>
Message-ID: <000001c35620$8bc8ca00$ee0ba8c0@legra.com>

Dan,

If I understand you correctly, the two ways you describe are mappping
the set of the capabilities onto an image or the set of capabilities
negotiated using the protocol by the image. In either case, the set of=20
such capabilities needs to be determined and agreed upon.

My preference is for the protocol that enables the controller (AR) that
implements policy to configure what the AP advertises. The image itself
may not determine what the AP is capable of; the same image could=20
conceivably support more than one hardware device. The AP may
advertise encryption capability or lack of it, but there is no =
requirement=20
from the protocol that it be used if the controller provided that
functionality.=20

I agree that the architecture must be flexible and that the capabilities
that are allowed to be negotiated must be scoped.=20

- Nehru

-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On =
Behalf
Of Dan Harkins
Sent: Tuesday, July 29, 2003 4:27 PM
To: lwapp@frascone.com
Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
Discovery Request/Reply, and validation.)=20


  Nehru,=20

  It's not naivity. It's just a different way of looking at what the
protocol is supposed to do. Does it allow for an AP and controller to =
agree
on what the AP can do and define how to configure and manage that? Or =
does
it merely allow for an AP to define what sort of image it can run and =
then
let that image provide for the configuration and management of services =
that
are encapsulated inside the image? I tend to believe in the latter.

  I just don't think it'll be a good idea to define a protocol=20
that allows for everything under the sun to be configured and if you =
don't
think that it would grow to include everything under the sun then that's
what's naive. There would be hour+ long arguments at meetings on whether =
one
clique's favorite feature was a MUST or a SHOULD. Inboxes would fill up =
over
whether to include support for some other group's favorite feature. And =
it
would require constant updating to keep up with the ever-growing number =
of
features possible.

  And it locks people into an architecture. For instance, you said that =
the
capabilities negotiated would include "encryption algorithms". Who says =
that
the AP is doing encryption and decryption? I know of at least one system =
in
which the AP just encapsulates encrypted=20
802.11 packets and sends them up the wire to the controller to process. =
In
that architecture it doesn't matter if the AP supports any encryption
algorithms at all! But is that a One Size Fits All Architecture? No,
absolutely not, but neither is the opposite. There is no One Size Fits =
All
so let's not paint ourselves into a box by architecting one.

  Dan.

On Tue, 29 Jul 2003 15:55:13 EDT you wrote
>=20
> I may be naive, but I would think a vendor's image only needs to=20
> specify which version of protocol (lwapp) it supports. The=20
> capabilities would be negotiated as part of the protocol. These=20
> include radio characteristics, encryption algorithms etc...
>=20
> - Nehru
>=20
> -----Original Message-----
> From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On=20
> Behalf Of Randy Bush
> Sent: Tuesday, July 29, 2003 3:28 PM
> To: Dan Harkins
> Cc: lwapp@frascone.com
> Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp]=20
> Certificates, Discovery Request/Reply, and validation.)
>=20
>=20
> > The AP says what kind of brain it can run and the controller gives=20
> > it
> > the right kind of brain. What that brain does is up to the vendor.
>=20
> so vendor A's controller will load the appropriate images into vendor=20
> B's and C's APs?  and that controller will know what capabilities each =

> of B's and C's images have, and how they will interface with the A=20
> controller's capabilities?
>=20
> sounds way cool.
>=20
> but somehow i think there's a bit of a missing piece here.  i suspect=20
> that an effective brain transplant requires hooking up all the nerves=20
> to the existing senses and making sense of them.  and, to be=20
> effective, that brain needs to be able to make the local mouth and=20
> ears discuss with the rest of the brains in the room, what it is=20
> sensing and what it should do about it.
>=20
> randy
>=20
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp
>=20
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp


From aframe@trapezenetworks.com  Wed Jul 30 02:27:46 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Tue, 29 Jul 2003 18:27:46 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

> My concern is regarding the way the AR and AP understand each others
> capabilities. Given an image (a binary file) how does the AR know
> what hardware and services are included in that image? Will this be
> be automagically derived from the image when its stored on the AR,
> or does an operator select/deselect from a list of services
> corresponding to every image? Is'nt it easier/flexible/automatic
> if the AP-AR negotiate this as part of LWAPP with message exchanges?

How AR-stored images are associated with hw-capabilities and
service-capabilities can be a point for further discussion.

>=20
> > There is no reason to insist on the particular configuration
> > and management of the AP between vendors Y and Z be the same.
>=20
> But then how would an AR from vendor X turn off feature Z in an
> AP from vendor Y?
>=20
> On a related note, would SNMP and LWAPP between AP & AR co-exist? If
> not, how do you update parameters, or read parameters from an AP in
> a standard/interoperable manner for this service Z? Can we assume that
> the standard/WG that defines Z would provide those messages? How do
> those configuration messages fit in with the LWAPP "AR Configuration"
> messages?

Since the image is being provided by the AR, an assumption can be made
that it was written by the same software team (or at least the same
company) who wrote the AR software. Pick your favorite poison for
parameter setting/reading, as long as its out of the scope of the
proposed WG. Put another way, communication at the 'service level' stays
out of scope.

>=20
> > > So the AR sends an image to the AP based on the capabilities that
> > > the AP advertises? Should'nt that be the other way around? The AP
> > > should advertise its capability based on the image that has been
> > > downloaded to it. The AR need not worry about the image and its
> > > contents for every AP of every vendor. It can just use messages
> > > during the discovery process to find out the capabilities of the
> > > AP and the services supported.
> >
> > No, what the AP "advertises" is, for instance, the particular radio
> > and chipset it has. The controller may have a diverse set of images
> > it can give to an AP. It doesn't want to send an image to drive a
> > radio that the AP does not have. Once the appropriate image has been
> > booted on the AP it can now "advertise" all sorts of services--
> > filtering, pre-auth, fast context handoff, etc.
>=20
> ok, so we have two different things the AP advertises:
>  1. its hardware capabilities
>  2. its service capabilities
> The AR needs to link #1 with the list of images it has. This can be
> with operator intervention or automated. For #2 dont we need a
protocol
> for sending advertisements and acknowledgements for these services
> between the AP and AR? This seems to contradict the proposal of the AR
> using the image it downloaded to find out what services the AP
supports.
> If the AP advertises its services, then the AR need not care about
> the contents of the image it downloaded to the AR.

Exactly. The 'hardware capabilities' would be announced in the Discovery
process in order to hookup with an AR that can service it with an image.
An AR will only assert and control an AP with hardware compatible with
the available images. This 'marriage' is purely conditional and is based
on a compatible image being available on the AR. I believe you
misunderstood Dan, the 'service capabilities' would not be advertised by
the AP after an image was offered, as the capabilities would be already
known by the AR.

Andrew

From puneetb@myway.com  Wed Jul 30 04:33:56 2003
From: puneetb@myway.com (Puneet B)
Date: Tue, 29 Jul 2003 23:33:56 -0400 (EDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <20030730033356.EA58539F7@xmxpita.myway.com>

> Since the image is being provided by the AR, an assumption can be made
> that it was written by the same software team (or at least the same
> company) who wrote the AR software. Pick your favorite poison for
> parameter setting/reading, as long as its out of the scope of the
> proposed WG. Put another way, communication at the 'service level' stays
> out of scope.

I think I am still missing something here: I thought the idea behind 
LWAPP was to allow APs from different vendors to interop with different
ARs. In that case how can we assume the AP image provided by the AR is
written by the same team that wrote the AR software? I am assuming a
scenario where I have an AR from vendor X and an AP from vendor Y. Vendor
Y now provides me a new software image that I must upgrade my APs with.
The AR from vendor X has no idea what the contents of that image are.
How does this scenario fit in with what you are proposing?

> Exactly. The 'hardware capabilities' would be announced in the Discovery
> process in order to hookup with an AR that can service it with an image.
> An AR will only assert and control an AP with hardware compatible with
> the available images. This 'marriage' is purely conditional and is based
> on a compatible image being available on the AR. I believe you
> misunderstood Dan, the 'service capabilities' would not be advertised by
> the AP after an image was offered, as the capabilities would be already
> known by the AR.

ok, so the AP does not advertise its service capabilities, the AR 'remembers'
the capabilities of each AP based on what image it downloaded to the AP. I
am also assuming that this download happens only once (not each time the
AP reboots). Is that correct? What happens when we now replace a failed AR
with another one or one from another vendor?  In your proposal how does the
new AR know the service capabilities of the existing APs?

Puneet

_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com

From aboba@internaut.com  Wed Jul 30 07:18:50 2003
From: aboba@internaut.com (Bernard Aboba)
Date: Tue, 29 Jul 2003 23:18:50 -0700 (PDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
In-Reply-To: 
References: 
 
Message-ID: 

> Focusing on standardizing a bootup-strap/discovery/image-download protocol
> for APs without dictating what the image does or how it does it allows
> vendors to track all standardization efforts within the image if they
> enjoy enduring pain, without forcing that pain upon the IETF.

Is there something unique about the AP bootstrap problem? (As opposed to
the generic bootstrap problem).

From pcalhoun@airespace.com  Wed Jul 30 12:25:46 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 30 Jul 2003 04:25:46 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC5386@bsn-mail-01.bstormnetworks.com>

> Assertion and control will only occur if the Controller can accomdate =
the=20
> AP's capabilities. If there is sufficient reason for a capabilities =
exchange=20
> I am not against this....

Isn't that what we are here for? Your alternative where each vendor must =
port their software to each OEM APs available on the market seems rather =
complex...=20

If I look at L2TP for instance, I suppose we could have enforced that =
all LNS' to simply download a software image to the LAC and be done with =
it, but would this have achieved any form of interoperability?

PatC=20

From pcalhoun@airespace.com  Wed Jul 30 12:28:13 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 30 Jul 2003 04:28:13 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC5387@bsn-mail-01.bstormnetworks.com>

> I presume as well we are talking about "software / firmware images and =

> specifying a software download protocol"

> Given that we need would need to deal several vendors AP connected to =
one=20
> AR, I see a problem of automation of this task.

> Therefore, I propose to declare the fireware download out of scope for =
that=20
> potential group.

It is a problem in Andrew's recommendation, because frankly it is not a =
very workable solution (from an engineering perspective). However, it is =
perfectly valid for my AR to fetch the latest code from an OEM AP's web =
site (either automatically or not) and download it to the APs.

patC

From dromasca@avaya.com  Wed Jul 30 12:33:30 2003
From: dromasca@avaya.com (Romascanu, Dan (Dan))
Date: Wed, 30 Jul 2003 14:33:30 +0300
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

>=20
> > I presume as well we are talking about "software / firmware=20
> images and=20
> > specifying a software download protocol"
>=20
> > Given that we need would need to deal several vendors AP=20
> connected to one=20
> > AR, I see a problem of automation of this task.
>=20
> > Therefore, I propose to declare the fireware download out=20
> of scope for that=20
> > potential group.
>=20
> It is a problem in Andrew's recommendation, because frankly=20
> it is not a very workable solution (from an engineering=20
> perspective). However, it is perfectly valid for my AR to=20
> fetch the latest code from an OEM AP's web site (either=20
> automatically or not) and download it to the APs.
>=20
> patC

Unless I miss something, I would say that this problem is not specific =
for CAPWAP, and does not require a new protocol.=20

Dan
=20

From pcalhoun@airespace.com  Wed Jul 30 12:34:32 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 30 Jul 2003 04:34:32 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC538A@bsn-mail-01.bstormnetworks.com>

>> Which is great, Plug AP X into Controller Y and get Z functionality.=20
>> Plug AP X into Controller A and get B functionality. Sounds like a=20
>> perfect model to preserve differentiation in the marketplace while=20
>> not loading up the IETF with excessive work....
>
> Does'nt this require that the AP and AR support the functionality or
> service Z in exactly the same manner? Unless the service is also
> described and standardized, how would the AP & AR interop? What
> happens when an AP with capability Y is plugged into an AR that
> implements the same functionality in a different manner (expects
> a message in a different format from the AP)?

> Perhaps some basic services or atleast a framework for negotiating
> them should be defined in the protocol between AP & AR.

Sorry folks, but you've lost me. What is this 'service'??? An AP needs =
to simply tunnel packets to the AR. Let's keep the AP as simple as =
possible and offload all 'services' to the AR, reducing the complexity =
of capabilities exchange. Currently, the spec really has one capability =
that is exchange (do you encrypt L2 or not?).

PatC

From pcalhoun@airespace.com  Wed Jul 30 12:40:16 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 30 Jul 2003 04:40:16 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC538C@bsn-mail-01.bstormnetworks.com>

> For instance, the vendor of controller Y thinks (IEEE TGi defined)
> pre-authentication is very valuable. The image downloaded to
> AP X when it agrees to be controlled by controller Y would include
> code to support it. It doesn't matter how that gets configured
> because the controller speaks to the AP using a protocol that is
> defined in the image the AP is now running. The vendor for=20
> controller Z may think pre-auth is valuable too and the image it
> downloads to the AP supports it. Externally, the AP looks the same
> but the protocol the AP now uses to configure pre-auth is different.
> There is no reason to insist on the particular configuration
> and management of the AP between vendors Y and Z be the same.

But the spec, as written, would cause the AR to decide whether 802.11i =
was required or not, it would terminate the 802.11i protocol, and =
download keys to the AP. This seems so much simpler than having this =
really complex capabilities exchange between the AP and the AR, no?

PatC

From pcalhoun@airespace.com  Wed Jul 30 12:41:45 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 30 Jul 2003 04:41:45 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC538D@bsn-mail-01.bstormnetworks.com>

I, for one, will not port my software to all APs available on the =
market. Maybe others believe this is a good idea, but I'm not one of =
them :(

PatC
-----Original Message-----
From:	Dan Harkins [mailto:dharkins@trpz.com]
Sent:	Tue 7/29/2003 12:27 PM
To:	Pat R. Calhoun
Cc:	Andrew Frame; puneetb@myway.com; randy@psg.com; carlw@mcsr-labs.org; =
lwapp@frascone.com
Subject:	Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, =
Discovery Request/Reply, and validation.)=20
  That's exactly right! The AP says what kind of brain it can run and
the controller gives it the right kind of brain. What that brain does
is up to the vendor. APs become commoditized and it lets the marketplace
decide whose brain is abby-normal and whose is not.=20

  The alternative is to tie people down to a particular architecture
(is the AP "thin", "fat", "svelte", or "pleasantly plump"?) and the
resulting protocol will be a complex mess of every whizbang feature,=20
gimmick, and standard-- some mandatory, some optional, all very complex.

  The "AP Brain Transplant Protocol" is something that can be easily
bitten off and chewed up, the alternative would be so large it would=20
cause gagging and vomitting. We could define a solution and close up the
WG in a reasonable amount of time or we can form another endless working
group (we all know which ones those are) that will be overtaken by=20
circumstances and end up defining something that is no longer useful=20
because people got tired of waiting for the standard, had others willing
to give them $$$$ for a solution, and went off and did their own=20
proprietary thing.

  Dan.

On Tue, 29 Jul 2003 04:20:11 PDT you wrote
> Sounds like just the "AP Brain Transplant Protocol", or am I missing =
somethin
>g?
>=20
> patC
>=20
>=20
> -----Original Message-----
> From:	Andrew Frame [mailto:aframe@trapezenetworks.com]
> Sent:	Mon 7/28/2003 11:53 PM
> To:	puneetb@myway.com; randy@psg.com; carlw@mcsr-labs.org
> Cc:	lwapp@frascone.com
> Subject:	RE: Scope of Charter Discussion (was: Re: [Lwapp] =
Certificates,
> Discovery Request/Reply, and validation.)
> > I am not sure if I understand this: By 'image' do you mean
> > the software/firmware that controls the AP? Would'nt that be opaque
> > to the AR? How would the AR and AP then know what services are
> > supported by each other?
>=20
> It is the Controller who is providing the image to an AP it knows the =
capabil
>ities of, as these will be advertised in the Discovery process. =
Assertion and=20
>control is conditional, this allows for the spec not to commit to a =
technology
> like 802.11, it can easily support 802.16 or Bluetooth with no =
changes...
>=20
>=20
> > Also, in what you are proposing, each time an AP boots up or
> > discovers an AR is there a way/need for the AP and AR to exchange
> > information about their respective capabilities (what services
> > are supported)? Are there services that need support in both
> > AP & AR? How are they handled?
>=20
> No capability exchange is neccessary, assertion and control will only =
be assu
>med by qualified controllers based on the AP's advertised capabilities, =
a hard
>ware descriptor if you will. The goal of the WG should be to respect =
the term=20
>'light-weight'.....
>=20
> Andrew
>=20
> /=06f)+-/=06?'y&iWj((Yb?~i
>=20
>=20
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp




From pcalhoun@airespace.com  Wed Jul 30 12:44:07 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 30 Jul 2003 04:44:07 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC538F@bsn-mail-01.bstormnetworks.com>

> I may be naive, but I would think a vendor's image only needs
> to specify which version of protocol (lwapp) it supports. The=20
> capabilities would be negotiated as part of the protocol. These
> include radio characteristics, encryption algorithms etc...

Maybe I'm naive too, then...

PatC

From pcalhoun@airespace.com  Wed Jul 30 12:46:00 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 30 Jul 2003 04:46:00 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC5390@bsn-mail-01.bstormnetworks.com>

But Dan, the goal is to provide true interoperability. I see your =
proposal as simply a convenient way to download each vendor's image to =
their APs. It does not provide interopability with other APs on the =
market.

PatC
-----Original Message-----
From:	Dan Harkins [mailto:dharkins@trpz.com]
Sent:	Tue 7/29/2003 1:27 PM
To:	lwapp@frascone.com
Cc:=09
Subject:	Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, =
Discovery Request/Reply, and validation.)=20
  Nehru,=20

  It's not naivity. It's just a different way of looking at what
the protocol is supposed to do. Does it allow for an AP and
controller to agree on what the AP can do and define how to
configure and manage that? Or does it merely allow for an AP to
define what sort of image it can run and then let that image
provide for the configuration and management of services that
are encapsulated inside the image? I tend to believe in the latter.

  I just don't think it'll be a good idea to define a protocol=20
that allows for everything under the sun to be configured and if
you don't think that it would grow to include everything under
the sun then that's what's naive. There would be hour+ long
arguments at meetings on whether one clique's favorite feature
was a MUST or a SHOULD. Inboxes would fill up over whether to
include support for some other group's favorite feature. And
it would require constant updating to keep up with the ever-growing
number of features possible.

  And it locks people into an architecture. For instance, you said
that the capabilities negotiated would include "encryption algorithms".
Who says that the AP is doing encryption and decryption? I know
of at least one system in which the AP just encapsulates encrypted=20
802.11 packets and sends them up the wire to the controller to
process. In that architecture it doesn't matter if the AP supports
any encryption algorithms at all! But is that a One Size Fits All
Architecture? No, absolutely not, but neither is the opposite.
There is no One Size Fits All so let's not paint ourselves into a
box by architecting one.

  Dan.

On Tue, 29 Jul 2003 15:55:13 EDT you wrote
>=20
> I may be naive, but I would think a vendor's image only needs
> to specify which version of protocol (lwapp) it supports. The=20
> capabilities would be negotiated as part of the protocol. These
> include radio characteristics, encryption algorithms etc...
>=20
> - Nehru
>=20
> -----Original Message-----
> From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On =
Behalf
> Of Randy Bush
> Sent: Tuesday, July 29, 2003 3:28 PM
> To: Dan Harkins
> Cc: lwapp@frascone.com
> Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] =
Certificates,
> Discovery Request/Reply, and validation.)=20
>=20
>=20
> > The AP says what kind of brain it can run and the controller gives =
it=20
> > the right kind of brain. What that brain does is up to the vendor.
>=20
> so vendor A's controller will load the appropriate images into vendor =
B's
> and C's APs?  and that controller will know what capabilities each of =
B's
> and C's images have, and how they will interface with the A =
controller's
> capabilities?
>=20
> sounds way cool. =20
>=20
> but somehow i think there's a bit of a missing piece here.  i suspect =
that
> an effective brain transplant requires hooking up all the nerves to =
the
> existing senses and making sense of them.  and, to be effective, that =
brain
> needs to be able to make the local mouth and ears discuss with the =
rest of
> the brains in the room, what it is sensing and what it should do about =
it.
>=20
> randy
>=20
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp
>=20
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp




From pcalhoun@airespace.com  Wed Jul 30 12:52:12 2003
From: pcalhoun@airespace.com (Pat R. Calhoun)
Date: Wed, 30 Jul 2003 04:52:12 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <40301581B2962B448690A023EF16DFE1DC5392@bsn-mail-01.bstormnetworks.com>

> It is a problem in Andrew's recommendation, because frankly=20
> it is not a very workable solution (from an engineering=20
> perspective). However, it is perfectly valid for my AR to=20
> fetch the latest code from an OEM AP's web site (either=20
> automatically or not) and download it to the APs.

> Unless I miss something, I would say that this problem is not specific =
for=20
> CAPWAP, and does not require a new protocol.=20

And the above is not in scope for CAPWAP. Fetching images to a specific =
box from a site on the net is not, but secure download of firmware to =
the AP is...

PatC



From bhandaru@legra.com  Wed Jul 30 14:11:14 2003
From: bhandaru@legra.com (Nehru Bhandaru)
Date: Wed, 30 Jul 2003 09:11:14 -0400
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: <20030730033356.EA58539F7@xmxpita.myway.com>
Message-ID: <000001c3569c$0f617d00$900ba8c0@legra.com>

IMO we should also consider APs that do not support =
firmware/software/image
download. Truly lightweight and commodity APs may not support such
a feature.

Thanks

- Nehru

-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On =
Behalf
Of Puneet B
Sent: Tuesday, July 29, 2003 11:34 PM
To: aframe@trapezenetworks.com
Cc: lwapp@frascone.com
Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
Discovery Request/Reply, and validation.)=20



> Since the image is being provided by the AR, an assumption can be made =

> that it was written by the same software team (or at least the same
> company) who wrote the AR software. Pick your favorite poison for=20
> parameter setting/reading, as long as its out of the scope of the=20
> proposed WG. Put another way, communication at the 'service level'=20
> stays out of scope.

I think I am still missing something here: I thought the idea behind=20
LWAPP was to allow APs from different vendors to interop with different =
ARs.
In that case how can we assume the AP image provided by the AR is =
written by
the same team that wrote the AR software? I am assuming a scenario where =
I
have an AR from vendor X and an AP from vendor Y. Vendor Y now provides =
me a
new software image that I must upgrade my APs with. The AR from vendor X =
has
no idea what the contents of that image are. How does this scenario fit =
in
with what you are proposing?

> Exactly. The 'hardware capabilities' would be announced in the=20
> Discovery process in order to hookup with an AR that can service it=20
> with an image. An AR will only assert and control an AP with hardware=20
> compatible with the available images. This 'marriage' is purely=20
> conditional and is based on a compatible image being available on the=20
> AR. I believe you misunderstood Dan, the 'service capabilities' would=20
> not be advertised by the AP after an image was offered, as the=20
> capabilities would be already known by the AR.

ok, so the AP does not advertise its service capabilities, the AR
'remembers' the capabilities of each AP based on what image it =
downloaded to
the AP. I am also assuming that this download happens only once (not =
each
time the AP reboots). Is that correct? What happens when we now replace =
a
failed AR with another one or one from another vendor?  In your proposal =
how
does the new AR know the service capabilities of the existing APs?

Puneet

_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp


From randy@psg.com  Wed Jul 30 15:37:24 2003
From: randy@psg.com (Randy Bush)
Date: Wed, 30 Jul 2003 07:37:24 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <000401c3560b$52ebf410$ea0ba8c0@legra.com>
 <200307292027.h6TKROn45199@homebrew.trpz.com>
Message-ID: 

> I just don't think it'll be a good idea to define a protocol 
> that allows for everything under the sun to be configured 
> ...
> And it locks people into an architecture. For instance, you said
> that the capabilities negotiated would include "encryption algorithms".
> Who says that the AP is doing encryption and decryption?

i am deeply confused.

if we should not standardize how configuration is done.  and we
should not standardize the capabilities of the devices and how they
interoperate.  then, other that they all run on 110/220, what the
hell are you doing for me, the user, to provide interoperability in
a multi-vendor deployment?

randy


From randy@psg.com  Wed Jul 30 15:38:42 2003
From: randy@psg.com (Randy Bush)
Date: Wed, 30 Jul 2003 07:38:42 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
Message-ID: 

> Since the image is being provided by the AR, an assumption can be made
> that it was written by the same software team (or at least the same
> company) who wrote the AR software.

so much for multi-vendor deployment, eh?

randy


From randy@psg.com  Wed Jul 30 15:40:20 2003
From: randy@psg.com (Randy Bush)
Date: Wed, 30 Jul 2003 07:40:20 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <40301581B2962B448690A023EF16DFE1DC5387@bsn-mail-01.bstormnetworks.com>
Message-ID: 

> it is perfectly valid for my AR to fetch the latest code from an
> OEM AP's web site (either automatically or not) and download it
> to the APs.

iff you have a way to make me comfortable that it is a certifiably
authentic image.  this should be doable.

randy


From Marcus Brunner   Wed Jul 30 16:08:02 2003
From: Marcus Brunner  (Marcus Brunner)
Date: Wed, 30 Jul 2003 17:08:02 +0200
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC538C@bsn-mail-01.bstormnetworks.com>
References: <40301581B2962B448690A023EF16DFE1DC538C@bsn-mail-01.bstormnetwor
 ks.com>
Message-ID: <30017262.1059584882@[10.1.1.130]>


--On Mittwoch, 30. Juli 2003 04:40 -0700 "Pat R. Calhoun" 
 wrote:

>> For instance, the vendor of controller Y thinks (IEEE TGi defined)
>> pre-authentication is very valuable. The image downloaded to
>> AP X when it agrees to be controlled by controller Y would include
>> code to support it. It doesn't matter how that gets configured
>> because the controller speaks to the AP using a protocol that is
>> defined in the image the AP is now running. The vendor for
>> controller Z may think pre-auth is valuable too and the image it
>> downloads to the AP supports it. Externally, the AP looks the same
>> but the protocol the AP now uses to configure pre-auth is different.
>> There is no reason to insist on the particular configuration
>> and management of the AP between vendors Y and Z be the same.
>
> But the spec, as written, would cause the AR to decide whether 802.11i
> was required or not, it would terminate the 802.11i protocol, and
> download keys to the AP. This seems so much simpler than having this
> really complex capabilities exchange between the AP and the AR, no?

I have seen quite a bit of work on capability exchange etc. in the research 
environment, but non of them I regard ready to standardize.

So also here I propose to rule capability exchange out of scope for a 
potential WG. Having various capabilities means you assume a function rich 
AP, what want to prevent.

Marcus







From Marcus Brunner   Wed Jul 30 16:11:32 2003
From: Marcus Brunner  (Marcus Brunner)
Date: Wed, 30 Jul 2003 17:11:32 +0200
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
 Discovery Request/Reply, and validation.)
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5390@bsn-mail-01.bstormnetworks.com>
References: <40301581B2962B448690A023EF16DFE1DC5390@bsn-mail-01.bstormnetwor
 ks.com>
Message-ID: <30227504.1059585092@[10.1.1.130]>

Exactly, if both sides are coming from the same vendor he can do what ever 
he likes anyway. Having the two sides from different vendors the image 
download capability is IMHO not possible or realistic and therefore out of 
scope for standardization.

Marcus


--On Mittwoch, 30. Juli 2003 04:46 -0700 "Pat R. Calhoun" 
 wrote:

> But Dan, the goal is to provide true interoperability. I see your
> proposal as simply a convenient way to download each vendor's image to
> their APs. It does not provide interopability with other APs on the
> market.
>
> PatC
> -----Original Message-----
> From:	Dan Harkins [mailto:dharkins@trpz.com]
> Sent:	Tue 7/29/2003 1:27 PM
> To:	lwapp@frascone.com
> Cc:	
> Subject:	Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
> Discovery Request/Reply, and validation.)    Nehru,
>
>   It's not naivity. It's just a different way of looking at what
> the protocol is supposed to do. Does it allow for an AP and
> controller to agree on what the AP can do and define how to
> configure and manage that? Or does it merely allow for an AP to
> define what sort of image it can run and then let that image
> provide for the configuration and management of services that
> are encapsulated inside the image? I tend to believe in the latter.
>
>   I just don't think it'll be a good idea to define a protocol
> that allows for everything under the sun to be configured and if
> you don't think that it would grow to include everything under
> the sun then that's what's naive. There would be hour+ long
> arguments at meetings on whether one clique's favorite feature
> was a MUST or a SHOULD. Inboxes would fill up over whether to
> include support for some other group's favorite feature. And
> it would require constant updating to keep up with the ever-growing
> number of features possible.
>
>   And it locks people into an architecture. For instance, you said
> that the capabilities negotiated would include "encryption algorithms".
> Who says that the AP is doing encryption and decryption? I know
> of at least one system in which the AP just encapsulates encrypted
> 802.11 packets and sends them up the wire to the controller to
> process. In that architecture it doesn't matter if the AP supports
> any encryption algorithms at all! But is that a One Size Fits All
> Architecture? No, absolutely not, but neither is the opposite.
> There is no One Size Fits All so let's not paint ourselves into a
> box by architecting one.
>
>   Dan.
>
> On Tue, 29 Jul 2003 15:55:13 EDT you wrote
>>
>> I may be naive, but I would think a vendor's image only needs
>> to specify which version of protocol (lwapp) it supports. The
>> capabilities would be negotiated as part of the protocol. These
>> include radio characteristics, encryption algorithms etc...
>>
>> - Nehru
>>
>> -----Original Message-----
>> From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On
>> Behalf Of Randy Bush
>> Sent: Tuesday, July 29, 2003 3:28 PM
>> To: Dan Harkins
>> Cc: lwapp@frascone.com
>> Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
>> Discovery Request/Reply, and validation.)
>>
>>
>> > The AP says what kind of brain it can run and the controller gives it
>> > the right kind of brain. What that brain does is up to the vendor.
>>
>> so vendor A's controller will load the appropriate images into vendor B's
>> and C's APs?  and that controller will know what capabilities each of B's
>> and C's images have, and how they will interface with the A controller's
>> capabilities?
>>
>> sounds way cool.
>>
>> but somehow i think there's a bit of a missing piece here.  i suspect
>> that an effective brain transplant requires hooking up all the nerves to
>> the existing senses and making sense of them.  and, to be effective,
>> that brain needs to be able to make the local mouth and ears discuss
>> with the rest of the brains in the room, what it is sensing and what it
>> should do about it.
>>
>> randy
>>
>> _______________________________________________
>> Lwapp mailing list
>> Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp
>>
>> _______________________________________________
>> Lwapp mailing list
>> Lwapp@frascone.com
>> http://mail.frascone.com/mailman/listinfo/lwapp
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>
>
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp



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

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus





From kempf@docomolabs-usa.com  Wed Jul 30 17:30:44 2003
From: kempf@docomolabs-usa.com (James Kempf)
Date: Wed, 30 Jul 2003 18:30:44 +0200
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: <232810-2200370270524394@M2W096.mail2web.com><00dd01c355ad$cfdd0ee0$036015ac@dclkempt40> 
Message-ID: <007201c356b8$e7a30e60$476015ac@dclkempt40>

Randy,

Thanx for the clarification. Sorry if my message implied anything other than
a need to clarify any overlap with existing work and with IEEE.

            jak

----- Original Message ----- 
From: "Randy Bush" 
To: "James Kempf" 
Cc: ; "Bernard Aboba" 
Sent: Tuesday, July 29, 2003 4:46 PM
Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
Discovery Request/Reply, and validation.)


> > As a followup to Randy's note, since CAPWAP is a new and
> > potentially complex area of work that IETF would be taking on,
> > there has been some discussion between IAB and IESG about how to
> > get the work scoped properly and make sure the right people are
> > involved so that it has a chance of succeeding in a reasonable
> > amount of time.
>
> lest we create the sound of black helicopters, let's be a bit more
> clear.  there have been no iesg/iab back room discussions of which
> i am aware of 'who', or 'scoping' of this work.  i have worked very
> hard, and have stuck my nose and prodded in this mailing list to a
> level that perhaps an area director (with hat on) should not,
> specifically to ensure that discussion of goals and means was
> completely open.
>
> there has been iesg/iab discussion of issues such as how to tell if
> there really is serious overlap with other existing work within the
> ietf and between the ietf and the ieee (and i have taken the
> position that i have no way of telling unless it is clear what this
> work is, darn it).  there has also been philosophic discussion of
> how to avoid the complexity explosion which made diameter into a
> many year effort.
>
> so please please focus on a simple and clear statement of goals and
> means.  we users really want interoperability, and that is what
> standards are about.
>
> randy
>
>


From kempf@docomolabs-usa.com  Wed Jul 30 17:34:18 2003
From: kempf@docomolabs-usa.com (James Kempf)
Date: Wed, 30 Jul 2003 18:34:18 +0200
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
Message-ID: <007301c356b8$eadab9c0$476015ac@dclkempt40>

Andrew,

Would you like to propose what you believe should be the problem statement?
From your postings, I don't get a very good idea what you think would be the
important elements, except that image download isn't one of them.

            jak

----- Original Message ----- 
From: "Andrew Frame" 
To: "James Kempf" ; "Randy Bush" ;

Cc: ; "Bernard Aboba" 
Sent: Tuesday, July 29, 2003 6:08 PM
Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
Discovery Request/Reply, and validation.)


> Ok, how do I phrase this gently, I will hold myself back from saying 'one
foot on the banana peel and the other on the edge of the slippery slope'...
;-)
>
> As I stated in an earlier email, this undoubtedly will become a perpetual
WG if we decide to stay in sync will all industry standardization efforts.
>
> Focusing on standardizing a bootup-strap/discovery/image-download protocol
for APs without dictating what the image does or how it does it allows
vendors to track all standardization efforts within the image if they enjoy
enduring pain, without forcing that pain upon the IETF.
>
> Andrew
>
>
> -----Original Message----- 
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Tue 7/29/2003 1:29 AM
> To: Randy Bush; carlw@mcsr-labs.org
> Cc: lwapp@frascone.com; Bernard Aboba
> Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
Discovery Request/Reply, and validation.)
>
>
>
> As a followup to Randy's note, since CAPWAP is a new and potentially
complex
> area of work that IETF would be taking on, there has been some discussion
> between IAB and IESG about how to get the work scoped properly and make
sure
> the right people are involved so that it has a chance of succeeding in a
> reasonable amount of time. The intent is to avoid situations in which
vendor
> interest evaporates because the original design is so complex that it
takes
> years to standardize.
>
> Randy and Bert would like a short (not more than two pages, and one is
> better) problem statement that clearly describes what CAPWAP would do and,
> perhaps more importantly, what it will NOT do. Ideally, the problem
> statement would partition the problem into areas that IETF would take on
in
> OPS, areas that might be appropriate for other IETF areas and a different
> working group (if any), and areas that are not really in IETF's scope and
> are better left to IEEE. In the areas that would be appropriate for a WG
in
> the OPS area might include work with existing protocols (like, for
example,
> SNMP), or they might include new work (in other words, the existence of a
> protocol that can supply a solution is not sufficient grounds in and of
> itself to not form a WG in OPS). This problem statement would then evolve
> into the charter.
>
> As a suggestion (and summarizing I* discussion), the current LWAPP
protocol
> contains a lot of functionality and is somewhat complex (thus the concern
> about long standardization times). Some suggestions are:
>
> - the encapsulation and data management function of the split MAC model
> seems separable from the AP control function. The encapsulation and data
> management function could be implemented in a variety of ways (over IP,
over
> 802, encrypted or not, etc.). Separating these two might be a good way to
> simplify.
>
> - dynamic power control is something that IEEE is not currently working on
> and might be an area where IETF might contribute value added. Channel
> provisioning between APs might be another possibility. These are specific
> instances of the general problem involving interactions between access
> points that today need to be provisioned by hand in order to deploy and
> manage a network, but could be automated relatively simply.
>
> - anything involving handover control and load balancing would require
close
> co-operation with 802.11k, which is currently working on designing
> management frames for sending metrics to the host that the host would use
> for making a handover decision, and so might be best left to IEEE. This
> would be more consistent with the 802.11 host controlled handover model.
> There might still be some role for handover control for management
purposes
> (i.e. an AP is about to be shut down for maintenance).
>
> - there clearly is a security issue of how an AR recognizes authorized
APs,
> but whether this is a task for an OPS-based WG is not clear. There was a
BOF
> at the last IETF on credential provisioning that might provide part of the
> solution, but there might also be some work required specifically for this
> application (certificate profiles, etc.). However, chances for quick
success
> are improved if existing IETF security solutions are built-upon, rather
that
> trying to invent new ones.
>
>                 jak
>
>
>
>
>
>
>
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>
>
>
>


From dharkins@trpz.com  Wed Jul 30 17:51:02 2003
From: dharkins@trpz.com (Dan Harkins)
Date: Wed, 30 Jul 2003 09:51:02 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: Your message of "Wed, 30 Jul 2003 07:37:24 PDT."
 
Message-ID: <200307301651.h6UGp2n48225@homebrew.trpz.com>

  For you the user? I'm letting you buy commodity-priced APs and use
them with any vendor's controller (doesn't even have to be a "wireless
switch") that happens to provide the functionality you think is
valuable.

  Depending on whose kool-aid you've been drinking you think that
the "fat AP" or the "thin AP" is the way to go. So what I'm saying
is that that doesn't matter. If vendor X is pushing the "fat AP"
model then his whippy-dippy configurator can put "fat AP" images
to these low-priced commodity APs and they will do everything. Vendor
Y, who is pushing the "thin AP" model, can put "thin AP" images on
those same APs and offload all processing to a switch somewhere.

  So what I'm doing for you the user is to make it so you don't
lock yourself into any particular architectural model. Much in the same
way that you are not forced to use a single vendor to buy a computer
and OS (you can, although that breed of company is getting smaller).
You can get a computer and-- depending on the type-- run Windoze on it
or netbsd or freebsd or linux or whatever suits you. Imagine defining
a protocol to standardize the capabilities of a computer. Sounds kind
of rediculous, no?

  Dan.

On Wed, 30 Jul 2003 07:37:24 PDT you wrote
> > I just don't think it'll be a good idea to define a protocol 
> > that allows for everything under the sun to be configured 
> > ...
> > And it locks people into an architecture. For instance, you said
> > that the capabilities negotiated would include "encryption algorithms".
> > Who says that the AP is doing encryption and decryption?
> 
> i am deeply confused.
> 
> if we should not standardize how configuration is done.  and we
> should not standardize the capabilities of the devices and how they
> interoperate.  then, other that they all run on 110/220, what the
> hell are you doing for me, the user, to provide interoperability in
> a multi-vendor deployment?
> 
> randy
> 
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp

From randy@psg.com  Wed Jul 30 17:53:41 2003
From: randy@psg.com (Randy Bush)
Date: Wed, 30 Jul 2003 09:53:41 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
 <200307301651.h6UGp2n48225@homebrew.trpz.com>
Message-ID: 

>   For you the user? I'm letting you buy commodity-priced APs and use
> them with any vendor's controller (doesn't even have to be a "wireless
> switch") that happens to provide the functionality you think is
> valuable.
> 
>   Depending on whose kool-aid you've been drinking you think that
> the "fat AP" or the "thin AP" is the way to go. So what I'm saying
> is that that doesn't matter. If vendor X is pushing the "fat AP"
> model then his whippy-dippy configurator can put "fat AP" images
> to these low-priced commodity APs and they will do everything. Vendor
> Y, who is pushing the "thin AP" model, can put "thin AP" images on
> those same APs and offload all processing to a switch somewhere.
> 
>   So what I'm doing for you the user is to make it so you don't
> lock yourself into any particular architectural model. Much in the same
> way that you are not forced to use a single vendor to buy a computer
> and OS (you can, although that breed of company is getting smaller).
> You can get a computer and-- depending on the type-- run Windoze on it
> or netbsd or freebsd or linux or whatever suits you. Imagine defining
> a protocol to standardize the capabilities of a computer. Sounds kind
> of rediculous, no?

if i was to take that reducto ad absurdiam argument seriously, we
could all leave the ietf and the ieee and i should buy that j/35
and stop wasting my time with this standards silliness.  so excuse,
but i'll ignore it.

maybe the leap i can't make in the download-the-image model is how,
in the absence of a agreed spec for user functionality, controller
C can download images into APs from vendors A and B, and know they
will interoperate at the user functionality level.

randy


From dharkins@trpz.com  Wed Jul 30 18:03:05 2003
From: dharkins@trpz.com (Dan Harkins)
Date: Wed, 30 Jul 2003 10:03:05 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: Your message of "Wed, 30 Jul 2003 04:46:00 PDT."
 <40301581B2962B448690A023EF16DFE1DC5390@bsn-mail-01.bstormnetworks.com>
Message-ID: <200307301703.h6UH35n48309@homebrew.trpz.com>

  True interoperability? No it's not. As you alluded to in an earlier mail
it's to come up with a new breed of lobotomized APs whose only task is to
"tunnel packets to the AR", which will "offload all 'services' to the AR."
The goal is to ensure that one particular architectural path which some
believe leads to Oz is the one that everyone must follow.

  That is not interoperability any more than having a lobotomized AP which
sat there waiting for an image to be downloaded to it. 

  Dan.

On Wed, 30 Jul 2003 04:46:00 PDT you wrote
> But Dan, the goal is to provide true interoperability. I see your proposal as
> simply a convenient way to download each vendor's image to their APs. It does
> not provide interopability with other APs on the market.
> 
> PatC
> -----Original Message-----
> From:	Dan Harkins [mailto:dharkins@trpz.com]
> Sent:	Tue 7/29/2003 1:27 PM
> To:	lwapp@frascone.com
> Cc:	
> Subject:	Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
> Discovery Request/Reply, and validation.) 
>   Nehru, 
> 
>   It's not naivity. It's just a different way of looking at what
> the protocol is supposed to do. Does it allow for an AP and
> controller to agree on what the AP can do and define how to
> configure and manage that? Or does it merely allow for an AP to
> define what sort of image it can run and then let that image
> provide for the configuration and management of services that
> are encapsulated inside the image? I tend to believe in the latter.
> 
>   I just don't think it'll be a good idea to define a protocol 
> that allows for everything under the sun to be configured and if
> you don't think that it would grow to include everything under
> the sun then that's what's naive. There would be hour+ long
> arguments at meetings on whether one clique's favorite feature
> was a MUST or a SHOULD. Inboxes would fill up over whether to
> include support for some other group's favorite feature. And
> it would require constant updating to keep up with the ever-growing
> number of features possible.
> 
>   And it locks people into an architecture. For instance, you said
> that the capabilities negotiated would include "encryption algorithms".
> Who says that the AP is doing encryption and decryption? I know
> of at least one system in which the AP just encapsulates encrypted 
> 802.11 packets and sends them up the wire to the controller to
> process. In that architecture it doesn't matter if the AP supports
> any encryption algorithms at all! But is that a One Size Fits All
> Architecture? No, absolutely not, but neither is the opposite.
> There is no One Size Fits All so let's not paint ourselves into a
> box by architecting one.
> 
>   Dan.
> 
> On Tue, 29 Jul 2003 15:55:13 EDT you wrote
> > 
> > I may be naive, but I would think a vendor's image only needs
> > to specify which version of protocol (lwapp) it supports. The 
> > capabilities would be negotiated as part of the protocol. These
> > include radio characteristics, encryption algorithms etc...
> > 
> > - Nehru
> > 
> > -----Original Message-----
> > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf
> > Of Randy Bush
> > Sent: Tuesday, July 29, 2003 3:28 PM
> > To: Dan Harkins
> > Cc: lwapp@frascone.com
> > Subject: Re: Scope of Charter Discussion (was: Re: [Lwapp] Certificates,
> > Discovery Request/Reply, and validation.) 
> > 
> > 
> > > The AP says what kind of brain it can run and the controller gives it 
> > > the right kind of brain. What that brain does is up to the vendor.
> > 
> > so vendor A's controller will load the appropriate images into vendor B's
> > and C's APs?  and that controller will know what capabilities each of B's
> > and C's images have, and how they will interface with the A controller's
> > capabilities?
> > 
> > sounds way cool.  
> > 
> > but somehow i think there's a bit of a missing piece here.  i suspect that
> > an effective brain transplant requires hooking up all the nerves to the
> > existing senses and making sense of them.  and, to be effective, that brain
> > needs to be able to make the local mouth and ears discuss with the rest of
> > the brains in the room, what it is sensing and what it should do about it.
> > 
> > randy
> > 
> > _______________________________________________
> > Lwapp mailing list
> > Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp
> > 
> > _______________________________________________
> > Lwapp mailing list
> > Lwapp@frascone.com
> > http://mail.frascone.com/mailman/listinfo/lwapp
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
> 
> 
> 

From dharkins@trpz.com  Wed Jul 30 18:10:51 2003
From: dharkins@trpz.com (Dan Harkins)
Date: Wed, 30 Jul 2003 10:10:51 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: Your message of "Wed, 30 Jul 2003 04:34:32 PDT."
 <40301581B2962B448690A023EF16DFE1DC538A@bsn-mail-01.bstormnetworks.com>
Message-ID: <200307301710.h6UHApn48346@homebrew.trpz.com>

  Who cares what the spec has at this point in time? We are not here
to put the IETF Stamp of Approval on any single Internet-Draft. We're
talking about what the charter should be. And if there is sufficient
grounds to form a WG.

  If you just want to advance an Internet-Draft to RFC (and we all
know why that would be) then there are other avenues to pursue.

  Dan.

On Wed, 30 Jul 2003 04:34:32 PDT you wrote
> 
> Sorry folks, but you've lost me. What is this 'service'??? An AP needs to sim
>ply tunnel packets to the AR. Let's keep the AP as simple as possible and offl
>oad all 'services' to the AR, reducing the complexity of capabilities exchange
>. Currently, the spec really has one capability that is exchange (do you encry
>pt L2 or not?).


From cchaplin@sj.symbol.com  Wed Jul 30 18:26:26 2003
From: cchaplin@sj.symbol.com (Clint Chaplin)
Date: Wed, 30 Jul 2003 10:26:26 -0700
Subject: [Lwapp] RE: Scope of Charter Discussion (was: Re: [Lwapp]
 Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

I too worry about the security implications of getting firmware images =
from the "vendor's" site....

Clint (JOATMON) Chaplin

>>> Randy Bush  7/30/03 07:40:20 >>>
> it is perfectly valid for my AR to fetch the latest code from an
> OEM AP's web site (either automatically or not) and download it
> to the APs.

iff you have a way to make me comfortable that it is a certifiably
authentic image.  this should be doable.

randy

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com=20
http://mail.frascone.com/mailman/listinfo/lwapp=20

________________________________________________________________________
This email has been scanned for computer viruses.


From dharkins@trpz.com  Wed Jul 30 18:45:36 2003
From: dharkins@trpz.com (Dan Harkins)
Date: Wed, 30 Jul 2003 10:45:36 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
In-Reply-To: Your message of "Wed, 30 Jul 2003 09:53:41 PDT."
 
Message-ID: <200307301745.h6UHjan48410@homebrew.trpz.com>

  I guess I don't understand why a seperate user functionality spec
is required. Perhaps I don't understand what you mean by a user
functionality spec.

  A vax running netbsd can "interoperate" (at the user functionality
level?) with a playstation2 running netbsd. If you put some secret sauce
into the netbsd source and rebuilt the kernels the vax could do the
secret sauce protocol with the playstation2. A proprietary kernel that
was as portable as netbsd and had the right drivers could do similar
things with APs from vendors A and B. The trick is to distinguish
between A and B and then what sort of drivers are necessary to include
in the image you download.

  Dan.

On Wed, 30 Jul 2003 09:53:41 PDT you wrote
> 
> maybe the leap i can't make in the download-the-image model is how,
> in the absence of a agreed spec for user functionality, controller
> C can download images into APs from vendors A and B, and know they
> will interoperate at the user functionality level.
> 
> randy
> 

From dmolnar@eecs.harvard.edu  Wed Jul 30 18:45:58 2003
From: dmolnar@eecs.harvard.edu (David Molnar)
Date: Wed, 30 Jul 2003 13:45:58 -0400 (EDT)
Subject: [Lwapp] authentic vendor images & upgrades
In-Reply-To: 
References: 
Message-ID: 


On Wed, 30 Jul 2003, Clint Chaplin wrote:

> I too worry about the security implications of getting firmware images
> from the "vendor's" site....

There are some standard ways to approach this issue, so while we of course
have to address it, I think it's doable. Assuming we decide firmware
download is in spec, of course. :)

One way to approach this is to use a PKI for code signing. Vendors create
public/private signature key pairs and sign code images. Then they have
their public key signed by VeriSign or other CA. ARs and maybe APs are
shipped with VeriSign's public key for verification of vendor public keys
and then the public key can be used to verify code images. There is some
question about whether the verification takes place on the AP or AR, but
that is the general idea. Java codesigning works on this model.

The thing I worry about -- sometimes bad images or bad bugfixes are
released; these are properly signed and so might be able to be "replayed"
against an AP or AR if we're not careful. At the same time, it's desirable
to be able to downgrade or reverse an image application in case the new
image causes problems, so you can't simply prohibit downgrades. I haven't
seen a good codesigning system that resolves this tension. It is probably
not in our scope to design a codesigning system that solves this problem,
but we should be aware of it.

-David


From puneetb@myway.com  Wed Jul 30 19:06:05 2003
From: puneetb@myway.com (Puneet B)
Date: Wed, 30 Jul 2003 14:06:05 -0400 (EDT)
Subject: [Lwapp] RE: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <20030730180605.AF0BD3A0A@xmxpita.myway.com>

> I too worry about the security implications of getting firmware
> images from the "vendor's" site....

Perhaps we can break this up into two parts:
- getting the firmware from the vendor to the AR (this is
  probably out of scope of LWAPP??)
- messages to upgrade/rollback the firmware between the AR & AP.
  LWAPP can perhaps define messages for this and standardize this 
  part.
Since there are other methods being proposed in the protocol
to build this trust relationship between the AP & AR (to counter
rogue devices), do we need another security mechanism for the
firmware?

Puneet

_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com

From aframe@trapezenetworks.com  Wed Jul 30 20:24:52 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Wed, 30 Jul 2003 12:24:52 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 


> -----Original Message-----
> From: Puneet B [mailto:puneetb@myway.com]
> Sent: Tuesday, July 29, 2003 8:34 PM
> To: Andrew Frame
> Cc: lwapp@frascone.com
> Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp]
Certificates,
> Discovery Request/Reply, and validation.)
>=20
>=20
> > Since the image is being provided by the AR, an assumption can be
made
> > that it was written by the same software team (or at least the same
> > company) who wrote the AR software. Pick your favorite poison for
> > parameter setting/reading, as long as its out of the scope of the
> > proposed WG. Put another way, communication at the 'service level'
stays
> > out of scope.
>=20
> I think I am still missing something here: I thought the idea behind
> LWAPP was to allow APs from different vendors to interop with
different
> ARs. In that case how can we assume the AP image provided by the AR is
> written by the same team that wrote the AR software? I am assuming a
> scenario where I have an AR from vendor X and an AP from vendor Y.
Vendor
> Y now provides me a new software image that I must upgrade my APs
with.
> The AR from vendor X has no idea what the contents of that image are.
> How does this scenario fit in with what you are proposing?

The code that drives the AP is written by the controller vendor, not the
AP vendor. If the AP is going to be compliant with this protocol it
needs to advertise all of its relevant hardware capabilities in the
Discovery process so the controller can determine whether or not it has
a suitable image. Best practices at the controller vendor can be to
completely modularize AP code in order to accommodate new
chipsets/cpu-arch's/bus-types/etc. This is far easier then going down
the VM path, which is out of the question.

>=20
> > Exactly. The 'hardware capabilities' would be announced in the
Discovery
> > process in order to hookup with an AR that can service it with an
image.
> > An AR will only assert and control an AP with hardware compatible
with
> > the available images. This 'marriage' is purely conditional and is
based
> > on a compatible image being available on the AR. I believe you
> > misunderstood Dan, the 'service capabilities' would not be
advertised by
> > the AP after an image was offered, as the capabilities would be
already
> > known by the AR.
>=20
> ok, so the AP does not advertise its service capabilities, the AR
> 'remembers'
> the capabilities of each AP based on what image it downloaded to the
AP. I
> am also assuming that this download happens only once (not each time
the
> AP reboots). Is that correct? What happens when we now replace a
failed AR
> with another one or one from another vendor?  In your proposal how
does
> the
> new AR know the service capabilities of the existing APs?

The service capabilities are purely software and are divorced from the
hardware capabilities. The services are determined by the image, giving
your AP the ability to do functionality X with Controller Y and
functionality B with controller C. This is where the approach differs
from LWAPP.=20

Andrew

From aframe@trapezenetworks.com  Wed Jul 30 20:35:20 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Wed, 30 Jul 2003 12:35:20 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 


> -----Original Message-----
> From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
> Sent: Wednesday, July 30, 2003 4:26 AM
> To: Andrew Frame; Randy Bush
> Cc: lwapp@frascone.com
> Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp]
Certificates,
> Discovery Request/Reply, and validation.)
>=20
> > Assertion and control will only occur if the Controller can
accomdate
> the
> > AP's capabilities. If there is sufficient reason for a capabilities
> exchange
> > I am not against this....
>=20
> Isn't that what we are here for? Your alternative where each vendor
must
> port their software to each OEM APs available on the market seems
rather
> complex...

Are you assuming that all APs manufactured will want to be
'lightweight'? Or even be 'lightweight capable'?

>=20
> If I look at L2TP for instance, I suppose we could have enforced that
all
> LNS' to simply download a software image to the LAC and be done with
it,
> but would this have achieved any form of interoperability?

Well, considering that a LAC is not trying to be a 'lightweight' device
I am not sure how much relevance this serves.

Andrew

From aframe@trapezenetworks.com  Thu Jul 31 02:37:45 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Wed, 30 Jul 2003 18:37:45 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 


> -----Original Message-----
> From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
> Sent: Wednesday, July 30, 2003 4:35 AM
> To: puneetb@myway.com; Andrew Frame
> Cc: lwapp@frascone.com
> Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp]
Certificates,
> Discovery Request/Reply, and validation.)
>=20
> >> Which is great, Plug AP X into Controller Y and get Z
functionality.
> >> Plug AP X into Controller A and get B functionality. Sounds like a
> >> perfect model to preserve differentiation in the marketplace while
> >> not loading up the IETF with excessive work....
> >
> > Does'nt this require that the AP and AR support the functionality or
> > service Z in exactly the same manner? Unless the service is also
> > described and standardized, how would the AP & AR interop? What
> > happens when an AP with capability Y is plugged into an AR that
> > implements the same functionality in a different manner (expects
> > a message in a different format from the AP)?
>=20
> > Perhaps some basic services or atleast a framework for negotiating
> > them should be defined in the protocol between AP & AR.
>=20
> Sorry folks, but you've lost me. What is this 'service'??? An AP needs
to
> simply tunnel packets to the AR. Let's keep the AP as simple as
possible
> and offload all 'services' to the AR, reducing the complexity of
> capabilities exchange. Currently, the spec really has one capability
that
> is exchange (do you encrypt L2 or not?).

Services are the value-add software features that the AP can offer. QoS,
Rogue detection, etc. How does LWAPP address the fact that multiple
queues might exist on the AP? And that the user might actually want to
take advantage of those queues, and oh wait, did I mention that there
might be a variable number of queues on a per-AP basis? See how easy it
is to rathole? This is one of many examples why the 'service layer'
needs to be separated and is completely out of charter...

Again, what I propose:

In charter: A bootup/discovery protocol for an AP to boot and find a
suitable AR that provides an image to run it.

Out of charter: What the image does (service layer).

Advantages:=20
1. The IETF can minimize its work since it does not need to track what
is in the image, the vendors can do that. The image will never stop
evolving, we need to decouple this from the IETF work (ie: slippery
slope).

2. Marketplace differentiation is preserved; Plugging AP X into
Controller Y gives you functionality Z while plugging AP X into
Controller B gives you functionality C.


Disadvantages:
1. Some porting work might be necessary from the Controller vendor to
create images that are suitable for more than one AP vendor. This is not
as hard as it sounds and there is precedence for this sort of work. The
image does not have to be written entirely by the Controller vendor,
think NDIS.

Andrew

From aframe@trapezenetworks.com  Thu Jul 31 02:40:10 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Wed, 30 Jul 2003 18:40:10 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 


> -----Original Message-----
> From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
> Sent: Wednesday, July 30, 2003 4:40 AM
> To: Dan Harkins; puneetb@myway.com
> Cc: Andrew Frame; lwapp@frascone.com
> Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp]
Certificates,
> Discovery Request/Reply, and validation.)
>=20
> > For instance, the vendor of controller Y thinks (IEEE TGi defined)
> > pre-authentication is very valuable. The image downloaded to
> > AP X when it agrees to be controlled by controller Y would include
> > code to support it. It doesn't matter how that gets configured
> > because the controller speaks to the AP using a protocol that is
> > defined in the image the AP is now running. The vendor for
> > controller Z may think pre-auth is valuable too and the image it
> > downloads to the AP supports it. Externally, the AP looks the same
> > but the protocol the AP now uses to configure pre-auth is different.
> > There is no reason to insist on the particular configuration
> > and management of the AP between vendors Y and Z be the same.
>=20
> But the spec, as written, would cause the AR to decide whether 802.11i
was
> required or not, it would terminate the 802.11i protocol, and download
> keys to the AP. This seems so much simpler than having this really
complex
> capabilities exchange between the AP and the AR, no?
>=20
> PatC

The point is that is now a choice, and it can be decided by the
Controller vendor how it wants to distribute all aspects of control
between the AP and Controller.

Andrew

From aframe@trapezenetworks.com  Thu Jul 31 02:53:40 2003
From: aframe@trapezenetworks.com (Andrew Frame)
Date: Wed, 30 Jul 2003 18:53:40 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: 

Without a VM, Controller vendors will have to choose a set of APs that
they work with and make the port. The majority of the code will exist,
and there will be ways to publish 'driver specs' to the OEM AP vendors
in order to expedite image creation. Who knows, it may be the OEM AP
vendors who eventually do all of the porting work....

Andrew

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Wednesday, July 30, 2003 7:39 AM
> To: Andrew Frame
> Cc: lwapp@frascone.com
> Subject: RE: Scope of Charter Discussion (was: Re: [Lwapp]
Certificates,
> Discovery Request/Reply, and validation.)
>=20
> > Since the image is being provided by the AR, an assumption can be
made
> > that it was written by the same software team (or at least the same
> > company) who wrote the AR software.
>=20
> so much for multi-vendor deployment, eh?
>=20
> randy


From rkp@intotoinc.com  Thu Jul 31 05:01:02 2003
From: rkp@intotoinc.com (Rama krishna prasad)
Date: Thu, 31 Jul 2003 09:31:02 +0530
Subject: [Lwapp] LWAPP: AP and AR from different vendors
Message-ID: <3F28947E.5090806@intotoinc.com>

Hi,
       I strongly support that we give provision where AP and AR are
       interoperable by protocol, not by downloading image implementing
       proprietary protocol between them. This eliminates the requirement
       for customer to buy equipment from the same vendor. 

       It is also not advisable for APs to get the images from the AP vendor
       website. Think of WLAN deployments where number of APs are in
       hundreds and thousands. I feel, AR or something behind this should
       provide facility where the Administrator put the latest AP images
       (if more than one vendor's AP is deployed which is possible in
       multiple divisions of a company spread across cities). APs should
       download the images or AR should upload them to the APs. Since AP
       and AR communication is secure and they do mutual authentication, there
       may not be any problem of secure image upload. 

Regards
Rama Krishna Prasad
Intoto Software (India) Pvt Ltd.



From dmolnar@eecs.harvard.edu  Thu Jul 31 16:13:15 2003
From: dmolnar@eecs.harvard.edu (David Molnar)
Date: Thu, 31 Jul 2003 11:13:15 -0400 (EDT)
Subject: [Lwapp] LWAPP: AP and AR from different vendors
In-Reply-To: <3F28947E.5090806@intotoinc.com>
References: <3F28947E.5090806@intotoinc.com>
Message-ID: 


On Thu, 31 Jul 2003, Rama krishna prasad wrote:

>        (if more than one vendor's AP is deployed which is possible in
>        multiple divisions of a company spread across cities). APs should
>        download the images or AR should upload them to the APs. Since AP
>        and AR communication is secure and they do mutual authentication, there
>        may not be any problem of secure image upload.

This suggests a solution by which the images are signed at the vendor,
then the signatures are verified at the AR. The AR then pushes whatever
image it likes to the AP, which accepts anything handed to it by a duly
associated AR.

The upside of such a solution is that it imposes no requirement for
signature verification or public key provisioning on the AP. The AP does
not make any decisions about what code it is allowed to run. This
certainly fits with reducing the computational requirements on the AP.

IMHO, signature verification can be lightweight enough (RSA with e=3 is
three multiplications + one hash...) and firmware download infrequent
enough that the real concern here is provisioning public keys in the AP.
The provisioning is comparatively easy if the AP will run only images from
the same company, but becomes more complicated otherwise.

The downside to such a solution is that a rogue AR can then flash the AP
with anything it likes. For example, I buy an AR and gain access to your
AP before your AR does. Then I push my own image to the AP; afterwards the
AP is free to lie about what code it runs, pretend to accept your AR's
upgrade and not actually upgrade, send duplicate copies of all traffic
somewhere else, etc. It's not clear to me how one would recover from this
scenario, although I can think of some possible architectures which might
help.

I suggest that if we do decide that
	1) firmware download is in scope and
	2) that we want a solution where the AR validates images but AP
	   does not perform image validation

then we should pay careful attention to how bootstrapping and
discovery interacts with firmware download. When is the AR authorized to
push a new image to the AP? What mechanisms are there for clearing the AP
image, and do they survive if the AP is flashed incorrectly?

-David

From Mike.Moreton@Synad.com  Thu Jul 31 16:26:20 2003
From: Mike.Moreton@Synad.com (Mike Moreton)
Date: Thu, 31 Jul 2003 16:26:20 +0100
Subject: [Lwapp] LWAPP: AP and AR from different vendors
Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA974@paris.synad.com>

How about a solution where the administrator installs the appropriate
images on the AR, and the AR downloads them?  As the format of the boot
image will be vendor specific (there is absolutely no benefit in making
it generic) any AP vendor who wants to sign their images can do so
without any involvement from the AR and check them in the AP.

I think validation in the AR just protects you from attack by your
system administrators.  I would venture to suggest that that is a pretty
pointless feature.

Mike Moreton
Synad Technologies Ltd.
=20

-----Original Message-----
From: David Molnar [mailto:dmolnar@eecs.harvard.edu]=20
Sent: 31 July 2003 16:13
To: Rama krishna prasad
Cc: lwapp@frascone.com
Subject: Re: [Lwapp] LWAPP: AP and AR from different vendors



On Thu, 31 Jul 2003, Rama krishna prasad wrote:

>        (if more than one vendor's AP is deployed which is possible in
>        multiple divisions of a company spread across cities). APs
should
>        download the images or AR should upload them to the APs. Since
AP
>        and AR communication is secure and they do mutual
authentication, there
>        may not be any problem of secure image upload.

This suggests a solution by which the images are signed at the vendor,
then the signatures are verified at the AR. The AR then pushes whatever
image it likes to the AP, which accepts anything handed to it by a duly
associated AR.

The upside of such a solution is that it imposes no requirement for
signature verification or public key provisioning on the AP. The AP does
not make any decisions about what code it is allowed to run. This
certainly fits with reducing the computational requirements on the AP.

IMHO, signature verification can be lightweight enough (RSA with e=3D3 =
is
three multiplications + one hash...) and firmware download infrequent
enough that the real concern here is provisioning public keys in the AP.
The provisioning is comparatively easy if the AP will run only images
from
the same company, but becomes more complicated otherwise.

The downside to such a solution is that a rogue AR can then flash the AP
with anything it likes. For example, I buy an AR and gain access to your
AP before your AR does. Then I push my own image to the AP; afterwards
the
AP is free to lie about what code it runs, pretend to accept your AR's
upgrade and not actually upgrade, send duplicate copies of all traffic
somewhere else, etc. It's not clear to me how one would recover from
this
scenario, although I can think of some possible architectures which
might
help.

I suggest that if we do decide that
	1) firmware download is in scope and
	2) that we want a solution where the AR validates images but AP
	   does not perform image validation

then we should pay careful attention to how bootstrapping and
discovery interacts with firmware download. When is the AR authorized to
push a new image to the AP? What mechanisms are there for clearing the
AP
image, and do they survive if the AP is flashed incorrectly?

-David
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

From randy@psg.com  Thu Jul 31 17:00:47 2003
From: randy@psg.com (Randy Bush)
Date: Thu, 31 Jul 2003 09:00:47 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
Message-ID: 

> The code that drives the AP is written by the controller vendor, not the
> AP vendor.

does this not assume that all AP vendors A will have to disclose all
details of their hardware to all Controller vendors C, and that all
C will have to implement images for all A?  how likely is this to
happen?

randy


From randy@psg.com  Thu Jul 31 17:02:07 2003
From: randy@psg.com (Randy Bush)
Date: Thu, 31 Jul 2003 09:02:07 -0700
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
References: 
Message-ID: 

> Out of charter: What the image does (service layer).

so, what the user needs to run a multi-vendor environment is
out of scope?  uh, do we have the same concept of the purpose
of the ietf?

randy


From dmolnar@eecs.harvard.edu  Thu Jul 31 17:03:11 2003
From: dmolnar@eecs.harvard.edu (David Molnar)
Date: Thu, 31 Jul 2003 12:03:11 -0400 (EDT)
Subject: [Lwapp] where to validate images
In-Reply-To: <0D3F1B25E75EE24483A6E69201142C867DA974@paris.synad.com>
References: <0D3F1B25E75EE24483A6E69201142C867DA974@paris.synad.com>
Message-ID: 


On Thu, 31 Jul 2003, Mike Moreton wrote:

> How about a solution where the administrator installs the appropriate
> images on the AR, and the AR downloads them?

I agree with this. I do not think the APs need to go out and get new
images; the new images should come from the AR.

> As the format of the boot
> image will be vendor specific (there is absolutely no benefit in making
> it generic) any AP vendor who wants to sign their images can do so
> without any involvement from the AR and check them in the AP.

Personally, I tend to agree that images should be checked at the AP.

The questions is, check them using what public key? The AP manufacturer
can embed its own public key in the AP at manufacture time. Then all
images would have to be signed with that key. This is fine if we believe
all AP images will come from that vendor. In a world where we standardize
an AP-AR protocol and let the AP vendors deal with the implementation, I
believe that is reasonable.

The world may be more general than that, however. At least if we buy into
Andrew Frame's proposal, it looks like APs may run many different images
written by many different vendors. Is it reasonable to ask for all these
images to be signed by the vendor of the AP? This turns the AP vendor into
a gatekeeper for running images on that AP platform, which may not be
desireable.

One alternative is to put a global CA public key in the AP instead of a
vendor's public key. Then we all go pay money to the CA, similar to Java
codesigning. Another alternative is to have AP vendors issue certificates
to image vendors allowing them to sign their own images and have them run
on the AP; in effect each AP vendor becomes the root CA for their device.

These PKI concerns are, IMHO, the best argument against pushing image
validation into the AP.

I'm still not clear if we all believe that firmware download will be in
spec or not, by the way. This discussion seems a bit premature until we
settle that, although I'm happy to have it.

>
> I think validation in the AR just protects you from attack by your
> system administrators.  I would venture to suggest that that is a pretty
> pointless feature.

I respectfully disagree -- validation in the AR gives the system
administrators confidence that they have not downloaded a malicious AP
image masquerading as the real thing. It's the same reason we sign RPMs -
someone might have changed the image on disk after download, or you might
have downloaded it from an untrustworthy source. Even honest system
administrators can fall victim to these problems.

Validation on AR allows a sysadmin to catch this malicious image before
pushing it to all APs. The AR also will certainly have enough computing
power to perform signature verification.

Of course, validation on the AR does not help in the case of a rogue AR.
That's why we would want to also consider validation on the AP.

-David


From scott@airespace.com  Thu Jul 31 17:28:34 2003
From: scott@airespace.com (Scott G. Kelly)
Date: Thu, 31 Jul 2003 09:28:34 -0700
Subject: [Lwapp] Re: where to validate images, Scope of charter discussion
References: <0D3F1B25E75EE24483A6E69201142C867DA974@paris.synad.com> 
Message-ID: <3F2943B2.9090108@airespace.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think this AP-image-signing discussion is a major distraction that we
shouldn't be worried about right now. I think the basic question is
this: is AP image download support a requirement of the protocol we're
discussing?

I've avoided responding to the thread regarding mix-n-match images on
APs, as I think I must be missing something. I think Randy alluded to
the primary issue that I perceive with this: without a standard hardware
platform, the problems quickly become intractable. I don't see how we
can seriously consider anything like this.

A question that occurs to me is, what sort of alternative architecture
would motivate someone to propose this as an alternative to the current
LWAPP proposal, and how would knowledge of that architecture reshape
this discussion? Very curious indeed...



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/KUOyMtIdhO0pgN4RAsdIAJ9lHj66Z6S65gzSPgy7zmk9xsXO5ACgkhnn
loooM/Fle0axHbNzr4OZgzY=
=wYvD
-----END PGP SIGNATURE-----


From Spencer Dawkins"  
Message-ID: <107d01c357a4$f6ffd400$0400a8c0@DFNJGL21>

I'm way outside my area of expertise, but wonder if others
might have the same question - do we have enough PKI to
burn public keys into cheap APs at manufacture time?
including key revoking?

I'm thinking that (to use an analogy) having a compromised
private key for a major Ethernet switch vendor on today's
networks would be pretty embarrassing, if we were downloading
Ethernet switches today, so if AP-lites really take off, it
would be nice to know what we would do if someone
compromised a major AP manufacturer's private signing key...

(signed) curious

----- Original Message ----- 
From: "David Molnar" 
To: "Mike Moreton" 
Cc: 
Sent: Thursday, July 31, 2003 11:03 AM
Subject: [Lwapp] where to validate images



>
> Personally, I tend to agree that images should be checked at the AP.
>
> The questions is, check them using what public key? The AP
manufacturer
> can embed its own public key in the AP at manufacture time. Then all
> images would have to be signed with that key. This is fine if we
believe
> all AP images will come from that vendor. In a world where we
standardize
> an AP-AR protocol and let the AP vendors deal with the
implementation, I
> believe that is reasonable.


From puneetb@myway.com  Thu Jul 31 23:13:08 2003
From: puneetb@myway.com (Puneet B)
Date: Thu, 31 Jul 2003 18:13:08 -0400 (EDT)
Subject: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)
Message-ID: <20030731221308.6CF4B3A15@xmxpita.myway.com>

Andrew,

> Again, what I propose:
>
> In charter: A bootup/discovery protocol for an AP to 
> boot and find a suitable AR that provides an image to run it.
>
> Out of charter: What the image does (service layer).
>
> Advantages: 
>1. The IETF can minimize its work since it does not need to 
> track what is in the image, the vendors can do that. The 
> image will never stop evolving, we need to decouple this 
> from the IETF work (ie: slippery slope).
>
> 2. Marketplace differentiation is preserved; Plugging AP X
> into Controller Y gives you functionality Z while plugging
> AP X into Controller B gives you functionality C.

can this be done by adding some sort of 'vendor-specific-message'
to LWAPP? APs and ARs that are not from that vendor will
ignore it, and still provide all the basic features. You can
use that message to exchange special service layer messages 
between the AP and the AR. The AR would then work with every 
LWAPP compliant AP, & if someone buys your or your partners 
AP, he also gets support for those extra features. 

> Disadvantages:
> 1. Some porting work might be necessary from the Controller 
> vendor to create images that are suitable for more than one 
> AP vendor. This is not as hard as it sounds and there is 
> precedence for this sort of work. The image does not have 
> to be written entirely by the Controller vendor, think NDIS.

That might actually be quite a few number of combinations
of chipset/hardware. Its going to be a bit of work for AR
vendors to support all, and I guess they'll all finally
just stick with the most common/cheapest/biggest_company AP.

For an AP vendor to be able to ship even a single unit, he 
needs to probably first have a couple of major AR vendors 
create and ship images specific to his AP. Also, he cannot 
make any change to his APs architecture without again going 
over the cycle of asking every AR vendor to prepare images 
for him. I think the current LWAPP proposal is much more 
balanced atleast for this purpose.

Puneet

_______________________________________________
No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com