Subject: RE: Revising the Spec (was :Re: [mobile-ip] FMIPv6: Sending FBU from the new link)

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 13 Mar 2003 11:29:47 -0800

> 
> > MN1 can send a binding update for MN2 (they have to be same on
> > the same link to make sure the ingress filtering on care of
> > address check succeeds), which cannot be found until you
> > do the crypto on it. SAD checks come after the IPsec processing.
> > So, i am missing something here.
> >
> 
> OK so there would be an issue if the two MNs shared an HA.
> 
> But wouldn't filtering be done on a random node sending BUs 
> to the HA prior to
> the crypto being done? Any IPsec experts out there care to comment?
> 
When you get an IPsec packet, you first have to lookup the SA. The SPI
and the destination address (and the protocol AH/ESP) is the only thing
that is used to lookup the SA. This is according to the spec. I know
of implementations that use the source address (here home addrress)
to lookup. In that case random nodes can 't send. What does it take
to just send a packet with home address option set to the right
home address ? For this to work, the SPI has to be correct and
the sequence number should be greater than the one sent by the
MN anytime before, for replay check to succeed. I would guess that this is much
easier for an on-link attacker as he can look at what sequence number
was sent before.

> 
> > > the TTL to filter,
> > > which is how RFC 2461 and SEND do it.
> >
> > Either the FBU comes from the wireless link or from the nAR which
> > is protected by an SA (oAR - nAR). Why would this be an issue ?
> >
> 
> The SA is the issue. What is it? How is it set up?
> 
An IPsec SA established at boot up.

> I've been proposing to use the SEND SA and to always signal 
> the current AR, and
> have the current AR take care of making the routing change, 
> passing along some
> kind of mobile authorization token.
> 
I am not in favor of any scheme. Just made some observations/comments.

-mohan

>             jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Mar 2003 11:44:46 -0800

> An IPsec SA established at boot up.

With the AR? How does it get to the next AR on handover? Context transfer (==
dependency on Seamoby)? AAA (= dependency on AAA)? Or is it re-established from
scratch  (== time consuming)?

            jak

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Mar 2003 13:54:10 -0800 (PST)

> scratch  (== time consuming)?

   From scratch outside of the critical path is worth 
   considering. Namely, you do not need to be directly
   adjacent to establish an SA with something. Once the
   SA is established, it may be just a matter of moving
   the tunnel endpoint to the new CoA.

   My personal fave idea:

   1) Allow IPsec tunnels to be used as MIP tunnels
   2) Use MIP to move the tunnel endpoint as normal.

	  Mike

---

From: "James Kempf" <[email-masked]>
Date: Sat, 15 Mar 2003 11:44:32 -0800

>    2) Use MIP to move the tunnel endpoint as normal.

Not sure I understand exactly what you are getting at w.r.t. to the tunnels, but
I've thought a little about prehandover SA establishment and there are a couple
of problems. Maybe I just don't understand enough about IKE to know how to
resolve them.

To establish an SA, I assume the MN would use the PrxyRtAdv to obtain the IP
address of the neighbor router. Then it would contact the neighbor router and do
ISAKMP and IKE. Problem is, the SA is set up to the CoA in the current subnet.
What we really want is an SA tied to a CoA in the neighbor subnet. Since the MN
isn't on the neighbor subnet currently, there's no way for it to conduct the IKE
transaction, at least as far as I understand it. So it looks like a
bootstrapping problem.

Presuming this could be solved somehow, there's still the issue of managing CoAs
on routers in the neighborhood. In the current spec, the PrxyRtAdv is no longer
tied to handover, but there is no protocol for preconfiguring the CoA on the
neighbor subnet prior to handover, which the router would then defend with proxy
ND. Such protocol could be introduced, but then there would need to be protocol
for maintaining the state, unless we were content to just let it expire, since,
being soft state, it will ultimately expire. The assumption here is that
addresss in IPv6 are cheap, that the probability of another MN wanting the
pre-reserved address is low, and that the MN will handover prior to the
prereserved CoA expiring. Any protocol for reserving an address or managing it
would make the overall protocol more complex.

Anyway, one reason I've been advocating using something like SEND is because it
allows the SA to be between any router and the MN, simpilifying the protocol. If
CGAs are used, the MN only needs to get a cert from the neighbor router via the
PrxyRtAdv (and not even that if site certs are used for the routers). If CGAs
aren't used, the MN must send a cert to the neighbor router, either when it
arrives on the new link or before. But doing this requires changing the
signaling, which people don't seem to want to do. We've still got some work to
do on SEND too, so something could come up.

There are similar problems in setting up an SA with a dynamically assigned HA.
Appendix B in the base MIPv6 spec talks about how to do this, but it is very
sketchy and I think the details may be tricky.

            jak

---

From: Michael Thomas <[email-masked]>
Date: Sat, 15 Mar 2003 12:04:12 -0800 (PST)

James Kempf writes:
 > ISAKMP and IKE. 

   Yup.

 > Problem is, the SA is set up to the CoA in the current subnet.

   Correct. This is where the combination of MIP/IPsec would
   be advantageous. If the IP-IP tunnel that MIP uses were
   replaced with an IPsec tunnel, changing the CoA -- ie the
   tunnel endpoint -- would just be a matter of changing the
   binding... which is what MIP does oh-so-nicely. The 
   nice thing about this is that it could be made
   to be completely backward compatible, etc. If
   you support using an IPsec tunnel instead of an
   IP-IP tunnel, you can do this, if you can't
   it's just going to be slower... 

 > would make the overall protocol more complex.
  
   Right.. this strikes me as the general problem
   of discovery. That is, the same problem that
   everybody has, regardless of your strategy to
   make handovers faster once you decide it's time
   to move.

 > do on SEND too, so something could come up.

   I don't understand how SEND helps much in this
   case. An unsecured advertisement would ultimately be
   vetted against an authenticated tunnel establishment, 
   so the worst you'd be getting is a DoS. No chance for
   hijacking. (indeed, it seems that that's a  legitimate 
   mitigation to SEND kind of problem from the 20000' level).

	      Mike