Re: [STDS-802-11-TGAK] 802.11ak - Encryption of EPD formated frames
HI Philippe,
On Thu, Jan 22, 2015 at 10:58 AM, Philippe Klein <philippe@xxxxxxxxxxxx> wrote:
>>>If you are talking about 802.1AE between those bridge ports, the bridge ports can do whatever they want. There is no reason for the STA to know anything >>about it. If the bridge ports apply 802.1AE, the payload will simply start with an 802.1AE tag.
>
> Meaning 2 crypto engines...
Only if you want.
We are only talking about one hop security here. Given how good 802.11
security is, I don't know why someone would run 802.1AE on the bridge
port to bridge port path that is being tunneled through the STA-to-STA
hop unless the STA and associated bridge were remote from each other
over a vulnerable wired path. Certainly in the normal case where the
bridge and the STA are in one box, I would imagine the connection
between them was as physically secure as the bridge and STA themselves
were.
> Eventually in an unified LAN bridged network when all wireless links will be 11ak EPD and the encryption engine AES GCM (notice that 11.ad crypto is AES GCM (and not AES CCMP) and this crypto will be applicable to earlier versions as well) should we be forced to retain both 801.AE AND 802.11i ?
High speed crypto pretty much requires hardware assist, typically at
the line card level, not necessarily crypto hardware per line but per
group of lines. As far as I can tell, the wired word's attitude
towards link security is that it is very expensive and is only
deployed in rare circumstances when the wired connection is at
particularly risk. The wireless world's attitude towards link security
is that all radio links are always at risk so hardware to support
crypto is always built in from the start and, as a result, from the
implementer's point of view, full speed crypto is free because the
hardware is just sitting there anyway.
So, the 802.11 hops, GLK or not, can always be secured and will
essentially always be secured. Given that, why would you waste the
money on crypto hardware to support 802.1AE for the bridge ports
leading to the GLK STA? I suppose if you have a bridge that is so slow
it can have central crypto hardware that supports crypto for all of
its ports, in that case that crypto is wasted for the ports going to
GLK STAs and you should not turn on 802.1AE for those bridge ports
since it lengthens the frame.
I also believe you underestimate the the quality complexity of 802.11
security. I believe 802.11 security does a better job of security for
group addressed frames and better handles the appearance and
disappearance of neighbors (a rare event in the wired word but common
and frequent in the wireless world). 802.1AE has a very simple affect
on the frame structure, just modifying the payload and pushing a tag
in front of it. 802.11 has different frame types with somewhat
different structure for data, control, management, etc. For data,
802.11 security and 802.1AE don't even happen at the same level in the
stack, 802.1AE operating at the frame level while 802.11 security
operates at the fragment level. And 802.11 security is not just
802.11i. There is 802.11w (Protected Management Frames) not to mention
the security aspects of 802.11s, 802.11r, 802.11ae, etc., etc.
Given all the above, I'm pretty sure it would be a massive and complex
operation to try to make 802.11 security be 802.1AE security if it is
even possible, an order of magnitude more massive and complex than all
of the rest of 802.11ak put together, and would add a minimum of one
year delay to 802.11ak completion.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@xxxxxxxxx
> /Ph
>
> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx]
> Sent: Thursday, January 22, 2015 5:43 PM
> To: Philippe Klein
> Cc: TGak
> Subject: Re: [STDS-802-11-TGAK] 802.11ak - Encryption of EPD formated frames
>
> Hi Philippe,
>
> ?
>
> A GLK STA provides an ISS interface to what is assumed to be a local bridge port for each other GLK STA it is talking to.
>
> If you are talking about 802.1AE between those bridge ports, the bridge ports can do whatever they want. There is no reason for the STA to know anything about it. If the bridge ports apply 802.1AE, the payload will simply start with an 802.1AE tag. Conceivably we might need to do something so that the bridge ports can conveniently talk 802.1X across the 802.11 hop but I don't think so. I think it will just work.
>
> If you are talking about changing STAs to use 802.1AE, I don't understand why. 802.11 provides excellent robust and essentially universally deployed security. Why muck with it?
>
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@xxxxxxxxx
>
>
> On Thu, Jan 22, 2015 at 12:28 AM, Philippe Klein <philippe@xxxxxxxxxxxx> wrote:
>> The current P802.11ak_D0.06 draft version does not mention any
>> requirement in regard to the encryption of EPD formatted frames.
>>
>>
>>
>> I suggest we add a requirement that EPD formatted frames must be
>> encrypted in a way compatible with IEEE 802.1AE (MACsec) as the
>> 802.3/Ethernet frames are (notice that 802.11ad crypto mode is
>> AES-GCM, the same crypto mode that the default Cypher Suite of 802.1AE).
>>
>>
>>
>> If you agree I will post a contribution that could be discuss next
>> Monday during the conf call.
>>
>> Thank you
>>
>>
>>
>> /Philippe
>>
>>
>>
>> Philippe Klein, PhD |Technical Director, Broadband Technology Group
>>
>> Broadcom Corporation | Golan House, P.O.Box 273, Airport City, 70100
>> Israel
>>
>> (M) +972 54 313 4500 | philippe@xxxxxxxxxxxx
>>
>>
>>
>> ______________________________________________________________________
>> _________
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
>> request to this CLOSED reflector. We use this valuable tool to
>> communicate on the issues at hand.
>>
>> SELF SERVICE OPTION: Point your Browser to -
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and then
>> amend your subscription on the form provided. If you require removal
>> from the reflector press the LEAVE button.
>>
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>> ______________________________________________________________________
>> _________
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________