Hi Steffen,
Thanks for your reply, some thoughts inline.
> > 3. In the Peer Header of Section 2.3, it’s said that the Peer Header
> > contains an optional ‘Sequence Number’ field and an optional
> > ‘Initialization Vector’ field. If both fields are optional, is this
Peer Header
> > optional too? What if neither of these fields are carried?
>
> If we don't do replay protection and the used cipher does not need an IV,
> we don't need the peer header.
> So yes, it is optional.
>
> The Sequence Number field is mandatory for ESP, while the IV is not. I
> think that's why it is used to carry an implicit IV for counter mode
> algorithms.
[Wei Pan] Replay protection is an important security property. I feel it's
better to make the Sequence Number field also mandatory for EESP.
> > The second thing is that if we want to minimize the overhead of the
> > EESP header, should we consider the optimization thoroughly? Not only to
> > omit the Payload Info Header, but also to consider what other fields
can be
> > optimized.
>
> Which other fields could be optimized?
[Wei Pan] I have no clear answer. I just wonder what else we can do if we need
optimization, one thing comes up into my mind is to minimize the length of all
fields as much as possible. But the question is whether there is such a need.
> > 8. In Section 2.5, the last paragraph (copied below) is the same as the
> > alignment requirement written in ESP. But I think this paragraph can be
> > omitted in EESP.
> > Note that the beginning of the next layer protocol header MUST be
> > aligned relative to the beginning of the EESP header as follows.
> > For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the
> > alignment is a multiple of 8 bytes.
> > In ESP, there is an IV field in front of the actual payload data. So I
think
> > the requirement above is actually for the IV field, i.e., the IV field
should
> > be a multiple of 4 / 8 bytes.
> > But the Payload Data in EESP doesn’t have the IV field, and it begins
with
> > the “next layer protocol header”. So the beginning of the next layer
> > protocol header is the beginning of Payload Data, and it will naturally
fit
> > the alignment requirement.
>
> I think the alignment of the next layer protocol header depends on the
> final EESP header layout with variable length options. So not sure if that
> text should be removed.
[Wei Pan] The actual payload data is copied from the original packet. In ESP,
the IPsec implementation needs to insert an IV field before the actual payload
data. So for this newly added IV field, you should make it a multiple of 4/8
bytes.
But in EESP, this IV field is in the Peer Header and doesn't belong to the
Payload Data. The Payload Data directly begins with the "next layer protocol
header" of the actual payload data. The alignment requirement is needed, but
not for the Payload Data, but for all the headers before the Payload Data. And
this requirement should be defined in the corresponding sections of the headers
before the Payload Data, not in this section.
> We will publish a new version with your feedback incorporated soon.
[Wei Pan] Looking forward to reading the new version. ^_^
Regards & Thanks！
Wei PAN (潘伟)
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
