Re: [babel] Shepherd's review of draft-ietf-babel-hmac-02

[Donald Eastlake <[e-mail]>]

Hi Juliusz,

Deleting stuff where we don't disagree:

On Wed, Dec 26, 2018 at 2:03 PM Juliusz Chroboczek <[e-mail]> wrote:
>
> ...
>
> > Section 5.2:
> > The diagram is odd. I would recommend sliding the Index field and
> > preceding vertical bar character to the left so it starts aligned
> > with the Type.
>
> I've tried, but I didn't like the result.  I'll leave it as it is, if
> that's okay with you.

I'm pretty sure the draft with the current figure is going to run into
problems at AD review and if it survives that, I can pretty much guarantee
the draft will run in problems with at least one AD when it hits the IESG.
The current figure tries to be in the style used for protocol headers but
that isn't the style normally used in the IETF for TLVs. The alternative
figures I included in my comments are more in the traditional figure style
for a Routing area TLV. See, for example, the numerous TLV and sub-TLV
diagrams in https://tools.ietf.org/html/rfc7176 which are close to my
second suggestion (except that I squeezed the lines a bit, dropping the
alternative "+" signs so that four bytes would fit more easily on a line).
Or https://tools.ietf.org/html/rfc8401 which has diagrams closer to my
first example.

If you really want to use a protocol header style figure for this TLV, I
think you will end up needing to change it to something like the following:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |         PC - upper half       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PC - lower half       |            Index...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

> ...
>
> > While it is reasonable, for implementation convenience, that there is
> > a maximum size for Index, perhaps for cryptographic strength, there
> > should be a minimum length, maybe 12 bytes?
>
> I disagree.  The only property that the index needs to satisfy is that it
> is never reused for a different PC sequence for a given (key, sender)
> pair.  In particular, if a node never loses state (e.g. it has reliable
> persistent storage), then it never needs to change indices -- and in that
> case, a 0-octet index is suitable.

The assumption that a node will never lose state and never count out the PC
space seems quite brittle to me.

>
> ...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [e-mail]

> Thanks again,
>
> -- Juliusz