On Thu, 2009-05-14 at 14:45 -0400, Dan McDonald wrote: > On Thu, May 14, 2009 at 02:34:29PM -0400, Sebastien Roy wrote: > > > - 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.
While the initial consumer is an IKE daemon, the function is general purpose by definition. Without taking into account what you have in mind for its initial use, I don't see anything inherent in this function that would require more privileges than a simple bind()/sendto() combination. The in-kernel local-address checks are extremely easy to implement (I would assume that one couldn't specify an address not assigned to the local system anyway), and are already implemented for the IP_PKTINFO code. > I'm thinking raw-sockets for the short term and bringup, and in the > longer-term, perhaps building a more appropriate ancillary data type. Assuming that you require the socket to have a bound port already, IP_PKTINFO may be all that you need. If it's anything more than that, I honestly don't think that a new ancillary data type would be that much more work than implementing a transport layer in user-space using a raw socket... -Seb _______________________________________________ networking-discuss mailing list [email protected]
