Hi Paul,
I think that the following assertion in the draft is wrong:
Although
ESN is good to avoid the sequence number running out in a short
period, there is a prerequisite for using ESN - RFC 4302 and RFC 4303
both require ESN to be used in conjunction with the anti-replay
function. That is, ESN can only be used if the anti-replay feature
is enabled.
Actually, RFC 4303 and RFC 4302 say:
Note: If a receiver chooses to not enable anti-replay for an SA, then
the receiver SHOULD NOT negotiate ESN in an SA management protocol.
While SHOULD is a strong requirement, it is still not MUST, so it is
perfectly valid to use ESN with no replay protection if you have a good
reason (and you have).
The text can be tweaked. But in practise these two properties are currently
linked.
In the case when the receiver has disabled anti-replay, but negotiated
ESN, it still needs to monitor SN values in the incoming packets and
maintain the upper
half of the ESN, since it is included in the ICV calculation.
But this is really small burden, compared to full replay protection.
Thus, I don't see a need for this notification at all.
The issue is that clients want to have both "disable replay protection" and
"ESN". Currently, many
implementations (including Linux) do not support this. We are working on
getting that fixed, but that
will inevitably need a signal by the IKE daemon to let peers know what is
supported and desired, so
that ESN can be requested for those that support ESN without replay protection.
And so that NO-ESN
can be selected for those implementations that do not support "disable replay
protection" with ESN.
I missed the deadline to extend the notify payload to add this signaling. The
next revision will include this.
Perhaps this discussion is a bit premature, since I currently have to
guess what
you intend to achieve and how this influences packet processing.
Can you please include answers to the following questions in the next
revision:
1. What happens with SN if peers negotiate not using replay protection:
- will it be incremented or send as a constant (what constant)?
- if incremented will it be allowed to wrap around (I guess yes)?
2. What happens with ESN if peers negotiate ESN and not using replay
protection:
- will SN be incremented or send as a constant (what constant)?
- how the upper half of ESN is computed (it is included in ICV
calculation)? Will it be deducted as usual or be constant?
- if ESN is incremented, will it be allowed to wrap around?
If the negotiation of the replay protection status is still needed, then:
- it is better to be done in a way it is done in draft-ietf-ipsecme-g-ikev2
(section 2.6),
since it couples this feature with negotiation of ESN
I am not a big fan of renaming the type 5 registry into "replay protection". It
seems to mixup integers
with flags (bits) and become a grab bag of miscellaneous things.
Not really, this is still integers:
- SN
- ESN
- no replay protection (do not look at SN at all)
Why doesn't the g-ikev2 doc simply
say to always negotiate NO-ESN if that is what is needed. I don't see the need
for a rename of the ESN
IANA registry?
Because if we want to negotiate replay protection in IKEv2 this is
a better way to do it via transform then via notify. Because,
for example, you may propose no replay protection only with
those encryption transforms, that have explicit IV and always propose
replay protection for implicit IV.
- a text should be added about incompatibility with RFC 8750
I guess we could, although I feel that RFC 8750 should have been more explicit
in saying "ESN is not
supported due to re-using the same counter after 2^32 bytes". There is nothing
specific to this draft that
related to that. Seems more like an errata against 8750, but I don't object to
warning users here either.
This is wrong, RFC 8750 supports ESN. In fact it does always use 64
bit IV,
but with no ESN the upper half is set to zero.
I just wonder that if you negotiate not using replay protection, then
the sender is free to send constant (E))SN or allowing SN it to wrap
around,
that is obviously incompatible with RFC 8750.
Regards,
Valery.
Paul
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
