Hi Graham,
thank you for the updated text.
I¹ve made some amendments to the proposed text based on Valerys comments.
I¹ve also added text around the correct sending of INFORMATIONAL messages
due to a Responder receiving an SA_INIT, this is a known problem today
with a number of implementations. (seen by Tero and myself).
Sorry, your text is wrong (or at least is not accurate). The responder
must never reply to an IKE_SA_INIT with INFORMATIONAL message.
See section 1.5 of RFC 7296:
In the second and third cases, the message is always sent without
cryptographic protection (outside of an IKE SA), and includes either
an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no
notification data). The message is a response message, and thus it
is sent to the IP address and port from whence it came with the same
IKE SPIs and the Message ID and Exchange Type are copied from the
request. The Response flag is set to 1, and the version flags are
set in the normal fashion.
Note, thet Exchange Type is copied from the request, so if some IKE_SA_INIT
request has unsupported major version the responder will send
INVALID_MAJOR_VERSION in the IKE_SA_INIT (not INFORMATIONAL) response.
The only case unprotected INFORMATIONAL message is sent is when
the host receives AH/ESP packet with unknown SPI. And all these cases
are covered in Section 1.5 of RFC 7296 in sufficient detail, including
DoS attacks prevention measures (rate limiting).
I don't think we should repeat all this in the draft.
I have also moved text to section 11. Security Consideration.
I¹ve added some words around the checking of the IDi/IDr. I¹ve personally
seen some issues when misconfigured clients have presented an identical
IDi, resulting in INITIAL_CONTACT deleting the Œother¹ clients SA.
Since INITIAL_CONTACT is processed after peer authentication,
malicious user cannot use it to perform DoS attack
(unless he/she is able to impersonate legitimate user, but in this case
he/she can do much worse things). And what about misconfiguration -
Section 2.4 of RFC 7296 already has all due warnings:
This notification MUST NOT be sent by an entity that may be
replicated (e.g., a roaming user's credentials where the user is
allowed to connect to the corporate firewall from two remote systems
at the same time).
Again, I don't think we should copy all the requirements concerning
INITIAL_CONTACT from RFC7296.
I did think about exhaustion of IP addresses when using configuration
payload to allocate clients IPs, if a malicious or misconfigured client
could exhaust the pool. But I feel the wording in section 8 covers this.
Unless others think otherwise?
Again, allocation of IP addresses takes place after user authentication,
so it cannot be used as DoS attack by malicious user.
cheers
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
