Pasi.Eronen@nokia.com writes:
> - A question: did the WG discuss the pros and cons of integrity> protecting the WESP header? (This does make WESP more complex to> implement, and currently the WESP header does not contain any data> that would benefit from integrity protection in any way.)

Thats is actually good question, as all of the data in the WESP header
is verified by comparing it to data elsewhere (either in packet (Next
Header) or data associated to SA (HdrLen, TrailerLen, flags)) already
I do not think if protecting WESP header adds anything.

I think that if we don't add it to ICV that could simplify
implementations as the ICV calculations would be exactly same as they
were before, so converting ESP -> WESP would be simple, by just
insertting new header and changing protocol number.

> - Section 2: "The bits are defined LSB first, so bit 0 would be the> least significant bit of the flags octet." This doesn't match the bit> numbering in Figure 2 (where bit 0 is the most significant bit).> However, the bit numbers are not really used anywhere, so I would just> suggest deleting this sentence.

> - Section 2: the text about TrailerLen is a bit unclearly written --> the offset from the end of the packet to the last byte of the payload> would be a negative number. I'd suggest phrasing this something like> the "The number of bytes following the payload data in the packet, in> octets: i.e. the total length of TFC Padding (normally not present for> unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header),> and ESP ICV."

TFC Padding cannot be included in the TrailerLen as it can be too
large to expressed in 8 bits. Actually reading the description it
would indicate that the Padding, Pad Length and Next Header at the end
of packet would be included in the TrailerLen, which would mean that
even that might not be expressed in 8 bits in octects.

I originally only assumed it includes the ICV field length, nothing
else. That is the only thing needed by the intermediate device, as it
can see pad length and padding from the packet and it can also skip
the TFC padding in the same way recipient will do.

With the current wording the TrailerLen would be different for each
packet depending how many bytes of padding there is, which will mean
that final recipient needs to do some extra calculations while
verifying its length is correct (i.e it cannot simply compare the
TrailerLen to fixed value based on the SA (12 for HMAC-SHA1 etc), but
it needs to calculate Pad Length + ICV length + 2 + TFC Padding length
and see that it matches the TralerLen.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec