> On Jul 2, 2015, at 9:22 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote: > >>> Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5 >>> supercedes or displaces Alices. >> >> Ah, I see the source of my confusion. >> >> I never think of a PAD as a table indexed by IP address. The "key" for >> the PAD is a peer, so in practice it might be indexed by an internal name >> (such as the "conn" labels in the ipsec.conf file in all *swan >> implementation) or it might be indexed by the content of the ID payload >> that we expect that peer to present in IKE. >> >> There is no entry for 192.0.2.5. > > At the end of the day though, IPSEC needs to apply policy to > application traffic presented to the kernel (almost universally) > via the socket API. The socket API gives the kernel a transport > endpoint UDP/192.0.2.5/53, how is the kernel to decide whether to > use Mallory's keys for that same address or Alice’s.
Host to host IPsec is very rare. VPNs are far more common and the packets don’t get there by a socket API. But regardless, let’s assume that the local address is 198.51.100.2. So the quintuple for the connection would be (UDP, 198.51.100.2:704, 192.0.2.5:53) The first thing a kernel does is look up with quintuple in the security policy database (SPD). Much like the PAD, the SPD is static. So if this quintuple is matched in the SPD, we get the tunnel endpoints (which may or may not be the same as the addresses on the packets) from the SPD. In this case we get that the remote endpoint is “alice.example.com”. Mallory’s entries never make it into the (static) SPD. > I think you mentioned that your design locates both the IP address > and the keys from DNS, so if the peers in the PAD database turn > rogue, they might subvert other peers, right? I’ve only configured Alice. If she turns rogue, she can send me to Mallory’s gateway and tell me to expect Mallory’s keys. What good it would do her, I don’t know. > >> I'm suggesting that there should be a static entry in the PAD for >> "alice.example.com". DNS is used to resolve this to an IP address >> and to a public key. Unless mallory can affect "alice.example.com" >> entries, the victim never gets to see his records, because she never >> looks for them. > > mallory.example is another domain in the PAD. Either domain can > return IP addresses that properly belong to someone else. Sure, but that only makes a difference to people looking for mallory. The protected domain of mallory’s IPsec host/gateway is pre-configured. Unless we use route-based VPN, and then we’re as secure as the routing protocol. Yoav _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
