288 lines
11 KiB
Plaintext
288 lines
11 KiB
Plaintext
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.
|
|
|
|
|