> On Jan 19, 2017, at 11:47 PM, Valery Smyslov <sva...@gmail.com> wrote: > > 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.
Right, so how about we say that a packet that causes the responder to choose which TCP connection to use must be: - A valid IKE or ESP message that can be successfully decrypted and authenticated - Not a retransmission - Not outside of the ESP replay window - In order for the sequence of message IDs for that SA Does that work to sufficiently be conservative about which packets to trust, while not adding undue complication? Thanks, Tommy > > 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
