Tero Kivinen wrote: > > I have one somewhat substantial concern with the document: it > > needs to be much clearer about what information is updated by the > > received REDIRECT messages, and what is not. > > Never really thought that issue. I myself assumed that both GWs are > identical, i.e. they return same ID, and use same authentication > data (i.e. if PSK, both use same PSK, if certs, both authenticate > against same trust anchor and use same identity in cert, but not > necessarely same private key).
I think that's roughly what I initially assumed, too. In this case, the REDIRECT payload is redirecting the VPN client from one IP address to another, but within the same "responder identity" (not from one responder identity to another) . (Here "responder identity" can be single physical box with several addresses, or multiple physical boxes configured to "look like one" -- the client doesn't have to know which.) > > One possible answer would be that REDIRECT is interpreted just as > > data received from DNS, so all the gateways (redirecting among > > each other) would send same IDr value. > > I think this is the easiest way to make sure redirect is secure. I agree -- and if we settle on this approach, we might want to rename the "New Responder GW Identity" field (in REDIRECT payload) to something like "New Responder Transport Address" -- since the IKE identity is not changed, only the address used for transporting IKE messages. I spent some time in trying to figure out how to specify the other approach (redirect to different "responder identity") securely, but couldn't really come up with anything that would work and be consistent with the RFC 4301 model... so at the very least, taking that approach will mean more work before we're done. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
