Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Wed, 26 Feb 2003 14:39:42 +0200

Only comments about the last part of Brian's mail...

	snip...

> > 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...
> 
> Simply generating a unique VT for each association (and init 
> attempt) can
> resolve this without walking an address list to find the association.

	"Simply generating a unique VT for each association" might not be that easy either...

	I'm just guessing here... I'm just exposing an idea... don't blame me... :-)

	Since you cannot keep any information upon sending the INIT ACK, obviously you don't have any list of "used VTs"...

	Then I suppose that your VT generator takes some kind of counter as its seed, and uses and algorithm that given a 32 bit number (or less), produces another "random" 32 bit number, which is not produced by any other different number taken as the seed, i.e., two different seeds produce two different VTs... So the VTs are only unique if the used seeds are different...

	You have to keep somehow the state of which seeds have been used. And you have to do it in a way so this state doesn't use more memory than a fixed maximum (and small) quantity, no matter how many (and which) seeds are in use. The only easy way I can think about now, is a simple counter... :-/ If this is the case, won't this make easier for the attacker to guess your "rule" of producing VTs? That rule is reversible, so... I'm just thinking in loud voice...

	And I suppose that the way you assure that all those VTs are unique, is the fact that 2^32 is a very big number and you won't wrap it... Establishing an association every 10 ms will give you about one year and a half... One association every millisecond gives you less than two months... This numbers might be acceptable, especially taking into account that the associations shouldn't last long, but I don't know... :-/

	After that time you cannot be sure that your VTs are unique... Unless, of course, all my suppositions were wrong... :-/

	BR Iván Arias Rodríguez

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Feb 2003 06:23:44 -0700

Ivan.Arias-Rodriguez,

On Wed, 26 Feb 2003, [email-masked] wrote:

> 	Since you cannot keep any information upon sending the INIT ACK,
> 	obviously you don't have any list of "used VTs"...
> 
> 	Then I suppose that your VT generator takes some kind of counter as
> 	its seed, and uses and algorithm that given a 32 bit number (or less),
> 	produces another "random" 32 bit number, which is not produced by any
> 	other different number taken as the seed, i.e., two different seeds
> 	produce two different VTs... So the VTs are only unique if the used
> 	seeds are different...
> 
> 	You have to keep somehow the state of which seeds have been used. And
> 	you have to do it in a way so this state doesn't use more memory than
> 	a fixed maximum (and small) quantity, no matter how many (and which)
> 	seeds are in use. The only easy way I can think about now, is a simple
> 	counter... :-/ If this is the case, won't this make easier for the
> 	attacker to guess your "rule" of producing VTs? That rule is
> 	reversible, so... I'm just thinking in loud voice...
> 
> 	And I suppose that the way you assure that all those VTs are unique,
> 	is the fact that 2^32 is a very big number and you won't wrap it...
> 	Establishing an association every 10 ms will give you about one year
> 	and a half... One association every millisecond gives you less than
> 	two months... This numbers might be acceptable, especially taking into
> 	account that the associations shouldn't last long, but I don't know...
> 	:-/
> 
> 	After that time you cannot be sure that your VTs are unique... Unless,
> 	of course, all my suppositions were wrong... :-/
> 
> 	BR Iván Arias Rodríguez

It is not necessary to guarantee that the VT is unique for each association to
avoid walking an address list, just that the VT and port pair are unique.
I use the same MD4 swirled entropy pool that Linux TCP uses to assign secure
TCP initial segment numbers with the port pair source and destination address
of the INIT packet hashed into the random number.  Lookups by vtag also check
port pair.  The probability of a duplicate on the same port pair is impossible
for dynamic port allocation (as discussed in previous note) and is so slim on
static port allocations that cosmic rays will mess things up first.

The worst that could happen is that if two associations ever happen to be
formed for the same statically allocated port pair, once in a blue moon the pair
could get the same vtag for both and both associations would abort.  But
applications which statically assign both local and remote port are rare in
themselves.

There is even a way around this rarity.  When the COOKIE-ECHO is received,
the vtag is placed in the established hashes.  If the vtag matches an existing
tag in the hashes, the association can be refused and the peer forced to send
another INIT which will select a different vtag.

That would limit the vulnerability of a duplicate to once in a blue moon made
out of green cheese with pigs flying on it and only if the implementation is
ever used for multiple associations using the same static port pair assignment.

Hardly worth considering.

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