Re: Removing T/TCP and replacing it with something simpler
From: Andre Oppermann (andre_at_freebsd.org)
Date: 10/21/04
- Previous message: Garrett Wollman: "Re: Removing T/TCP and replacing it with something simpler"
- In reply to: David O'Brien: "Re: Removing T/TCP and replacing it with something simpler"
- Next in thread: Russell L. Carter: "Re: Removing T/TCP and replacing it with something simpler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 21 Oct 2004 21:03:17 +0200 To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org
David O'Brien wrote:
>
> On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> > Thus after the removal of T/TCP for the reasons above I want to provide
> > a work-alike replacement for T/TCP's functionality:
> ..
> > This different implementation will be disabled by default and clearly
> > marked EXPERIMENTAL in a protocol sense. It will allow the only known
> > user of T/TCP to keep the same functionality with a very small change
> > to his application. It allows interesting new uses primarily in
> > Intranet environment where many short connections are openend in rapid
> > succession (LDAP servers, SQL servers, etc.). The modifications to
> > those programs to use the new option is minimal and requires only the
> > setting of the socket option, one setsockopt() call.
>
> I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any
> proposed RFC work that provides the qualities you want? The advantage
> with T/TCP is that there was a published standard.
Not for TCP. There are plenty of proposed or approved replacements for
TCP though. Implementing or importing them is a lot harder and applications
wanting to use it have to be extensively modified.
The nice thing of my proposed replacement is its simplicity. Submitting
an RFC draft for that is not hard and I'm going to do it based on the
feedback I've got so far. I think we can enough drive behind this to
make it an actual published RFC standard.
Don't worry. I don't want to remove one intrusive piece of code just to
replace it with another one.
-- Andre _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Garrett Wollman: "Re: Removing T/TCP and replacing it with something simpler"
- In reply to: David O'Brien: "Re: Removing T/TCP and replacing it with something simpler"
- Next in thread: Russell L. Carter: "Re: Removing T/TCP and replacing it with something simpler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: Removing T/TCP and replacing it with something simpler
... > proposed RFC work that provides the qualities you want? ... Not for TCP.
... The nice thing of my proposed replacement is its simplicity. ... make it an
actual published RFC standard. ... (freebsd-net) - Re: TCP: a practical question
... I think your referring to a part of the RFC that is attempting to describe ...
passive and active opens. ... Normally TCP connection establishment is a three packet
sequence. ... with real-world attacks from CORE IMPACT. ... (Focus-IDS) - Re: packets with syn/fin vs pf_norm.c
... Packets for TCP with SYN + FIN set are valid under TCP, ... The
only thing that RFC 1644 adds to this is the ability to ... (FreeBSD-Security) - Re: weird scans from port 80
... >>> played by the rules and send the TCP reset packet the standard says you
... >> Pardon me for butting in, but I have a comment about this response. ...
Looking at the number, 793, of this RFC leads me to believe it is ... (comp.os.linux.security) - Re: Firewall question
... Lars is correct per rfc 1912 ... 1536 which specifies zone transfers,
but it does not limit it to that. ... I find it hard to believe that a udp req could net
a tcp reply. ... (comp.security.firewalls)