Subject: RE: Matching addresses in INIT and INIT ACK

From: Caitlin Bestler <[email-masked]>
Date: Sat, 1 Mar 2003 19:33:02 -0600

On 2/25/03, [email-masked] wrote:

>> 
>> I want to ask, is it wrong to match only the address
>> received in IP header ?
>
>Yes, it is... If you don't do that, you could end up
>having open associations that having the same address/port
>as source, also have the same address/port at the
>destination.
>
>Imagine that you have an open association with
>AddrA/PortA... Then I send you an INIT from AddrB/PortA
>which also includes AddrA inside a parameter... If you go
>on with the association establishment, at the end you will
>have that packets coming from AddrA/PortA go either to the
>first or the second association. Depending on how much
>care you have put on this, it could be that an attacker is
>able to abort associations established by others...
>
>Or another example with the INIT ACK. Imagine your user
>tells you to establish an association with AddrA/PortA and
>also with AddrB/PortA, roughly at the same time... But
>then, inside the first INIT ACK you receive, you realize
>that those two addresses belong to the same peer... When
>you receive the second INIT ACK you shouldn't send back
>the COOKIE ECHO but understand that you are basically
>trying to establish the same association twice...
>

I'm in full agreement with the above, but there's a step in
the solution that is still missing.

The scenario, as I understand it, deals with a client that
attempts to create two associations with the same remote
endpoint without realizing that it is the same endpoint:

Host A                                  Host B  == Host C

INIT from A:1000 to B:1000---------------->
INIT form A:1000 to C:1000---------------->
<--------------------------------------INIT-ACK to A:1000
                                        from B|C:1000
<--------------------------------------INIT-ACK to A:1000
                                        from B|C:1000

Am I correct that the point of the clarification is that
despite the different Verfication Tags, the two Init-ACKs
SHOULD be applied to the same TCB. (Actually I'm unclear
as to why that is not a MUST).

What's missing is that the eclipsed TCB needs to be
terminated. The resources should be released promptly,
but more importantly it SHOULD NOT retransmit. Correct?

Caitlin Bestler
http://asomi.com/CaitlinBestler/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 1 Mar 2003 20:09:35 -0700

Caitlin,

> but more importantly it SHOULD NOT retransmit. Correct?

No such thing.  The example as you describe (without other
addresses in the INIT) are two valid associations.

--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 ¦

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sun, 02 Mar 2003 11:36:30 -0600

>>but more importantly it SHOULD NOT retransmit. Correct?
Yes, Caitlin you are completely correct... you are NOT
allowed to have two associations between the same set
of endpoints aka.

Host-A                                                                   
        Host B
IP-A:1000          <-------------------------------------------> IP-B, 
IP-C :1000

Cann only have ONE association between the two endpoints.
And the above scenario where Host-A sends INIT's to IP-B and IP-C
port 1000 would attempt to cause that situation.

I think Brian answers below like he does for the same reason he
answered earlier in this thread on how an association would not
come up (in my and Ivan's example) .. which is he has a very very
specialized stack for IUA/SS7 world. It is REQUIRED to pre-know
all the addresses on each side. Now a stack vendor COULD require
this but it really makes the use of its stack very limited.. In a general
purpose stack, say for HTTP or peer to peer communication within
the internet, one would NOT want to impose this requirement... it
may make sense for the SS7/signalling world.. but not for a general
SCTP stack..

I took a look at Brian's code.. his hashing to tags scheme will
work  due to his requirement i.e. that all of the addresses of both
sides are pre-known.. Very limited IMO and not something I
would want in my stack... But if it meets your requirments thats
fine...

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: Sun, 2 Mar 2003 15:40:31 -0700

Randall,

> >><--------------------------------------INIT-ACK to A:1000

No, I meant that there is nothing the matter with:

Host A                                  Host B  == Host C

Forming two associations as:

A:1000 <--------------------------------------> B:1000

and

A:1000 <--------------------------------------> C:1000

Regardless of whether B and C are on the same endpoint.

Further, if the intention is to form an assocation:

A:1000 <----------------------------------> B:1000
                                            C:1000

There is no need to peer in the INIT in this case.  It is not
until the COOKIE-ECHO is sent that any assocation is fully
formed (no TCB exists).

So, for example, if the first INIT is for A:1000-->B:1000 and
the initiator does not get a response fast enough, it should be
free to send A:1000->C:1000 and get a valid INIT-ACK.

The host receiving the INIT cannot refuse the second INIT,
because to do so would be to maintain state from the first INIT.

Only once it receives a second COOKIE-ECHO for an existing TCB
is it necessary to be careful to establish only one association.
I did not say that it was unnecessary to examine the addresses
in a COOKIE-ECHO.  It is just not necessary in the INIT or
INIT-ACK.

For proper populate of tie-tags in the cookie, it is necessary
to determine if there is an existing TCB when an INIT is
received.  However, there can only be one socket bound to the
local port number for the destination address (be it B or C) so
there is still no need to look in the address list of the INIT
to find the TCB to populate tie-tags.

This is true in general, and is not application-specific.

So, it is not necessary to look in the address list of the
INIT as a general rule, so don't try to tell me I "SHOULD".

The INIT-ACK case can be handled by VT, so don't try to tell
me I "SHOULD" there either.

Thank you.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Mar 2003 06:12:27 -0600

>in a COOKIE-ECHO.  It is just not necessary in the INIT or
I believe Caitlin was talking about the case where the INIT-ACK had
two addresses in it (aka B:1000, C:1000).. The case above, two
seperate endpoints, is correct as well ... different case though
(at least its how I interpreted what Caitlin was getting at.. Caitlin?)

>me I "SHOULD" there either.
If you don't look in the INIT for addresses your VT method only
works if:

A) you can assure that you hand out unique VT's
and
B) you KNOW all the addresses that the peer can give you apriori

Both of the above our true in your implementation..

My point is, for a general implementation that WILL NOT be able
to assrue <B> above, you need to look in the INIT-ACK...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 09:06:38 -0700

Randall,

> (at least its how I interpreted what Caitlin was getting at.. Caitlin?)

Read above, I'm talking of the B + C case.

> to assrue <B> above, you need to look in the INIT-ACK...

You didn't read above.

--brian