Address validation take 2

[thomas-fossati]

No description provided.

[martinthomson]

Lots of suggestions. I hope they are helpful.

[martinthomson]

I think that the main thing here is to observe that reordered datagrams don't cause excessive thrashing if datagrams are reordered by the network. That makes this less than a firm requirement and maybe not something that you want to include in the list, but more as supplementary information.

[hannestschofenig]

I am not sure what text changes would be useful here because I don't understand the "thrashing aspect" you talk about here.

[martinthomson]

"Reordered datagrams that are sent prior to a change in a peer address might otherwise cause a valid address change to be reverted. This also limits the ability of an attacker to use replayed datagrams to force a spurious address change, which could result in denial of service, however an attacker might be able to force an address change if they are able to rewrite source addresses or if replayed packets are able to arrive before any original."

?

[boaks]

The main trigger for my comment in issue #69 was the previous definition based on "record sequence number window", which then would turn into "MUST use such a window" in order to prevent such simple kind of attacks.

I therefore wrote that comment, to show, that both solutions may have their justification.

Though you never know, if your under "fire" or if it*s a delay before or after a NAT. Therfore you will never know, what will be the perfect action, to update or not update the address. Neither with the window nor with the newer definition.
My personal preference is therefore the simpler implementation.
An my intention of issue #69 is to prevent this extension from adding a "MUST" to the window approach.

[boaks]

This also limits the ability of an attacker to use replayed datagrams

FMPOV, both solutions, the "window" or "newer" will prevent address updates from replay attacks. In difference to a replay attack, where the record sequence number is used twice (and assume, that the modified datagram is received later), such attack are mitigated by both approaches.

[boaks]

however an attacker might be able to force an address change if they are able to rewrite source addresses

FMPOV, that's mainly the "on-path-adversary", which requires other means, which are out of the scope of this document.

or if replayed packets are able to arrive before any original.

FMPOV, the means against such "lucky attackers" are the same as for the "on-path-adversary".

In my comment in the tls-mailing list

https://mailarchive.ietf.org/arch/msg/tls/8EAYDGU5RqVcH6POHFZg30wcUYE

I expressed,

I would prefer to have the basic advice, to apply some kind of filter against modified replay attacks (either the
DTLS 1.2 Anti-Replay protection, https://tools.ietf.org/html/rfc6347#section-4.1.2.6, or other means, see
proposal #69 ) in the "draft-ietf-tls-dtls-connection-id",
instead of including that to an additional RFC together with the more complex "on-path adversary" scenario.

So again, my preference is to have the simple "filter" definitions "window or newer" both mentioned in this document. Also the comment, that "on-path-adversary" will able to bypass that protection (as "lucky" attacker will also do).
And the discussion and solution for the "advanced on-path-adversary" in a separate document.

[hannestschofenig]

I completely agree with you. We don't want to make this artificially complicated.

[martinthomson]

The changes look good to me.

[martinthomson]

"Reordered datagrams that are sent prior to a change in a peer address might otherwise cause a valid address change to be reverted. This also limits the ability of an attacker to use replayed datagrams to force a spurious address change, which could result in denial of service, however an attacker might be able to force an address change if they are able to rewrite source addresses or if replayed packets are able to arrive before any original."

?

[chris-wood]

This split makes sense to me. Thanks for making the change!