On Thu, 31. Jan 21:43, Michael Rash wrote: > What is most likely happening here is that the fwknopd server is > operating on a per-packet basis, and an SPA payload that is greater than > the Ethernet MTU will cause the SPA data to arrive in more than one > packet. (Technically I'm equating "packet" with "frame" and "datagram" > depending on the context.) So, fwknopd doesn't try to stitch together > UDP packet payloads even though they are associated with the same > overall communication - it just sees each one individually and tries to > decrypt with available decryption keys. You can confirm this by running > a sniffer and taking a look at how the SPA data is delivered to the > server. > > With the current architecture, fwknop is limited to using 2048-bit GnuPG > keys. I do have in mind an alternative in a future release to allow > fwknopd to acquire packet data via a real UDP server socket. Nothing > would ever be sent back to any client, so people cannot scan for the > server just as they can't scan for it when libpcap is used, and there > are some other nice properties like not linking against libpcap. In > this mode, it would be a lot easier to accept larger SPA payloads, so it > would be compatible with larger GnuPG keys. This would not be the > default packet acquisition method though, and the code has not been > started for this yet.
Thanks Mike that's much clearer now. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Fwknop-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
