Subject: [Ipsec] Question about N(COOKIE) and N(INVALID_KE_PAYLOAD) combination

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Oct 2004 18:31:24 +0300

Lets verify that I have understand this correctly:

(HDR(I,R,M) = Header with SPI-I = I, SPI-R = R, and Message-ID = M)

	Initiator			Responder
	---------			---------
1.	HDR(A,0,0), SAi1, KEi, Ni ->
					<responder wants to
					 send cookie>

2.					<-- HDR(A,0,0), N(COOKIE)
						
	<initiator retries with cookie>

3.	HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni ->

					<responder is happy with
					 cookie, but notices that KEi
					 is not proper group, and
					 wants to change it, it still
					 does not want to store state,
					 so it sends another
					 N(COOKIE), might be same than
					 last time>

4.					<-- HDR(A,0,0), N(COOKIE'),
					    N(INVALID_KE_PAYLOAD) 

	<initiator retries with cookie,
	 and with proper KE payload>

5.	HDR(A,0,0), N(COOKIE'), SAi1,
	KEi', Ni ->

					<responder replies with its
					 own packet>

6.					<-- HDR(A,B,0), SAr1, KEr, Nr,
					    [CERTREQ]

	<exchange continues>

Now, I have some questions:

1) Are all packets above (1-6) have message id of 0 (I assume yes).

2) Are all packets above (1-6) having exchange type of IKE_SA_INIT (I
   assume yes).

3) If the responder allows storing state in the step 4, he could also
   reply without the cookie, and in that case the packet 5, wouldn't
   have the cookie either. Would the SPI-R still be zero? (I assume
   no, and I also assume that then packet 5 and 6 would also require
   same SPI-R, than what was returned in packet 4).

	I.e. is the responder SPI-R allocated after state is created
	or only after it is replying with the SAr1. As the responder
	will use the SPI-R as a reference point to the SA, I assume it
	needs to allocate it immediately when it stores state.

4) If responder do not include N(COOKIE') in the packet 4, I assume
   that inititator MUST NOT include N(COOKIE) in its packet 5, i.e. it
   can only include the cookie if it was sent in the last packet from
   the other end to it.

	Btw, with the suggested algorithm in the draft the N(COOKIE)
	and N(COOKIE') would be same, unless the shared secret was
	changed in the between. In all cases I assume that the
	initiator must only send N(COOKIE) out if it just received one
	in from the responder.

5) if NAT-T was enabled, all the packets above would be using port
   500, and only the first IKE_AUTH packet would be using port 4500,
   and the first responder packet having the N(NAT_DETECTION_*_IP)
   payloads would be packet 6, and all initiator packets above would
   include them.

Ps. Page 60 of draft-ietf-ipsec-ikev2-17.txt have one reference to the
IKE_INIT_SA instead of IKE_SA_INIT.
-- 
[email-masked]

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

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Thu, 7 Oct 2004 19:21:43 -0700

Hi,
   This is what I think would need to happen.

Initiator                                       Responder
1. HDR(A,0,0), SAi1, KEi, Ni-->
                       <---      HDR(A,0,0)N(COOKIE)
2. HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni----->
                       <----    HDR(A,B,0) N(INVALID_KE_PAYLOAD)
    (At this time, state is created by both responder too.)
3. HDR(A,B,1), SAi1, KEi(new), Ni------->
                        <----- HDR(A,B,1), SAr1, KEr, Nr. [CERTREQ]

I feel that Initiator need to choose message id 1 in transaction 3.
if transaction 3 uses message ID 0, it is possible that responder
might return the previous response as message id is same.  If the responder
chooses not to create the state in transaction 2, it would be treating message ID 0 as new
transaction and that would work. Since, initiator would not know the behaviour of the responder,
it is better if Initiator chooses new message ID for transaction 3.

Srini
Intoto Inc.
www.intoto.com

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Fri, 08 Oct 2004 00:13:01 -0400

Wouldn't this work?

HDR(A,0,0), SAi1, KEi, Ni ->
                                            <-- HDR(A,0,0), N(COOKIE)
HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni ->
                                             <-- HDR(A,0,0), 
N(INVALID_KE_PAYLOAD)
The responder could be still stateless (although it does not need to be) 
to keep things simple!
HDR(A,0,0), N(COOKIE), SAi1, KEi', Ni ->
                                             <-- HDR(A,B,0), SAr1, KEr, 
Nr, [CERTREQ]

I think mess-ID MUST be zero and exch_type = IKE_SA_INIT.

(Sec 2.2. The IKE_SA initial setup messages will always be numbered 0 and 1)

If an implementation chooses to include KEi in "cookie" computation, the 
initiator would have to start all over, i.e., without N(COOKIE).  
Starting all over might not be such a bad idea, because we can't assume 
that an implementation won't do that.

cheers,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 Oct 2004 13:36:29 +0300

> I feel that Initiator need to choose message id 1 in transaction 3.

But the setion 2.2 says that IKE_SA initial setup message will always
be number 0 and 1, and in your case the IKE_AUTH coming after the 3rd
transaction would have message id 2....

> might return the previous response as message id is same.

Yes, that happens unless, it understand this case separately.

> If the responder chooses not to create the state in transaction 2,
> it would be treating message ID 0 as new transaction and that would
> work.

In that case it would need to send new N(COOKIE) too, as in my
example. Otherwise it would not know that this is node that has talked
to him before.

> Since, initiator would not know the behaviour of the responder, it
> is better if Initiator chooses new message ID for transaction 3.

If the responder allocated SPI-R (B) then it means that it has created
state, and if the responder is still using SPI-R of 0, as in N(COOKIE)
exchange, then it knows that the other end has not created any state
yet.

One (not so good) option would also be that in the INVALID_KE_PAYLOAD
case the initiator MUST select new SPI-I, i.e. instead of A it would
use A', i.e. start new negotiation, and the responder will simply
consider the N(INVALID_KE_PAYLOAD) as an error, and refuse to process
any further messages to the SA.

I.e. the normal INVALID_KE_PAYLOAD exchance without cookies would go: 

1. HDR(A,0,0) SAi1, KEi, Ni --->
		    <--- HDR(A,X,0) N(INVALID_KE_PAYLOAD)
2. HDR(A',0,0) SAi1, KEi(new), Ni --->
		    <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ]

and combined with cookies it would be:

1. HDR(A,0,0) SAi1, KEi, Ni --->
		    <--- HDR(A,0,0) N(COOKIE)
2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni --->
		    <--- HDR(A,X,0) N(INVALID_KE_PAYLOAD)
3. HDR(A',0,0) SAi1, KEi(new), Ni --->
		    <--- HDR(A',0,0) N(COOKIE2)
4. HDR(A',0,0) N(COOKIE2), SAi1, KEi(new), Ni --->
		    <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ]

Note, that we need second cookie exchange, as the SPI-I has changed,
thus the cookie given in the first step does not work for the A'.

Note, that I used SPI-R of X in the N(INVALID_KE_PAYLOAD) error, as I
do not know if we need to use 0 or allocate something there.

The first packets before SPI-R is allocated by the responder and
before the initiator also starts using that, must use different
retransmission and window rules anyways. I.e. we must check if the
SPI-R is 0, and if so we must use the whole packet to detect
retranmissions. So our retranmission policy needs to be so that if the
packet is exactly same than previous time, we can retransmit our old
packet back. If it is changed then we need to process it again (it
might be new negotiation from some one else simply using the same
SPI-I than the previous user).

The responder could optimize things a little bit, by processing the
SAi1 already in the first step, i.e.

1. HDR(A,0,0) SAi1, KEi, Ni --->
		    <--- HDR(A,0,0) N(COOKIE), N(INVALID_KE_PAYLOAD)
2. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni --->
		    <--- HDR(A,B,0) SAr1, KEr, Nr, [CERTREQ]

but this would open the responder to the DoS attacks as it now needs
to do something more complicated than only request cookie for the
first packet.

Actually the whole error handling in the first packet is not really
defined well. The 2.21 does not mention anything about that. I would
say the best option is that if anything goes wrong when processing the
first IKE_SA_INIT packet from initiator, we simply return packet with
zero SPI-R cookie, and containing the error notification(s), and then
responder simply deletes all information about the actual exchange.

It can use global retransmission system retransmitting exactly same
reply back if it receives exactly same request, but nothing more.

If the message is different than previous one, we must always process
it, just like any new message. Initiator should keep the SPI-I same
all the time as otherwise the N(COOKIE) payloads do not match. Also
the exchange fails only after it times out, not because of
unauthenticated notifications.

I.e:

1. HDR(A,0,0) SAi1, KEi, Ni --->
	(lost)	<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
2. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit)
		<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
   (initiator decides to ignore the error message as it is unprotected)
3. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit)
		<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
4. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit)
		<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
5. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit)
		<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
6. Initiator gives up, as the other end does not reply.

or

1. HDR(A,0,0) SAi1, KEi, Ni ---> (bit error, or attacker modifying the
				  packet in transit causing invalid syntax)
		<--- HDR(A,0,0) N(INVALID_SYNTAX)
2. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit)
		<--- HDR(A,0,0) SAr1, KEr, Nr, [CERTREQ]
  (exchange continues)

or

1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3)
		<--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2)
2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag)
		<--- HDR(A,0,0) SAr1, KEr, Nr, [CERTREQ] (major=2)
  (exchange continues)

or

1. HDR(A,0,0) SAi1, KEi, Ni --->
		<--- HDR(A,0,0) N(COOKIE)
2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie)
		<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
   (initiator decides to ignore the error message as it is unprotected)
3. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit)
		<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
4. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit)
		<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
5. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit)
		<--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN)
6. Initiator gives up, as the other end does not reply.

or

1. HDR(A,0,0) SAi1, KEi, Ni --->
		<--- HDR(A,0,0) N(COOKIE)
2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie)
		<--- HDR(A,0,0) N(INVALID_KE_PAYLOAD)
   (initiator notices, that it has wrong KEi, changes it to new, still
    keeps cookie, as this is simply retransmission of packet)
3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit)
		<--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ]
   (exchange continues)

or

1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3)
		<--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2)
2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag)
		<--- HDR(A,0,0) N(COOKIE) (major=2)
2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie,
					     major=2, version flag set)
		<--- HDR(A,0,0) N(INVALID_KE_PAYLOAD) (major=2)
   (initiator notices, that it has wrong KEi, changes it to new, still
    keeps cookie, as this is simply retransmission of packet)
3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit, major=2,
						  version flag set))
		<--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ] (major=2)
   (exchange continues)

or the last one optimized:

1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3)
		<--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2)
2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag)
		<--- HDR(A,0,0) N(COOKIE),N(INVALID_KE_PAYLOAD) (major=2)
2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> 
   (initiator notices, that it has wrong KEi, changes it to new, still
    keeps cookie and major = 2, as this is simply retransmission of packet)
3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit, major=2,
						  version flag set))
		<--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ] (major=2)
   (exchange continues)

So the error handling for the first packet would be:

	If responder detects any error when processing the initiators
	IKE_SA_INIT packet, it does not allocate any state, it simply
	returns error message having same SPI-I, SPI-R and message id
	fields (i.e. SPI-R and message id will be 0). The message
	contents will be the error notification(s) about the error
	(COOKIE, NO_PROPOSAL_CHOSEN, INVALID_MAJOR_VERSION,
	INVALID_KE_PAYLOAD etc).

	When initiator gets an error notification back from the
	responder if the notification gives any indication how to fix
	the situation (COOKIE -- add N(COOKIE) to request;
	INVALID_KE_PAYLOAD -- change KEi payload to use requested
	group; INVALID_MAJOR_VERSION -- fall back to lower version
	etc), then it should act accordingly and retransmit its packet
	using same SPI-I and message id. It might need to fix it's
	packet multiple times to get it right (i.e. first fall back to
	older version, then add N(COOKIE), then in addition to those
	already done change the group to different etc).

	It SHOULD not fail the negotation based on the unauthenticated
	notification.  The negotiation will fail only after it times
	out. 

	Responder SHOULD keep a retransmit packet buffer for incoming
	first packets, but it can only retransmit its reply to the
	initiator if the packet contents sent by the initiator is
	exactly same as what was in the packet which generated that
	reply. Responder MUST also check the source and destination
	IP-addresses and ports when checking if the packet is same. If
	the IP-addresses or ports are changed responder needs to
	process the packet again, instead of using the stored reply.
	This is because the contents of NAT_DETECTION_*_IP
	notifications will change if the IP-addresses or ports
	changes, thus the reply will not be same. When the initiator
	changes the packet, the responder needs to process the packet
	again (it might succeed now, or generate new different error
	notification(s)).
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 Oct 2004 13:49:44 +0300

> Wouldn't this work?

It would, and as you can see from my second email, this is something I
actually proposed to be probably the best way to go.

> initiator would have to start all over, i.e., without N(COOKIE).

Or actually in that case the responder would send new N(COOKIE) after
the KE changed, and the initiator would need to update to using that
new cookie. 

> that an implementation won't do that.

When you start over you will need to do new cookie exchange every
time, as the SPI-I is going to be included in the cookie. 
-- 
[email-masked]

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Sun, 10 Oct 2004 18:43:46 -0700

Hi,
     
 Message ID:  I also noticed the statement 'The IKE_SA initial setup messages will
   always be numbered 0 and 1'.   I think, these are values if there are no errors
   in leading to SA establishment. I am hoping that, no implementation would reject
   the initial exchanges if the message IDs are not numbered 0 and 1. Actually, in EAP
   case, the message IDs go beyond 1, before it completes AUTH exchange.

There are some errors and indications which can be corrected by the IKE
automatically and there are other type of errors, which require changes by
the administartor.  In the later case, I feel, there is no need to maintain the state.
For example, NO_PROPOSAL_CHOSEN kind of errors can only be corrected
by changes to the policy configuration. Any new IKE transaction starts with new 
SPI value and message ID as 0. Here, there is no problem of DoS attack, as the
attacker has to guess the new SPI and that is difficult for an attacker to do that kind
of guessing.

In the case of errors, which can be corrected automatically, such as
INVALID_KE_PAYLOAD, I guess different intrepreations are possible due to
no explicit descripton in the IKEv2 draft.  Whichever is the solution should be
interoperable and should not lead to simple DoS attacks.  You are indicating 
one solution ie if responder chooses SPI value, then the responder is maintaining
the state and if is is zero, responder does not maintain the state. 

To protect against DoS attacks, I feel that, if the responder is not maintaing the
state (it indicates by keeping the responder SPI to 0), then the initiator should
start the transaction with new initiator SPI value.  If the Initiator chooses the same
SPI value, it becomes easier for an attacker to send error notification, if the attacker
is intelligently records the previous initiator SPI.

Keeping the above issues and interoperability issues in mind, following behaviour at
the Initiator side, I feel, would work fine in all cases (This suggestion is similar to one of suggestions
you made)

* Initiator should send  the IKE_SA_INIT exchange with new SPI and
     message ID 0, when the response message contains error indication.

Note: Retransmision case is different. In retransmission case, either request is missed or
response is missed. In that case, the initiator would repeat the same request as is. I would
assume, implementations, to simplify the complexiy would divide the retransmission logic
from the main IKE state machine. Retransmission would be taken care of retransmission 
logic.  

* Responder need not generate its SPI, when it sends error notification as part of 
   IKE_SA_INIT response.

With this, combined logic of COOKIE and INVALID_KE_PAYLOAD appear like this
 on the wire.

     <--- HDR(A',X,0) N(INVALID_KE_PAYLOAD)

Even though above example is given with INVALID_KE_PAYLOAD, it is applicable for
other messages such as NO_PROPOSAL_CHOSEN. For example, it will appear like this.

1. HDR(A,0,0) SAi1, KEi, Ni --->
     <--- HDR(A,0,0) N(COOKIE)
2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni --->
     <--- HDR(A,X,0) N(NO_PROPOSAL_CHOSEN)
Proposals in the policies are corrected.
3. HDR(A',0,0) SAi1, KEi, Ni --->
     <--- HDR(A',0,0) N(COOKIE2)
4. HDR(A',0,0) N(COOKIE2), SAi1, KEi, Ni --->
     <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ]

In my opinion, Initiator can even generate new SPI value in transaction 2 ie while sending
IKE_SA_INIT request with N(COOKIE). With this, even if the attacker 
records INIT_SA_RESPONSE with N(COOKIE)and replays the same, the exchange
does not succeed.  
Srini
Intoto Inc.
www.intoto.com

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Oct 2004 14:47:03 +0300

>    case, the message IDs go beyond 1, before it completes AUTH exchange.

For the EAP case, I think it is quite clear that additional IKE_AUTH
exchanges have new message IDs. For the IKE_SA_INIT, I think the
protocol is simplier if we always assume that the message id is 0, and
the responder does not store any state before it can successfully
reply to the IKE_SA_INIT packet. 

> attacker has to guess the new SPI and that is difficult for an attacker to do that kind

How does now SPIi protect against DoS attacks? If he can see the first
packet having SPIi in it, he can se the new SPIi too. If he cannot see
any traffic he needs to guess the right SPIi in any case and the attack
cost remains about same.

> the state and if is is zero, responder does not maintain the state. 

Actually I think it is better that responder never keeps state in that
case, it simply returns error and forgets the exchange. The initiator
will then fix the problem and try again (and he can and should use
same SPIi as the responder have forgotten the previous packet, so there
is no reason why not to use old SPIi, using old SPIi keeps the cookies
valid in case cookie exchange was needed). 

> is intelligently records the previous initiator SPI.

If the attacker can see the first exchange, he can also see the next
exchange, thus no point of changing SPIi there. I do not think the
change of SPIi will really get you any protection against DoS, but it
will cost you several round trips again, as you need to do cookie
exchange again for each new modification because of the new SPIi. It
also makes the N(COOKIE) notification a special case where the
initiator MUST keep the same SPIi. So easiest way to implement it is
to say that the SPIi stays same as long as the initiator continues
trying, and responder will forget the packet immediately if it
returned error for it (COOKIE, INVALID_KE_PAYLOAD,
INVALID_MAJOR_VERSION etc). 

>      message ID 0, when the response message contains error indication.

That will not work for the N(COOKIE) error notification, as it is
already explained in the draft and it mandates that you keep the SPIi
same. 

> * Responder need not generate its SPI, when it sends error notification as part of 

I would say responder MUST NOT generate its SPI when it sending error
notifications as part of IKE_SA_INIT response. That would be
consistent with the N(COOKIE) error, i.e. the N(COOKIE) would not be a
special case, but just using same rules as other errors.

There is no benefit for initiator to change SPIi, or responder to
allocate SPIr in error cases, but for N(COOKIE) error we cannot change
SPIi and we cannot allocate SPIr, so lets keep the processing same for
all error messages including N(COOKIE). 

>      <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ]

This will add one extra round trip, one extra half-open SA in the
responder end (the one returning INVALID_KE_PAYLOAD), which need to be
timed out and so one. Not very clean solution. 

>      <--- HDR(A,X,0) N(NO_PROPOSAL_CHOSEN)

We cannot accept the NO_PROPOSAL_CHOSEN directly, as it would open DoS
attack by just sending one packet. We need to keep on sending until
the initiator times out. After that we will of course start new
negitation using differnt SPIi, as the old one has already failed. 

> records INIT_SA_RESPONSE with N(COOKIE)and replays the same, the exchange

If initiator will genreate new SPIi, then responder will send new
N(COOKIE) back again, as the old one does not match (it contains SPIi
in it). The initiator will detect that the replayed IKE_SA_INIT
response do not give any new information how to continue processing
the message, so it will simply continue sending the last packet it has
sent out (having the N(COOKIE)) until the other end responds. If the
attacker send fake N(FAKECOOKIE) notification back before the
responder sends its iwn N(COOKIE) then the initiator will first try
with N(FAKECOOKIE) and when it gets the real N(COOKIE) exchange, it
notices that ok, this changes state again, so it will send new packet
with N(COOKIE) and the responder will only continue with the proper
N(COOKIE) exchange:

Initiator		Attacker		Responder
1. HDR(A,0,0) SAi1, KEi, Ni --->
2.		   <--- HDR(A,0,0) N(FAKECOOKIE)
						Responder gets the 1.
						packet and replies
3.						<--- HDR(A,0,0) N(COOKIE)
   Initiator replies using attackers cookie
4. HDR(A,0,0) N(FAKECOOKIE), SAi1, KEi, Ni --->
						Responder will either
						ignore the message
						with wrong cookie, or
						reply with similar
						message than in 3,
						i.e. sends the right
						cookie.
   Initiator gets the real cookie from responder
   notices it is different, and replies with that
5. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni --->
			Attacker tries to confuse
			things more, and sends new
			N(FAKECOOKIE) message
6.		   <--- HDR(A,0,0) N(FAKECOOKIE)
   Initiator sees again different cookie, and tries
   with that.
7. HDR(A,0,0) N(FAKECOOKIE), SAi1, KEi, Ni --->
						In the mean while the
						responder gets the
						packet sent in 5, and
						notices that the
						cookie is valid and
						replies with his
						message
8.						<--- HDR(A,B,0) SAr1,
						     KEr, Nr
						When initiator gets
						packet sent in step 7
						it either ignores it
						or replies with
						message 3, with right
						cookie.
   When initiator gets the message 8
   it moves to the IKE_AUTH phase, and after
   that it may ignore all IKE_SA_INIT messages.
   If it wants to protect from all DoS attacks
   it still continues looking for IKE_AUTH messages
   and it will move to the IKE_AUTH phase for each
   valid IKE_SA_INIT message it gets, and tries to
   finish them all. When one of those IKE_AUTH
   exchanges finishes, all other half open IKE SAs
   with same SPI-i A are deleted. If we continue
   example here.
			Attacker decides he wants
			to cause even more problems
			and sends 2 more valid
			looking IKE_SA_INIT replies.
9.		   <--- HDR(A,X,0) SAr1', KEr', Nr'
10.		   <--- HDR(A,Y,0) SAr1'', KEr'', Nr''
   Initiator will process them all, and
   start IKE_AUTH for all of them. All of the
   packets are encrypted with different key, and MAC'ed
   with different key. Each of those require a separate
   Diffie-Hellman, as the KEr, KEr', KEr'' received
   from other end are different. 
11. HDR(A,B,1) SK1{IDi,AUTH,SAi2,TSi,TSr} --->
12. HDR(A,X,1) SK2{IDi,AUTH,SAi2,TSi,TSr} --->
13. HDR(A,Y,1) SK3{IDi,AUTH,SAi2,TSi,TSr} --->
			Attacker cannot reply
			to any of those as it does
			not know how to generate
			valid AUTH paylod for reply
			packet. He do know
			how to generate valid MAC
			and how to encrypt the packet,
			but he cannot authenticate
			himself.
						Responder will
						ignore unknown SPIr
						values X and Y, and
						reply to the SPIr B.
14.						<--- HDR(A,B,1)
						     SK1{IDr, AUTH,
						     SAr2, TSi, TSr}
   Initiator receives the valid packet
   authenticating the IKE SA, and deletes
   IKE SA (A,X) and (A,Y), at the same time
   when it marks (A,B) as finished. 
-- 
[email-masked]

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Tue, 19 Oct 2004 11:29:21 -0700

I guess this should work. I guess similar logic need to be done on receiver end too as
MITM can spoof  AUTH request and send to the receiver
for the purpose of DoSing the negotiation between
security gateways. 

Srini
Intoto Inc.
www.intoto.com