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

From: Soliman Hesham <[email-masked]>
Date: Tue, 25 Nov 2003 09:56:27 -0500

Thanks Gab, I'm now comfortable that we're on the 
same page. A couple of comments below.

 > > => 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? 
 > 
 > I gather that by "sender" you mean the "RCoA". 

=> Right, sorry I wasn't clear.

   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.

=> Right. Just to clarify, both are possible but one (LCoA)
address changes and the other (RCoA) doesn't. If we replace
RCoA with HoA and LCoA with CoA the processing of the 
BU's ESP/AH should be identical to MIPv6.

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

=> The paragraph that you're responding to was talking about
the case after the SA is setup and an authenticated BU is
received. So, we are expecting to *find* an SAD entry. Where 
we expect/hope to NOT find an entry is during the IKE 
negotiation itself, which is part of the IKE policy check.

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

=> Right, but the part that says "configured as usual" 
doesn't have to imply manual configuration, right? 
It could refer to a list of addresses, whether they 
are generated from the SAD info/BCEs or manual config is 
not really important, right? For instance you could point
the IKE implementation to a file containing all the currently
assigned RCoAs. How this file is updated is a different issue.

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

=> Exactly.

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

=> Ok, but AFAIK there is no mandate (in IETF standards) 
about how IKE does its policy checks. I mean whether it has 
to look through a list and act upon finding Vs not finding 
certain bits of information is left up to the implementation.
For instance, MIPv6 is silent on the case where the HoA is not
included in the certificate. This case implicitly requires
that IKE checks a list of configured addresses that should 
match the id in the certificate (FQDN, NAI...etc).  
Granted that some implementations may need to be modified
to handle this. This is something that can be added to
the current text.

 > > - When the MAP sees RCoA it will check (this is the IKE
 > > policy check) that the address is not *already* allocated
 > > to *another* MN. 
 > 
 > But how does it know it is the same or another MN? What are 
 > you using as
 > an ID? 

=> There is no need for ids to perform this check. We assumed 
that once an SA is established it will be sufficient for all the 
MN's BUs for that particular RCoA (there is room for 4 billion 
BUs). So the mere fact that an SA already exists is sufficient 
to warrant the assumption that the address is already in use 
and should not be used at this time. It doesn't matter who's 
using it at this stage.

Incidentally, once an SA is established, the MAP will have
known the RCoA <=> "id" association. Where "id" is whatever
id is contained in the MN's certificate. We don't assume
that the IKE neogtiation is based on preconfigured SAs, it
is very likely to be based on public keys/certificates.

   If this same MN asked for another RCoA, then presumably,
 > the fact that it's asking would make it look like another MN,

=> No. In theory the MN could request more than one RCoA in
two separate negotiations, the reverse is what we explicitly 
stop (i.e. more than one MN asking for the same RCoA).

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

=> Ok, sure there can be extra check to prevent that. BTW, 
the MAP would see a certificate since we don't prevent the MN from using 
a certificate. So the MAP can stop this situation from happening, but
I never thought it would be a problem given the current
iid space (i.e. the MAP is unlikely to run out of addresses).
Anyway, we seem to be on the same page now. I can add some
text to explain that some IKE implementations may need
to be modified to handle this policy check. But of course
there are no IKE protocol issues impacted.

Also, I can add text to say that the MAP can have a limit
on the number of RCoAs associated with each MN based
on the RCoA <=> "subject" association that the MAP will
know after the IKE negotiation.

Hesham

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

---

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

>  > But if you *DON'T* find it, then create a proper entry for it

Ok, we're finally on the same page.

> about how IKE does its policy checks.

Hmmm... Doesn't at least
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-00.txt
talk about this?

This runs a fine line between policy check and policy establishment.

<snip>

> that once an SA is established 

But it's not yet created, you're in the process of establishing it
in this step.

Anyway, I see you're ok with adding more text/warnings from the rest of your
msg, so that's ok.

BTW, IESG will give (has given) us grief whenever processing is changed
(not just protocol on the wire) with respect to IPsec. Because of that,
this same scheme may not IMO carry HMIPv6 into PS-hood. But that's ok,
we can worry about that later.

-gabriel

---

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

> we can worry about that later.

Yes, SEND had this problem, which is why it had to change to not use IPsec.
The IPsec processing sequence in most kernels is pretty performance
sensitive because it is done on each packet, and it is tuned very closely to
the firewall like policy handling of the basic design. In the SEND case, it
wasn't the IESG who complained but some vendors who had a look at the
initial design, and the results of two prototype implementations on Linux
and BSD bore out their concerns.

            jak