[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: opportunistic encryption deployment problems
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Wes" == Wes Hardaker <wes@hardakers.net> writes:
Wes> 1) your method of obtaining information is by reverse DNS lookup,
Wes> which will provide problems with people who can't control their
Wes> reverse DNS bindings. As an example, I don't have control over the
Wes> subnet mapped to my house and can not insert information into the
Wes> controlling DNS server (and can not convince them to redirect to
Wes> me).
Yes, this is a well known unresolved issue.
We may eventually have some proposals to make on this.
Note that this does not impact your ability to *initiate* opportunistic
encryption even if you do not control your reverse map. section 7.3 of the
draft says:
7.3 Use of FQDN IDs
Unfortunately, not every administrator has control over the contents
of the reverse-map. The only case where we can work around this is
where the initiator (SG-A) has no suitable reverse map. In this
case, the authorization record present in the reverse map of Alice
may refer to a FQDN instead of an IP address.
In this case, the client's TXT record gives the fully qualified
domain name (FQDN) in place of its security gateway's IP address.
The initiator should use the ID_FQDN ID-payload in phase 1. A
forward lookup for a KEY record on the FQDN must yield the
initiator's public key.
This method can also be used when the external address of SG-A is
dynamic.
Note that the client's reverse map must still exist.
[Perhaps not said here is that if Alice == SG-A, i.e. an end-node. I will
clear this text up]
Wes> 2) your method of obtaining information is by reverse DNS lookup,
Wes> which will provide problems with people behind NATs. Until IPv6
Section 8 deals with NATs.
Section 8.1 points out that if the NAT is colocated with SG-A, then the
packets appear to come from SG-A, and in fact SG-A is just acting as an
end-node. This is a common situation for people who have their single IP
address ADSL and a Linux box doing "masquerading".
This does not permit *incoming* connections to nodes behind SG-A/NAT-A, but
NAT already has this problem. Whether or not one can do OE *to* SG-A (say, to
the resident web server or smtp server) depends on whether or not SG-A can
control its reverse map.
Section 8.2 says that if you are behind a NAT (such as all the ADSL "Vibe"
customers of NBtel are), then you are screwed for IPsec anyway. If you do get
IPsec through, you likely can only do it outgoing, so you can again initiate
with FQDNs only.
Wes> (if) widely deployed, this will continue to be a growing problem.
Wes> Sure, if you can convince your NAT provider to do encryption to
Based number of installations (rather than number of people screwed by
NAT), I think that the majority of people are behind NAT boxes that they
(or their organization) owns. Maybe someone has a better statistic. This is
self-inflicted pain.
Wes> 3) The wider and wider spread use of things like web and other proxies
Wes> will provide similar problems seen in #2.
Why?
Once the packets are encrypted, they can not be determined to be port 80 or
whatever and redirected or played with. Perhaps this will result in poorer
performance, but one could certainly exempt port 80 packets from OE with an
appropriate SPD entry.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO3/1PoqHRg3pndX9AQEYbgQAykXN/H96ysAm/w414G5qtLUlbLcRlhlM
ZKxswtx2d21o0tXK7BfT+UrRx+htGKYGmRFuzyVU0NcVShY6oeyB73ht5Ll41OH9
b3KuJw48tT8C9Z0HQq6fkPf8nDFSSblP2NtPliGB5l0pzOKf4hd5JXsFyfOIDBps
J6JKpsiQ6w0=
=F+bX
-----END PGP SIGNATURE-----
Follow-Ups:
References: