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

From: Soliman Hesham <[email-masked]>
Date: Mon, 24 Nov 2003 06:32:51 -0500

Thanks for registering this issue. A couple of comments
below. I agree with the recommendation to remove OCoT, but
wanted to add a couple of clarifications.

 > 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. 

=> True, with one exception (more on it below): there is 
no permanence requirements for the RCoA. I.e. there is 
no particular RCoA reserved for each MN because it's not 
used for reachability (unlike the HoA).

   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.

=> Agreed.

 > 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. 

=> Perhaps none of this configuration would be needed if 
the requirement for a _specific_ HoA per MN were removed? 
I mean, if it didn't matter which HoA the MN gets, then
there would be no config requirement, which is the case for
the MN - MAP relationship.

 > 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, 

=> The latter is the case in HMIPv6.

   tunnel endpoint update using the RR discussed
 > (empty informational exchange) is perhaps more likely to happen
 > and would certainly render the OCoT unnecessary.

=> If done within IKE, yes, but IKE does not run every
time the MN changes its address (I hope ;) ). Do you mean
that a single handshake is done in IKE when an address
changes?

 > 
 > So, if MAP-MN security is based on IPsec I believe you're
 > right, we can get rid of OCoT. 

=> Ok, I have no problem with this suggestion.

   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.

=> Ok. Sounds good.

Hesham

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

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 14:34:11 +0100

> used for reachability (unlike the HoA).

Ah, I see our disconnect. I've been assuming that the bootstrapping
problem has to assign a HoA to the MN, thus I don't think there is
much of a "permanence" requirement for it in this case either.
If the MN does not even know its prefix (otherwise it would just
use the existing mechanisms in MIPv6), then I assume there is no
fixed HoA for it either, so no permanence.

...

> the MN - MAP relationship.

and for the bootstrapping situation for MIPv6.

> that a single handshake is done in IKE when an address

the proposal is to simply update the endpoint, no rekeying
is done at all. so yes, lightweight.

Don't think these comments are very relevant to the issue1 (OCoT removal)
itself, so I'll leave them out, but you're welcome to update it of course.

Unless we hear otherwise, seems like we're close to closing this one.

-gabriel