OpenBSD Journal

N2K8 Hackathon Summary Part 2

Contributed by merdely on from the i > u dept.

Mark Uemura (mtu@) is back with his second installment of his account of the Network Hackathon in Japan:

Network Hackathon (Part 2) - May 5-10, 2008, Ito, Japan

I remember meeting David Gwynne (dlg@) at AUUG (2004). At that time, he was working on USB drivers for OpenBSD. Since then, he's been all over the tree. It is really interesting to see him interact with the other developers at a hackathon. He's really humble and humorous in his subtle way (a hilarious collection of T-Shirts) but very articulate. That is, he knows how to convey his thoughts clearly or argue his position but in a non-confrontational way. I guess that was why he sat right beside Theo during the hackathon or was it because he was in spitting distance to those Tim Tams?

More from Part 2, with pictures, below.

dlg@
David didn't really have any idea of what he was going to work on at the hackathon. Then on the first day or so, he pulls out a rather smallish diff and says, "I don't know what I'm doing but I think that I got a diff that seems to implement 'active-active firewalling' (with state, of course) but I really don't know what I'm doing, really!".

By the end of the week, it was refined even further and I overheard someone saying, "This is great and another first! There are a lot of firewalls that claim that they do 'active-active' firewalling but only OpenBSD does it with state and no one has figured this out yet." David was kind enough to demonstrate this very cool (and very difficult to implement) bit of functionality before my eyes on a few Liantec boxes.

Here is what David had to say about his contributions to the hackathon:

"I came to n2k8 with basically no planning or forethought beyond getting flights and arriving at the airport on time with enough clothes for the week. I hadn't really considered what I would work on until I was sitting in the hack room with nothing to do but eat Tim Tams.

To get things rolling I decided to complete the implementation of interface transmit mitigation. This was a largely mechanical change to the network stack that caused all paths that put packets onto an interfaces send queue to only send them when the queue is full or when packet processing is complete.

After that I was idle again, but somehow got reminded of problems with synced PF firewalls when traffic for one TCP connection goes over two separate machines. For example, if you have two hosts called A and B talking TCP to each other through stateful PF firewalls X and Y, and all the traffic from A to B goes via X, and the packets from B to A go via Y, then things don't work too well. More specifically, each firewall needs information found on the other firewall to be able to know if its own view of half the connection should proceed. Because pfsync updates are relatively slow compared to the actual traffic between A and B, pf on each firewall would drop packets when the real connection moves beyond the TCP window it has learnt from the other firewall.

The traditional solution to this problem is to configure PF firewalls into a master-backup setup, ie, one machine takes all the traffic till it falls over, at which point the backup takes over all the traffic handling. Unfortunately there are situations where such a setup cannot be guaranteed or it is difficult to implement, so having master-master PF configurations would be nice to have.

Since this was my first foray into PF, I spent the following days trying to figure out the code that caused the issue and the various ways to solve it. With the help of basically everyone in the room, we came up with at least four different mechanisms for coping with this problem and a variety of diffs to test them. Eventually on the last day we came up with a working solution to the problem. Special credit must go to Ryan McBride (mcbride@) who helped me understand the code and actually wrote half of the diff for me.

Unfortunately the code needs a bit more work before it can be put in the tree. Enabling this support for master-master setups will probably hurt machines more than help them, so some further work to optimise the stack (and pfsync in particular) for the task must be done first.

I reckon I could have eaten more Tim Tams."

-dlg


Markus Friedl (markus@) works for GeNUA, a very successful company in Germany that offers sophisticated IT security solutions based on OpenBSD. He is one of the main team members developing and maintaining OpenSSH. He is responsible for many things in OpenSSH such as adding support for the SSH2 protocol and SFTP.

I was extremely happy that Markus was able to make it to the event. He is not just an OpenSSH developer. He has also done quite a lot of work in OpenBSD and continues to do so as you'll see below. As quiet as he is, he was seen moving around the hackathon room alternating between Marco Pfatschbacher (mpf@) and Damien Miller (djm@).

Etoh and Markus
Besides hacking, he seemed to enjoy taking a lot of pictures but seemed camera shy himself. We didn't get too many shots of him. The one really nice shot was of him in the onsen with a small white towel over his head. We didn't think that it was appropriate to show but the smile on his face says it all.

One of the best photos that Sakurai-san took of him was while he was talking with our Japanese ProPolice Stack Protection GURU, Hiroaki Etoh, during the party on the last day of the hackathon.


Here is what Markus Friedl had to say about his work at the 2008 network hackathon:

"...just a few notes. Apart from many discussions I think I did this:

pf(4)-scrub can usually just match the src-, dst-ip or the protocol. Now you can scrub packets based on tags. This way you can tag them on input (based on the port for example) and scrub matching packets on output. Additionally, I added 'set-tos' to scrub so you can enforce 'lowdelay' or other policies with scrub.

For easier support of transparent tcp/udp/ip-proxies, I've added 'divert' support. it allows redirection of packets into the userland without modifying the original packet. Additionally with new socket options you can enforce binding to non-local addresses (see netcat's -s code for an example -- see nc(1)).

I also fixed several bugs in ssh, like forwarding sigpipes from the ssh(1) client to the process run by sshd(8) and a 10% speed increase by removing extra data copies."

-markus

(n2k8 hackathon summary to be continued)

Thanks again to Mark for this excellent write-up.

(Comments are closed)


Comments
  1. By jirib (89.176.154.98) on

    "For easier support of transparent tcp/udp/ip-proxies, I've added 'divert' support. it allows redirection of packets into the userland without modifying the original packet. Additionally with new socket options you can enforce binding to non-local addresses (see netcat's -s code for an example -- see nc(1))."

    hm... what application could i use for transparent redirecting some traffic via socks from PF?

    for example: <some app> - <PF redirection> -> <some app talking socks> -> <tor>

    Comments
    1. By Anonymous Coward (74.59.190.33) on

      > "For easier support of transparent tcp/udp/ip-proxies, I've added 'divert' support. it allows redirection of packets into the userland without modifying the original packet. Additionally with new socket options you can enforce binding to non-local addresses (see netcat's -s code for an example -- see nc(1))."
      >
      > hm... what application could i use for transparent redirecting some traffic via socks from PF?
      >
      > for example: <some app> - <PF redirection> -> <some app talking socks> -> <tor>


      This is 'divert' feature is great step forward IMHO. I think one of the only valid reason that could justify, in some cases, not going with PF instead of commercial fw (or perhaps even iptables), was the lack of ability to transparently bump packets for upper layer inspection / proxying. With divert it sounds like it will be much easier for third parties to develop transparent inspections/nat engines (cizzzcoee pix fixup style)!

      This is cool stuff!


  2. By Anonymous Coward (81.83.80.223) on

    These things are pretty cool to read :) Well done with all the progress made, guys! If you're ever in Belgium, give me a shout and I will supply you with plenty of beer to lubricate your brains!

    Comments
    1. By Anonymous Coward (79.114.19.105) on

      > These things are pretty cool to read :) Well done with all the progress made, guys! If you're ever in Belgium, give me a shout and I will supply you with plenty of beer to lubricate your brains!

      This is just a geek myth that beer is good, many developers don't preffer it. So cool it.

      Comments
      1. By wim wauters (82.69.131.70) openbsd@unisoftdesign.co.uk on unisoftdesign.co.uk

        > > These things are pretty cool to read :) Well done with all the progress made, guys! If you're ever in Belgium, give me a shout and I will supply you with plenty of beer to lubricate your brains!
        >
        > This is just a geek myth that beer is good, many developers don't preffer it. So cool it.

        True, beer is a sysadmin thing, coders should stick to caffeinated drinks :-)

        An excellent article BTW, maybe it can be "co-opted" by that new BSD mag!


        Being a sysadmin with Flemish roots, I'm going to have a nice Flemish beer now :-)

        Gezondheid!

      2. By clvrmnky (198.73.193.2) on http://clevermonkey.org

        > > These things are pretty cool to read :) Well done with all the progress made, guys! If you're ever in Belgium, give me a shout and I will supply you with plenty of beer to lubricate your brains!
        >
        > This is just a geek myth that beer is good, many developers don't preffer it. So cool it.

        1. You mean "greek myth." Sheesh. Prometheus brought fire down from the mountain for a reason.

        2. Apparently you haven't seen the after-hours pictures from some other hackathons. Consider it a given than when developers collide, beer happens. It's like a natural law. You wouldn't want to break a natural law, would you?

  3. By clvrmnky (69.28.228.76) on http://clevermonkey.org

    Nice update. We live in exciting times for network packets.

  4. By Anonymous Coward (213.118.21.15) on

    Is it possible to donate tim-tams? ;-)

    Comments
    1. By Anonymous Coward (68.107.65.28) on

      > Is it possible to donate tim-tams? ;-)

      This is just a geek myth that beer^H^H^H^H tim-tams is good, many developers don't preffer it. So cool it.

      (just screwing with the person who posted up above) ;-)

  5. By Rob Sessink (80.127.105.250) on

    Nice to read about N2K8 and the possibility to run active-active firewalling. One question, the report mentions that a working solution was created fro active-active firewalling but does not go into detail about the inner workings for this solution. How does it work ? Or is this still too premature?

    Regards Rob

  6. By MaximB (212.116.70.46) on

    Nice to be able to enforce "TOS" on packets!

  7. By Anonymous Coward (212.20.215.132) on

    Love the T-shirt ;-)

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]