Subject: RE: [Mipshop] 2 more WG LC comments on hmipv6

From: Soliman Hesham <[email-masked]>
Date: Mon, 24 Nov 2003 19:27:47 -0500

> I don't suppose statically configured RCoA's will work. I don't
 > believe they will be useful to *identify* the MN, so I question
 > why one would want to use RCoA as the identity in Phase 2.

=> I see what you mean. The reason is that we want the SAD 
entries to be based on RCoA so that the MN does not 
renegotiate the SA everytime it moves. Exactly the same 
reason that we use the HoA in phase 2 with the HA. 

 > Not advocating any particular identity to be used, nor am I
 > sure that IKE is the only way to do this. I'm just saying that
 > perhaps we shouldn't pretend that we know this will actually
 > work as written in the text and leave that even more tentative
 > than in its present form (basically allowing for future work
 > on MN-MAP security to depart widely from the ha-mn-ipsec
 > scheme if need be).

=> Sure, I was trying to work out if you meant that there is
less certainty that this will work when compared with the 
MN-HA scenario. Basically, protocol-wise, I can't see any difference.
It's ok to allow future mechanisms of course, but at the
same time, we don't want to specify something that might
not work (local implementation issues aside). It's ok to
have a certain level of certainty without being interpreted
as "the only way it will work". 

If another mechanism gets developed later that's fine too.
My main concern is that the current doc specifies something
that works based on the current IKE/IPsec because that's 
what we have right now. I'd prefer if the text doesn't give the 
impression that the specified mechanism might work without
explaining to the reader where it might fail.

Hesham

 > -gabriel

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

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 25 Nov 2003 11:18:04 +0100

Soliman Hesham wrote:
> renegotiate the SA everytime it moves. 

I think of this as tunnel endpoint management. You don't have
to use one of the tunnel endpoint addresses as ID in order to
set up the tunnel to begin with. That's where I see we're forcing
one function onto the other.

> Exactly the same 

I thought it was more ID related... Maybe you have good text
to point out in the current specs. At any rate, I think the
issue is captured here:

  Gab wrote:
  > 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,

  Hesham wrote:
  => The latter is the case in HMIPv6.

and also:

Hesham wrote:
=> I don't think it needs to be statically configured.
If I understand Gab's comment correctly, he's saying
that IKE needs to know about the RCoA that the MN picked
in order to use it in Phase 2. I.e. some exchange of information
locally within the MN (and the same in the MAP to verify that
the RCoA is not already allocated to someone else).

So you say that in HMIPv6 the RCoA is configured at the MAP as tied to a given
SA. How/when does this exchange of information happen? Presumably it would
have to happen *before* phase 2 in order to then *use it* in phase 2,
or am I missing something? In MIPv6 this exchange of information is
handled via some preconfiguration or by inserting the HoA in the
certificate, so when Phase 2 comes along, this info is ready to
be used. But how does one guarantee that it is ready to be used
in HMIPv6 if there is no apriori relationship between the MN and the
RCoA?

This is why I thought that perhaps in HMIPv6 this "phase 2 trick" won't
necessarily apply (i.e. one would finish and establish the IPsec SA
first, then worry about establishing some "binding" or relationship
between the RCoA and this SAD entry, and finally use that in order
to take care of tunnel endpoint management).

I tend to think that this "exchange of information" is an HMIPv6 thing,
e.g., more likely to be done by an LBU + some RR than by an IKE operation
(phase 2 ID exchange, etc).

But frankly, I don't know. If this is known, then the current text
in the security considerations is fine. If it is not, then we need to
tone it down, that's all I'm saying.

> as "the only way it will work". 

Yes, I'm saying that I have less certainty, but maybe it's just
me (and, I guess, also James who's voiced similar concerns).

> what we have right now. 

It's what we have, but does it work in practice for the HMIPv6
case?

> I'd prefer if the text doesn't give the 

Here we agree. So now I'm not sure what it is we've been arguing about.
All I said was: tone down the text, say this may work, but there may
be some problems. I interpret the paragraph above as saying the same
thing. If so, other than producing the actual text to carry this out,
I think we agree. Or?

-gabriel