On Thu, May 14, 2009 at 02:34:29PM -0400, Sebastien Roy wrote:
> On Thu, 2009-05-14 at 14:12 -0400, Dan McDonald wrote:
> >     - Insert something into the sendmsg() path that explicitly sets the
> >           local IP & port for a single datagram.
> > 
> >             This involves kernel modifications, which would be awful if
> >             anyone requested such a daemon to run on older kernels.
> 
> This is the cleanest and most sensible approach, IMO.  A new ancillary
> data type that specifies the source address and/or port makes sense to
> me.
> 
> There has to be forward progress in the kernel as necessary.  We can't
> always say that we can't introduce new features because consumers of
> those features might need them on versions of the OS that don't have
> those features, that doesn't make sense to me.

Those are good arguments.  Some customers may disagree with you (especially
those who listen to their high-priced consultants who think you should
never/rarely upgrade), but that's not a topic for *this* list.  :)

> >     - Use a raw socket and construct the whole IP and UDP headers.
> > 
> >             Can we do this for packet transmission?  I know we can for
> >             ICMP headers ala. ping(1M), but can we for UDP as well?
> 
> You can do that, but I don't think you should.  This introduces
> irrational implementation-specific privilege constraints on the
> consumers of the API, and it also bypasses the UDP port space altogether
> allowing applications to tromp on port numbers that may be in use by
> real UDP applications.

Keep in mind that an IKE daemon will require a lot of privileges anyway, PLUS
it would only reflect back traffic bound for its already (properly) bound
port(s).  Also, the previously-mentioned kernel modification would either
require privilege (to limit soure-address spoofing) or require in-kernel
checks for local-address goodness.

I'm thinking raw-sockets for the short term and bringup, and in the
longer-term, perhaps building a more appropriate ancillary data type.

Dan
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to