Change default cookie session affinity format

[Tratcher]

Fixes #1980

This also addresses the doc issues for #1981, but some of those should be backported to the release/latest branch.

This adds two new cookie based session affinity policies, 'HashCookie' and 'ArrCookie' that use stable hashes rather than Data Protection, making it easier to deploy across multiple instances without additional configuration or external storage.

• 'HashCookie' uses XxHash64 which is fast and compact. This is the new default policy.
• 'ArrCookie' uses SHA-256 and matches the format IIS's ARR uses, allowing YARP and ARR to be used together in the same environment.

Breaking Change: This is considered a behavioral breaking change because existing session cookies will not be honored on upgrade unless the old 'Cookie' policy is specified in config. The request will be re load balanced and the old cookie will be replaced. This format also makes fewer security guarantees about the protection level of the key data, the destination id. Sensitive data should not be used for destination ids.

[blowdart]

One thing that occurred to me just now is the actual algorithm. As you're not using SHA256 for anything cryptographically related, you may want to consider one the of the non-cryptographic hashes we added a couple of versions ago. This was done so it would be a clear indication the hash wasn't be used for security purposes, and to enable folks to stop getting warnings for old algorithm use like SHA1. While SHA256 is probably not going away anytime soon, using anything from System.IO.Hashing.NonCryptographicHashAlgorithm would head that sort of code review off at the pass, and they'd be faster to generate as well.

[eyalg-msft]

One thing that occurred to me just now is the actual algorithm. As you're not using SHA256 for anything cryptographically related, you may want to consider one the of the non-cryptographic hashes we added a couple of versions ago. This was done so it would be a clear indication the hash wasn't be used for security purposes, and to enable folks to stop getting warnings for old algorithm use like SHA1. While SHA256 is probably not going away anytime soon, using anything from System.IO.Hashing.NonCryptographicHashAlgorithm would head that sort of code review off at the pass, and they'd be faster to generate as well.

The SHA256 is required to be compatible with ARR. This is an important requirement for products migrating from ARR. If we really want, we can allow selecting different algorithm. However, I do suggest keeping it simple, and to keep the ARR backward compatible version the default behavior.

[blowdart]

The SHA256 is required to be compatible with ARR. This is an important requirement for products migrating from ARR. If we really want, we can allow selecting different algorithm. However, I do suggest keeping it simple, and to keep the ARR backward compatible version the default behavior.

Are there really mixed setups where something could hit ARR and Yarp at the same time and you want routing to work the same in both? Or is the concern that a yarp cookie would upset ARR, in which case changing the cookie name is better.

Avoiding unnecessary SDL compliance issues is a huge plus for not using SHA256, and the current, non-SHA approach isn't compatible with ARR either, so using something else puts you in the same incompatible format. The original issue did not talk about wanting strict ARR compatibility. Also using SHA256 doesn't ensure ARR compatibility at all, unless ARR works in the exact same way, hashing the exact same resource identifier, and that seems a fragile thing to base a decision on.

[MihaZupan]

I'm not a fan of this O(n) (I realize we already have a TODO for it in BaseSessionAffinityPolicy)

[eyalg-msft]

The SHA256 is required to be compatible with ARR. This is an important requirement for products migrating from ARR. If we really want, we can allow selecting different algorithm. However, I do suggest keeping it simple, and to keep the ARR backward compatible version the default behavior.

Are there really mixed setups where something could hit ARR and Yarp at the same time and you want routing to work the same in both? Or is the concern that a yarp cookie would upset ARR, in which case changing the cookie name is better.

Avoiding unnecessary SDL compliance issues is a huge plus for not using SHA256, and the current, non-SHA approach isn't compatible with ARR either, so using something else puts you in the same incompatible format. The original issue did not talk about wanting strict ARR compatibility. Also using SHA256 doesn't ensure ARR compatibility at all, unless ARR works in the exact same way, hashing the exact same resource identifier, and that seems a fragile thing to base a decision on.

We had to check ARR code to validate, and we did already validate its working well it in FastFood.

[blowdart]

We had to check ARR code to validate, and we did already validate its working well it in FastFood.

That doesn't answer my question about what you mean by ARR compatible, and why it's needed.

[Tratcher]

Rebased, cleaned up. Still working through the Sha vs Hash discussion offline.

[Tratcher]

Updated plan (see the edited description above): Ship both XxHash64 and SHA-256 implementations, with XxHash64 as the default.

[MihaZupan]

Am I misunderstanding this or is this just plain wrong? If the key is shared by more than 1 destination, we'll pick whichever one we happen to find first.

[Tratcher]

The current policy implementations would pick the first one since we do a linear search, but the abstraction allows us to create keys that are not specific to a single destination. E.g. if you had sets of destinations a-1, a-2, b-1, b-2... you could make a policy that used the key a and returned both a-1 and a-2, then load balancing would choose between them.

[davidfowl]

This is an excellent change!

[davidfowl]

@Tratcher do we need to hardcode the ARR affinity cookie name for it to be compatible? Or should we document that if the name isn't set appropriately, it won't be compatible?

[Tratcher]

@Tratcher Chris Ross FTE do we need to hardcode the ARR affinity cookie name for it to be compatible? Or should we document that if the name isn't set appropriately, it won't be compatible?

That's at least worth documenting, what was the name?

YARP doesn't have a default cookie name for session affinity, it must be specified in config.