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

From: Joe Touch <[email-masked]>
Date: Tue, 29 Jul 2008 03:30:55 -0700

Hi, Hideaki (et al.),

YOSHIFUJI Hideaki / ???? wrote:
| Hello.
|
| In section 3.2., TCP-AO Option is defined as follows (option 1):
|             +---------------------+---------+-------------------+
|             | Kind= TBD-IANA-KIND | Len=var |      MAC          |
|             +---------------------+---------+-------------------+
|             |              MAC (con't)            ...
|             +-------------------------------------...
|
|               ...-----------------+---------+
|               ...  MAC (con't)    |  KeyID  |
|               ...-----------------+---------+
|
| 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.

If we want to reduce padding and keep the MAC aligned, the best option is:

~                 +---------+---------+---------+---------+
~                 | Kind=?? | Length  |  KeyID  |   0     |
~                 +---------+---------+---------+---------+
~                 ...
~                 ...
~                 +---------------------------------------+
~                 |       MAC...                          |
~                 +---------------------------------------+

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

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?

Joe
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Tue, 29 Jul 2008 06:51:49 -0400 (EDT)

Hello.

> | With this layout, An implementation will end up put it like this

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:

I support this.

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

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

> of MAC could be sacrificed for our KeyID, e.g.:

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

---

From: Stefanos Harhalakis <[email-masked]>
Date: Tue, 29 Jul 2008 16:09:51 +0300

> I don't think this is a waste of space and good thing to have -

Please don't do this. Leave the padding as an issue for the OS implementation 
just like all other TCP options do. Any OS implementation may add a NOP at 
the begging and solve this problem (if it actually exists).

Also, noone can say whether there will be a 5 bytes option in the future that 
will be able to be effectively combined with this one.

Btw, how sure can you be that *all* TCP implementations out there (PCs, 
Non-PCs, small-embedded, mobiles etc) benefit from exactly 32bit writes? 

IMHO, when talking about thinks like this one, the underlying hardware should 
not be considered at all.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Jul 2008 06:45:42 -0700

YOSHIFUJI Hideaki / ???? wrote:
...
<what if we...>
|> 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.

Can you explain this further? We're talking about the number of keys
used within a single TCP connection; there isn't a clear need (AFAICT)
for more than a very small number of these.

| And is NOT simple and more complex from implemntation point of view
| - eats a lot of cpu cycles.

It would consume only two additional cycles in the following:
	header && 0011111111.... || keyID

(store keyIDs as values 0, 64, 128, 192 so you don't need to shift them
in/out)

I.e., 2 opcodes to encode the bits in the location desired.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jul 2008 14:15:19 +0100

> the begging and solve this problem (if it actually exists).

(contributor hat on)

I agree with this.

Lars