Subject: [Mipshop] [issue1] OCoT should be removed

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 10:37:51 +0000

This has been entered in the issue tracker as issue 1.

owner: gabriel montenegro <[email-masked]>:

category: Technical
draft: draft-ietf-mipshop-hmipv6
priority: Should fix
status: Pending
title: OCoT should be removed

Hesham (and Greg) ask if OCoT is needed (in part justifying a removal on the
fact that such a test does not exist in MIPv6 for the MN-HA BU).

In short, I agree that we should delete this from the draft (textual
changes to be worked out).

More info below in response to Hesham's question on the list:

That's a good question. Yes, as you note this doesn't exist in for the HA
in MIPv6. But this is not quite representative of the much more dynamic
nature of the MN-MAP relationship. So the fact that it was dismissed for
the HA (as also noted by Greg) is not directly applicable, I believe.

As I've alluded to before, I think the MAP-MN security problem is akin
to that of bootstrapping an MSA MIPv6. This, of course, has not been
solved completely (speced). So the question is: if it were, would such
a solution still require something like an OCoT?

The dynamic nature of the MN-MAP relationship means that static manual
configuration along the lines of the ha-mn-ipsec draft is highly unlikely.
So I believe we can conclude that MN-MAP SA setup implies use of dynamic keying
Even here, dynamic keying according to	ha-mn-ipsec is perhaps not a good fit
given the onerous configuration requirements for this to work. Dynamic
keying along the lines of the SSH proposal (see "IPSec and Mobile IPv6
using SSH QuickSec Toolkit" in
http://users.piuha.net/jarkko/publications/mipv6/issues/issue319.txt)
may be a better fit for bootstrapping mobile SA's. At this point though,
we might as well think about using IKEv2.

Presumably, doing that will involve a dialog (e.g., EAP over IKEv2 or
some such) which will involve at least one exchange from which liveness
can be inferred. So initial MSA setup between MN-MAP will most likely
not require extra OCoT checking.

Beyond initial MSA setup, changing endpoint from LCoA1 to LCoA2
(retaining the same MAP), would also imply a liveness check
via the MOBIKE proposed IKEv2 endpoint update mechanism referred to in:

http://mobike.kivinen.iki.fi/protocol/img4.html

Current thinking is that this return routability won't be
needed if the MN address is in the certificate, or if manual
configuration assures such mapping. As applied to HMIPv6, this
means that either the RCoA would be in the certificate or
configured at the MAP as tied to a given SA. Although this is
possible, tunnel endpoint update using the RR discussed
(empty informational exchange) is perhaps more likely to happen
and would certainly render the OCoT unnecessary.

So, if MAP-MN security is based on IPsec I believe you're
right, we can get rid of OCoT. Even if it doesn't, it seems quite
likely that even though liveness checks will always be required,
OCoT by itself is not enough, and a more complete check will have to
be used. At that time, we can specify a better thought out OCoT 
superset if need be, instead of saddling the protocol now with something
of dubious value.
_____________________________________________________
Mipshop issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mipshop/issue1>
_____________________________________________________

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop