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

From: Soliman Hesham <[email-masked]>
Date: Tue, 25 Nov 2003 06:47:48 -0500

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

=> I'm not sure I follow, if RCoA is not specified in 
phase 2, how can the MAP lookup the SA when it receives
an authenticated BU ? doesn't it need to look it up
based on the IP address of the sender and other selectors, 
like proto ...etc? 
So if that IP address changes the SA will not be found in
the SAD, i.e. the BU cannot be authenticated. That's
the reason I see for setting up the SA based on the RCoA.

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

=> This information exists after the IKE negotiation is complete
and an SA is established. I think we were talking about different
steps of the SA negotiation. When a MN receives the MAP option
it will:

- Derive an RCoA depending on the MAP prefix and an iid.
- Start IKE neogotiation, using the RCoA in phase 2
- When the MAP sees RCoA it will check (this is the IKE
policy check) that the address is not *already* allocated
to *another* MN. 
- If the address is not allocated to another MN, the SA
is established. 
- The MN will then send a BU to the MAP to set the RCoA -> LCoA
binding. 

 > Presumably it would
 > have to happen *before* phase 2 in order to then *use it* in phase 2,
 > or am I missing something? 

=> I think you're assuming that a specific address is picked 
for each MN. The address itself does not matter. Any address
will do, provided that it's "free", i.e. not allocated to
another MN. This is the *only* condition for allowing a MN
to use an RCoA.

  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. 

=> Exactly, because in MIPv6, it does matter which address
is allocated to the MN, but this is not the case here in HMIPv6.
It's a subtle difference but makes life a lot easier for 
HMIPv6.

   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?

=> I hope I clarified that part above. Basically any address
is ok provided that no one else is using it. Therefore
there is no need for special authorisation to use a particular
address. This is because RCoAs are not stable addresses that MNs
need to use to be reachable, it's just a CoA (effectively).

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

=> Let me know if the above made sense. 

 > > => 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". 
 > 
 > 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).

=> I hope the above clarified our disconnect on this one.

 > 
 > > 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. 
 > 
 > It's what we have, but does it work in practice for the HMIPv6
 > case?

=> I think so. Of course the IKE policy check (to make sure
that no other MN is using the address) needs to be implemented.
But this is what I mean by "local implementation issues". 
For MIPv6, IKE needs to verify an id in the certificate
against some config (in case the HoA is not in the cert). 
In HMIPv6, it needs to verify it against existing SAs/BCEs.
They're extremely similar checks but the data is generated 
differently. That's why I think there is no difference.

 > 
 > > 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.
 > 
 > 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, 
                                               ^^^^^ :) 

=> This is where I was trying to extract more info from you
to understand why you say "may work". I wanted to understand
the conditions under which it does not work so that I can
make that clear in the draft. But it seems to me that we
are making different assumptions above about the utility
of the RCoA. That might be why you think it won't work 
sometimes and why I'm not following the argument. 

I guess what I'm trying to say is that softening the 
text is not a problem, we can do that. But I think there
is a bigger issue here and in a way I'm trying to verify
that our understanding of how HMIPv6 works is correct, we seem
to have a different understanding of the SA setup procedure.

Hesham

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

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 25 Nov 2003 15:23:37 +0100

> based on the IP address of the sender and other selectors, 

I gather that by "sender" you mean the "RCoA". So you're
assuming the policy checks are based on the
the internal IPv6 source address, not the external
true IPv6 source address (LCoA). Both are possible,
but as you say, you'd expect the search to find something.

what you're doing is different (from below), you're doing
the search based on phase 2 "identity" and expecting/hoping
*NOT* to find an entry (for this particular RCoA). This is
what makes me think there's some subtleties and differences
from regular IPsec usage.

So if we don't want to go there, we might have to look
for alternatives, like setting up an IPsec SA as usual
(in a manner unrelated to mobility or HMIP) and then
on a subsequent step have the MAP process the LBU and
effect whatever changes in the corresponding SAD entry
and BCE are appropriate.

> the reason I see for setting up the SA based on the RCoA.

Yes, this would appear to work, it's just the "setting up of
the SA based on the RCoA" that may be a bit tricky.

> - Derive an RCoA depending on the MAP prefix and an iid.

ok.

> - Start IKE neogotiation, using the RCoA in phase 2

Here is where I think we have our source of confusion.
Usual ipsec implementations would expect this ID used in
phase 2 to be present already. You seem to be changing ipsec
processing here. You're not just saying: "here's an ID, go
look in your policy where it must have been configured somehow
previously, and if you do find it I want to use it to authenticate."

This is the usual.

But, what you're saying is: "here's an ID, go look in your policy
and if you do find it, then you *SHOULDN'T* let me use it.
But if you *DON'T* find it, then create a proper entry for it
and then let me use it."

This departs considerably from current IPsec, or so it seems.
If one is going to depart as much then at least a warning about
it sounds like a good idea. And it also justifies thinking about
IKEv2.

By doing this we're  watering down the meaning of an ID.
It's no longer an ID, it doesn't identify the MN. More below.

> policy check) that the address is not *already* allocated

But how does it know it is the same or another MN? What are you using as
an ID? If this same MN asked for another RCoA, then presumably,
the fact that it's asking would make it look like another MN,
and if this RCoA is not yet assigned, then it would now.
If, on the other hand, the MAP saw a real
ID (nai's, email address, fqdn...) and associated cert
material, then this MN would not be able to continue assigning
RCoA's to itself (thus exhausting the MAP, which may not be limited
by the number of possible RCoA's but by the number it is willing
to provide service to).

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Nov 2003 09:08:24 -0800

Hesham,

I think I understand now what you are getting at, but there is still one

> need to use to be reachable, it's just a CoA (effectively).

So what does the MAP use to determine the MN's identity? It has to be
something in the certificate and it has to be something that's in the BU so
it can be validated when the BU arrives. The HoA?

            jak