Section2, Page4
1 bit: Extensions Present (X). Setting the Extensions
Present bit to 1 indicates that WESP Extensions are present
between the WESP Header and the ESP Header (as shown above). The
recipient MUST ensure consistency of this flag with the
negotiated policy and MUST drop the incoming packet otherwise.
"MUST drop the incoming packet otherwise", is *MUST* necessary here?
IMHO, ignoring some extensions but the payload data available instead of
dropping the whole packet MAY be required in some scenarios.
Section2.1.1, Page6
The recipient of an OAM CV option MUST add the OAM CV option to the first
subsequent packet that is small enough to hold it, or generate an empty
packet after a timeout.
I can't understand this paragraph well. I'm sorry for my poor English as
a non-native English speaker. Which is required small enough? The OAM CV
option? It is already small with zero-length data. The first subsequent
packet?
But why this need to be small enough?
"or generate an empty packet after a timeout", is it indicated that the
empty packet
with OAM CV option?
Would you make this paragraph clearer?
Section2.1.2, Page6&7
IKE or ESP has already defined some error notification messages. In my
personal
opinion,The advantage of WESP error notification options compared to IKE/ESP
error notification messages is the extended information fields which could
carry
some important information.
Section2.3, Page9
I like the idea of Encryption Offset option. This option will provide
flexibility
of the data encryption. It can help the intermediate devices to detect the
visible
part of upper layer data.
Even more, besides offset, a new field could be added to this option which
stands for
the length of data need to be encrypted. For example, the offset field is X,
the length of
encrypted date field is Y, this indicates only the Y octets data from the X
octets from
the beginning of the payload data is encrypted. This means that this
extension can
provide a kind of ability that just a part of the payload data is encrypted.
It is just my humble opinions, welcome for more discussions.
Best regards,
Min Huang
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
