Hi Tero,
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Monday, May 30, 2022 10:26 PM
> To: Valery Smyslov
> Cc: 'Christian Huitema'; sec...@ietf.org;
> draft-ietf-ipsecme-rfc8229bis....@ietf.org; ipsec@ietf.org; last-
> c...@ietf.org
> Subject: RE: Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06
>
> Valery Smyslov writes:
> > If the TCP connection is abandoned (for any reason) and the
> > associated IKE SA is still up, then the IKE initiator will re-create
> > it. So, it is not a big deal, but definitely can influence
> > performance. On the other hand, an attacker who is able to alter the
> > packets on the wire (TCP, UDP, any) can make IKE peers to tear down
> > IKE SA (e.g. by spoiling every packet). So, I'm not sure using TCP
> > gives significant advantages for an attacker here, in most cases it
> > will result in DoS.
>
> Actually just messing up any length octets on the wire will completely
> mess up the packet structure, as there is no way of recovering that
> except to tear down the TCP and start over, so this makes it easier to
> attack than to attack against UDP.
Agree, that's what is in the suggested text:
o if an attacker alters the content of the Length field that
separates packets, then the receiver will incorrectly identify the
margins of the following packets and will drop all of them or even
tear down the TCP connection if the content of the Length field
happens to be 0 or 1 (see Section 3)
> For udp you would need to modify every single udp packet to cause them
> to fail to authenticate. For tcp, you need to take single TCP packet,
> and modify length bytes (for example simply flip one bit there), and
> that will mess up the whole stream and most likely tear down the whole
> IKE SA.
>
> I.e., if you change the length bytes of 100 byte IKE packet to 200
> bytes, then receiver will keep waiting until it has 100 extra bytes
> after the IKE packet (from the next IKE or ESP packet in tcp tunnel),
> and then try to parse the IKE packet and notices it is only 100 bytes
> long (the authentication of the IKE packet will succeed, as it was not
> modified, and the IKE packet has length inside, so it will know that
> IKE packet was only 100 bytes long).
>
> Now after that it will read two random bytes from the stream, and
> assume they are then length field, and wait for that long and so on.
> I.e., it will never really recover (except by accident).
>
> Receiver can notice that, i.e., if it sees that there is extra data
> after the IKE SA packet, or the length field of the TCP stream is less
> than what is expected by the IKE packet, it knows something is wrong,
> and can restart the TCP connection.
>
> Detecting this on ESP packets is harder, but if the packets after the
> length field does not look like ESP packet, then we know that
> something is messed up and we need to restart the TCP stream.
>
> And as others already pointed out, it is very easy to just send few
> bytes in to the TCP stream, or just modify one frame by modifying the
> length fields.
>
> I think we need to add text explaining how to detect when the TCP
> length framing gets messed up by attacks, and how to recover (i.e.,
> close down the TCP channel and recreate the TCP channel).
I'm not sure we must go so far and this complication is really needed. Let us
make a distinction between on-the-path attackers and off-the-path ones.
On-the-path attackers who are able to read, modify and inject (or even drop)
packets
can do a lot of bad things and modifying specifically the length
field is not the easiest way to disrupt communication between peers.
On contrast, it's quite a hard task for the off-the-path attacker, who
cannot read the TCP stream, to modify exactly those two bytes in the stream
where
the Length sits. So, most probably a larger part of the stream will be
corrupted,
that will cause some packets drop, and, in case these are IKE packets,
most probably the IKE SA will be teared down by the peers (due to timeout).
Moreover, from my reading of RFC 5961, in many cases the result
of data injection attack will be that RST will be sent by one of the peers
(due to ACK war).
So, I'm not sure we should advise implementers to complicate their code for
this specific case,
because the final result will be the same. I think that it is enough if we
mention
the possibility of this event (as in the suggested text).
Regards,
Valery.
> --
> kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
