UDP catchall

Matus Harvan mharvan at inf.ethz.ch
Wed Oct 31 07:49:34 PDT 2007


On Mon, Oct 29, 2007 at 07:49:47PM +0000, Bruce M. Simpson wrote:
> Brooks Davis wrote:
>> While I think this idea has some merit, I think we specifically want
>> the current wildcard ability to allow for a system that requires
>> minimal configuration.  The problem with a range is that it doesn't
>> allow disjoint sets and it requires that if you really do want all the
>> ports you need to produce a list of currently allocated ports to avoid
>> allocating.  A more (over)engineered solution holds some attraction, but
>> I'm not yet convinced the fact that it could exist precludes the current
>> implementation.
> 
> Actually I concur with you on this point, based solely on the disjoint sets 
> point.

A slightly different argument:

What if you set a certain port range for catchall and an application
then tries to bind to one of these ports? Should the whole port range
be reserved for the catchall socket or should an application be
alllowed to "take" on of the ports. The latter seems more practical to
me. But then there would be no point in changing from the wildcard
ability to a port range functionality.

> Another vector of attack would be to put the relay functionality into PF, 
> which can do the packet matching. However this of course suffers from the 
> problem that if you just want a plain old UDP socket for mtund, you won't 
> get that unless you go to the inpcb layer anyway.
> 
> But who says mtund needs to use sockets for its traffic relay? There is 
> definite appeal in *not* doing it in the socket layer at all -- an 
> adaptation of pf's log socket may suffice...

For UDP catchall this would suffice. However, we should also prevent
the kernel from sending back a (icmp) notification that the port in
question was closed. How could this be done with pf's log socket or
bpf? Blackhole functionality would have to be enabled? This would then
seem to me more of a hack than doing this in the socket layer.

Matus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20071031/e6dfed09/attachment.pgp


More information about the freebsd-net mailing list