diff options
Diffstat (limited to 'doc/opportunism.known-issues')
| -rw-r--r-- | doc/opportunism.known-issues | 287 |
1 files changed, 287 insertions, 0 deletions
diff --git a/doc/opportunism.known-issues b/doc/opportunism.known-issues new file mode 100644 index 000000000..90752dee3 --- /dev/null +++ b/doc/opportunism.known-issues @@ -0,0 +1,287 @@ +Known issues with Opportunistic Encryption Claudia Schmeing +------------------------------------------ + + +This is an overview of known issues with OE. + + +This document supplements: + + +FreeS/WAN Quickstart Guide doc/quickstart.html + +Opportunism HOWTO doc/opportunism.howto + +Opportunism spec doc/opportunism.spec + +Internet Draft doc/draft-richardson-ipsec-opportunistic.txt + + + +* Use the most recent Linux FreeS/WAN 2.x release from ftp.xs4all.nl + to try OE. + + +DESIGN LIMITATIONS + + +* Because Opportunistic Encryption relies on DNS: + - to authenticate one FreeS/WAN to another, and + - to prove that we have the right to protect traffic for a given IP, + this authentication/authorization is only as strong as your DNS is + secure. + + Without secure DNS, OE protects against passive snooping only. + Because the public key and gateway information that FreeS/WAN gets from + DNS is not authenticated, a man-in-the-middle attack is still possible. + We hope that as DNSsec is widely adopted, OE with strong authentication + will become more widespread. + + However, our software does not yet distinguish between strongly and weakly + authenticated OE. This information might be useful for defining local + security policy. + + +* Denial of service attacks are possible against OE. If you rely on OE rather + than VPN to connect several offices, a determined attacker could prevent you + from communicating securely. + + +* OE challenges the notion that all IPsec peers are "friends". With OE, + strangers can potentially tunnel IPsec packets _through_ your defenses + against cleartext packets. This may call for a re-visit to firewall policy. + + +* FreeS/WAN only creates OE connections when it traps an outgoing packet. + Since most traffic is two-way, for most traffic, FreeS/WAN 2.x may soon + trap an outgoing packet and create an IPsec connection to + protect both incoming and outgoing traffic. However, if a local + FreeS/WAN box accepts inbound traffic from a remote peer but + generates no outbound traffic in response, the local FreeS/WAN will not + attempt to initiate OE. Of course, the peer may also initiate OE upon + trapping its own outbound traffic. + + +* OE is only as reliable as your DNS is. + + If your DNS service is flaky, you will not be able to reliably establish + OE connections to known OE-capable peers. + + If you ping a peer, but your FreeS/WAN does not find a TXT record signifying + the peer's ability to respond to OE negotiation), FreeS/WAN will not try to + opportunistically initiate, and communication will fallback to clear. + + For more secure and reliable DNS, we recommend that you run DNS + within your security perimeter, either on your security gateway, or + on a machine to which you have a VPN connection. It is also possible + to have your DNS server located elsewhere on your LAN, though this may + cause lag on startup. + + This mailing list message explains how to run a local caching name server: + http://lists.freeswan.org/pipermail/design/2003-January/004205.html + + See also "Getting DNS through" in opportunism.howto + http://lists.freeswan.org/pipermail/design/2002-April/002285.html . + + + +CURRENT ISSUES + +* There are several special issues re: using OE when running FreeS/WAN with + kernel native IPsec, introduced in the 2.6 kernel. Please see + doc/2.6.known-issues. + +* If A and B have an OE connection, but A is rebooted, normally A will try to + re-connect to B and (if it has no DNS-related failures) it will succeed. + But, if A is set up for responder-only OE, you will have a one-way + connection until B notices that its original tunnel has expired. For details + see: + + http://lists.freeswan.org/pipermail/design/2002-May/002582.html + http://lists.freeswan.org/pipermail/design/2002-June/002610.html + + TIP: If an OE connection isn't behaving, you can recreate it with + + ipsec whack --oppohere sourceIPaddress --oppothere targetIPaddress + + +* There is no good clean facility to delete OE connections. + Available are: + + ipsec auto --status to list connections + ipsec whack --deletestate to delete by state#. + + +* You may experience seeming gaps at rekey time. Once you generate traffic, + you will find that the OE connection returns. + + By default, OE connections are not rekeyed; if they were we'd have a + mountain of useless connections. As a consequence, if your OE connection is + idle at rekey time, it will go down until you generate further traffic. + To ensure prompt rekeying, you can run a ping thorough the OE tunnel. + + +* At the moment, you can only run active OE on one physical interface. + + Active means --routed, to trap outbound packets. It is this route + that is a problem. + + Untested theory: you can have multiple active OE conns, for different + source addresses, but they all have to point their traffic out the single + interface. + + When responding: you can only define one OE connection (per host or subnet) + in ipsec.conf, and that conn will apply to one interface. Normally this + will be the public interface which your default route uses; it is, however, + configurable. + + Theoretically, it might make sense to select between multiple OE conns + based on some criterion, such as address ranges. This might be useful for + local OE, or in a complex routing scenario. + + Currently, Pluto expects only one OE connection. If you add another, + Pluto may choose randomly between them, producing unpredictable results. + + +* Building OE conns between nodes on a LAN is not possible. + + This is a side effect of conflicts about ARP entries + in the rt_cache and our "stupid routing tricks". + There is no known workaround at this time. + + "Stupid routing tricks" are an ongoing issue, and should + go away in a future software revision. + + See these explanations: + http://lists.freeswan.org/pipermail/design/2002-April/002285.html + http://lists.freeswan.org/pipermail/design/2002-August/003249.html + + +* FreeS/WAN may not correctly follow a CNAME (Canonical Name) trail resulting + from reverse DNS delegation. + + Solution: Use a recent Bind 9 (we tested with Bind snap-pre9.3) for the + DNS services which the FreeS/WAN box relies on. + + Reason: This Bind correctly implements "implied helper support" for + traditional DNS records, and so can follow a properly constructed CNAME + record trail which ends in a TXT record. Thus, in cases where a reverse + domain has been delegated, FreeS/WAN + Bind 9 can find a TXT record and + create an OE connection. + + For more on the problem, see "OLD ISSUES", below. + + +* To make OE operation smoother, we may need a script that runs and warns + if we have the reverse DNS records, but not the software running. + The reverse records advertise that we can do OE, but when the software is + not running this is false advertising. + + + +OLD ISSUES + +* Coterminal OE doesn't work in practise. This includes OE-in-WAVEsec. + Solved in 2.02. + + Old diagnosis: + + If you have coterminal OE connections (two OE connections which share + one endpoint), you should have use of one of the encrypted links, but it + is not clear which one KLIPS will prefer. In particular, the behaviour + may not be symmetrical. + + Worse yet, it just seems to trip over itself and be generally + unworkable. + + Weird but predictable: + + If you have both a gateway and a host who advertise (via DNS) an + ability to do OE you need to be serious about doing host-based + OE, or you will be stuck in initiator-only mode. If your host + advertises but does not run OE, then when a peer tries to connect to + your host, it will fail to clear. The peer will then not try to encrypt + traffic bound for that host as it travels to the gateway. To remedy + the situation, restart ipsec on the peer (or otherwise flush out + the %pass eroute), and ping the peer from your host to initiate + OE. + + +* One-way connection was created on rekey. Solved in 2.0. + + If one side (A) has a shorter _keylife_ than the other, + and that side also has _rekey=no_, then when the keylife has + expired, it will expect that its peer (B) will make a new conn to replace + the existing one. Unfortunately, B has no idea. + + B continues to send out encrypted packets on the original connection, + while A passes the return packets along in the clear. + + There is a proposed patch for (A) here: + http://lists.freeswan.org/pipermail/design/2002-July/003114.html + + +* Failure to look up own host name is a show stopper. + Solved in 1.98 and 1.98b. + + Solution: new setting %dnsondemand. Usage: + + leftrsasigkey=%dnsondemand # now in sample ipsec.conf + rightrsasigkey=%dnsondemand. + + From man ipsec.conf: + + The value %dnsondemand means the key is to fetched from DNS + at the time it is needed. + + If Linux FreeS/WAN can't get the key for your public interface from + DNS, it will not keep trying, and you will not be able to do OE. + + The error message is: + + May 14 09:40:24 road Pluto[21210]: failure to fetch key for 193.110.157.18 + from DNS: failure querying DNS for KEY of 18.157.110.193.in-addr.arpa.: + Host name lookup failure + + Workaround: 1 or 2 + 1. Supply a key in the conn. leftrsasigkey=0s... + 2. Fix the KEY lookup failure and try again. + + +* Assertion failure at OE rekey time. Fixed in 2.0pre0. Patch for 1.98b posted + at http://lists.freeswan.org/pipermail/design/2002-August/003347.html + + +* 1.91 to 1.94 have serious problems with %trap and %hold bugs. These bugs, + introduced while coding the support structure for OE, affect both OE and VPN + connections. + + +* OE may not work with reverse delegation (CNAMEs). This problem was once + capable of being a show stopper. + + When relying on Bind versions before 9 for local DNS services, FreeS/WAN + could not follow a well constructed CNAME trail that ended in a TXT or KEY + record. Although OE required both record types, in practise we noticed the + problem with the more common TXT lookups, rather than the rarer KEY lookups. + Bind 9 largely solves the problem, by correctly seeking TXT records in + delegated reverse domains. In addition, OE between two FreeS/WAN 2.02 or + later boxes no longer relies on KEY records. + + Old symptoms: + + When a DNS server queried by Linux FreeS/WAN follows a CNAME, + it seems to forget what record type it is looking for, and it + returns a PTR, despite the fact that another record type was requested. + + Workaround: + + Send your provider KEY and TXT records for direct insertion into the + reverse ZONE files, rather than asking your provider to delegate authority + using CNAME. + + People who own IP blocks, rather than leasing them, may not + experience this problem. If you were assigned IPs more than + five years ago, you may own your IPs. + + |