Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Mon, 10 Mar 2003 15:17:27 +0200

Brian,

> 
> Randall,
> 
> Here's what I doing differently (but I still think that you owe
> me and the OpenSS7 implementation an apology):
> 
> When sending the INIT-ACK the implementation is choosing a new
> verification tag instead of using the verification tag of the
> existing TCB.  But the implementation also follows the RFC in
> that the INIT-ACK is sent back to the source of the INIT.  If

	Yes, this is what the RFC says, but it has been changed by the IG.

> the VT from the TCB was sent, it would be handed to the attacker
> (in the initiate tag rather than tie-tags).  The OpenSS7
> implementation sacrifices the collision case (rare) to protect
> all other association initializations.

	Just because of this it is why section 5.2 has been modified...

> The IG is not normative.  This is why I asked on tsvwg why it
> had not been advanced.  There are many clauses in the IG that
> are clarifications and interpretations of RFC 2960 and can be
> implemented without the IG being normative, but 2.6 is not one
> of them.  RFC 2960 tells me that I MUST send the INIT-ACK back
> to the source of the INIT.

	Since we detected this problem, that's why it was modified.

> To follow 2.6 I need to find the existing TCB to use the VT from
> the TCB in the initiate tag of the INIT-ACK and send the
> INIT-ACK to C instead of D.  But this still does not justify the
> statement in 2.18, because it is only necessary to consider the
> source address list in the INIT iff there exists one or more
> TCBs for the port pair and local address, and iff one ore more
> of those TCBs is in the COOKIE-WAIT state, (i.e. only if a
> collision indeed can exist).  It is certainly not necessary to
> consider and arbitrarily long and suspect source address list on
> all INITs, or even on INITs where there is no TCB for the port
> pair and destination address, or even on INITs where there is no
> TCB for the port pair and destination address in the COOKIE-WAIT
> state.  To consider an arbitrarily long and suspect source
> address list on all INITs would open an implementation up to
> DoS attacks with long source address lists.

	This is perfectly reasonable. You don't really need to take a look first to the address and then to the ports. You can do it as you like...

	You are right that if there isn't an open association whose source/destination ports match those of the INIT, not matter how deep you dig inside the address parameters, the INIT will never belong to any of the existing associations.

	But the text in section 2.18 doesn't say that you have to check the addresses anyway. It tells you that the addresses inside the parameters are as valid as the source address to identify the association. In other words, if you are checking the source address of the INIT (I guess that if you do that that's because either you check first the addresses -which I would say it is not the wiser thing to do-, or because you have already found a matching port pair), don't stop there and also use the addresses inside.

> So I still think that the new paragraph D) in IG 2.18 is
> unwarranted.  It is OK to let implementations search how they
> will as long as they meet the other requirements.

	I think there could be a change. So far we were thinking about something similar to:

   D) An INIT or INIT ACK chunk MUST be treated as belonging
      to an already established association (or one in the
      process of being established) if the use of any of the
      valid address parameters contained within the chunk
      would identify an existing TCB.

> I will illustrate the need for the "extra" COOKIE-ECHO to limit
> a DoS attack for the INIT-ACK case to address Caitlin's example
> in a separate mail.
> 
> I will also address in a separate mail the new text for section
> 5.2.1 in section 2.6.  There, I believe that it is unnecessary
> for the receiver of an INIT to reject it just because it includes
> new addresses when the packet source address of the INIT is one
> of the existing addresses of the TCB.  Also, that to not send an
> INIT-ACK again opens a DoS attack (where the existing TCB in the
> COOKIE-ECHOED state is for an association to a malicous endpoint).
> 
> Please consider that--just maybe--I know what I'm talking about
> (yes, I can right sometimes ;), and please skip the attacks and
> innuendos on both myself and the OpenSS7 implementations.
> 
> --brian

	Ok, so now finally agree that not checking the address parameters can make that the peer is not "able to establish associations in certain circumstances", as section 2.18.3 says.

	And now let's see about those problems/improvements...

	By the way. I perfectly know that you know what you are talking about. That's why I have completely read everything you have written in your mails...

	It is just the way you talk sometimes what I don't like... :-/

	BR Iván Arias Rodríguez

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 10 Mar 2003 07:45:24 -0600

Hi again Ivan :>

>	Since we detected this problem, that's why it was modified.
Exactly.. and eventually when we close out the IG it will become the
replacement text for the current text in RFC2960... :>

>      would identify an existing TCB.

This, I think is a very nice wording.. it says the same thing but a bit 
more
specific :>

>	Ok, so now finally agree that not checking the address parameters can make that the peer is not "able to establish associations in certain circumstances", as section 2.18.3 says.
Well, this is progress..

>	It is just the way you talk sometimes what I don't like... :-/
I doubly agree :>

R

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Mar 2003 12:47:53 -0700

Ivan,

I don't know that I agree with 2.6 yet...

Consider your last case.  If Interface C is unreachable
from A, and following 2.6 and sending the INIT-ACK to C
instead of D, the association will fail to form.

INIT A:1000->C:1000              INIT D:1000->A:1000
----------------------\     /-----------------------
                       \   /
                        \ /
                        / \
                       /   \        C unreachable
<---------------------/     \--------------X

INIT-ACK A:1000->C:1000             C unreachable
------------------------------------------>X

Following RFC 2960, the association would form regardless
of whether C was reachable from A.

INIT A:1000->C:1000              INIT D:1000->A:1000
----------------------\     /-----------------------
                       \   /
                        \ /
                        / \
                       /   \        C unreachable
<---------------------/     \--------------X

INIT-ACK A:1000->D:1000                    
---------------------------------------------------->
                           COOKIE-ECHO D:1000->A:1000
<----------------------------------------------------
COOKIE-ACK A:1000->D:1000
---------------------------------------------------->

Section 2.6 appears to sacrifice reliability in the INIT
process by treating all interfaces except the interface
that A has sent an INIT to as though they were an attacker.

Is it the intention of 2.6 to sacrifice this collision case
if interface C is temporarily unreachable?

Our current implementation does not sacrifice this case
(or the case where C is reachable) if D is supplied to
connect().  The current implementation sacrifices the cases
where D is not supplied to connect().

For applications that can have a knowledge of D (e.g. from
DNS lookup or static assignment) and requires a reliable
INIT process our current implementation is superior to
IG 2.6.  Where the application has no knowledge of D and
does not care about a reliable INIT process, 2.6 is superior
to our current implementation.

Is this not a tradeoff that depends on the application?

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦