On Wed, May 5, 2021, at 15:51, Achim Kraus wrote:
> For me, this requires, that cid is used in both directions. If not, the
> "elicits" doesn't work, or? If both parties are using CID in order to
> signal, that the addresses are changing, my feeling is, this scenario is
> not that common. (Even more, it will have anyway troubles, with or
> without CID.)
Nothing here depends on using a CID, except perhaps to the extent that the
endpoint that observes the "migration" needs to be able to match incoming
records with connection state. If they need a CID for that, then this needs a
CID.
The attacker can ensure that the other endpoint receives all records from the
same address, so whether it uses a CID doesn't matter.
> I see, that in cases, where both sides uses cid and dynamic addresse,
> there maybe that manipulation. But, I can't see the attack. Maybe I
> oversee something. If the "on path attacker" is installed and that
> attacker changes the source of the traffic again in order to attack an
> other victim peer, the probe will again protect the victim's new source
> from being DDoS'ed.
> So, please be more explizit, what the resulting attack would look like?
0. Connection is setup between a victim and its peer on a certain network path.
1. Attacker causes victim to believe it has received (valid) packet from a new
address.
2. Victim probes toward that address.
3. Attacker captures the probe and forwards it to the victim's peer, spoofing
the source address so that it follows the original path (from Step 0).
4. Attacker captures the response to the probe and forwards it to the victim,
spoofing the source address to match the address the attacker chose in Step 1.
5. Victim believes that the connection has migrated and stops sending on the
old path.
If the new address is attacker controlled, the attacker is now on-path. The
attacker can stop forwarding and deny service at its discretion.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
