On 12/04/2014 10:37 AM, Jacob Appelbaum wrote: > On 12/4/14, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
>> I'm not sure i'd characterize a simple DHCP client as "quite straight >> forward", but certainly minimalist one is more straightforward than one >> which handles all the possible extensions that have cluttered DHCP over >> the years. > > We've already written the start of very basic non raw socket DHCP > client - it doesn't yet include the parser and later stages but it > does fetch leases. It is completely straight forward with the basic > socket API. It is absolutely not required to use a raw socket but it > requires some trickery with the rp_filter in the kernel. I'm happy to hear about your progress! can you point to the code someplace for people who are interested to review it? > The parsers for any dhcp client are of course rather annoying and the > rest of the hooks are too. However - remember the DHCP client that > talks to the *network* does not need to do anything other than the > full DHCP lease process. Thus with the right design, a minimal or a > full client are something in another process anyway. Getting the thing to a state where it's usable for normal people with normal computers encompasses the whole scope, so the project will have to deal with the stickier parts eventually. > I'd be happy to talk with them. Please do introduce me to them in some way? done offlist. hopefully we can produce something useful :) >> * specify the lease renewal behavior algorithm > > It seems rather straight forward to use the time offered by the server > - what else do you think is important to consider? the time offered by the server tells you when the lease expires. it's up to the client to decide when to try to renew (t/2 seconds? t - 20 seconds? something else? how does it deal with weird values for t like very small or very large values?). It's also up to the client to decide how to deal with the renewal when ACKs are delayed or not forthcoming. Specifying all of the fiddly optional parameters of the renewal strategy would help implementations avoid being fingerprintable based on timing as well as content. Regards, --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.