RE: [LinkSec] RE: Reminder: linksec call on Tuesday at 2:00pm ET
The tricky bit about characterizing pain, relative to PN size, is that
it is highly data dependent. It might be valid for us to take the
emprical packet size distributions for TCP on the public internet as a
model, however we would also need to accept the fact that it would be a
suboptimal model in pathological cases. Wired LANs are a fine example
where specific types of traffic exist that aren't common on the public
internet. E.G. X windows (lots of small transactions), moving multi GB
files (Lots of max-size packets with ACKs) or real time, fixed packet
size CBR traffic.
An interesting metric that I like to harp on about is the 'ease of key
retrieval'. Given you might have a stream cipher in a mode like CCM, it
is nice if you can have the cipher stream ready as the data arrives,
thus incurring no delay beyond the XOR gate and the inserted security
headers and trailers and saving you from having to buffer ciphertext at
the front of the MAC.
It turns out, in cases where you might have more than a small number of
keys, that key retrieval can be the major contributor to the likelihood
of being able to get the cipherstream started in time. If the
encapsulation allows you to get at the key by direct indexing, rather
than searching, then you are in good shape. So, for instance, a huge
SAID means it is useless for indexing into a small key table unless
there is some other information or structure in the SAID that allows you
to find the key in an algorithmically small time.
In situations where speed matters, this is an important but often
ignored issue. Check out 802.11i for an example of getting it wrong.
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: Mick Seaman [mailto:mick_seaman@ieee.org]
> Sent: Sunday, September 14, 2003 12:47 PM
> To: Johnston, Dj; 'LinkSec'
> Subject: RE: [LinkSec] RE: Reminder: linksec call on Tuesday
> at 2:00pm ET
>
>
>
> I suggest that we construct an overall "added bit budget"
> table so that we can put some of these discussions in
> context. The amount spent on each field should result in some
> equality of pain when the length of one field gets changed
> versus the length of another.
>
> In line with Russ' previous plea for algorithm independence,
> I don't see how the "pick one and live with it choice works".
>
> I would suggest that the header needs just a few publicly
> decodable fields (a) for network administrator use, for
> example presence or absence of a secure authentication origin
> field a.k.a. who put this header on this frame) (b) for the
> intended recipient to identify the association (overloaded
> word, here I mean the other party(ies) and instance of key
> and algorithm distribution - I hope that's clear). The length
> of the PN is after the latter and surely won't change at
> least until rekeying occurs, so it can be a fixed field that
> lasts that long.
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf
> Of Johnston,
> Dj
> Sent: Sunday, September 14, 2003 11:15 AM
> To: Dolors Sala; LinkSec
> Subject: [LinkSec] RE: Reminder: linksec call on Tuesday at 2:00pm ET
>
>
>
> My thinking, that will probably be the substance of my contribution on
> Tuesday is to try to answer the question "How long is the PN?".
>
> We have to cover a range of speeds arguably 10kbps through to 100Gbps
> today, and those bounds can be expected to move outwards in
> the future.
>
> Large PNs (say 64 bits with a non birthday attack susceptible mode)
> represents transmission overhead. Small PNs equate to rapid rekeying,
> and if this requires a lot of backaul AAA type interaction, the
> per-rekeying effort may be high.
>
> So the short answer is that there is no PN length that is optimal for
> all cases.
>
> We have options:
> 1) Pick a number, live with it and suffer the consequences (maybe poor
> adoption)
> 2) PN length negotiation. See Rogaway's NIST submissions for why this
> might be a bad idea.
> 3) Fixed technology to PN length mapping (.3 gets 64 .11 get 48 bits,
> .15.4 gets 32 etc) might work, but the PHY rate of those technologies
> changes with time and how do we cope with provider bridges that have
> different technologies at either end?
> 4) Elastic PN. Encode the PN with a delimiter so its length can vary.
> Smaller number take less space. Rekey when you don't like the size of
> the PN. This sounds complex (at least in terms of MAC design)
> and might
> have some subtle security failure I haven't appreciated.
> 5) Others?
>
> If I have a proposed solution by Tuesday, you will see it. If
> not, then
> you will only have problems to show.
>
> 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: Dolors Sala [mailto:dolors@ieee.org]
> > Sent: Sunday, September 14, 2003 6:58 AM
> > To: LinkSec
> > Cc: Johnston, Dj; Marcus Leech
> > Subject: Reminder: linksec call on Tuesday at 2:00pm ET
> >
> >
> > This week we will discuss MACsec header formats. Marcus Leech
> > already sent a
> > preliminary proposal for discussion to the reflector. See the
> > message below
> > and subsequent discussion:
> >
> http://www.ieee802.org/linksec/email/msg00614.html
>
> David Johnston will send some additional material in advance.
>
> Call in details included below.
>
> Dolors
>
> ---
>
> Call in details:
>
> Date/Time: Tuesday, 2:00pm ET
> Toll Free: (800) 486-2726
> Dialer Paid: (201) 368-8643
> Participant Code: 535172
>
> Bridge sponsor: Dan Romascanu, dromasca@avaya.com
>
>
>