Re: bind() udp behavior 2.6.8.1

[Adam Denenberg]

i have some more updated information for this.  It seems that linux is
generating a duplicate transaction ID in the udp header in the dns query
when making a dns request.  This piece seems to be what is preventing
the Firewall from distinguishing unique dns requests.  It sees a second
DNS request come from the linux server with the _same_ transaction ID in
the UDP header as it is marking that session closed since it already saw
the reply successfully.  So for example the linux server is making a dns
query with DNS Transaction ID 0x598d, then a response comes back with ID
0x598d, and then another query gets sent out with ID 0x598d.  When that
second response comes back, the firewall gets confused b/c it is in the
middle of closing the original 0x598d session and thus drops the packet,
causing a DNS timeout.

 Why is linux generating a redundant transaction ID in the dns header
here?  The first 2 requests have incremented values, but then for some
reason the third seems to have the same value which is causing issues. 
Has anyone encountered this behavior?

thanks again
adam

Please CC me i am not on the list.




On Tue, 2004-12-14 at 22:19, Kyle Moffett wrote:
> On Dec 14, 2004, at 21:23, Adam Denenberg wrote:
> > i think you guys are all right.  However there is one concern.  Not 
> > clearing out a UDP connection in a firewall coming from a high port is 
> > indeed a security risk.  Allowing a high numbered udp port to remain 
> > open for a prolonged period of time would definitely impose a security 
> > risk which is why the PIX is doing what it does.  The linux server is 
> > "reusing" the same UDP high numbered socket however it is doing so 
> > exactly as the firewall is clearing its state table (60 ms) from the 
> > first connection which is what is causing the issue.
> >
> > I think a firewall ought to be aware of such behavior, but at the same 
> > time be secure enough to not just leave high numbered udp ports wide 
> > open for attack.  I am trying to find out why the PIX chose 60 ms to 
> > clear out the UDP state table.  I think that is a random number and 
> > probably too short of a span for this to occur however i am still 
> > researching it.
> >
> > Any other insight would be greatly appreciated.
> 
> 60ms is certainly _way_ too small for most UDP traffic.  With something 
> like
> that, OpenAFS would die almost immediately.  I think the current OpenAFS
> minimum is like 20 minutes, although somebody patched the OpenAFS
> source to send a keepalive every 5 minutes, so it could be reduced.  
> OTOH,
> sending a keepalive every 60ms would take a _massive_ amount of
> bandwidth even for one client, think about a couple hundred :-D.  Heck, 
> I've
> even seen pings on a regular basis that take longer than 60ms, which
> means that even an infinitely fast kerberos server wouldn't respond 
> quickly
> enough :-D.
> 
> Cheers,
> Kyle Moffett
> 
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
> L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
> PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
> !y?(-)
> ------END GEEK CODE BLOCK------
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/