Re: [STDS-802-11-TGAK] 802.11ak - Encryption of EPD formated frames
Hi Mark,
On Thu, Jan 22, 2015 at 1:41 PM, Hamilton, Mark
<Mark.Hamilton@xxxxxxxxxxxxxxx> wrote:
> Just checking (I'm not a .1AE expert):
>
>> We are only talking about one hop security here.
> Only? Ever? If that's true, then I side with Donald. It doesn't matter to the 'bridge' part of the implementation, and the Wi-Fi part already comes with it all plumbed in. (In fact, most of the devices we're discussing will want to do non-GLK Wi-Fi, and have to have the traditional 802.11 security anyway, so this would really be _adding_ a second security).
>
> But, I'm unsure if .1AE (or anything else in .1-land) could support "end-to-end" (across bridges, that is, at least) security. Is there any such thing?
Well, who knows about the future, but currently 802.1AE works between
"directly" connected ports. It modifies the frame and inserts an
802.1AE tag right after the MAC DA/SA at the start of the 802.3 frame,
even before any VLAN tags.
However, I put "directly" in quotes because it is the case that, for
example, if 802.1AE is running between customer bridge ports, there
could be intervening balanced sets of Provider or Provider Backbone
Bridges such that the entire customer payload, including the 802.1AE
security is tunneled through the provider service... However, you
can't have two customer end stations talking 802.1AE through a
customer bridge. The customer level secure channel would be terminated
at the customer bridge port...
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@xxxxxxxxx
> Mark
>
> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx]
> Sent: Thursday, January 22, 2015 9:57 AM
> To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
> Subject: 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
> _______________________________________________________________________________
_______________________________________________________________________________
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
_______________________________________________________________________________