Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Tue, 25 Feb 2003 16:08:39 +0200

Hei!

> Iván,
> 
> But I don't have to look in either the INIT or INIT-ACK to determine
> this.  All I have to do is look in the cookie of the COOKIE-ECHO.

	Why looking in the COOKIE ECHO and not in the INIT directly? Don't you save time if you identify this situation earlier?

> (For the second INIT ACK below, the verification tag gives away
> the establishing association and a second COOKIE-ECHO can be
> avoided without looking at the address list.)

	If you don't pay attention to the addresses inside the first INIT ACK, then you send the COOKIE ECHO and you save in your TCB the information about those addresses. When the second INIT ACK comes, you do the same... Depending how you have coded your implementation, you will either take that second INIT ACK as going to the first association, or to the second... If you take it as going to the first, you will discard it... otherwise you will create another association (still pending the receipt of the COOKIE ACK)...

	I don't see how taking a look to the parameters in the INIT/INIT ACK can hurt... :-/ You will have to do it sooner or later in any case...

	And most probably you can think about more harmful situations...

> So that doesn't really explain the section to me...
> 
> Also the section in the IG implies that associations will fail to be
> formed that would otherwise be formed (not that multiple associations
> will be attempted to be formed and could fail in one way instead of
> another).

	Sometimes you cannot form the association, sometimes you have some other kind of problems... That's why I suggested the change... But that's in the other thread of mails...

	BR Iván Arias Rodríguez

> --brian
> 
> On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote:
> 
> > Hi Ivan,
> >     Thanx for ur reply !!!!  Now i got it.
> > 
> > Regards,
> > Vijay
> > 
> > 
> > -------Original Message-------
> > From: [email-masked]
> > Date: Tuesday, February 25, 2003 10:00:39 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: Matching addresses in INIT and INIT ACK
> > Hi Vijay!
> > See my comment below...
> > > Hi All,
> > > In the sctp imp guide, a new point is added
> > > 
> > > New text: Section 5.1.2
> > > 
> > > D) When searching for a matching TCB upon reception of an INIT
> > > or INIT-ACK chunk the receiver SHOULD use not only the
> > > source address of the packet (containing the INIT or
> > > INIT-ACK) but the receiver SHOULD also use all valid
> > > address parameters contained within the chunk.
> > > 
> > > 
> > > 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...
> > > What will happen if i will not match the addresses, which are 
> > > contained in
> > > the INIT or INIT ACK ?
> > See above.
> > BR Iván Arias Rodríguez
> > > Regards,
> > > Vijay
> > > 
> 
> -- 
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 07:33:20 -0700

Ivan.Arias-Rodriguez,

On Tue, 25 Feb 2003, [email-masked] wrote:

> 	Why looking in the COOKIE ECHO and not in the INIT directly? Don't you
> 	save time if you identify this situation earlier?

Saving time is implementation specific thing.  Time can be saved (and
security improved) by not trusting anything until verified with a cookie.

> 	If you don't pay attention to the addresses inside the first INIT ACK,
> 	then you send the COOKIE ECHO and you save in your TCB the information
> 	about those addresses. When the second INIT ACK comes, you do the
> 	same... Depending how you have coded your implementation, you will
> 	either take that second INIT ACK as going to the first association, or
> 	to the second... If you take it as going to the first, you will
> 	discard it... otherwise you will create another association (still
> 	pending the receipt of the COOKIE ACK)...
> 
> 	I don't see how taking a look to the parameters in the INIT/INIT ACK
> 	can hurt... :-/ You will have to do it sooner or later in any case...
> 

I was considering a resent INIT ACK, because the case you gave is not
possible on our implementation.  (A user cannot establish two associations
in such a manner: the second attempt will be refused and no INIT sent.)

> 	Sometimes you cannot form the association, sometimes you have some
> 	other kind of problems... That's why I suggested the change... But
> 	that's in the other thread of mails...

The thread does not cite a case where an association will not be formed that
would otherwise be formed if the list was examined.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 25 Feb 2003 09:16:32 -0600

>security improved) by not trusting anything until verified with a cookie.
I do not see how putting info you get from a INIT into a COOKIE and then
waiting for the COOKIE to come back to check this same information
improves security? After all it should be the same information, right?

>would otherwise be formed if the list was examined.
Here is one for this thread:
 E-A                                                                     
                E-Z
IP-A/IP-B                                                               
         IP-X/IP-Z

INIT (ipsrc=IP-A,ipdst=IP-X)[IPA/IPB]------------------------>
      <--------------------INIT-ACK(ipsrc=IP-Z, ipdst=IP-A)[IPX,IPZ]---

Now when the INIT-ACK arrives if you solely look at the ipsrc address
you will not find the association since at the time of startup you
did not know IPZ existed.. all you knew about was IPX.

Why would E-Z send a INIT-ACK sourced from IP-X? Well it
could be the prefered route out..

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: Tue, 25 Feb 2003 08:52:58 -0700

Randall,

> improves security? After all it should be the same information, right?

Because the all of the source addresses of an INIT are suspect until
verified.

> could be the prefered route out..

One can use the destination address (IP-A) and port number to find the
association.  As one does not need to look at the source address at all
to find the association, digging in the INIT ACK at this point is a waste
of time.  The association is found using IP-A and port number and then
verified using VT, or it can simply be found with VT and checked for IP-A
and port number (the order makes no difference).  Only once the association
is found and the VT and destination address/port are verified, and the
state of the association is correct for processing an INIT-ACK does the
implementation need to deal with source addresses and lists.

I use VT because it has better hash characteristics and is faster.

Finding the association with source addresses is a waste of time for
INIT-ACKs that will be discarded on VT mismatch or incorrect destination
addresses (the MUST in 5.2 B), and therefore opens up the implementation
to possible attacks (INIT-ACK flooding with long address lists, or out
of range address list parameter lengths).

So in this case, a recommendation to dig the address list before looking
for the association is a poor one.

Do you have another case where you think an association cannot be formed?

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 25 Feb 2003 10:12:30 -0600

>Because the all of the source addresses of an INIT are suspect until
Ok, I can buy that.. but how does this:

---Src-IP-A-----INIT(IPA,IPB,IPC,IPD)--------->Dst-IP-Z
     Dst-IP-A<------------------INIT-ACK(IPZ,IPX,IPQ)----Src-IP-Z
Src-IP-A------------------CookieEcho()------------------>Dst-IP-Z

Make things more secure? You still have the same
information and you still have not verified anything about
IPB,IPC or IPD...

>of time.  The association is found using IP-A and port number and then
So, lets see, if E-A sent out 100 INIT's to different endpoints .. setting
up 100 associations, how can we depend on IP-A and Port to find the
association? Just the IP-A and Port will not cut it.. you need
to look at the source address and port as well.. which means
you must dig through the INIT-ACK to find IP-X...

>and port number (the order makes no difference).  
>
The V-Tag is only an optimization that you happen to be using.. it is
not one of the things that makes a association unqiue.... not by
protocol design.. as I said, one can implement it this way but it
is NOT part of the spec...

>Only once the association
I think you are discussing your particular design details.. which is
specific to your implementation...

>I use VT because it has better hash characteristics and is faster.
And that is fine.. but it is NOT, according to RFC2960, what uniquely
identifies an association....

>of range address list parameter lengths).
I can flood you with INIT-ACK's without long lists and still get the same
effect... For that matter, UDP-Flooding is more effective :-0

>for the association is a poor one.
This is only based on your design and is NOT part of the protocol 
specification.
And in my above example, if you are sending out 100's of INIT's you can
end up in a situation where you can't form the association..  This happened
in several bake-offs...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 10:56:13 -0700

Randall,

> information and you still have not verified anything about

You have verified the hash in the cookie so you know that the
sender of the cookie was the sender of the INIT.

> you must dig through the INIT-ACK to find IP-X...

So use VT.

> is NOT part of the spec...

But don't suppose to me I have to look (or even should) look in the list
when I don't have to and can use more optimal approaches.

> specific to your implementation...

And how associations are found is always implementation specific.  One
does not have to use the source address list, so don't suppose to say
so.

> identifies an association....

RFC2960 does not say that it does NOT identify an association: it just
does not say that it does.  So what?

> effect... For that matter, UDP-Flooding is more effective :-0

If you walk the list to find the association, that is simply not true.

> end up in a situation where you can't form the association..  This happened

Simply generating a unique VT for each association (and init attempt) can
resolve this without walking an address list to find the association.
As this is indeed implementation dependent, I suggest it be left alone.
It should be left completely at the discretion of the implementation.
As long as only one assocation can exist between endpoints, how an
implementation goes about enforcing that is internal to the implementation.

> >Do you have another case where you think an association cannot be formed?

Obviously you don't have a case where one must look in the source address
list to form proper associations, just so that they can be failed in certain
ways in corner cases.

--brian