On Wed, 17 Mar 2004, Eugen Leitl wrote:
On Tue, Mar 16, 2004 at 03:29:42PM +0800, Sandy Harris wrote:
So, the apparent solution for me seems to be the approach that the SPAM blacklists used - publish information in a subspace of the forward DNS space instead of using the authoritative in-addr.arpa area.
Worth discussing at least.
No, anything requiring publishing DNS records won't fly. OE is *opportunistic*. It doesn't care about what the true identity of the opposite party is. Any shmuck on dynamic IP should be able to use it instantly, with no observable performance degradation, using a simple patch.
If it doesn't fit these minimal requirements, it will die, just the same way FreeS/WAN did.
I discussed it with friends. There could be a way to advertise the OE availability, at least for TCP connections; my original idea was to use some magic number in the payload (which is normally zero) in the TCP/SYN and TCP/SYNACK packets. I was advised against this, as these packets are likely to be thrown away, and got suggested that there are various TCP options in the header. Maybe we could hijack one of them, eg. use the MD5 checksum option otherwise used by BGP (RFC 2385) to advertise our support for OE. The field is 128 bits of data we can use for a magic number and a bitfield of options. It is defined in RFCs, so it should be valid. We could put it into TCP/SYN packets when opening a connection, to advertise we support OE; the server then can use the same mechanism to send back confirmation of its OE support, and the method (if present) that can be used for authenticating its identity. The disadvantage is that we still have some risk that some routers will throw such packets away; see the problems eg. ECN has. However, some RFC offers a remedy for this, as it defines that if the first TCP/SYN with ECN support set doesn't get a SYNACK, the retry is WITHOUT the ECN offer. (This principle introduces the possibility of failure to use OE if the SYN packet with the OE (or the corresponding ACK) offer gets dropped due to congestion, but it should introduce no additional overheads (except the need to retry TCP/SYN in case it gets dropped due to non-RFC-compliant infrastructure on the link). Another disadvantage is that we don't protect UDP, due to lack of the header options. The advantage could be the possibility to implement this transparently on eg. the firmware of a NAT box; it has to track the connection states anyway, so it should be capable of mangling the first TCP/SYN packet by putting the OE offer in, and then strip it from the answers before passing it back, and handle the encryption in transparent manner. This way we got big savings in terms of effort needed to deploy OE between a heterogenous LAN and the Net; just upgrade the router. This scheme, as all OE are, is susceptible to an attack by stripping the OE offers from the packets. It, however, is not the passive way anymore, is more expensive, poses more difficulties, and a variant of eg. "arpwatch" userspace daemon can alert us that something like that is happening, that sites that used to use OE don't do so anymore, or that their identities are suspiciously changed. Told something like this to the crew of OpenSWAN developers. Got some reaction, but it's too soon to know more. Opinions, comments?