[Gluster-devel] On Identity, UUIDs, IPs, SSL, authentication/verification and fragility

[Paul Jakma]

Hi,

I'm having issues with Gluster with Peer Rejected states. Adding new 
peers to a cluster pool tends to be pot-luck, and if I have a host that 
others don't like there doesn't seem to be any way to fix it (from 
within gluster).

Debugging, my issues seem to stem from Glusters desire to (implicitly, 
via various lookups for the peerinfo) validate the IP of a connection, 
against the reverse DNS lookup for the hostname, against the forward 
lookup for that hostname, and known hostnames.

I guess this stems from a history of IP-as-authentication-handle in 
Gluster, but it's a bit frustrating as I'm using SSL. All the packets 
were already authenticated - IP/DNS validation is not really adding for 
me security wise (indeed, I don't want any assumption of security by 
IP).

Part of the background here is that I have a network where:

- Hosts may have a number of IPs
   - site-local
   - public
   - different interfaces on different subnets (e.g. using VLANs to
     through L2 switches and give servers presence on multiple subnets,
     while avoiding having to bounce packets in and out of a router; v
     common).
   - service addresses
   - v4
   - v6
     - ephemeral privacy addresses
     - EUI-64
     - stable

- A DNS hostname may list multiple IPs
   - v4 and v6
   - or v6 only
- The PTR for an IP may not list the IP
- There may be no PTR for an IP
- An IP may not be listed in any AAAA/A record

E.g., ephemeral and other addresses need not have DNS records. You 
generally wouldn't want them to have DNS records either.

What I would like to do is make Gluster just accept the SSL identity, 
use that for the UUID binding, and not do any host/IP validation (other 
than checking for self).

One way would be to just use the SSL peer identity as the hostname, and 
store that in the peerinfo, instead of IP or DNS/name-service host. 
Another would be to bolt on SSL identity alongside in the peerinfo, and 
check both.

My inclination would be to just add an option to use SSL identity as the 
canonical hostname, and ignore IPs/name-service hostnames - I just don't 
see any value in validating the latter when you have strong TLS 
authentication in place.

Would such a patch be welcome?

Cause I really need some kind of fix for the current behaviour of 
gluster - it just doesn't work on more complex network setups, esp. 
with v6.

Note: Client mount code seems to have similar issues. Will dig into that 
(it has a workaround), but need to fix the server side first for myself.

regards,
-- 
Paul Jakma | paul at jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
There is no fool to the old fool.
 		-- John Heywood