Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Tue, 11 Mar 2003 17:25:26 +0200

Brian, Randall,

	I made a mistake in my earlier response...

	... snip...

> >Here is a reverse hijack:
> >
> >Host A/B                                       Host X   Host C
> >  |                                               |        |
> >  |INIT A:1000 -> X:1000                          |        |
> >  |---------------------------------------------->|        |
> >  |TCB1:                                          |        |
> >  |VT: X                                          |        |
> >  |PT: 0                                          |        |
> >  |Loc: A:1000                                    |        |
> >  |Rem: X:1000                                    |        |
> >  |State: COOKIE-WAIT                             |        |
> >  |                                               |        |
> >  |                  INIT-ACK X:1000 -> A:1000 (C)|        |
> >  |<----------------------------------------------|        |
> >  |(TCB1 is found)                                |        |
> >  |                                               |        |
> >  |COOKIE-ECHO A:1000->X:1000                     |        |
> >  |---------------------------------------------->|        |
> >  |TCB1:                                          |        |
> >  |VT: X                                          |        |
> >  |PT: W                                          |        |
> >  |Loc: A:1000                                    |        |
> >  |Rem: X:1000, C:1000                            |        |
> >  |State: COOKIE-ECHOED                           |        |
> >  |                                  X does not   |        |
> >  |                                  send (or delays)      |
> >  |                                  COOKIE-ACK   |        |
> >
> 
> So the association is not fully formed and you are in
> COOKIE-ECHOED state.. not established...

	This was my mistake... Alright, it is in the COOKIE ECHOED state...

> >  |                                               |        |
> >  |T1-cookie timeout                              |        |
> >  |COOKIE-ECHO A:1000->X:1000                     |        |
> >  |---------------------------------------------->|        |
> >  |                                               |        |
> >  |T1-cookie timeout                              |        |
> >  |COOKIE-ECHO A:1000->X:1000                     |        |
> >  |---------------------------------------------->|        |
> >  |                .                              |        |
> >  |                .                              |        |
> >  |                .                              |        |
> >  |                                               |        |
> >  |                          INIT (IT: Y) C:1000 ->  A:1000|
> >  |<-------------------------------------------------------|
> >  |                                               |        |
> >
> And I believe RFC2960 states:
> "
>    For an endpoint that is in the COOKIE-ECHOED state it MUST populate
>    its Tie-Tags with the Tag information of itself and its peer (see
>    section 5.2.2 for a description of the Tie-Tags).
> "

	By the way, Randall... there is a mistake in the IG, in the Note of the new text for section 5.2.2... It is a cut & paste error. That Note shouldn't include the COOKIE ECHOED state... Most probably this is what confused Brian here...

> >  |INIT-ACK (IT: X, no tie tags)                  |        |
> >  |------------------------------------------------------->|
> >  |                                               |        |
> >  |                           COOKIE-ECHO C:1000 -> A:1000 |
> >  |<-------------------------------------------------------|
> >  |Action B                                       |        |
> >
> So you would have tie-tags... But I still think you would
> end at action B..

	Yes...

> >  |COOKIE-ACK A:1000 -> C:1000                    |        |
> >  |------------------------------------------------------->|
> >  |TCB1                                           |        |
> >  |VT: X                                          |        |
> >  |PT: Y                                          |        |
> >  |Loc: A:1000                                    |        |
> >  |Rem: X:1000, C:1000                            |        |
> >  |State: ESTABLISHED                             |        |
> >  
> >
> And here is where you make a mistake.. and maybe because action-b's
> wording needs some updates.
> 
> When the COOKIE-ECHO arrives and you take Action-B you would
> update your address list with only those addresses in the COOKIE.

	This is what I have always understood... I just rebuild the TCB (not erasing the data but putting it apart), and send a notification to the user... Maybe we should state this in section 5.2.4 (for all the cases?)

> So your association would NOT include X. And of course you
> have two TCB and would need to collapse one of them... this
> again is where possibly having a special "hold" state to see
> who is who may be warrented... but, curently, the way our

	The "old" association (which was never formed but there was a TCB for it) will become the new one... I will take all the information from the cookie and replace the old one...

> implementation works.. the other assocation (the one with
> X) would get aborted at least internally... and the other
> would hold VT's X/Y but the Address X would NOT be
> a part of the association... so if X did send in the
> a message it would be rejected... since X does not belong
> to the association.. no matter if the Vtag is correct or
> not...

	It can forge the source... It could even try to add itself to the association again... forging the A address... However, let me see... No, that's not possible...

	X should send the ASCONF to A using C as its source address. Then, C would receive the ASCONF ACK and it would send an ABORT with the "Association Aborted due to illegal ASCONF-ACK", and the association will crash...

> R
> 
> >X now knows A's verification tag for its association with C.
> >X can know that the association is established with C because
> >COOKIE-ECHOs stop prematurely, or if A does not kick X out of
> >the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will
> >eventually tell X that it is in the established state.  DATA
> >or a HEARTBEAT would also tell X C's verification tag for the
> >association.  Or, if X is not kicked out of the TCB, it could
> >send an INIT and read C's verification tag out of the tie tags
> >in the cookie in the INIT-ACK.

	Well... this I think won't be possible... It should include X, thus, it would be adding addresses... Either it will get an ABORT back (as per the IG), or the INIT ACK will go to C (the other option we have been thinking about)... In any case, it won't get the INIT ACK back...

> >If X is not kicked out of the TCB then one-way
> >eavesdropping is possible.
> >
> >  |                                               |        |
> >  |DATA (VT: Y)                                   |        |
> >  |---------------------------------------------->|------->|
> >  |                                               |        |
> >
> >Even if X is kicked out of the TCB, X knows A's verification tag
> >for the association between A and C.  A simultaneous attack on
> >C could yeild C's verification tag for the association.

	Uff... this will be almost impossible... if not completely... let me think...

	First, you will have to know that both peer want to establish an association, which is not a very big deal though... Then, both Hosts A and C, before connecting each other, should connect you (really, really unrealistic, why would they want to do so if you want to attack them?). After keeping them for a while in the COOKIE ECHOED state, they should try to connect to each other. However, they are already trying to connect to each other (or so they think), so, they will not send any INIT or stuff...

	This case won't be possible...

> >A DoS attack would be to send an ABORT to A with the known VT
> >when the COOKE-ECHO is not received, and start the process again
> >with a new INIT.  This DoS attack has the difference over the
> >previous one that no ERROR message is sent to C.

	But this DOS attack is really unrealistic... It is done by a "friend"... If Host A tries to connect to X that's because A "knows" X...

	I don't know how an attacker could attract you to him, instead of he coming to you...

> >To avoid this problem, INIT received in the COOKIE-ECHO state
> >needs to be treated the same as INIT in the ESTABLISHED state
> >(new verification tag chosen), or COOKIE-WAIT (sent to X or
> >known address of X).  The former is preferrable because it
> >does not cause a new denial of service attack.

	It is really easy to say it... You don't know which other consequences this might have... All the other cases should be taken into account... But this might be worthy to study... however, only if people with expertise in security think that this possibility of attack really makes sense noticing...

> >Closing this latter vulnerability also removes the need to find
> >the existing TCB in the COOKIE-ECHO state based on the source
> >address list, because a new IT is generated and no tie tags
> >populated.

	You should populate the tie tags, thus, you must find the TCB. Otherwise you would receive a Cookie in which the VTs don't match, and the Tie Tags are set to 0, so you would discard it and the association won't come up...

	Thus, doing that (so you avoid checking the address list) precisely is what would make impossible for Host C to establish a legitimate association...

	Since you need to populate the Tie Tags, you need to check the address list...

	But thanks for your efforts... So far I think we (you don't have to include yourself if you don't want) have agreed about some changes in the IG due to your perseverance. At least I can think about:

	a) Should we include the new addresses added in the "new addresses..." cause of error when sending the ABORT as a response to an INIT adding addresses? Should we include the error cause at all? Should we send the ABORT at all? Should we instead send the INIT ACK to *any* of the known addresses?

	b) Should we really apply the "new addresses added" procedure if the INIT comes from a "known address"?

	c) We should make some changes to the explanation of the action to be performed upon receipt of a duplicate COOKIE ECHO. Explaining that the new address should be used, and, at least I remember for the C) case, stating that a COOKIE ACK should be sent back.

	d) The Note at the end of the new text for section 5.2.2 is wrong. It shouldn't include the COOKIE ECHO state.

	...

	BR Iván Arias Rodríguez

> >--brian
> >
> >  
> >
> 
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
> 
> 
>

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 11 Mar 2003 10:00:01 -0600

>	By the way, Randall... there is a mistake in the IG, in the Note of the new text for section 5.2.2... It is a cut & paste error. That Note shouldn't include the COOKIE ECHOED state... Most probably…

Yep.. a cut and paste error.. I will get a fix into the xml for -09

>	This is what I have always understood... I just rebuild the TCB (not erasing the data but putting it apart), and send a notification to the user... Maybe we should state this in section 5.2.4 (for…
Yep.. this is what I am thinking.. it is not clear enough evidently...

>	X should send the ASCONF to A using C as its source address. Then, C would receive the ASCONF ACK and it would send an ABORT with the "Association Aborted due to illegal ASCONF-ACK", and the associ…
M Tuexen and I are going to be working on a Public Key Chunk draft ... 
we think.. we will discuss
it next time we get together..

R