Hi Paul,
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)?
It will be incremented, eg just like today, guaranteed to be unique.
It will not be allowed to wrap (this cannot work with things like AES_GCM where
the same number is in use)
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)?
Same as above. The sending does not get modified at all. Only the receiving
side omits any checks for in-order
or in-window and will always allow any packet with any SN.
- how the upper half of ESN is computed (it is included in ICV
calculation)? Will it be deducted as usual or be constant?
Same as now.
- if ESN is incremented, will it be allowed to wrap around?
No - same as now.
Sorry, but here I’m completely lost. From your explanation it looks
like the sender’s behavior is not affected by this notify –
it is the same for both SN and ESN cases regardless of whether this
notify was exchanged or not. Given the fact, that reply protection is a local
matter –
what is the purpose of this notify? In other words, why to inform the
other side about the state of your replay protection if this information
doesn’t change that side’s behavior as a sender? What’s the reason? Am
I missing something?
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)
SN or ESN cannot be sent as constant number, or rather it can be since you have
to keep a counter anyway
for the AEAD counter, there is no point doing that. Only the receiver changes
as to not drop any packets
based on SN / ESN.
This is only true for implicit IV. All original AEAD transforms use
explicit IV that is not
related to (E)SN. And in case of several multicast senders the GCKS
takes care
to assign a unique IV prefix to each sender, so IVs don’t repeat
(unlike SNs).
Transforms with implicit IV cannot be used with multicast, which is
documented in RFC 8750, Section 7.
replay protection is therefor orthogonal to SN/ESN, which is why I don't like
mashing this into the Transform Type 5.
Not completely. In case of several unsynchronized multicast sender the
SN is not guaranteed to be unique,
thus the replay protection is turned off. In this case ESN cannot be
used 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.
I don't believe in this, but if I did, wouldn't you extend the Transorm Type 5
to:
- SN
- ESN
- SN without replay protection
- ESN without replay protection
The last case is meaningless for multicast scenario.
Hence my comment about bytes and flags being a bit confusing. I don't think we
can repurpose this registry as
flags (bits) because some implementations will read the two octets and require
the integer 0 or 1 out of that.
I still have to understand why you want to inform the other side about
your replay protection state
if this doesn’t change that side’s behavior as a sender.
Multicast is a separate thing, where “ESN without replay protection”
makes no sense.
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.
I don't think anyone should do constant (E)SN or wrapping around ever. I think
these two items have nothing
to do with replay protection.
Please, see my confusion above.
Regards,
Valery.
Paul
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
