Subject: RE: [mobile-ip] MIPv6 IPSEc and s=0

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 9 Jan 2003 10:02:29 -0800

> Greg O'Shea wrote:
> > The authentication/authorization of the HoA appearing in the BU gets
> > looked up in IPSec which is fine - I was thinking of the implicit
> > (derived) HoA' that don't get looked up in IPSec when 
> creating a home
> > binding because IPSec never gets sight of the HoA'.
> 
> Right. I agree with Greg that we do have an issue here.
> 
> > Re Jari's ideas:
> > A) explicitly tests that a given MN owns and is explicitly 
> authorized to
> > use a specific HoA, and simultaneously that IPSec is 
> configured for that
> > HoA (else HoT for that HoA may be compromised on a foreign 
> net). In my
> > experience it is extremely easy to misconfigure IPSec for MIPv6 so
> > personally I would draw confidence from explicitly testing 
> these things
> > when creating each home binding. Others may feel 
> differently. I agree
> > that this would be awful to implement for s=0.
> 
> Sigh, but I guess you are right... we also have an additional
> problem with security associations: it is impossible
> to deduce from reception of a message on SA1 that another message
> on SA2 could be correctly received. That is, if you configured
> the SAs manually, I really don't know if the MN has a key that
> would allow sending a packet that passes the SPD/SADB for HoA'.
> Remember that the SAs are HoA-specific! In IKE, there's no
> problem as we can check whether the same phase 1 identity
> would have been allowed when creating a phase 2 SA for HoA'.
> This ties S=0 to IKE, which I'd very much like to avoid.
> If anyone has a suggestion, let me know.
> 
The problem is there with dynamic keying also. If the IPsec SA is bound
to HoA alone, then packets coming in with HoA' will fail the selector
check. Unless we can bind a single SA with multiple addresses, i don't see
how it works. In the case of manual keying i can still set up multiple SAs
for different HOAs i.e HoA, HoA' and selector check will succeed. It seems to
work for manual keying though setting up these SAs is a real nightmare.

> Conclusion? If the above is right, we got more problems with
> S=0. But I'm trying to fix this anyway.  Here's the suggested
> text:
> 
> When the Single Address Only (S) bit is zero, the home agent
> MUST check that the IPsec and IKE security policies would
> allow the creation of a security assocation for the implied
> home addresses by the same identity that was used when
> creating the security association that carried the Binding
> Update.
> 
> > B) Presumably an empty SPD/SADB would be conflict free...
> > 
> > Please make support for s=0 an optional feature on HA and 
> MN, then I can
> > stop worrying about its consequences.
> 
> Well, we are debating this in the other issue... I guess the main
> objection to that was that if its optional then the MN implementors
> will have to prepare for S=1 case anyway, and will not implement
> S=0 at all => more BUs will be needed. However, perhaps this is
> an unnecessary fear. It is the MNs that care about speedy access
> and small number of packets. If they care about that, they will
> implement S=0 even if the code has to have a fallback for S=1.
> 
> Could this be a compromise?
> 
I still feel that s=0 case does not work well with IPsec.

-mohan

> Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Jan 2003 17:14:16 +0200

> work for manual keying though setting up these SAs is a real nightmare.

Ah yes. You bring up important points. Let me first explain
my idea about the dynamic keying case. The idea was *not* to
use the SAs or their selectors at all. Instead, I'd have the
MIPv6 code ask the IKE module the following question: "Would
you accept the creation of an SA for HoA' if someone named
<identity> requested it?". Here <identity> is the identity
presented in the Phase 1 that was used to create the SA for
carrying the received BU.

This seems to work, but it requires a lot from the API between
IKE and MIPv6.

And then to your point about manual SAs. I noticed that
draft-ietf-ipsec-sctp-04.txt (currently in IESG evaluation)
defines the "list" selector type. Hmm... maybe this could be
the solution for both manual and IKE-based S=0? If the SA
that protects the BU has the selectors to allow for HoA and
Hoa', then the MIPv6 code can verify that the given BU
would have resulted in the use of the *same SA* even if the
home address had been HoA'. The use of such selectors
would also make the manual SA config easier, as there are
less SAs.

What do others think? Greg? Here's suggested text for the
5.1:  "When the Single Address Only (S) bit is zero, the home
agent MUST check that the same security association would
have been used if the Binding Update had been sent using
any of the implied home addresses."

I hate noticing serious issues like this at the last
minute. But what do folks think, would the above and
making S=0 optional for MNs solve this?

Jari

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 10 Jan 2003 17:39:20 +0100

> making S=0 optional for MNs solve this?

It seems like it, even though the SCTP ID_LIST is probably not
in any current IPsec implementation (also, they seem to only
allow IPv4 addresses, how come?). So how much work would it
be to include all the above?

Would it be riskier at this stage than  leaving the
S bit for another spec? I know you've concluded that
since there is strong support for it, by default it
should stay in. I don't agree. It is an optimisation
which is not essential to the base protocol, and it's
creating way too many complications (and huge volumes of
email discussing issues like 202 and 184). I'd argue that
by default (like all non-essential items) it should be out
of the base spec. Folks could work on defining it later on.

This late in the game, though, let's do the simplest, I'm just
wondering if after your recommendations above, Jari, inclusion of
the S bit is still the simplest.

-gabriel

---

From: Francis Dupont <[email-masked]>
Date: Sun, 12 Jan 2003 16:19:24 +0100

=> I strongly agree with Gabriel!

Thanks

[email-masked]