Re: [MPI]Comments on draft-eddy-nemo-aero-reqs-00.txt

On Sat, Jun 30, 2007 at 11:34:51AM +0200, marcelo bagnulo braun wrote:
> >
> >I understand that the MIPv6 basic RO security isn't IPsec based, but I
> >don't see this as a good reason not to require the NEMO RO to be
> >securable through IPsec.  The MIPv6 RO security wasn't built on IPsec
> >because it was felt that the needed PKI structure didn't exist.  With
> >recent work like BTNS, I believe this concern could be revisited.
> 
> I am not sure BTNS could provide the security required by a nemo ro 
> solution. BAsically BTNS is an unathenticated mode of using IKE/IPSec. 
> The whole point of RO security is proving address/prefix ownership, 
> which is exactly what btns lacks. I mean, btns approach is basically a 
> leap of faith approach, where basically it makes sure that the 
> communication peer remains the same that the one contacted at the 
> begining of the communication. But in nemo RO this is not enough, 
> basically becasue the one that initiated the contact maybe an attakcer 
> trying to hijack a prefix. so, i seriously doubt btns could do the work 
> needed for securing nemo ro....
> 

I don't quite understand what you're trying to say.  RO is for
application flows and the RO security ensures that a node you can talk
to over the HA tunnels is the same node that is claiming to be at some
other topologically-correct address.  My understanding is that the
entire reason IPsec wasn't chosen to secure this is that
pre-configuration of trust anchors or other credentials between MNs and
CNs was seen as impossible; but now BTNS enables SAs to be configured
without this pre-configuration, so IPsec should become viable for RO
security, by my (possibly flawed) reasoning.