Re: [Xen-users] Re: Live Migration Config

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Nigel Head wrote:

> On 10/31/05, *Anthony Liguori* <aliguori@xxxxxxxxxx 
> <mailto:aliguori@xxxxxxxxxx>> wrote:
>     [...]  To enable migration from specific
>     addresses, you would then say:
>
>       iptables -I INPUT -p tcp --source 192.168.1.100
>     <http://192.168.1.100> --destination-port
>     8002 -j ACCEPT
>
>
> Or from anyone claiming to have ip address 192.168.1.100 
> <http://192.168.1.100>  ...
Yeah, IP based filtering is only going to help you if

1) you're on a trusted subnet
2) you trust that the router between your subnet and the rest of the 
world is going to prevent spoofing to your subnet
Without IP based filtering, you're additionally assuming:

3) the subnet is not accessible to the outside world

This means you have to have your dom0's configured to be on a physically 
isolated network.
Having a truly secure migration session means that you could do 
migrations over an untrusted subnet.  This is going to have a 
performance impact though.  This scenario also is not going to work out 
of the box in 3.0.
You can get that though with an SSH tunnel.  It should Just Work too.  
It would be interesting to know the performance impact of migrating over 
an SSH tunnel.
Regards,

Anthony Liguori

> I'm quite sure that the best (for my definition of 'best' of course) 
> way to do this is not via firewalling, because of the above spoofing 
> possibilities, but also not by complicating the xen tools themselves. 
> I'd like to come back again to the 'VPN' type solution discussion.
> I know that a full VPN setup is sufficiently complex that I've always 
> been scared away from trying, but I have the feeling that it wouldn't 
> be too terribly difficult to setup some wrapper type functionality so 
> that ssh could be used to build a 'tunnel' to the target machine and 
> connections to the target xfrd could then be made from, and limited 
> to, 127.0.0.1 <http://127.0.0.1> on the target machine. 
>
> While I haven't plunged through the xfrd code to see how a tunnel 
> create/destroy script could be built in I don't imagine it would be 
> too terrible. There is a lot of precedent for using ssh this way 
> ('rsync -e ssh' etc), it is as secure as you are likely to want, and 
> it's easier than trying to add credential support directly into the 
> tools themselves, as well as being more in the *nix spirit of 
> combining what you already have.
> For small setups, this could be done statically using port forwarding 
> (with something like Vtun, if you prefer virtual devices) ... the 
> dynamic variant would only be needed where there are too many systems 
> to build static interconnects from everywhere to everywhere else.
> In security terms, if ssh is compromised on any of my systems they're 
> dead in the water anyway, so using ssh for this wouldn't seem to add 
> any risk that I haven't already accepted.
> I'm going to try this out as soon as my day job leaves me enough time 
> ... which won't be for a while I'm afraid.
>
>
> Now, as this is surely not fresh news to most of you, what is wrong 
> with my definition of 'best' ??
>
> --
> N.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users