Vijay Devarapalli writes: > The one significant piece of information that the gateway has during the > IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT exchange, > is the identity of the client. Some folks want to redirect the client > based on whatever identity it presents. So if thats they case, the first > IKE_AUTH response would be used for sending the REDIRECT payload. If the > gateway wanted to redirect the client because of load conditions, it > would have done it during the IKE_SA_INIT exchange itself. I don't > expect the EAP exchange or the multiple auth exchange to trigger a > redirect. We can make this explicit if needed.
I tought someone wanted to do some kind of radius lookup to select where client is redirected to and in some cases client might not be sending the ID used for that in the ID payload but might use the EAP identity request/reply (even though RFC4306 3.16 says SHOULD NOT). If it will be enough to only see IDi to do redirect, meaning we can always restrict the REDIRECT to message 4, then it might be even acceptable to make that change. The main reason I was against having REDIRECTS in IKE_AUTHs is that there is so many locations where it can be and testing all possible combinations with all possible authentication methods and other extensions gets very complicated. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
