[ipv6hackers] Windows 7/2008 R2 Improved Resilliency to IPv6 Floods

Andrew Yourtchenko ayourtch at gmail.com
Thu Apr 18 01:12:27 CEST 2013


Hi Marc, all,

re. "sample code for happy eyeballs" - I had that ambition in the beginning
(it was a bit more - to try to create a patch to retrofit the existing code
with stuff like LD_PRELOAD and similar), but after studying the wide
variety of the ways the various hosts do the connections, I decided against
it - way too cludgy.

Happy Eyeballs implies more than one connection in progress, and this
implies the concurrency model, and between the poll() loop, select() loop,
threads du jour and separate processes I had decided there is no way to
make a sample code that would be useful enough.

One thought I had which might make this a bit tractable is to suggest a
model that would separate the DNS lookup/connection establishment into a
separate process, and use some more or less portable mechanism [1] to pass
the file descriptors around..

The idea is to export a function with an interface of:

int connect_by_name(char *hostname, char *service);

which if necessary would fork and start a "happy connection process", which
in turn does all arbitration and maintains the "knowledge" between the
processes.

But I am very much divided from the security PoV - this delegates all the
connection authority to a separate process, and seemingly break the
assumptions the various anti-evil software might have, and I did not have
enough quiet time to think it through.

What do the folks think - would such a project be useful ?

--a

[1]
http://stackoverflow.com/questions/909064/portable-way-to-pass-file-descriptor-between-different-processes




On Mon, Apr 15, 2013 at 12:19 AM, Marc Heuse <mh at mh-sec.de> wrote:

> On 15.04.2013 05:24, Jim Small wrote:
> >> In my mind, that's a poor tradeoff. I would much rather have seen MS
> >> implement happy eyeballs. It would have much greater overall benefit,
> >> and none of the drawbacks.
> >
> > I understand what you're saying - that's exactly how I felt.  I spoke to
> someone close to the Microsoft core networking team.  From Microsoft's
> vantage point the most important thing is determinism.  The problem with
> happy eyeballs is you have non-deterministic behavior.  For an excellent
> discussion of this with references, see here:
> >
> http://blog.ioshints.info/2013/03/happy-eyeballs-happiness-defined-by.html
> >
> > It would be nice if there were an option to enable happy eyeballs though
> if the user/organization desired that behavior.  But again, I think
> Microsoft is afraid of the supportability/costs of a non-deterministic
> approach.
> >
> > I' not sure I completely agree with the end result, but I understand
> where they are coming from.
>
> I understand Microsoft as well on this point. undeterministic behaviour
> is a big issue if you need to diagnose problems.
>
> But in my opinion, user experience should be the top priority, and IMHO
> the happy eyeballs technique is the best solution.
>
> The common unix/network solution fails too at least for me (I mean the
> getaddr(ptr, "foo.com);while(ptr != NULL) { connect(foo->addr)... one)
> because if the IPv6 connection to the destination fails, the user has to
> wait for the timeout before the IPv4 address is tried.
>
> About the happy eyeballs technique - is there a simple best practice
> code published somewhere that is cross platform? That would be very
> helpful to point to and encourage developers to implement instead.
>
> btw. this reminds me of the Apple issue to close the DNS resolve UDP
> port, once the first response (A or AAAA) came in, and only use this
> answer. is this still the case and not fixed? because this is is the
> most undeterministic behaviour ever! :-)
>
> Greets,
> Marc
>
> --
> Marc Heuse
> www.mh-sec.de
>
> PGP: FEDD 5B50 C087 F8DF 5CB9  876F 7FDD E533 BF4F 891A
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
>



More information about the Ipv6hackers mailing list