Re: UDP catchall

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

Attachment: pgpODY0G1X354.pgp
Description: PGP signature

Relevant Pages

  • Re: UDP catchall
    ... minimal configuration. ... ports you need to produce a list of currently allocated ports to avoid ... Actually I concur with you on this point, based solely on the disjoint sets ... adaptation of pf's log socket may suffice... ...
    (freebsd-net)
  • Re: Grob 103 question
    ... The socket contains three o- ... rings to keep the three ports separated when the probe is inserted. ... Two of the o-rings are easily replaceable from the front opening. ... you cut out the tripple probe mount to do this. ...
    (rec.aviation.soaring)
  • Re: Grob 103 question
    ... The socket contains three o- ... rings to keep the three ports separated when the probe is inserted. ... you cut out the tripple probe mount to do this. ... them to avoid wear and tear on the O-rings. ...
    (rec.aviation.soaring)
  • Re: Wrapping TCP communications in HTTP
    ... We're using Winsock2 sockets with overlapped I/O through completion ports. ... HTTP won't help you a bit since it's not a secure protocol. ... >>> establishes a TCP socket connection to a server, ...
    (microsoft.public.win32.programmer.networks)
  • Re: question related to sockets
    ... The short answer is that the OS doesn't release a socket for up to 4 mins and hence your reconnect would fail. ... This pc, sometimes my app crashes on it, which is pretty usual cuz of application bugs and I fix them of course. ... But the problem is that the ports r left open when the app crashes. ... The *-o* switch for this netstat command shows the process that owns these ports but clearly that process died a long time back and has no signs in the task manager of windows xp either. ...
    (microsoft.public.dotnet.languages.vc)