pasi.ero...@nokia.com writes: > 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). > 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. > - Section 5: I don't think treating REDIRECT+"sufficient time period" > as implicit delete is a good idea. RFC 4306 requires sending delete > payloads whenever possible, and if the VPN GW wants to close the > IKE_SA, it could include the Delete payload in the same message as the > REDIRECT notification... I think it said that it can delete it without client sending any packets, but that delete is not implicit, it is explicit, and gateway will then send delete payload to delete the IKE SA. The sufficient time is used when the client has been talking to the gateway for longer already, and has multiple IPsec SAs up and in use. Then when gateway decides to redirect client somewhere else it sends N(REDIRECT) and client acks that. After that client starts recreating existing IKE SA and Child SAs with the new gateway, and after finishing that the client will delete the IKE SA with delete payload. If server runs out of resources before that it can send delete payload even before client finishes its redirection process but as that causes disruption of the flow of packets (if client didn't have time to set up new Child SAs), server should allow some time for that. I agree that the text could be written in more clear way, i.e. explictly say that the "delete the securition association" does mean the normal IKEv2 way, i.e. sending delete payload. > - Section 7: I'm a bit skeptical if this actually works. The rest of > the document certainly does not describe how it would work, and in > many places, assumes the client-gateway case (e.g. Section 6.1 says > REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the > responder can't actually tell the initiator it supports this feature, > etc.) Also, the "what is actually updated by REDIRECT and what is not" > may get even more complex in peer-to-peer case. My personal > preference would be to restrict the scope to client-gateway unless > someone really has the energy needed to specify how the peer-to-peer > case works in detail. Also the current text says "the responder MUST NOT respond to re-direct message from the initiator, if it has already decided to re-direct the initiator." and that is impossible with IKEv2. If node receives some request, it must reply with response, it cannot leave that response out, as if he does that then the IKE SA will be teared down when the other end times out the exchange. I think the original idea was that even when we talk about VPN client and gateway, this could be used as building block for other things too, and even this document uses terms like "VPN client" and "VPN gateway", this could also be used even when the IKE peers are not VPN client/gateway. This includes cases where for example SIP/MobileIP client connects to SIP/MobileIP server using IPsec. I do not think this can be used as generic gateway to gateway redirection mechinism (MOBIKE can be used for that too). I.e. I would simply change the section 7. to contain: ---------------------------------------------------------------------- 7. Use of the Redirect Mechanism between IKEv2 Peers The Re-direct mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers, but this protocol is asymmetric, meaning that only the responder can redirect initiator to some other server. ---------------------------------------------------------------------- And leave everything else out, including changing the protocol so it can be used in both directions. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
