Date: Fri, 8 Jun 2001 09:37:15 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: <freebsd-net@FreeBSD.ORG>, <freebsd-arch@FreeBSD.ORG> Subject: Re: New TCP sequence number generation algorithm; review needed Message-ID: <20010608080013.F93237-100000@achilles.silby.com> In-Reply-To: <3B20A02E.B1507A80@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Jun 2001, Terry Lambert wrote:
> OK, I read the code. Not to poop the party, but off the top
> of my head, I have several major objections:
>
> 1) You stole the space reserved for the cache status
> flags; calling it 'tao_flags' would have been more
> honest.
rmx_filler still has extra space in it, there's no problem fitting in
tao_flags when and if it becomes used.
> 2) This doesn't work right for cloned routes.
On the contrary, it only works for cloned routes.
> 3) This blows up if you delete and re-add the default
> route, and the route in question is a clone of the
> default.
Yes, this will cause the cloned route to get blown away, and the ISN
reset. This is only a minor issue, and can be ignored unless a host sees
frequent route changes. Even if the cloned route is blown away
frequently, this will simply cause the algorithm to revert to totally
random ISNs, which isn't the end of the world.
Can anyone who's familiar with FreeBSD boxes which serve as routers
confirm how route changes affect their cloned routes?
> 4) Your claim of "extra space" comes because you
> are allocating these things with a cruddy
> allocator; some of us aren't wasting the same
> space in our kernel that the rest of you are,
> and don't intend for that practice to continue
> for the rest of you very much longer.
I fail to see how basing a patch for FreeBSD on FreeBSD is a strike
against it. If you have a new route table, please post information about
it so that we can all see how it wll affect this patch and others.
> 5) This blows up for keepalive packet sends, which
> use preallocated tcptemplate structures, which
> get a copy of the first header in when setting
> up a connection; check the keepalive sequence
> numbers using your new scheme...
Why would changing ISN generation affect keepalive packets? I haven't
changed how connection setup works whatsoever.
> 6) This adds per-connection state, which is evil
> when you want a lot of connections: the way to
> get a lot of connections is to remove as much
> per-connection state as possible, which in turn
> reduces your per-connection resource costs, and
> that in turn increases the number of connections
> you are capable of sustaining with a constant
> set of resources.
This patch doesn't add per-connection state. The additional 16 bits added
to the route structure were already present as unused space.
> 7) The "monotonicity in TIME_WAIT" problem you mention
> is not really a problem. It is the 2*MSL value of
> 30 seconds and a tcp_timer that controls that; the
> sequence number is irrelevent (if you can prove
> your claim of "funky" in a bit more detail than
> simply calling it that, I would be willing to
> withdraw this objection; but I think the other six
> stand on ther own, still).
Go read RFC 793, or this chunk of code from tcp_input.c:
/*
* If a new connection request is received
* while in TIME_WAIT, drop the old connection
* and start over if the sequence numbers
* are above the previous ones.
*/
if (thflags & TH_SYN &&
tp->t_state == TCPS_TIME_WAIT &&
SEQ_GT(th->th_seq, tp->rcv_nxt)) {
iss = tcp_next_isn(taop);
tp = tcp_close(tp);
goto findpcb;
}
I didn't create this behavior; it's been part of *BSD for a very long
time. We must respect it, as we cannot change it now.
> I'm sure anyone with an "IP failover" or "IP takeover"
> product could probably come up with several other major
> objections; I don't know if anyone has implemented NECP
> sevices on FreeBSD, or "Direct Server Return" switch
> hacking of packets with Apache on FreeBSD cooperation,
> but I would be surprised if people who have would not
> also have objections.
Any package that depended on predictable sequence numbers would've broken
twice in the last 9 months already. If there were any complaints at those
times, they didn't appear on the lists, and didn't lead to the ISN
generation being changed then. If you're in one of the above classes of
people, I'd like to hear from you to better understand the issue; the NECP
RFC draft didn't appear to have any information on this topic, as far as I
could tell.
Mike "Silby" Silbersack
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010608080013.F93237-100000>