Subject: RE: [Ipsec] Clarification on error notifications, please

From: [email-masked]
Date: Fri, 23 Sep 2005 13:58:42 +0300

What exactly do you mean by "MUST NOT act based on them"?

For instance, if the authentication of the initiator fails
(e.g. responder doesn't like the certificate), I think the 
exchange would look something like this:

1. HDR, SAi1, KEi, Ni -->
   <-- 2. HDR, SAr1, KEr, Nr
3. HDR, SK { IDi, CERT, AUTH, SAi2, TSi, TSr } -->
   <-- 4. HDR, SK { N(AUTHENTICATION_FAILED) }

What exactly should the initiator do after it receives messsage 4?
("Doing nothing" is not an option)

IMHO the sensible action would be to log an error (maybe), terminate 
this IKE_SA, and if the initiator is really concerned about DoS
attacks, maybe try again from the start a couple of times.

The option "pretend that we didn't receive message 4 at all 
(=continue retransmitting message 3)" doesn't make any sense, because
the message had a valid MAC, and there's no way the initiator is 
going to receive a different message 4 with valid MAC.

...unless it also receives a different message 2, that is (perhaps
the attacker was faster than the real responder in replying to
message 1). In this case, receiving AUTHENTICATION_FAILED could
sort of "roll back" the state to the situation where we've
just sent message 1 (so the initiator would continue retransmitting
message 1 in a hope that it gets a different message 2 back).
But this gets quite complicated, and I'm not totally convinced
of its usefulness...

Best regards,
Pasi 

> -----Original Message-----
> From: Tero Kivinen
> Sent: 21 September, 2005 19:04
> To: Michael Richardson
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ipsec] Clarification on error notifications, please 
> 
> Michael Richardson writes:
> >   I think that they are useful to send, and for the recipient to
> > rate-limit log. It's a signal to "please fetch human".
> 
> I agree in that there is some use for sending them, but I still think
> the responder MUST NOT act based on them...
> -- 
> [email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Sep 2005 16:01:34 +0300

> attacks, maybe try again from the start a couple of times.

He should probably log it, but I would say he should otherwise ignore
the packet (or use it as hint), and continue trying until it times
out, or after the policy is modified. The IKEv2 draft is quite clear
about that (section 2.21):

   A node receiving such an unprotected Notify payload MUST NOT
   respond and MUST NOT change the state of any existing SAs. The
   message might be a forgery or might be a response the genuine
   correspondent was tricked into sending. A node SHOULD treat 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.

Before we have processed the other ends AUTH payload the notifies are
unprotected, as we do not know who the other end is. So the only
option draft really gives you is to use it as a hint (i.e. you can log
it, and you can perhaps make you time out faster, and limit the number
of retranmissions). 

> going to receive a different message 4 with valid MAC.

Currently people doing that have another problem. They do not rete
limit the IKE SA requests they are sending. I.e. they fail immediately
when they receive the AUTHENTICATION_FAILED, and the delete IKE SA and
for the next ping packet or so they trigger again, and start to
recreate the IKE SA again, thus going to endless loop of
renegotiations without rate limits. To cope with that problem they
need to add separate rate limiter.

If they would do the normal timing out of the IKE SA that would act as
a nice rate limiter automatically. I.e. they would not fail the
negotiation so quickly, they would wait for the timeout before it
fails, and then they could restart the exchange, and do those retries
only every few minutes after each timeout.

AUTHENTICATION_FAILED will not normally disappear without user
interaction. There are few cases where that can happen (network to the
OCSP/LDAP etc server was down and is now up again), but usually those
takes also some minutes to do, so retrying every second is not really
usefull in those cases. 

> But this gets quite complicated, and I'm not totally convinced

That mechanism is defined in the draft, so you MAY implement it and in
that case you do want to ignore the AUTHENTICATION_FAILED messages.

Also I agree that in AUTHENTICATION_FAILED is probably one of those
notifies that you could act based on unauthenticated notifies, but in
general the IKE SA is only authenticated after we have done the AUTH
processing, and before that it is not authenticated, and all notifies
before that are unauthenticated, and the IKEv2 draft do not point out
some errors as special case which you can act on based on
unauthenticated information.

You can use them as hints, you MUST NOT change the state of any
existing SA. I would consider tearing down the IKE SA in process of
being created as changing state of an SA, thus actually violating the
spec.

I do not think this is so important feature that we would need to
start pulling back IKE draft and start making modifications because of
that. Also I do not think we can change MUST NOT of the IKEv2 draft in
the clarification draft.

So lets live with this and continue working with the draft we have.
-- 
[email-masked]

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 23 Sep 2005 09:44:49 -0700 (PDT)

> unprotected, as we do not know who the other end is.
>
The draft uses the word unprotected in a few other
places. I guess this meaning would make sense only in
this context i guess. Mostly, unprotected means
"packets that don't have cryptographic protection".
Perhaps, the above should be changed to
"unauthenticated".

> So the only
This is given in section 2.4:

Since IKE is designed to operate in spite of Denial of
Service (DoS)
   attacks from the network, an endpoint MUST NOT
conclude that the
   other endpoint has failed based on any routing
information (e.g.,
   ICMP messages) or IKE messages that arrive without
cryptographic
   protection (e.g., Notify messages complaining about
unknown SPIs)...... 

Implementations MUST limit the rate at which they take
   actions based on unprotected messages.

So, the draft is very clear on this.

> takes also some minutes to do, so retrying every
Retry a few times and stop. The user would retry once
more but eventually he stops. This happens in lot of
cases today.

> that. Also I do not think we can change MUST NOT of
I still think the implementation can do either way in
this case. 

-mohan