Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Tunnel Name Generation Logic To Not Include Potential for Hash Collision #1748

Open
aauren opened this issue Oct 8, 2024 · 0 comments
Open
Labels
bug override-stale Don't allow automatic management of stale issues / PRs

Comments

@aauren
Copy link
Collaborator

aauren commented Oct 8, 2024

What happened?

Related to: #1745 (comment), the current code looks like:

func GenerateTunnelName(nodeIP string) string {
	// remove dots from an IPv4 address
	strippedIP := strings.ReplaceAll(nodeIP, ".", "")
	// remove colons from an IPv6 address
	strippedIP = strings.ReplaceAll(strippedIP, ":", "")

	h := sha256.New()
	h.Write([]byte(strippedIP))
	sum := h.Sum(nil)

	return "tun-" + fmt.Sprintf("%x", sum)[0:11]
}

@twz123 points out: This would mean that "21.3.0.4" hashes to the same tunnel as "2.13.0.4". Is that something that kube-router should care about?

Wouldn't it be more straight forward to operate on the IP address bytes, instead of their string representation? E.g. like this:

func GenerateTunnelName(nodeIP net.IP) string {
	if v4 := nodeIP.To4(); v4 != nil {
		return fmt.Sprintf("tun-%x", []byte(v4))
	}

	hash := sha256.Sum256(nodeIP)
	return fmt.Sprintf("tun-%x", hash[:6])[:15]
}

The four bytes of an IPv4 address can be losslessly converted to an eight byte hex string. The 16 bytes of an IPv6 address need to be hashed, as before.

The tunnel names for IPv4 addresses will be shorter, and can be easily converted back to the original IP address. Not sure if that's an undesirable side effect. If yes, the four IPv4 bytes could be hashed, as before, although I suppose that this is not a problem at all?

What did you expect to happen?

Tunnel name generation should not have the potential to lead to a hash collision that could cause tunnels to not be created properly for IP addresses that are the same numerically in different parts of the octet.

Additional context

We currently rely on tunnel name generation being predictable in order to clean up old tunnels. This means that we would either need to implement fall-back logic for matching tunnels for a set of releases, or we would need to couple this change to a release where we advise cluster administrators to do a rolling reboot in conjunction with the kube-router rollout (advice that is usually either missed, or pushed back against by community members).

@aauren aauren added the bug label Oct 8, 2024
@aauren aauren added the override-stale Don't allow automatic management of stale issues / PRs label Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug override-stale Don't allow automatic management of stale issues / PRs
Projects
None yet
Development

No branches or pull requests

1 participant