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

From: Wesley Eddy <[email-masked]>
Date: Mon, 2 Jul 2007 14:23:34 -0400

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.

If IPsec SAs for application flows are set up using Home Addresses
through the bi-directional tunnel (when necessary, using BTNS PAD
entries), then they should later be able to move to topologically
correct addresses (via multihoming capabilities of MOBIKE).  Can you
clear up what I'm missing here, and what would be wrong with this?

If it isn't a completely braindead idea (and it may be ... I just don't
see why yet, because your previous criticism didn't make sense), I can
add more detail and compare to the current standard.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 3 Jul 2007 11:19:45 +0200

El 02/07/2007, a las 20:23, Wesley Eddy escribió:

> other topologically-correct address.

not only that, but also that the node is the actual owner of the home  
address (in some sense). I mean, MIPv6 protects against the so called  
time shifted attacks, where the attacker is able to intercept packets  
along the path for a short period and then moves and continue with  
the attack (this is the motivation why the RR check need to be  
performed periodically)

so, in order to provide proper security for RO we need to provide  
some form of address/prefix ownership proof.

>   My understanding is that the
> CNs was seen as impossible;

exactly

> but now BTNS enables SAs to be configured
> without this pre-configuration,

right but doing so, it looses some features and one of such features  
i what is needed for securing RO afaiu

BTNS lacks of any authentication and data origin proof capabilities  
and this is a critical feature for securing RO

it would be possible to add such features adding additional stuff  
(like using CGAs in IKE) but this is certainly not btns and i don't  
think it worth the complexity and probably some nemo RO specific  
security solutions make more sense

> so IPsec should become viable for RO

that there is no address ownership proof in this scheme
btns does not provides that and mobike assumes a competelly different  
scenario. Mobike afaiu, i designed for the roadwarrior case i.e. an  
endpoint with tunnel mode with a security gateway with preshared  
trust, whcih would not apply for the any-to-any nemo RO scenario that  
we are considering here

just for reference, an excellent description of the address ownership  
and time shifted attacks and related RO security background can be  
found in RFC4225 and for btns applicability scenarios see http:// 
www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-applic-05.txt

regards, marcelo

> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <[email-masked]>.
> To unsubscribe, E-mail to: <[email-masked]>
> To switch to the DIGEST mode, E-mail to <[email-masked]>
> To switch to the INDEX mode, E-mail to <[email-masked]>
> Send administrative queries to  <[email-masked]>
>