Re: [tcpm] TCP-AO Option Layout

Hello.

In article <488EF15F.4070302@isi.edu> (at Tue, 29 Jul 2008 03:30:55 -0700), Joe Touch <touch@ISI.EDU> says:

> | With this layout, An implementation will end up put it like this
> |                                     +---------+---------+
> |                                     | Kind=?? | Length  |
> |                                     +---------+---------+
> |                 +--------------...--+---------+
> |                 |       MAC         |  KeyID  |
> |                 +--------------...--+---------+
> 
> Why is this the case? IP with no options is 20 bytes; the base TCP is 20
> bytes, so the options begin aligned; noting that most MAC sizes are
> multiples of 4 bytes, the alignment is most likely to result in:
> 
> ~                 +---------+---------+--------------------+
> ~                 | Kind=?? | Length  |   MAC...           |
> ~                 +---------+---------+--------------------+
> ~                 ...
> ~                 ....
> ~                 +-------------------+---------+
> ~                 |       MAC         |  KeyID  |
> ~                 +-------------------+---------+
> 
> In this case, the prepad is 0 and the postpad is 1, but the MAC is only
> half-word aligned.

Well, memory cop works much better if the memory regions are on 32bit
word aligned.  (We put timestamp etc.'s "value" on 32bit aligned.)

> If we want to reduce padding and keep the MAC aligned, the best option is:
> 
> ~                 +---------+---------+---------+---------+
> ~                 | Kind=?? | Length  |  KeyID  |   0     |
> ~                 +---------+---------+---------+---------+
> ~                 ...
> ~                 ...
> ~                 +---------------------------------------+
> ~                 |       MAC...                          |
> ~                 +---------------------------------------+

I support this.

> I.e., pad ourselves. We suggest that the option start word-aligned. This
> wastes space, IMO.

I don't think this is a waste of space and good thing to have -
to save CPU cycle(s).

> I would favor a more economical approach that recognizes that a few bits
> of MAC could be sacrificed for our KeyID, e.g.:
> 
> ~                 +---------+---------+-----+--------------+
> ~                 | Kind=?? | Length  | KID |  MAC'...     |
> ~                 +---------+---------+-----+--------------+
> ~                 ...
> ~                 ....
> ~                 +-------------------+
> ~                 |       MAC'        |
> ~                 +-------------------+
> 
> Use 2 bits for the KID; 1 is insufficient, and 2 is more than sufficient
> IMO.
> 
> The MAC' is a half-word aligned MAC with the top 2 bits overwritten
> (i.e., it is NOT shifted right); the KID occupies those top 2 bits.
> 
> If a user wants word alignment, pick a MAC length of N-2 bytes.
> 
> Wouldn't that be simpler and more space efficient?

We have 256 keys, and it is not enough.
And is NOT simple and more complex from implemntation point of view
- eats a lot of cpu cycles.

--yoshfuji
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

Re: [tcpm] TCP-AO Option Layout - Alignment and Padding