HI Tero, > Actually Valery did raise good point, that for IKE this might cause > issues. > > Now when I am thinking about this, I think that for IKE packets the > response to the IKE request should go to the same TCP session where > the request came in. This would be aligned with the RFC7296 which says > you reverse ip-addresses and ports for incoming IKE request, and reply > to that address.
That makes sense. > For new requests the IKE should use the same TCP session than what is > being used for ESP, i.e., the most fresh one. > > The most fresh should then be defined as the one which has received > ESP sequence number which is not out of order (note, that there might > be multipe ESP SAs in the same TCP connection, so largest sequence > number is not right way to express this), or which has received new > IKE request (note, not IKE respose, or retrasmitted request) last. It doesn't really help to prevent attack, but unnecessary complicates implementations. I'd rather suggest to choose the TCP connection over which the latest valid ESP or IKE packet (that is not a retransmission) is received. In most cases this is equivalent to the rules you suggests (since TCP prevents reordering the latest packet will have the highest SN/MID). In case of powerful attacker on the path, who can steal, drop, modify and replay packets, the rules you suggest won't help anyway. Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
