Thanks for your clear presentation.
Three observations on your presentation (pruning the data expansion) and
one additional remark (cross-802 use of LinkSec):
- The length of the PN field can be
allowed to vary, if part of its value is already known on the recipient's
side.
- The length of the ICV field can be
allowed to vary, rather than chosen as fixed.
- There are situations where one does
not want encryption and authenticity, but rather only data authenticity
(obvious example: export control).
The combined effect of taking these
observations into consideration is that the 18 bytes = 144 bits of data
expansion introduced by adding frame protection can be trimmed down considerably
(say, from 18 bytes to 11 bytes, if one where to send 8 byte PNs in compressed
format).
These measures are detailed in my IEEE
802.15.4 presentation 02/474r2 (posted Jan 2003), where these mechanisms
are proposed to send a 1-byte compressed PN value rather than the full-length
4-byte PN value (thus, saving 3 bytes in security status information overhead)
and to allow flexibility as to the protection level required (e.g., encryption
and/of authenticity, the latter at different levels, viz. 0, 32-bit, 64-bit,
128-bit). The total cost hereof for 802.15.4 is 4-bit indicator info (1
bit compression identification, 3-bit protection level identification),
but benefit is flexibility towards what applications can bear, both in
terms of communication overhead (data expansion due to frame protection)
and computational overhead (no encryption if not needed). Again, in the
context of 802.15.4, there might be more than one application running on
each device and, whereas applications might fix the protection level among
themselves, this does not necessarily mean that each device runs at a fixed
protection level (indeed, there might even be applications that do *not*
require security, whereas others do, running on the same device). This
holds more general than just in the 802.15.4 setting (which, arguably,
is the most constrained wireless standard under the IEEE 802 umbrella).
One additional remark (re Slide 14 of
your presentation): you suggest that negotiation over provider bridge should
pick longest PN field if there is more than one option. This would force
the more constrained device (read: 802.15.4) to reserve the longest PN
fields in memory. This seems to be the wrong way around: one should put
the extra burden with devices that can afford this, not with devices that
are already operating on their toes. Anything else will be hard to accept
for users of standards that were designed to fit the needs of constrained
implementation environments. Moreover, there is a practical limitation,
e.g., 802.15.4 security does not work with nonces/frame counters of size
more than 4-bytes; no space available for more). A better option seems
to be (with a security suite with an increasing nonce in mind, such as
CCM) to adopt an approach, such as the following (still have to elaborate
on details):
- devices send frames using nonces with
a length that fits their own capability (i.e., 4-bytes for 802.15.4 and,
possibly, 8-bytes for 802.3).
- devices that receive nonces from a
device A store these according to the minimum of their own capability and
that of the sending device (i.e., if storage comes at premium, then store
a shorter nonce corresponding to sending device A).
- when updating the nonce value, an
"overflow/infinity" value is generated if the increased nonce
value does not fit the rules as stipulated aobve.
Consequences:
- devices within one standard use fixed
nonce/seq counter sizes, so situation same as now.
- devices that talk accross bridge with
sending dev 8-byte nonce and receiving device 4-byte nonce: sending device
can update nonce value as long as it fits within 8-byte format; recipient
device accepts nonce if it fits within 4-byte format (i.e., represent 32-bit
integer and unequal to "infinity" value 0xffffffff).
Note: There is one caveat with this
approach, which is that the formatting depends on the capabilities of the
underlying MAC of the sending device (maybe, we can indicate this in the
header as contextual info: indication that allows inference of size of
nonce field).
Rene
"Johnston, Dj"
<dj.johnston@intel.com> Sent by: owner-stds-802-linksec@majordomo.ieee.org
As before, I've put the files on my impoverished website.
If you like open(ish) formats, try:
https://www.deadhat.com/linksec/Linksec_FrameFormats.pdf
Or if you like to lock your data in a monopolist's closed format, try:
https://www.deadhat.com/linksec/Linksec_FrameFormats.ppt
Regards,
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)
> -----Original Message-----
> From: Hal Keen [mailto:Hal.Keen@att.net]
> Sent: Tuesday, September 16, 2003 7:48 AM
> To: Dolors Sala
> Cc: Johnston, Dj
> Subject: bounced giant message
>
>
> Dolors,
>
> The message with the frame-format slides was nearly a quarter
> MB, way over
> the size limit for the reflector.
>
> I see you got a copy; can you post the file?
>
> Regards,
> Hal
> Hal.Keen@ieee.org
>
>