>>>>> "Paul" == Paul Wouters <p...@cypherpunks.ca> writes:
Paul> But my kernel SPD/SAD can only have one src:dst policy. In the case of
Paul> failure to do IKE, this would be a block to prevent plaintext leaks.
Paul> So if i can trick a client into connecting to paul.example.com, I can
Paul> ensure that user will not be able to talk to www.google.com.
This "attack" and the usage you gave for IPSECKEY is not consistent with
RFC4322.
By the time that IPSECKEY RR was approved, RFC4322 was already approved
(don't be confused by the order of the document numbers...). RFC4322
specifies TXT
RR. An RFC4322-bis that specified IPSECKEY, and IKEv2 was envisioned,
but never compelted.
Paul> Clearly, a lot of this will depend on local policy/implementation that
Paul> is not specified in any RFC. And depending on soft vs hard fail this
Paul> would be a DoS or a downgrade attack.
RFC4322 specifies it.
Section 3.2 discussed "OE-permissive" (fail-to-clear) and "OE-paranoid"
(fail-to-drop) versions. Openswan by default put the 0.0.0.0/0 into
OE-permissive policy bucket, so if IKE failed, then the "%hold" should
get replaced with a %pass.
Paul> The core problem is that anyone can make a claim about someone elses'
Paul> IP address with respect to the public key. We have no way of knowing
"claim", yes, but not enforce.
OE failed initially because of lack of control over reverse, and later,
due to there being no reverse for systems on the NATwork.
Paul> The difference with TLS is that the client has a concept of the
Paul> terminal name it connected to, and has its own src-dst transport,
Paul> whereas for IPsec we only have one src-dst for the entire host.
Agreed.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
pgpMSZmewYg8s.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
