Tero:
[2.21:]
> such a message (and also a network message like ICMP destination
> unreachable) as a hint that there might be problems with SAs to that
> IP address and should initiate a liveness test for any such IKE_SA.
> An implementation SHOULD limit the frequency of such tests to avoid
> being tricked into participating in a denial of service attack.
>
> A node receiving a suspicious message from an IP address with which
> it has an IKE_SA MAY send an IKE Notify payload in an IKE
> INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The
> recipient MUST NOT change the state of any SAs as a result, but may
> wish to audit the event to aid in diagnosing malfunctions. A node
> MUST limit the rate at which it will send messages in response to
> unprotected messages.
We should also extend this section and include at least following
cases:
- Errors happening before authentication
- Errors in the IPsec SA creation on IKE_AUTH
- Describe which errors are so fatal that they cause the whole IKE
SA to destroyed.
Paul indicated he's not convinced any of these new cases are needed.
Proposed new text would be welcome.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
