Re: Fixing "Slipping in the window" before 4.11-release
At Mon, 3 Jan 2005 01:31:29 -0600 (CST), Mike Silbersack wrote: > For the life of me, I can't figure out why SYN packets (other than delayed > retransmissions of the original SYN) would ever show up once a connection > is in the ESTABLISHED state. They "shouldn't" and I think ignoring them makes sense, but that's just me. I gather you did a search of Stevens to see if there had ever been a justification for dealing with SYN once established? The only thing I could think of was to go look again at how half open connections are handled. I have not taken a look at that, but it sticks in my mind as the only thing that could cause an issue. > So, I'm proposing the attached patch, which simply ignores any > packet with the SYN flag on it while a connection is in the > ESTABLISHED state. That sounds fine to me. > What are people's thoughts on this? I'm especially interested how > stateful firewalls like IPF or PF would handle such a situation. How do > they respond to unexpected SYN packets? Well, those I cannot comment on. > diff -u -r /usr/src/sys.old/netinet/tcp_input.c > /usr/src/sys/netinet/tcp_input.c One quick comment on the patch. Do we want to count these kinds of drops separately? Later, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current problem reports assigned to you
Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description --- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description --- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/57985: [patch] Missing splx in ether_output_frame (-stable)
Synopsis: [patch] Missing splx in ether_output_frame (-stable) Responsible-Changed-From-To: freebsd-net->rwatson Responsible-Changed-By: rwatson Responsible-Changed-When: Mon Jan 3 12:25:48 GMT 2005 Responsible-Changed-Why: Grab ownership of this PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=57985 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing "Slipping in the window" before 4.11-release
On Jan 3, 2005, at 2:31 AM, Mike Silbersack wrote: For the life of me, I can't figure out why SYN packets (other than delayed retransmissions of the original SYN) would ever show up once a connection is in the ESTABLISHED state. So, I'm proposing the attached patch, which simply ignores any packet with the SYN flag on it while a connection is in the ESTABLISHED state. Are you relying on the IPID or the connection tuple of srcIP+srcPort+destIP+destPort to identify the SYN packet as being associated with an already established connection? I suppose that if the sending TCP stack has poor IPID sequence generation, maybe it could be reusing IPIDs and thus breaking the uniqueness assumption. This means that SYN packets left of the window will no longer receive an ACK, and SYN packets in the window will no longer reset the connection. In all states other than ESTABLISHED, SYN packets are handled as they were before, in case there's some edge case where that could happen. This seems to be a reasonable improvement: the stack shouldn't be ACK'ing data outside of a valid connection window to begin with. What are people's thoughts on this? I'm especially interested how stateful firewalls like IPF or PF would handle such a situation. How do they respond to unexpected SYN packets? Generally, each bare SYN packet is treated as a seperate new connection request, and they expect the destination TCP stack to handle any duplicate SYNs resulting from duplicated packets. -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing "Slipping in the window" before 4.11-release
> The SYN side of the equation, however, is a bit more tricky. The > proposed RFC recommends ACKing SYN packets in the window, just like > we do to SYN packets to the left of the window right now. > > For the life of me, I can't figure out why SYN packets (other than > delayed retransmissions of the original SYN) would ever show up once > a connection is in the ESTABLISHED state. So, I'm proposing the > attached patch, which simply ignores any packet with the SYN flag on > it while a connection is in the ESTABLISHED state. This means that > SYN packets left of the window will no longer receive an ACK, and > SYN packets in the window will no longer reset the connection. In > all states other than ESTABLISHED, SYN packets are handled as they > were before, in case there's some edge case where that could happen. This sounds OK to me. FWIW. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ pgpUCetwOld1O.pgp Description: PGP signature
Re: Fixing "Slipping in the window" before 4.11-release
On 3 Jan, Mike Silbersack wrote:
>
> With re's permission, I'm going to commit FreeBSD's fix for the RST part
> of the slipping in the window attack to 4.11 in the next few days. That's
> not a big deal, we seem to have an acceptable solution there. (See
> tcp_input.c rev 1.235 for more info.)
>
> The SYN side of the equation, however, is a bit more tricky. The proposed
> RFC recommends ACKing SYN packets in the window, just like we do to
> SYN packets to the left of the window right now.
>
> For the life of me, I can't figure out why SYN packets (other than delayed
> retransmissions of the original SYN) would ever show up once a connection
> is in the ESTABLISHED state.
It can happen if one side of the connection crashes and tries to
reconnect using the same source port. The BGP case, which is the case
where attacks are of most concern, likes to connect from port 179 to
port 179.
> So, I'm proposing the attached patch, which
> simply ignores any packet with the SYN flag on it while a connection is in
> the ESTABLISHED state. This means that SYN packets left of the window
> will no longer receive an ACK, and SYN packets in the window will no
> longer reset the connection. In all states other than ESTABLISHED,
> SYN packets are handled as they were before, in case there's some edge
> case where that could happen.
That'll hose things in the case I mentioned above. A client that
reboots and loses it's connection state won't be able to reconnect until
the server transmits something that provkes a RST response that causes
the server to drop the connection.
It's probably safer to just defang the code that handles the in-window
case, which would reduce the probability of a reconnection attempt
failing.
/*
* If a SYN is in the window, then this is an
* error and we send an RST and drop the connection.
*/
if (thflags & TH_SYN) {
if (tcp_insecure_syn == 0)
goto drop;
else {
tp = tcp_drop(tp, ECONNRESET);
rstreason = BANDLIM_UNLIMITED;
goto dropwithreset;
}
I'd also be hesitant to change the default behaviour.
> What are people's thoughts on this? I'm especially interested how
> stateful firewalls like IPF or PF would handle such a situation. How do
> they respond to unexpected SYN packets?
>
> Mike "Silby" Silbersack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing "Slipping in the window" before 4.11-release
On 3 Jan, Don Lewis wrote:
> /*
> * If a SYN is in the window, then this is an
> * error and we send an RST and drop the connection.
> */
> if (thflags & TH_SYN) {
> if (tcp_insecure_syn == 0)
> goto drop;
> else {
> tp = tcp_drop(tp, ECONNRESET);
> rstreason = BANDLIM_UNLIMITED;
> goto dropwithreset;
> }
Writing and posting while sleepy is not a good thing. The braces are
unbalanced and the else after the goto drop isn't necessary, so just
adding
if (tcp_insecure_syn == 0)
goto drop;
in the obvious place would do the trick.
This is probably the same section of code that would need to be modified
to implement the behaviour recommended in the Internet Draft.
A new version of the draft was release in November, but I haven't had a
chance to look at it yet. It is at:
.
There was a presentation at an IETF meeting about the issues relating to
the Cisco IPR claims:
User process starvation under heavy network traffic in FreeBSD 5.3
Hello, I posted this question to freebsd-arch earlier. Stefan Bethke suggested that I try freebsd-net instead. We are building a network appliance running FreeBSD 5.3 and under very heavy network traffic the user processes don't get scheduled for an unacceptable period of time. Marking the user process/thread real-time class doesn't help since the real-time user threads priorities are still lower than the interrupt threads. BTW, in our case, the CPU spends very long time at PI_NET (16) priority level, instead of at the (PI_SOFT + 4) soft intr level due to the packet forwarding nature. Either way, the user processes don't have a chance. In the following discussion I'll use PI_NET to represent the network interrupt threads priority. I am experimenting with improving the real-time threads scheduling performance and would like to hear from you. Here is what I am doing: 1. Raise the minimum real-time user threads priority to a value higher than PI_NET, e.g. #define PRI_MIN_REALTIME0 And use the rtprio() syscall or command to set the priority to be higher than PI_NET, e.g. "rtprio 10 " This didn't turn out to be enough, since the real-time user process still uses system services or drivers that run at a lower priority than PI_NET, e.g. disk, tty, etc. 2. Change the PI_NET value to be the highest of all interrupt threads. Potential performance impact isn't a concern here since we have relatively rare non-network events. So PI_NET is changed to (PRI_MIN_ITHD + 32) from (PRI_MIN_ITHD + 16). This should give preference to all other I/O interrupt threads. I am assuming the software interrupt scheduling isn't the bottleneck. I haven't got a chance to reproduce the problem using the 2nd change yet. I suspect that it isn't enough to get what I want, since lots of kernel code do msleep(...,pri,...) with "pri" bigger than the changed PI_NET. But, if this thinking of changing the priority ranges makes sense, PI_NET can always be changed to the highest value of all kernel priority values, ie the lowest kernel priority. Hopefully this change would work and not be intrusive to the kernel. Thank you for your comments in advance. Youlin Feng ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing "Slipping in the window" before 4.11-release
On Mon, 3 Jan 2005, Charles Swiger wrote: Are you relying on the IPID or the connection tuple of srcIP+srcPort+destIP+destPort to identify the SYN packet as being associated with an already established connection? Connection tuple. This means that SYN packets left of the window will no longer receive an ACK, and SYN packets in the window will no longer reset the connection. In all states other than ESTABLISHED, SYN packets are handled as they were before, in case there's some edge case where that could happen. This seems to be a reasonable improvement: the stack shouldn't be ACK'ing data outside of a valid connection window to begin with. I spoke inaccurately above. We trim the ACK to the left edge of our window, then ACK that value. So, it *shouldn't* affect the state of the connection, but it will cause us to flood ACKs. More comments coming, see upcoming reply to Don... Mike "Silby" Silbersack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing "Slipping in the window" before 4.11-release
On Mon, 3 Jan 2005, Don Lewis wrote:
For the life of me, I can't figure out why SYN packets (other than delayed
retransmissions of the original SYN) would ever show up once a connection
is in the ESTABLISHED state.
It can happen if one side of the connection crashes and tries to
reconnect using the same source port. The BGP case, which is the case
where attacks are of most concern, likes to connect from port 179 to
port 179.
Argh. I was assuming that the client would be using ephemeral ports, and
therefore pick a different one after the crashed. Apps like BGP throw a
wrench into this, I guess. :)
I just went and took a look at the REVISED version of the draft for this
issue:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-02.txt
And it turns out that I should have looked at it earlier; this version
actually provides useful advice on the SYN case. Specifically, it
suggests that in response to all SYNs, an ACK for the left edge of the
window be sent; no SYNs are allowed to reset the connection.
Sounds like that's the way to go, with the addition of rate limiting those
ACKs.
The TCP state machine is pretty complex, so it seems like we'd better
use something which does not alter the state in any way to send out the
ACKs here. Does this look like it'd do the trick? (Stolen from the
keepalive code):
t_template = tcpip_maketemplate(inp);
if (t_template) {
tcp_respond(tp, t_template->tt_ipgen,
&t_template->tt_t, (struct mbuf *)NULL,
tp->rcv_nxt, tp->snd_una - 1, 0);
(void) m_free(dtom(t_template));
}
Mike "Silby" Silbersack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing "Slipping in the window" before 4.11-release
On 3 Jan, Mike Silbersack wrote:
>
> On Mon, 3 Jan 2005, Don Lewis wrote:
>
>>> For the life of me, I can't figure out why SYN packets (other than delayed
>>> retransmissions of the original SYN) would ever show up once a connection
>>> is in the ESTABLISHED state.
>>
>> It can happen if one side of the connection crashes and tries to
>> reconnect using the same source port. The BGP case, which is the case
>> where attacks are of most concern, likes to connect from port 179 to
>> port 179.
>
> Argh. I was assuming that the client would be using ephemeral ports, and
> therefore pick a different one after the crashed. Apps like BGP throw a
> wrench into this, I guess. :)
>
> I just went and took a look at the REVISED version of the draft for this
> issue:
>
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-02.txt
>
> And it turns out that I should have looked at it earlier; this version
> actually provides useful advice on the SYN case. Specifically, it
> suggests that in response to all SYNs, an ACK for the left edge of the
> window be sent; no SYNs are allowed to reset the connection.
That's pretty much what previous versions of the draft suggested. The
earlier versions made some suggestions about how to deal with the corner
case by adjusting the sequence number in ACK, but these schemes added a
bunch of complexity and had some fatal flaws.
I believe that sending the ACK challenge is the Cisco IPR claim.
> Sounds like that's the way to go, with the addition of rate limiting those
> ACKs.
I'm not sure that it makes sense to rate limit the ACKs in this special
case. If an attacker has enough information to trigger an ACK response
flood from the hardened stack, he could still produce a flood by turning
off the SYN bit. A general way of rate limiting ACKs triggered by the
reception of out of window data could be a good idea, but this would
have to be done very carefully to avoid breaking the algorithms that
look at ACKs to sense network congestion.
> The TCP state machine is pretty complex, so it seems like we'd better
> use something which does not alter the state in any way to send out the
> ACKs here. Does this look like it'd do the trick? (Stolen from the
> keepalive code):
>
> t_template = tcpip_maketemplate(inp);
> if (t_template) {
> tcp_respond(tp, t_template->tt_ipgen,
> &t_template->tt_t, (struct mbuf *)NULL,
> tp->rcv_nxt, tp->snd_una - 1, 0);
> (void) m_free(dtom(t_template));
> }
I was going to suggest just doing a
goto dropafterack;
but there's a lot of code in tcp_output() that might unnecessarily
perturb things. I think you can get away without creating a template
for this. Take a look at the code under the dropwithreset label.
I'd put this code down with dropafterack and dropwithreset. There may
be other cases where it should be used in place of the dropafterack
code.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing "Slipping in the window" before 4.11-release
On Mon, 3 Jan 2005, Don Lewis wrote: That's pretty much what previous versions of the draft suggested. The earlier versions made some suggestions about how to deal with the corner case by adjusting the sequence number in ACK, but these schemes added a bunch of complexity and had some fatal flaws. I believe that sending the ACK challenge is the Cisco IPR claim. The goofy special cases in the previous draft could have potentially been unique. In the current draft, however, their description of the ACK challenge to an incoming SYN follows RFC 793 Figure 10 (page 34) exactly. I think we're safe here. Sounds like that's the way to go, with the addition of rate limiting those ACKs. I'm not sure that it makes sense to rate limit the ACKs in this special case. If an attacker has enough information to trigger an ACK response flood from the hardened stack, he could still produce a flood by turning off the SYN bit. A general way of rate limiting ACKs triggered by the reception of out of window data could be a good idea, but this would have to be done very carefully to avoid breaking the algorithms that look at ACKs to sense network congestion. I probably agree here... but I want to just fix this one problem for 4.11, and I don't want to touch the rest of the TCP stack whatsoever. If integrating this case with others in rate limiting makes sense, we could do that in 6.x and 5.x, but I don't want to risk breaking 4.x by rewriting dropafterack at this point in time. I was going to suggest just doing a goto dropafterack; but there's a lot of code in tcp_output() that might unnecessarily perturb things. I think you can get away without creating a template for this. Take a look at the code under the dropwithreset label. Hm, tcp_respond does look like a good candidate... BTW, that tcp template code should probably have been removed years ago, it's only used by keepalives now. I just haven't gotten around to replacing it. Mike "Silby" Silbersack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing "Slipping in the window" before 4.11-release
On 4 Jan, Mike Silbersack wrote: > > On Mon, 3 Jan 2005, Don Lewis wrote: >> I'm not sure that it makes sense to rate limit the ACKs in this special >> case. If an attacker has enough information to trigger an ACK response >> flood from the hardened stack, he could still produce a flood by turning >> off the SYN bit. A general way of rate limiting ACKs triggered by the >> reception of out of window data could be a good idea, but this would >> have to be done very carefully to avoid breaking the algorithms that >> look at ACKs to sense network congestion. > > I probably agree here... but I want to just fix this one problem for 4.11, > and I don't want to touch the rest of the TCP stack whatsoever. If > integrating this case with others in rate limiting makes sense, we could > do that in 6.x and 5.x, but I don't want to risk breaking 4.x by rewriting > dropafterack at this point in time. Agreed. Tweaking the dropafterack stuff would need to be thoroughly discussed, and it would need to soak for quite a while in 6.x to make sure that it didn't cause an interoperability problems. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
