On Thu, 17 Aug 2017, Tero Kivinen wrote:
Basically, we are in the case where "Have PPK" is not yet known.
I think the discussion earlier was that we solve this by policy, where
responder is configured BEFORE initiator.
I thought about this a few times, and after some discussions with
myself, I agree that you are right.
I.e., if responder sees
initiator that says PPK is supported (meaning initiator has PPK) then
responder is safe to assume that it has also been configured PPK for
that ID. Anyways if this guess turns out to be wrong, it can then
fail the exchange later, and mark that peer as not having PPK when it
reconnects, i.e., add peer IP-address to temporary list saying that if
connection comes from this IP-address, and says it has supports PPK,
we do not have PPK for it, so fall back to standard IKE.
That is a terrible hack. It will likely not work well with NAT, when
the client mind end up with a new exchange on a different NAT port,
so you cannot tell whether this is 1 client behind NAT or 2 clients
behind NAT. But I see how we can just call this a "misconfiguration"
and I don't mind it not working.
Anyways this kind of text needs to be added to the protocol draft.
Yes.
So I agree with Tero. And I guess our code is already doing this.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
