Hi Tommy, > >> 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
Technically this requirement is wrong, since every ESP packet with SN greater than the highest seen so far will be outside ESP replay window (and will update this window if the packet is decrypted and verified successfully). > - 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? I think that it is enough if this is a valid (one that passed a replay check, then successfully decrypted and authenticated) ESP packet or IKE message that is most recently received. This rule would avoid all complexities concerned with determining the highest SN for many ESP connections over single TCP. In normal cases (no attack) the most recently received ESP packet will always have the highest SN if TCP encapsulation is employed. In case of attack that Tero described the attacker must be on the path and there is no defense against she anyway, so no need to complicate the responder. It is also a good thing to advise, that for TCP encapsulation ESP replay window size should be set to 0 (since TCP doesn't allow reordered packets). Regards, Valery. > 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
