Valery Smyslov writes: > > This should be happening anyways, as there will not be reordering happening > > inside the TCP connection, so this will not cause issues for normal > > cases. > > > > Same for the IKE SA, i.e. the message-id must be larger than anything > > seen before, not just something that is in the window. > > Isn't it easier to add a requirement that the received message must > not be a replay? For example: > > It should choose the TCP > connection on which it last received a valid and decryptable IKE or > ESP message that is not recognized as a replay of some early message.
No. Not replay == ESP packet we have not seen before that is still in window != ESP packet which has largest sequence number. I.e., attacker sends RST to the tcp connection, initiator recreates TCP session, and initiator sends one ESP packet to the TCP connection having sequence number of 0x1000. Attacker messes up with the TCP connection so that responder never sees the ESP 0x1000 packet, and TCP connection is reset. For example sends RST before the actual packet reaches the responder, but after the attacker has seen the contents of the packet in TCP stream. Initiator then recreates tcp session with responder and sends some ESP traffic with sequence numbers of 0x1001-0x1005. Attacker kills that TCP connection, creates completely new TCP session and replays the old ESP message with sequence number of 0x1000 (which was not seen by the server before). Responder will accept this as valid non replayed ESP packet, and will move all traffic to this new TCP connection. The attack is not very efficient, and there are most likely easier ways to do similar attacks, but there might be some other tricks people might invent if we leave this thing open. Thats why I think it is better to close it by saying that it is not enough to have valid ESP packet which is not replay, but it must be valid ESP packet which have sequence number that is higher than anything seen before. One way of implementing that is to configure ESP replay window size to be 1... > > So I would say MUST accept packets with fragmentation from TCP if > > fragmentation is supported and enabled. SHOULD NOT fragment packets if > > sending them to the TCP connection. > > I agree with your comment here, however I can see a reason for MAY - > some implementations may have a single configuration knob, that > triggers between "always fragment" and "never fragment". > These implementations may choose to always fragment > (if the knob is on) regardless of the used transport just for simplicity. So we are allowing this kind of stupid things because there might be some implementation that will implement this new protocol and which does not want to fix their own broken implementation about fragmentation? I assume they do not really care about the fragment sizes, and will fragment everything to 100 byte fragments, just because of simplicity? Again SHOULD will not prevent that, and MUST accept will allow them to work... Hmm.. and the responder SHOULD respond with fragments too if I read RFC7383 right... On the other hand sending fragments to the TCP connection is already against SHOULD NOT in the RFC7383 which says that "IKE fragmentation SHOULD NOT be used in cases where IP-layer fragmentation of both the request and response messages is unlikely."... So I think SHOULD NOT fragment is correct here, as it is directly derived from the RFC7383... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
