An interesting point, T/TCP does indeed require multiple flags to be set simultaneously, however, it's also not a proven protocol. In fact there are potential security issues Apart from the potential DoS (re-introducing SYN floods to some environments) it's not clear how all IP stacks will respond to these packets. There's also a clear security issue with allowing one side of the handshake to send commands before the handshake's been completed - with standard TCP/IP it's relatively easy to spoof the source IP for the SYN but this doesn't get the perpetrator very far - with T/TCP a spoofed SYN could actually send a command which may be actioned if the target host only uses the source IP as validation (such as rlogin/rsh). This last matter isn't a show stopper, I don't allow rlogin etc - and if I did it would only be for addresses that can only be internal (the firewall would prevent external devices from spoofing such addresses). But this is just one example of a new security hole being opened by T/TCP...Ever cautious, I'm inclined to block this traffic and see what else turns up as the protocol matures. If anything, this reaffirms my belief in blocking any unexpected traffic (allow it only when it becomes clear that it must be allowed through, and only after making sure that new security holes aren't being introduced) While on the subject, have there been any moves to ramp up the acceptance of T/TCP, I can see that there are distinct performance advantages for HTTP? -----Original Message----- From: Alun Jones [mailto:alun@texis.com] Sent: 18 October 2002 22:28 To: benjamin@seattleFenix.net Subject: Re: Ambiguities in TCP/IP - firewall bypassing At 03:55 PM 10/18/2002, Benjamin Krueger wrote: > One could also make a case for continuing to abide by the cardinal >rule "Be permissive in what you accept, and strict in what you send". >Tough call, but its difficult to justify describing stacks that are >permissive as "highly bogus" or "lazy" given that being permissive in >what you accept is an established notion. If a usage makes any kind of sense, then it has usually been allowed. >Compliant by the letter, if questionably in spirit. I'm not aware of any >tcp client systems that would send SynFin in the real world, so a stack >that responded with RST could arguably be "more" correct (for example). Not necessarily. Have you heard of T/TCP? Before that was around, I remember hearing discussion of using a packet with SYN, FIN, and data all in one, to cut down on round-trips in really short communications, while still providing reliability. One of the lessons you learn when writing / reading RFC material is that "there are more things on heaven and earth, Horatio, than are dreamt of in your philosophy" (or thereabouts). Just because _you_ don't see a use for a feature, that doesn't mean to say that someone else won't / can't, and specifically, it isn't usually worth limiting a protocol for the rather arbitrary reason that you can't see how a feature would be used. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email alun@texis.com Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.
