diff options
Diffstat (limited to 'doc/opportunism.known-issues')
| -rw-r--r-- | doc/opportunism.known-issues | 287 |
1 files changed, 0 insertions, 287 deletions
diff --git a/doc/opportunism.known-issues b/doc/opportunism.known-issues deleted file mode 100644 index 90752dee3..000000000 --- a/doc/opportunism.known-issues +++ /dev/null @@ -1,287 +0,0 @@ -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. - - |